Re: torrent client traffic shaping question
On Thu, 12 Mar 2009 16:24:37 +1100 (EST) Ian Smith smi...@nimnet.asn.au wrote: On Wed, 11 Mar 2009 12:42:23 + RW rwmailli...@googlemail.com 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? Because tcp is best controlled at the tcp-level You could get smoother, lower-latency transfers, and you're not dropping any packets that have already passed through the ISP bottleneck. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
torrent client traffic shaping question
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. TIA Brent Clark ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: torrent client traffic shaping question
Hi, 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. Maybe torrent protocol includes something where by the client tells its peers to send data at a slower rate. Traffic shaping is done at IP or TCP level, while the up/down load speed is managed at the client level. Bests, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: torrent client traffic shaping question
Olivier Nicole wrote: Maybe torrent protocol includes something where by the client tells its peers to send data at a slower rate. Traffic shaping is done at IP or TCP level, while the up/down load speed is managed at the client level. Bests, Olivier Hi I posted the same Q on netfilters mailinglist. This was one of the answers I got snip If you read from socket at fixed rate, it's TCP receive buffer is emptied at same rate. TCP announces free buffer in receive window field, so congestion window on sender side is also adjusted, thus limiting send speed to the rate you read from socket on receiver side. /snip Brent ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: torrent client traffic shaping question
On Wed, 11 Mar 2009 11:13:16 +0200 Brent Clark brentgclarkl...@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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: torrent client traffic shaping question
On Wed, 11 Mar 2009 12:42:23 + RW rwmailli...@googlemail.com wrote: On Wed, 11 Mar 2009 11:13:16 +0200 Brent Clark brentgclarkl...@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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
