From owner-freebsd-hackers Sun Jul 15 10:32:45 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 72A0537B401 for ; Sun, 15 Jul 2001 10:32:40 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f6FHWd008447; Sun, 15 Jul 2001 10:32:39 -0700 (PDT) (envelope-from dillon) Date: Sun, 15 Jul 2001 10:32:39 -0700 (PDT) From: Matt Dillon Message-Id: <200107151732.f6FHWd008447@earth.backplane.com> To: Leo Bicknell , Julian Elischer , Drew Eckhardt , hackers@FreeBSD.ORG Subject: Re: Network performance tuning. 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> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :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