Date: Fri, 19 Jul 2002 19:45:17 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Rik van Riel <riel@conectiva.com.br> Cc: freebsd-hackers@FreeBSD.ORG, <freebsd-net@FreeBSD.ORG> Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP Message-ID: <200207200245.g6K2jHOh081549@apollo.backplane.com> References: <Pine.LNX.4.44L.0207192301280.12241-100000@imladris.surriel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:It's not too hard actually. Random early drop should be
:enough for incoming packets, just artificially restrict
:the bandwidth to something like 90% of your maximum
:download bandwidth and drop packets that come in too
:fast.
:
:This will cause tcp to slow down to the speed limit you've
:chosen and the ISP queue will never fill up.
:
:regards,
:
:Rik
As a receive side mechanism the idea has merit, but I really
dislike artificallly dropping packets as a means of controlling
TCP. It's impossible to know what the effect of the drop would
have on the remote host's protocol stack. Controlling the
remote transmitter by having the receiver change it's window
advertisement seems to be a safer route.
I may take up the receive-side problem after I get the transmit
side down. I still have a lot of work to do on the transmit
side. It still takes a little too long to lock onto the
correct bandwidth, and interactive traffic will confuse it
(though that is one of the reasons why one should set a fairly
high minimum, like 4K-8K or so).
Your comment on limiting the bandwidth to 90% of maximum is
really humerous to me! I spent good two hours trying to get
the sender-side algorithm to maintain >90% maximum available
bandwidth. The algorithm I am using winds up being the most stable
at around 88% and it took a bit of messing around to get it
to stabilize at > 90%. I expect a receiver side algorithm would
have the same problem.
-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?200207200245.g6K2jHOh081549>