On 2008-1-3, at 11:11, ext Stewart Bryant wrote:
Wouldn't Bittorrent fail congestion considerations review?
Not necessarily. It does use a large number of TCP connections, because the goal is to fully saturate a user's up- and downlink. But because it uses TCP, it will correctly back off under loss, so congestion collapse at least is not an issue. (It obviously does cause issues for ISPs that provisioned their networks with certain aggregation ratios in mind, which became invalid with the rise of P2P. Separate issue though.)
There are still fairness issues with BitTorrent, in that the large number of BitTorrent sessions will use a comparatively large fraction of a user's access link compared to the typically small number of other (and typically bursty) connections that are active. Given that users typically run P2P in the background, this decrease in performance of the transport sessions that the users were more immediately interested in quickly got noticed. Modern BitTorrent implementations have pretty clever schemes to free up a larger share of the access link capacity when they notice concurrent non-BitTorrent sessions sharing the access link. This piece of BitTorrent seems to be pretty actively evolving, and I'm not sure how much of it has been written down. Basically, BitTorrent has recently been trying approximate a scavenger service that tries to restrict its transmissions to otherwise idle capacity, using application-level mechanisms. (Which is IMO exactly what it should be.)
There has been a bunch of research an even some standardization attempts on integrated congestion control, i.e., congestion and rate controlling the aggregate traffic that a host is sending at any given time, i.e., across all active connections, but deployment never happened and interest quickly waned.
Lars _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf