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

[Fred Baker]

On Sep 25, 2006, at 7:08 AM, Detlef Bosau wrote:

> Isn´t it a more fundamental question, wether burstiness may cause  
> grief in a significant number of scenarios, so that it would be  
> useful to avoid burstiness at all?

I think there is a fair bit we can say from mathematics. For example,  
there is a fairly dramatic difference between the delays experienced  
in an M/M/1 and an M/D/1 scenario. Queuing delays result from packets  
sitting in queues, and variability in queue depth results in  
variability in delay. Increased burstiness increases average delay  
and average jitter.

That said, I will agree with Craig that burstiness in moderation  
doesn't itself cause major problems in the network. Short sessions,  
which are as you say very common in web and mail applications, are  
inherently bursty, and it's hard to imagine them being otherwise when  
slow-start combined with the fact that they are moving small amounts  
of data are brought into consideration. Longer sessions also occur in  
web and mail transactions, and are common in p2p applications, which  
are now pretty prominent as a traffic source. But when TCP runs in a  
longer session, I think you will find that burstiness levels out, as  
the duration of a burst is stretched by the queues of bottlenecks in  
the path, resulting in a reduction of the rate of the burst as  
traffic crosses the network, and the Acks come back at a rate less  
than or equal to the bottleneck rate. I would expect to see ack  
clocking spread the traffic of a longer TCP session so that it is  
less bursty.

Pacing attacks burstiness. AQM actually doesn't; it attacks average  
queue depth.

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.  
Beyond handling extreme cases like that, I'm not convinced it's worth  
the effort - it sounds like a lot of mechanism solving a problem that  
I'm not sure actually hurts us all that much.

I'm much more interested in TCPs that will handle high loss rates and  
variable delay (WiFi/WiMax) and long delays over a wide range of  
speeds, consistently delivering a good approximation of the available  
bandwidth (there's still a lot of dial in the world, and there are  
many places that sport fiber end to end) to applications that attempt  
to use it.