Hello,

in January I had an idea to shape download bandwidth, and I exchanged some
emails with various developers (Mike Frantzen, for example).

People asks how to limit *download* bandwith without dropping packets already
passed via the pipe to the firewall itself. The point is limiting the data
sent by the sender.

I think we could take advantage of the existing feature that Daniel added to
"prioritize ACKs", and work on those ACKs based on sequence numbers. These
numbers are strictly related to the data received by the receiver, so acting
on them we should be able to limit (reduce) the number of pps sent by the
sender. So, in the end, dropping ACKs from the receiver instead of dropping
data from the sender. This would happen locally without saturating the
(expensive) pipe to the internet.

How does it sound?

Sounds like a lot of work for (next to) nothing.

If you drop the ACKs, there'll be a retransmit anyway.  So only thing
you'd really change is that the TCP packet would arrive a little bit
sooner, which could make a minor (probably not noticeable) difference
for interactive stuff, such as SSH.  Then again, ssh isn't really what
you're likely to throttle anyway.

Terje

On Tuesday 02 May 2006 14:24, Terje Elde wrote:

You play with the window size too...

On 05/02/2006 08:04:14 AM, Ed White wrote:

So long as we're dreaming a design, I'd like to see something that
ensures X amount of free bandwidth on the download pipe, thus
making it available for whatever high priority traffic might
happen to show up, at the expense of low priority traffic and
regardless of whether there's other high priority traffic
already in the pipe.  (E.g. Another voip call is initiated.)
Given that it's really the sender that's going to limit bandwidth
and the latency involved this may not be practicable, but
it might be worth thinking about.

Meanwhile, I notice that DSL is half duplex
which means that filling the download pipe can clog the upload
pipe as well -- another reason for wanting some control
over the incoming bandwidth.

Step 1, as pointed out by D Hartmeier ages ago, is to come
up with some numbers proving how well the concept of
sender throttling works given, say, a http download.
That might generate actual interest on somebody's part
to code.

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