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

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

Congestion Avoidance and Control. ∗. Van Jacobson†. Lawrence Berkeley 
Laboratory. Michael J. Karels‡. University of California at Berkeley. 
November, 1988

TCP Extensions for High Performance

The criminal mastermind: bufferbloat!

Karl <k...@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Reply via email to