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

Marko Zec zec at tel.fer.hr
Thu Sep 28 09:39:20 PDT 2006

On Thursday 28 September 2006 02:02, Rick Jones wrote:
> >The question whether or not we can implement fine-grained pacing in
> > software might be becoming less relevant now that the silicon industry is
> > irreversibly pushing with TCP segmentation offload implementations in
> > hardware.
> We industry types have to because the researchers keep adding straws to
> TCP's back and increasing the path length :) And because the IEEE types
> won't standardize a larger MTU each time they increase the bit-rate by an
> order of magnitude...
> >Given
> >that the OS typically feeds a TSO engine with at least a 32 or 64 kbyte
> > raw data chunk per single TCP session, this corresponds to a 22 or 44
> > segment wire-speed burst at minimum.  Thinking what things might look
> > like if multiple such streams would get synchronized is quite scarry...
> If they trigger losses, then the cwnd's kick-in and the TSO's become
> smaller.

It's obvious that doing hardware TSO for say an 8 K data chunk, i.e. 5 
segments, provides great savings in terms of CPU cycles and I/O bus 
utilization spent on transmitting TCP streams.  But what is the performance 
gain for going up from 8 K / 5 segment TSO to 64 K / 44 segment bursts, 
knowing that bursts that large clearly coudl be a double-edged sword?

In other words, how large the TSO bursts could be considered tolerable and 
justified - roughly where should we draw the line?


More information about the end2end-interest mailing list