Date: Sun, 15 Jul 2001 10:32:39 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Leo Bicknell <bicknell@ufp.org>, Julian Elischer <julian@elischer.org>, Drew Eckhardt <drew@PoohSticks.ORG>, hackers@FreeBSD.ORG Subject: Re: Network performance tuning. Message-ID: <200107151732.f6FHWd008447@earth.backplane.com> References: <200107130128.f6D1SFE59148@earth.backplane.com> <200107130217.f6D2HET67695@revolt.poohsticks.org> <20010712223042.A77503@ussenterprise.ufp.org> <200107131708.f6DH8ve65071@earth.backplane.com> <3B515097.6551A530@elischer.org> <20010715103334.A64293@ussenterprise.ufp.org> <200107151705.f6FH5Gd08326@earth.backplane.com> <20010715131351.A72087@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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.
That isn't what RED does, not really. Basically it statistically
drops packets at an ever-increasing rate as the buffer fills up.
It does NOT prevent packet buffering from occuring, and it doesn't
kick in the moment buffering is used -- the buffer has to start to
fill up significantly before RED has an effect.
I personally do not believe that RED has a future or, if it does,
that it will wind up only kicking in when queues would otherwise
start to drop packets anyway, as a fail-safe rather then as a
prime bandwidth management system.
The bandwidth delay product code kicks in instantly - before a
significant number of packets get queued at the router, so it is
effectively under RED's radar. And if packet loss does occur
NewReno takes over again, so the bandwidth delay code will not
interfere with NewReno (or whatever we do to deal with packet loss).
:> 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 - bicknell@ufp.org
re: slow-start. Actually I think this would work quite well in
regards to setting the initial buffer size.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107151732.f6FHWd008447>