On 01/11/2011 09:23:48 AM, Daniel Staal wrote: > > On Tue, January 11, 2011 1:35 am, Bonnie Packet wrote:
> The problem with trying to throttle incoming bandwidth is that no > matter > what you do, you have already received the packets. As long as your > internal network is faster than the external network feeding it, > throttling incoming is useless: you've got the packets, putting them > on > your internal network won't slow things down, and dropping them will > only > cause them to get retransmitted. (And use up *more* of your > already-scarce external connection.) It is oft-repeated that you can't throttle inbound traffic, and while true in some special cases, not true in most real-world use-cases. If all your traffic was UDP, then yes, your argument holds. But most real-world traffic, especially that which is bulky, is TCP -- which contains it's own throttling mechanism to adjust to "downstream" changes in bandwidth. So, the sender will slow down transmission if you drop packets. There are may proofs that throttling TCP works, starting with the original paper (Van Jacoson) in 1988 through to the many products today that _do_ manage to reserve enough inbound bandwidth that, e.g., VOIP works reliably. I once promised on this list to setup a test environment and re-prove it but have never gotten around to it and it hardly seems worth bothering. Exactly how well TCP throttling works and how to best make it work in the real world is still up for grabs, but it can be made "good enough". It may or may be able to be made to work in the future as there seem to be increasing problems with 'bufferbloat', where equipment manufacturers decide to buffer TCP, which breaks TCP's congestion control and introduces the very latency that throttling is (usually) trying to eliminate. Still, if you're willing to waste enough bandwidth they'll probably always be a way to reserve a bit of unused inbound bandwidth for low-latency needs. Congestion Avoidance and Control. ∗. Van Jacobson†. Lawrence Berkeley Laboratory. Michael J. Karels‡. University of California at Berkeley. November, 1988 http://ee.lbl.gov/papers/congavoid.pdf rfc1323 TCP Extensions for High Performance http://tools.ietf.org/html/rfc1323 The criminal mastermind: bufferbloat! http://gettys.wordpress.com/2010/12/03/introducing-the-criminal- mastermind-bufferbloat/ Karl <k...@meme.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein
