[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?
craig at aland.bbn.com
Mon Sep 25 07:20:37 PDT 2006
Yes burstiness matters.
Some background reading:
* Jacobson's original TCP paper. And, if you can find them on-line
some of the IETF talks before and after. The early TCP was
bursty -- indeed, it retransmitted bursts. The effects were awful.
Plenty of operational measurements to prove it.
* Jim Kurose had a paper (I think it is Nagarajan/Kurose in
INFOCOM '92) that showed that burstiness effects tend to multiply
(e.g., burst meets burst in routers) and synchronize. Also,
see Jacobson/Floyd on synchronization of periodic routing
messages (SIGCOMM '93), where you see self organized bursts
destroying a network.
* Jacobson sent out notes (not sure if it was ever published) showing
that small flows suffered disproportionatly when competing with a
big bursty flow. The big flow would end up synchronizing its
bursts with the available queueing space in routers, leaving
the small flows shut out. So even if most TCP flows are short
and small, one cares about burstiness in the big flows as that
will affect the short flows (e.g. web download times).
What my previous post was trying to point out is that the definition
of harmful burstiness is not well understood in this day and age.
Network capacity has gotten larger -- than means larger bursts don't
cause the same destructiveness they once did.
This does not mean we can ignore burstiness (ala the HOTNETs paper that
argued naively that we should optimistically transmit). But it does mean
there's room for someone who wants to understand whether an evil burst
is 8 packets (as it was in the old days) or 8,000.
More information about the end2end-interest