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

[John Heffner]

Detlef Bosau wrote:
> It´s a provocative question and perhaps it was answered dozens of time, 
> but is the ACK clocking approach feasible
> for "inherent bursty applications"? Or is it well suited for greedy 
> flows with non bursty applications but in other scenarios it may run 
> into problems?

I don't see this as a problem with ack clocking.  Networks generally 
don't like large bursts, but you can have a (mostly) ack-clocked flow 
with smoothed bursts.


> And I´m not even sure whether this could be solved by pacing, as pacing 
> implicetely assumes a certain rate to be available for a flow. But what 
> happens if a flow did not send anything for a while and the path 
> capacity is occupied by competing flows then?
> Which rate is appropriate for the flow when it continues sending?

RFC2861 (Congestion Window Validation) is one approach.  It's sort of an 
inverse slow start.  Linux has been doing this for some time.

   -John