[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?
johnh at ISI.EDU
Tue Sep 26 10:28:34 PDT 2006
On Mon, 25 Sep 2006 15:23:26 EDT, Craig Partridge wrote:
>A team I was on showed you could do this a few years ago. I no longer
>remember all the details (Dennis Rockwell did the hard work with UNIX
>timers) but it is probably in the paper:
> J. Kulik, R. Coulter, D. Rockwell and C. Partridge,
> "Paced TCP for High Delay-Bandwidth Networks,"
> IEEE Workshop on Satellite Based Information Systems,
> December 1999.
Vikram Visweswaraiah and John Heidemann.
Improving Restart of Idle TCP Connections.
Technical Report N. 97-661, University of Southern California, Computer Science Department, November, 1997.
(Unfortunately, never published beyond a technical report.)
If one accepts moderate-size bursts (4-8 back-to-back segments), and a
100Hz clock (reasonably even by 1997 standards), one can pace at
nearly 10Mb/s with ease (100Hz ticks * 1500B/pkt * 8B/b * 8
pkts/ticks), and increase by a factor of 4-8 in the next round trip.
Given that today's kernels typically run at 1kHz by default, one can
multiple that by 10 even before starting any serious hacking.
>In message <200609251911.MAA24244 at gra.isi.edu>, Bob Braden writes:
>> *> There are places where improving TCP burstiness can be of value, such
>> *> as in the cases where (usually Linux) TCPs decide to send their
>> *> entire next window in a short period of time it would be nice of they
>> *> could be convinced to do so at a rate that doesn't exceed cwnd/srtt.
>>The ability of an OS to do that pacing has traditionally been limited
>>by the coarse-grain software clocks that were available -- i.e., by
>>interrupt overhead. Suppose CPU chip designers listened to the needs
>>of networking people. Could they provide fine-grain hardware clocks
>>that could be easily used by transport protocols for pacing out packets
>>in large windows?
More information about the end2end-interest