[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?
jheffner at psc.edu
Tue Oct 3 07:47:27 PDT 2006
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.
More information about the end2end-interest