Date: Thu, 12 Mar 2009 16:24:37 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: RW <rwmaillists@googlemail.com> Cc: Brent Clark <brentgclarklist@gmail.com>, freebsd-questions@freebsd.org Subject: Re: torrent client traffic shaping question Message-ID: <20090312152340.S71460@sola.nimnet.asn.au> In-Reply-To: <20090311175001.21BD41065792@hub.freebsd.org> References: <20090311175001.21BD41065792@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11 Mar 2009 12:42:23 +0000 RW <rwmaillists@googlemail.com> wrote: > On Wed, 11 Mar 2009 11:13:16 +0200 > Brent Clark <brentgclarklist@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090312152340.S71460>