[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?

[Detlef Bosau]

Lachlan Andrew wrote:
>> The big problem in pacing is determining the rate available at the
>> bottleneck.
>
> That seems to be confusing rate control with scheduling.
>
To my understanding, there are quite a few TCP flavours and mechanisms 
which integrate some kind of rate control.
Just to mention TCP Westwood, Equation Based Congestion Control (Widmer, 
Floyd, Padhye) and I think XCP works in the same direction.

And of course TCP (sender) pacing does rate control.


> A pacing scheme can measure the RTT and still maintain a "window"
> (even though not used as a sliding window), following the standard
> rules of (New)Reno/SACK/H-TCP/...
>
> If we pace packets out at a rate "window / RTT" then we transmit at
> the same average rate as if we used ACK-clocking.  The only difference
> is that the packets are sent with roughly equal spacing in the case of
> pacing, and sent irregularly with pure ACK-clocking.
>

That´s the gerneral idea.  I found the following paper useful:

> @inproceedings{ aggarwal00understanding,
>     author = "Amit Aggarwal and Stefan Savage and Thomas Anderson",
>     title = "Understanding the Performance of {TCP} Pacing",
>     booktitle = "{INFOCOM} (3)",
>     pages = "1157-1165",
>     year = "2000",
>     url = "citeseer.ist.psu.edu/aggarwal00understanding.html" }
>  

Detlef