ietf
[Top] [All Lists]

IAB plenary discussion: Was RE: Applications assume bilateral connections?

2008-12-04 10:38:15
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
<Prev in Thread] Current Thread [Next in Thread>