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

Craig Partridge craig at aland.bbn.com
Mon Sep 25 07:20:37 PDT 2006

Hi Detlef:

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 mailing list