torrent client traffic shaping question

Ian Smith smithi at
Wed Mar 11 22:24:40 PDT 2009

On Wed, 11 Mar 2009 12:42:23 +0000 RW <rwmaillists at> wrote:
 > On Wed, 11 Mar 2009 11:13:16 +0200
 > Brent Clark <brentgclarklist at> 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.

cheers, Ian

More information about the freebsd-questions mailing list