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.