[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?
fred at cisco.com
Mon Sep 25 07:54:49 PDT 2006
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
Pacing attacks burstiness. AQM actually doesn't; it attacks average
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.
More information about the end2end-interest