[p2p-hackers] UDP file transfer link speed identification

[Greg Bildson]

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.

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.

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.

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.

This is imperfect to be sure but mostly where the trial and error approach
comes in.  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.  To coexist nicely and maximize your own
throughput, you should start to back off when your round trip times escalate
by some factor (or multiple) over your baseline average round trip time.

3) Apply standard exponential backoff rules.


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.

Thanks
-greg

> -----Original Message-----
> From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org]On
> Behalf Of David Barrett
> Sent: Thursday, July 21, 2005 4:49 PM
> To: Peer-to-peer development.
> Subject: [p2p-hackers] UDP file transfer link speed identification
>
>
> How do you decide how fast to send UDP file-transfer packets?
>
> Lots of people on this list make file sharing applications.  Many of
> those applications use UDP.  A big drawback of using UDP for file
> transfers is you can't rely upon the link-speed detection capabilities
> of TCP.  As a result, if you send UDP too slow, you're not maximizing
> your connection.  But if you send it too fast, you'll congest your
> upstream and/or the remote peer's downstream connection, causing packet
> loss at the very least, as well as possibly denial of service.
>
> How have you resolved this problem?  I'm using an approach where the the
> client (receiving peer) provides continuous feedback to the server
> (sending peer) as to how fast it should send data.  Thus the client can
> control the rate at which it receives data from the server.
>
> But the question is: how does the client know how fast to request data?
>   The overall approach I'm using is to request data at a certain rate,
> measure how fast it is actually received, calculate what new rate should
> be tried, repeat.
>
> However, I'm finding this surprisingly tricky.  Either I ramp up too
> slow, or I ramp up and down erratically.  I've considered some FSM
> approaches, and some formulaic approaches, and I still haven't come up
> with something I like.  I've read the TCP RFC for guidance, but it
> leaves the specifics left as an exercise to the reader.  Other than
> that, I'm not sure where else to read for inspiration.
>
> So I'm curious, how have you solved this problem?  What can you advise?
>
> -david
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences