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

[Marko Zec]

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?

Marko