nanog mailing list archives
Re: fixing TCP buffers (Re: packet reordering at exchange points)
From: "E.B. Dreger" <eddy+public+spam () noc everquick net>
Date: Wed, 10 Apr 2002 01:13:33 +0000 (GMT)
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.
Current thread:
- Re: packet reordering at exchange points, (continued)
- Re: packet reordering at exchange points Paul Vixie (Apr 09)
- Re: packet reordering at exchange points E.B. Dreger (Apr 09)
- Re: packet reordering at exchange points Richard A Steenbergen (Apr 09)
- fixing TCP buffers (Re: packet reordering at exchange points) E.B. Dreger (Apr 09)
- Re: fixing TCP buffers (Re: packet reordering at exchange points) Richard A Steenbergen (Apr 09)
- Re: fixing TCP buffers (Re: packet reordering at exchange points) E.B. Dreger (Apr 09)
- Re: fixing TCP buffers (Re: packet reordering at exchange points) Richard A Steenbergen (Apr 09)
- Re: fixing TCP buffers (Re: packet reordering at exchange points) E.B. Dreger (Apr 09)
- Re: fixing TCP buffers (Re: packet reordering at exchange points) Richard A Steenbergen (Apr 09)
- Re: fixing TCP buffers (Re: packet reordering at exchange points) E.B. Dreger (Apr 09)
- Re: fixing TCP buffers (Re: packet reordering at exchange points) E.B. Dreger (Apr 09)
- Re: packet reordering at exchange points Peter Galbavy (Apr 10)
- Re: packet reordering at exchange points Neil J. McRae (Apr 10)
- Re: packet reordering at exchange points John Kristoff (Apr 10)
- Re: packet reordering at exchange points Richard A Steenbergen (Apr 10)
- Re: packet reordering at exchange points Peter Galbavy (Apr 10)
- Re: packet reordering at exchange points Mathew Lodge (Apr 10)
- Re: packet reordering at exchange points Stephen Sprunk (Apr 10)
- Re: packet reordering at exchange points Stephen Sprunk (Apr 10)
- Re: packet reordering at exchange points Paul Vixie (Apr 10)
- RE: packet reordering at exchange points Jim Forster (Apr 10)