From owner-freebsd-questions@FreeBSD.ORG Thu Mar 12 05:24:40 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91412106566B for ; Thu, 12 Mar 2009 05:24:40 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 0F44B8FC1D for ; Thu, 12 Mar 2009 05:24:39 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id n2C5ObvV083407; Thu, 12 Mar 2009 16:24:38 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 12 Mar 2009 16:24:37 +1100 (EST) From: Ian Smith To: RW In-Reply-To: <20090311175001.21BD41065792@hub.freebsd.org> Message-ID: <20090312152340.S71460@sola.nimnet.asn.au> References: <20090311175001.21BD41065792@hub.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Brent Clark , freebsd-questions@freebsd.org Subject: Re: torrent client traffic shaping question X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 05:24:40 -0000 On Wed, 11 Mar 2009 12:42:23 +0000 RW wrote: > On Wed, 11 Mar 2009 11:13:16 +0200 > Brent Clark 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