Internet Measurement Conference 2003 Source-Level IP Packet Bursts: Causes and Effects Hao Jiang Constantinos Dovrolis (hjiang, College of Computing Georgia Institute of Technology

Main questions ŸSource-level burst: several IP packets sent back-to- back from the source of an individual flow Strongly correlated packet interarrivals within a flow ŸWhich are the causes of source-level bursts? Identify several protocol/application causes ŸCan source-level bursts create scaling in short timescales? Yes, in timescales that correspond to duration of bursts ŸWhat is the impact of source-level bursts on queueing performance? Increased maximum backlog and queue-size tail distribution

Causes of source-level bursts ŸUDP message segmentation ŸUnused congestion window increases ŸPacket reordering ŸIdle restart timer bug ŸBursty applications ŸCumulative or lost ACKs ŸSlow start ŸLoss recovery with Fast Retransmit ŸACK compression

UDP message segmentation in multiple IP packets/fragments

Normally, if sender stays idle for more than certain timer, TCP should restart in slow start Otherwise, entire window can be sent back-to-back

Multi-Resolution Analysis of traffic process ŸTime series of traffic process at scale T j =2 j T 0 : Amount of traffic in ŸEnergy at scale T j : ŸCompute energy plots using wavelet-based MRA tool (Darryl Veitch) Variance of Haar wavelet coefficients at scale T j

Scaling behavior and energy plots ŸShort-time scaling vs long-time scaling ŸShort-time scaling corresponds to sub-RTT timescales

Packet-train model of source-level bursts ŸParameters: L, C, N, T off ŸCorrelated packet interarrivals within burst ŸAll bursts have same characteristics ŸIgnore all other correlations

Source-level bursts cause short-time scaling Energy plot Scaling from L/C to NL/C with slope 2.0 ŸAutocorrelation function ŸLinearly decreasing correlations up to NL/C

Burst detection in packet traces ŸDetect burst as sequence of packets from a single flow that arrives at trace point with burst rate pre-trace capacity ŸNOTE: we may detect more than source-level bursts ŸHow to estimate pre-trace capacity? ŸEstimate minimum-capacity on the path between source host and trace-point ŸUse packet pair dispersion technique ŸApply only to equal-sized packets ŸTCP sends many packet pairs due to delayed-ACK algorithm

Example of pre-trace capacity distribution ŸObserve modes at 1.5Mbps, 10Mbps, 45Mbps, and 100Mbps

What if there were no bursts? Modify trace by spreading detected burst: ŸUniform respacing of packets within burst ŸNot possible in practice

Effect of bursts on short-time scaling ŸDecreases scaling exponent to almost zero in sub- RTT timescales

But not entirely..

Effect of bursts on queueing performance ŸSignificant reduction of maximum backlog in moderate utilization (infinite-buffer model)

Effect of bursts on queueing performance ŸFaster decrease of queue-size tail probability

Conclusions ŸVarious protocol/applications mechanisms create source-level bursts ŸSource-level bursts can cause short-time scaling in Internet traffic ŸBut they are not the only reason ŸRemoval of bursts would decrease scaling in sub-RTT timescales and would improve queueing performance ŸMore recent work: ŸEffect of self-clocking on short-time scaling ŸEffect of TCP pacing and TB-shaping on short-time scaling

Unused congestion window increase

ACK reordering

Cumulative or lossed ACKs

Loss recovery with fast retransmission

ACK compression

Bursty application

Slow start can cause bursts when W < C T C: capacity of source & path, T: Round-Trip Time