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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Title: RE: Applications assume bilateral connections?
From: John C Klensin [mailto:john-ietf@xxxxxxx]
>> 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?

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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]