fixing TCP buffers (Re: packet reordering at exchange points)

Wed Apr 10 01:13:33 UTC 2002

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 at brics.com>
To: blacklist at 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 at brics.com>, or you are likely to
be blocked.