From: Lars Eggert [mailto:lars.eggert@xxxxxxxxx]
Sent: Fri 15/02/2008 10:53 AM
To: Hallam-Baker, Phillip
Cc: Dan York; Jonathan Rosenberg; Harald Tveit Alvestrand; Joel M. Halpern; ietf@xxxxxxxx
Subject: Re: Do you want the protocol DEPLOYED or not? Re: I-DAction:draft-rosenberg-internet-waist-hourglass-00.txt]
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