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 mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf