RE: Do you want the protocol DEPLOYED or not? Re: I-DAction:draft-rosenberg-internet-waist-hourglass-00.txt]

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: RE: Do you want the protocol DEPLOYED or not? Re: I-DAction:draft-rosenberg-internet-waist-hourglass-00.txt]

OK, yes that will lag for the first few packets after a change in transmission rate but quickly converge on my proposal. The rate of convergence will depend on the adaptation algorithm.

 

Since my lossy TCP is essentially congruent to what folk are trying to get out of UDP here it appears that the problem is due to the sockets layer not exposing sufficient information to the application layer. We can fix this at the sender end point.

 

We don't need a new protocol, all we need to do is to accept the fact that some parts of the Internet as deployed are easier to change than others and build a deployment strategy accordingly.

---

From: Harald Tveit Alvestrand [mailto:harald@xxxxxxxxxxxxx]
Sent: Thu 14/02/2008 1:06 PM
To: Hallam-Baker, Phillip; Dan York; Jonathan Rosenberg
Cc: 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]

--On 14. februar 2008 08:38 -0800 "Hallam-Baker, Phillip"
<pbaker@xxxxxxxxxxxx> wrote:

>
> As with most protocol design issues, this is a problem that becomes much
> easier to deal with if there is a frank and realistic understanding of
> the real world constraints.
>
> While UDP or TCP are acceptable for virtually all protocol needs there
> are many protocols for which they are not optimal.
>
>
> 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.
>
>
> 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, alternatively we can
> eliminate the assumption that unacknowledged packets are going to be
> retransmitted. That might well be the better approach.

Many years ago I implemented an even simpler approach to "lossy TCP":

When sending a packet (most higher level protocols have packets), check how
full the sending buffer (which retains a copy of all unacknowledged data)
is; if it's "rather full", and the packet is "not important", throw it away.

Worked like a charm. And no redefinitions of TCP semantics required at all.

                     Harald

_______________________________________________

Ietf@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf