[46753] in North American Network Operators' Group
Re: fixing TCP buffers (Re: packet reordering at exchange points)
daemon@ATHENA.MIT.EDU (E.B. Dreger)
Tue Apr 9 21:15:58 2002
Date: Wed, 10 Apr 2002 01:13:33 +0000 (GMT)
From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net>
To: Richard A Steenbergen <ras@e-gerbil.net>
Cc: Paul Vixie <paul@vix.com>, nanog@merit.edu
In-Reply-To: <20020410003934.GA523@overlord.e-gerbil.net>
Message-ID: <Pine.LNX.4.20.0204100057230.23010-100000@www.everquick.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu
Rough attempt at processing rules:
1. If "enough" buffer space, let each stream have its fill.
DONE.
2. Not "enough" buffer space, so we must invoke limits.
3. If new connection, impose low limit until socket proves its
intentions... much like not allocating an entire socket
struct until TCP handshake is complete, or TCP slow start.
DONE.
4. It's an existing connection.
5. Does it act like it could use a smaller window? If so,
shrink the window. DONE.
6. Stream might be able to use a larger window.
7. Is it "tuning time" for this stream according to round robin
or random robin? If so, use BIG buffer for a few packets,
measuring the stream's desires.
8. Does the stream want more buffer space? If not, DONE.
9. Is it fair to other streams to adjust window? If not, DONE.
10. Adjust appropriately.
I guess this shoots my "split into friendly fractions" approach
out of the water... and we're back to "standard" autotuning (for
sending) once we enforce minimum buffer size.
Major differences:
+ We're saying to approach memory usage macroscopically instead
of microscopically. i.e., per system instead of per stream.
+ We're removing upper bounds when bandwidth is plentiful.
+ Receive like you suggested, save for the "low memory" start
phase.
--
Eddy
Brotsman & Dreger, Inc. - EverQuick Internet Division
Phone: +1 (316) 794-8922 Wichita/(Inter)national
Phone: +1 (785) 865-5885 Lawrence
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT)
From: A Trap <blacklist@brics.com>
To: blacklist@brics.com
Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots.
Do NOT send mail to <blacklist@brics.com>, or you are likely to
be blocked.
