torrent client traffic shaping question

[Ian Smith]

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.

Sure.

 > 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