[p2p-hackers] UDP file transfer link speed identification

[David Barrett]

Greg Bildson wrote:
> I used a totally undocumented (as of yet) approach in our UDP based 
> firewall-to-firewall transfer code.  One of the main reasons it is 
> undocumented is that a lot of it is essentially a trial and error
> based hack.  However, I think a couple parts of it are interesting in
> the general sense.

That's cool; I think Limewire has pretty well demonstrated its ability
to transfer files. :)


> There are three basic things going on to determine our data rate:
> 
> 1) We try to achieve 2% to 3% UDP failure rate.  So, if you don't
> have enough failures then speed up the sending rate in small
> increments.

This is a novel approach.  I hadn't considered intentionally targeting a
certain packet loss; I was approaching it from a more cautious angle of 
finding the maximum throughput that creates no packet loss.


> In reality, we decrease the wait time between data packets and
> actually start making some multiple of wait times zero before a real
> wait occurs. The zero wait times is just a way of dealing with the
> fact that our current data message size is small (500 bytes) and
> fixed at the moment.

Could you restate this in another way?  I didn't quite get what you were
trying to say; I don't see how wait time is related to message size.

Incidentally, why are your data packets so small?


> 2) We try to coexist nicely with TCP.  If your round trip times goes
> up above some factor of the baseline average, back off a little.

That's interesting that you monitor not only packet loss, but RTT.  TCP
makes no mention of monitoring latency.  However, you're also operating
more aggressively than TCP, so perhaps it doesn't need to.


> What you will notice if you run an algorithm that continues to 
> increase in aggression is that the round trip times will start to go
> up when you are crowding out TCP.

This is an excellent real world lesson; thanks for sharing it.


> 3) Apply standard exponential backoff rules.

*Definitely.*


> If I did it over again, I would definitely just follow the rule book
> of TCP congestion control or some other good source.  Writing your
> own congestion control is fun but dangerous.

I agree with you there.  But TCP's congestion control algorithms are 
closely tied with it's use of ACK.  Because I'm not ACK'ing data in the 
same fashion as TCP, I've got little choice but to tweak its congestion 
control.  Regardless, TCP serves as a good model, even if the specifics 
change.

-david