[p2p-hackers] UDP file transfer protocol peer review

[Matthew Kaufman]

David Barrett:
> Thus if the link speed does in fact remain constant and I'm 
> not competing with anyone else, by design it should 
> monotonoically increase with the link speed as a sort of 
> asymptote.  (Though I'm reconsidering this in light of our 
> discussion about competing more aggressively than TCP.)
> 
> But, if the link speed changes or competition increases, then 
> it'll back off first a little, and then a lot, and eventually 
> restart over from scratch.

Your "thought experiment" here is flawed.

The first case ("link speed constant, not competing with anyone else")
*never* occurs in the real world. Your packets are *always* competing with
other flows, in the output queue from your machine, LAN card drivers or
hardware, maybe in a LAN switch, each router and switch encountered on the
way, the drivers and stack on the receiving end. Always. And because the
speed of light isn't infinite, there is always a non-zero RTT. And because
of that, even with ack-every-packet, your information about the current link
state is always out of date.

All you can do is play fair with TCP when you and TCP both encounter
approximately the same loss and RTT. If you try to ramp speed more smoothly
with averaging math, or you get your feedback less often and so can't react
as quickly, you have to do it more aggressively to make up for the times
when you're sending faster than TCP is. But likewise, when another source of
congestion goes away, you want to ramp up as fast as (but no faster than)
TCP would, on average. Since congestion is always changing, you need to be
prepared to reduce or increase your rate all the time.

Then, once you've got that all right, go look at the problems with TCP
itself on large delay*bandwidth connections with low but nonzero loss during
startup, and solve that problem in a way that is compatible with the
extentions to TCP which try to solve the same problem.

Matthew