On Sun, Jul 15, 2001 at 10:05:16AM -0700, Matt Dillon wrote:
> Well, 4 connections isn't enough to generate packet loss. All
> that happens is that routers inbetween start buffering the packets.
> If you had a *huge* tcp window size then the routers inbetween could
> run out of packet space and then packet loss would start to occur.
> Routers tend to have a lot of buffer space, though. The real killer
> is run-away latencies rather then packet loss.
Sure it is, in a lot of cases. Keep in mind RED is becoming the
default (in paritcular one major router vendor ships with it as
the default now), so in general routers will discard packets _before_
they will buffer them.
> Also, the algorithm is less helpful when it has to figure out the
> optimal transmit buffer size for every new connection (consider a web
> server). I am considering ripping out the ssthresh junk from the stack,
> which does not work virtually at all, and using the route table's
> ssthresh field to set the initial buffer size for the algorithm.
This would probably be a big win, as in web-server type cases there are
many small connections back to back.
Now, if you want a really radical idea, how about not doing slow-start
on the second-nth connection, but starting where the previous connection
left off.
Whoa, that's loaded with issues. :-)
--
Leo Bicknell - [EMAIL PROTECTED]
Systems Engineer - Internetworking Engineer - CCIE 3440
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
