On 05/02/2006 08:04:14 AM, Ed White wrote:
On Tuesday 02 May 2006 14:24, Terje Elde wrote:
> 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.
You play with the window size too...
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 <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
