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