torrent client traffic shaping question
smithi at nimnet.asn.au
Wed Mar 11 22:24:40 PDT 2009
On Wed, 11 Mar 2009 12:42:23 +0000 RW <rwmaillists at googlemail.com> wrote:
> On Wed, 11 Mar 2009 11:13:16 +0200
> Brent Clark <brentgclarklist at gmail.com> wrote:
> > Hiya
> > I got this question to ask, and I was hoping the TCP/IP gurus would be
> > able to help me understand this.
> > K you know how with traffic shapping you can control only the traffic
> > leaving you, how it is that torrent clients say they can control the
> > download as well as the upload. I would think the client can only
> > control the upload.
> If the client reads from a TCP socket slower than the data is coming-in,
> the buffers fill-up and the sliding-window algorithm in TCP causes the
> sending side to slow down.
> A traffic shaper could efficiently regulate downloads by proxying TCP.
> And even though PF does some limited TCP proxying, unfortunately
> dummynet and altq work at the IP level.
I don't know why you say 'unfortunately' here? I can only talk about
ipfw + dummynet from my own experience, but you can use dummynet pipes
and their queue/s to shape any sort of IP(v4) traffic, in- or outbound,
directed to/from any sort of flow ipfw can distinguish by any of the
usual packet selectors (TCP, UDP, ICMP, raw IP or by any IP protocol or
options; for TCP/UDP by src/dest ports as well as addresses, whatever)
While it's true that shaping listen-only unacknowledged streaming UDP by
dropping further packets once the inbound pipe's queue is full involves
packet loss, many real-world UDP transfers (eg realaudio) will back off
from sending more in the absense of some sort of specific or periodic
acknowledgements. I'm not sure what happens with multicast traffic.
More information about the freebsd-questions