|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: fixing TCP buffers (Re: packet reordering at exchange points)
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 <[email protected]>
To: [email protected]
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 <[email protected]>, or you are likely to
be blocked.
|