From: John C Klensin [mailto:john-ietf(_at_)jck(_dot_)com]
It was not clear from the context of the argument what was
being referred to. Seemed more likely that they were imaging
something involving more parties than bilateral. It was one of
those 'well people only disagree with me because they are
ignorant of an area that I will specify so vaguely a to make
it impossible to refute the claim' type shots.
Then why did you initiate this conversation thread rather than
not wasting your/our time on it?
Because the obvious confusion in this area might be the result of the problem
being very hard rather than other explanations. Because when there is obvious
confusion the source of the dispute might be the confusion rather than an
actual difference of opinion as to facts or desirable outcomes.
Because any topic that is worth devoting an IETF plenary to and the attention
of the IAB, is also worth the attention of the IETF list.
One of the limitations of TCP/IP for apps developers is that
it requires applications to merge control and data into a
single channel. A better applications interface would allow
these to be separated (c.f. DIME, BEEP etc) so you have a data
channel paired with a (possibly lossy, possibly
unidirectional) data channel.
That is an interesting comment given how recently people were
denouncing the one major application that separates control and
data channels as hopelessly outdated and generally hopeless.
FTP tries to do the right thing, but does so in a manner that makes a number of
assumptions that are increasingly not true. In particular it assumes that if A
can read B then B can reach A.
I take this as a sign that the protocol is inadequately abstracted from the
transport. We need to have control/data separation within a single IP/Port
connection bundle. The network middlebox infrastructure needs to know that the
two channels are interdependent. Nor is it a necessary assumption, there is no
reason that the data channel should be opened in the opposite direction (in
fact it isn't on many modern systems). So we end up relying on the weaker
assumption that if A can reach B on IP port X, then A can reach B on IP port Y.
But even that is unnecessary, it could be reduced to A can reach B on IP port
X, then A can reach B on IP port X without loss of functionality.
FTP uses the control/data separation to do a number of interesting things, like
allowing A to open up a data transfer between two remote points B and C. But it
is also entirely embedded in obsolete modes of interaction. The FTP control
channel is conceived as a human/machine connection, which is why it is layered
over Telnet according to the spec.
If we are going to be serious about multi-media transport and use multicast
effectively I want to be able to do things like:
Alice decides to watch the superbowl, she turns on the TV and selects the
channel multicasting the superbowl.
* A multicast session is set up to obtain packets in realtime from the
broadcast source
Alice presses pause
* Local application buffers data
Alice switches off TV
* Multicast session is shut down
Bob comes over to watch with Alice, Alice starts TV and tells it to resume from
the point she left off.
* Unicast session is set up to local storage
Alice and Bob skip the game to watch the ads (its the superbowl), they skip
forward to live
* Application switches to using the live feed.
Now currently the protocol abstractions for managing a unicast and a multicast
session are very different and coding this type of scheme would essentially
require the programmer to develop an abstraction that allows unicast and
multicast streams to be used interchangeably.
We actually have a window of opportunity here. XML is increasingly used for the
control channel and uncompressed XML really isn't very satisfactory as a data
transport for motion video.
You are moving off into what I believe to be an entirely
different issue -- your theories about resource location in
network designs-- and that is one on which I have no desire to
comment.
Only you just did.
My entire point, from start to finish was the need to have a clear view of the
Internet architecture that takes into account that the 2008 Internet is not the
1980 Internet. We have learned much since, we use the net in different ways
since. We cannot roll back Layers 1 through 6 to their pristine state in 1980
when nobody completely understood what they were going to be used for. But what
we can do is to adapt layer 6 so that Layer 7 can act as if Layers 1-6 were
pristine. And that is in fact the purpose of a layer model.
At the plenary I raised the topic of encapsulation. What is the encapsulation
for the IETF? What are the interfaces that it needs to expose to the outside
world?
* It needs to interface to the people developing the layer 2 transport
* It needs to interface to the people developing applications outside the
IETF
* It needs to tell layer 3-6 implementors what they need to do for
interoperability
At the moment there is a piecemeal approach. And I think that hurts IPv6
deployment. There is no Gestalt. I think that is what we need which is why I am
trying to get the IETF list to continue this discussion.
.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf