RE: Deployment Cases

["Hallam-Baker, Phillip" <pbaker@xxxxxxxxxxxx>]

Title: Re: Deployment Cases

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@xxxxxxxxxxxxxxxxx]
Sent: Tue 08/01/2008 5:56 AM
To: Lars Eggert
Cc: 'Tony Finch'; Ping Pan; 'IETF discussion list'; stbryant@xxxxxxxxx
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@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf