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

[Fred Baker]

On Sep 25, 2006, at 3:42 PM, Ritesh Kumar wrote:

> The paper presents many details but the gist is that when TCP is  
> paced, it takes very little time for the bottleneck queue to build  
> up from nothing to the full queue size.

actually, I'm not sure that ack clocking that worked perfectly (all  
traffic is evenly paced throughout the RTT) or pacing that worked  
perfectly would behave much differently in any given RTT. The big  
issue with pacing in every RTT is that it is every RTT - you never  
step back to being ack clocked and as a result are not responsive to  
the millisecond-to-millisecond variations inherent in the network.

My thought is that there are a few cases where you would like to use  
a pacing algorithm to deal with momentary events, like when some  
implementations get their input blocked and so throw away ACKs for a  
while and then suddenly get an Ack that appears to permit them to  
send a large volume all at once. Using some appropriate trigger, such  
as "the current combination of effective window and available data  
permits me to send more than N segments in a burst", I would hope it  
would send whatever it chose to send at approximately cwnd/srtt.

As Bob says, systems often have fairly obnoxious timing signals  
available to them. One might hope that this could get fixed :-(