Re: BitTorrent swarms have a deadly bite on broadband nets

[Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>]

On Sun, 21 Oct 2007 19:31:09 -0700
Joel Jaeggli <joelja () bogus com> wrote:

> Steven M. Bellovin wrote:
>
> > This result is unsurprising and not controversial.  TCP achieves
> > fairness *among flows* because virtually all clients back off in
> > response to packet drops.  BitTorrent, though, uses many flows per
> > request; furthermore, since its flows are much longer-lived than web or
> > email, the latter never achieve their full speed even on a per-flow
> > basis, given TCP's slow-start.  The result is fair sharing among
> > BitTorrent flows, which can only achieve fairness even among BitTorrent
> > users if they all use the same number of flows per request and have an
> > even distribution of content that is being uploaded.
> >
> > It's always good to measure, but the result here is quite intuitive.
> > It also supports the notion that some form of traffic engineering is
> > necessary.  The particular point at issue in the current Comcast
> > situation is not that they do traffic engineering but how they do it.
>
> Dare I say it, it might be somewhat informative to engage in a priority
> queuing exercise like the Internet-2 scavenger service.
>
> In one priority queue goes all the normal traffic and it's allowed to
> use up to 100% of link capacity, in the other queue goes the traffic
> you'd like to deliver at lower priority, which given an oversubscribed
> shared resource on the edge is capped at some percentage of link
> capacity beyond which performance begins to noticably suffer... when the
> link is under-utilized low priority traffic can use a significant chunk
> of it. When high-priority traffic is present it will crowd out the low
> priority stuff before the link saturates. Now obviously if high priority
> traffic fills up the link then you have a provisioning issue.
>
> I2 characterized this as worst effort service. apps and users could
> probably be convinced to set dscp bits themselves in exchange for better
> performance of interactive apps and control traffic vs worst effort
> services data transfer.

And if you think about these p2p rate limiting devices a bit more
broadly, all they really are are traffic classification and QoS policy
enforcement devices. If you can set dscp bits with them for certain
applications and switch off the policy enforcement feature ...

> Obviously there's room for a discussion of net-neutrality in here
> someplace. However the closer you do this to the cmts the more likely it
> is to apply some locally relevant model of fairness.
>
> >             --Steve Bellovin, http://www.cs.columbia.edu/~smb


-- 

        "Sheep are slow and tasty, and therefore must remain constantly
         alert."
                                   - Bruce Schneier, "Beyond Fear"