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(_at_)alvestrand(_dot_)no]
Sent: Thu 14/02/2008 1:06 PM
To: Hallam-Baker, Phillip; Dan York; Jonathan Rosenberg
Cc: Joel M. Halpern; ietf(_at_)ietf(_dot_)org
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(_at_)verisign(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
http://www.ietf.org/mailman/listinfo/ietf