BitTorrent.org community
You are not logged in.
I've just read the current version of BEP29, and while the congestion control seems to be a good idea, I do have some comments about the whole thing:
- recreating a TCP-like communication over UDP for BT transfer is a waste of overhead; this per-packet acknowledgment is really unnecessary, we're talking about simple file transfer, and there are no strict (or even loose) deadlines for the data. Per-block acknowledgements would be more than enough, in fact, come to think of it, it's actually unnecesarry to send ACKs. The scenario would be the following:
The peer requests a block, let's say of 1MB; the seeder transmits it, not really caring if the other end received it correctly or not, the receiver can check for those missing/erronous blocks, AFAIK the torrent file does contain the necessary information to do that, if incorrect, request the missing pieces again, maybe from another seed. If all went ok, then there's no need to bother the seeder with this, it's useless information. Not interrupting a whole block of data-tranfer because of few erronous packet would decrease the time needed for the transfer.
- although the congestion control seems to be dependent on this TCP-like communication in the current implementation, it really doesn't have to be: the timestamps don't need to be attached to every single packet, it'd be more than enough to append that information to a data block every 10 seconds for example. Let's face it, checking for congestion at every packet won't make it bulletproof, OTOH having a stable rate for the existing connections even for a short period would even make it easier for a new connection to figure out it's own rate.
To sum it up, UDP should be used for what it is: unreliable; which in the case of BT can be a big advantage, if used wisely.
just my 2 cents
Offline
you can't check for congestion just every 10 seconds. loading of websites, skype, videostreaming can ramp up in the fraction of seconds and thus alter the network load on the last mile within the timeframe.
BT also requires in-order delivery. Maybe not as strict as provided by TCP but at least on a status-message level. And since payload messages are greater than the MTU we also need packet reassembly.
In fact, the opposite should be done. The congestion controller (LEDBAT) should not be used over a custom-made UDP transport (uTP) but instead plugged into TCP so that all the well-known characteristics of TCP can be reused, layer-4-aware routers (traffic shaping) can categorize flows properly and that we can use common network analysis tools etc. etc.
The only reason uTP (and many many other custom UDP-based transports) exist is that people want to plug one tiny feature like NAT-traversal or in this case a different congestion controller into TCP, but can't. So everyone reinvents the wheel... over and over and over again.
Offline
My time/size values were not a real world example. Anyway, my point is, that for BT traffic ACKs aren't needed as much as BEP29 uses it, packet reassembly can be done without ACKs for every packet. It just needs to be a bit more fault tolerant.
Offline
Acks are required for every packet in order to maintain an up-to-date delay measurement, which is required for the congestion control and that's the whole point of uTP.
Offline