Hi, On 2008-2-14, at 18:38, ext Hallam-Baker, Phillip wrote: > In particular there are many cases where you would like to establish a > 'lossy TCP connection'. That is you want the flow &ct. advantages that > you get from establishing a control channel session while accepting > the > fact that in a real time connection you may well want to start > dropping > packets that are arriving too late. you're not the first one to have that idea. Which is why there is DCCP. And you're going to say that that doesn't work because it uses a different protocol number, but if you are going to reuse protocol 6 for "lossy" TCP, you are going to need a flag somewhere that lets a receiver differentiate between standard and "lossy" TCP. What you're proposing is DCCP with that flag somewhere other than the protocol number, or any other field that NATs have assumptions about. > I think this can be done end-to-end in a manner that is entirely > backwards compatible. All we have to do (people are going to hate > this) > is to eliminate the traditional assumption in TCP that a retransmitted > packet is going to be the same as the original, There is no such assumption in TCP. A hole in the sequence number space can be filled through any combination of retransmissions. > alternatively we can > eliminate the assumption that unacknowledged packets are going to be > retransmitted. That might well be the better approach. And that's what DCCP does. > A high level abstraction for a lossy connection will inevitably > involve > additional overhead and additional programmer complexity. There has to > be a mechanism to allow the application layer. There is a piece of this sentence missing, but anyhow, DCCP has realized this and is working on a "user guide" that would tell app implementers about how to use the protocol. > The approach that comes to mind is to identify communication 'frames' > that are to be either transmitted in their entirety or lost. The high > level applications at the sending and receiving side need to know > which > frames are transmitted, which are being lost and some indicator to > show > if the delivery rate could be stepped up. You might want to read RFC4340. > Lossy TCP should not be a problem for the Internet core since there is > never a guarantee that packets travel on the same path. There might > be a > stateful inspection firewall that checks TCP sequence numbers but the > more usual concern is to control session initiation and teardown. Few things are a problem for the core, but there's a ton of middleboxes at the edge that have assumptions about what TCP should look and act like. Things aren't as simple as using protocol number 6 with something that sort of looks like a TCP header. Lars _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf