On Jan 8, 2008, at 4:22 AM, Lars Eggert wrote:
On 2008-1-3, at 11:11, ext Stewart Bryant wrote:
Wouldn't Bittorrent fail congestion considerations review?
Since Bittorrent is heavily used now by endusers and is likely to be
used by commercial enterprises (either as is, or with modifications
for security, DRM, etc.), if it doesn't provide good congestion
control it would be better to try and fix it than to simply bemoan it.
Regards
Marshall
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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf