Building the deployment case for a strictly functional protocol that does not
have a competitor is simply a matter of asking 'does anyone actually case about
these use cases enough to deploy'. In the case of Bittorrent, the answer is of
course yes.
Proposing to transition from current bittorrent protocol to an incompativble
successor on the other hand requires much more thought. What is the deficiency
with the current protocol that is going to be fixed?
If the defect is functional in nature one can expect rapid take up. If on the
other hand the proposal is to convert XML to ASN.1 or vice versa for the sake
of prettification then its not likely to happen.
________________________________
From: Marshall Eubanks [mailto:tme(_at_)multicasttech(_dot_)com]
Sent: Tue 08/01/2008 5:56 AM
To: Lars Eggert
Cc: 'Tony Finch'; Ping Pan; 'IETF discussion list';
stbryant(_at_)cisco(_dot_)com
Subject: Re: Deployment Cases
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf