[p2p-hackers] UDP file transfer protocol peer review

Matthew Kaufman matthew at matthew.at
Mon Jul 25 20:26:45 UTC 2005


David Barrett:
> Am I understanding you correctly that even though UDP is unreliable,
> 801.11 still does retransmission under some circumstances, 
> and when it does it introduces a 1-2 second delay? 

Even if the delay isn't that long, the way 802.11 handles automatic speed
adjustment when the signal level is low can create large delay variance
("jitter")
 
> Does this 
> delay only affect the packet being retransmitted, or does it 
> affect it and all subsequent packets in the UDP flow?  In all 
> connections?

Typically you find that everything sent during a
retransmit-due-to-respeed/loss gets buffered and sent later.

> Yes, no kidding.  Have you tried using any congestion control 
> technique that doesn't rely upon packet loss as an indicator? 

First problem with this theory is that you have to interoperate with TCP,
which *does* rely upon packet loss as an indicator.

The only real improvement to be had in this area is Explicit Congestion
Notification, which isn't deployed widely enough to be useful.

>  I'm still reading through the "TCP-Friendly" congestion 
> control profile for DCCP that Wes recommended a while back.  
> My understanding is it's "equation based" (as opposed to 
> packet-loss triggered?) but I haven't read far enough to know 
> what that means, though.

We've played with various equation-based schemes here. Almost all of them
are designed to "smooth" the response to congestion, or to provide for
congestion control with less frequent feedback than ack-every or
ack-every-other as most TCP implementations do. As I've pointed out before,
in order to be fair with a smoothed response, you must compensate properly
for those times when, because of the smoothing, you're sending more than TCP
would at that instant, by sending less later. And, much more important, and
as I've also pointed out before, doing congestion control properly requires
instantaneous feedback, or at the very least, feedback one RTT later than
instantaneous. If you try to do equation-based but only give it loss data,
say, every second, or every 10 seconds, what you'll find is that the loss
data is *so* out of date that the response is totally decoupled from how
real TCP would work.

Matthew




More information about the P2p-hackers mailing list