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

[Detlef Bosau]

Xiaoliang (David) Wei wrote:
>
>      So, it seems to us that there are a lot to understand in the 
> future. The performance of paced TCP/bursty TCP seems to depend on 
> several questions:
> 1. Is aggregate throughput the most important metric?
> 2. What is the packet loss pattern in Internet?
> 3. How does TCP reacts to loss? (Besides Reno, there are many new 
> algorithms)
> 4. How do we implement and deploy pacing? (Are paced flows going to 
> compete with bursty flows? We can also tune the paced flows to let 
> them compete... Are we using AQM to generate less bursty packet loss? 
> and etc)
>
> -David

Perhaps the following will become clear, when I read the aformentioned 
papers.

But what I´m curious about in all (sender) pacing approaches is: Where 
does the pacing rate stem from? Typically, it´s obtained from one of the 
numerous TCP formulae (Padhye, Mathis...), but these are first 
(admittedly rough) estimates and second need some measurements to have 
an initial value set.

Moreover, widely deployed pacing would practically replace the currently 
used AIMD mechanism for achieving a fair share, because the currently 
used AIMD probing leads to "microbursts", which means that the TCP 
sender _exceeds_ its fair share of rate for short periods of time. This 
doesn´t matter as TCP is not rate controlled.  And the final rate is 
corrected by ACK clocking.
How does this work with sender pacing, i.e. putting a leaky bucket  or 
flow shaper or something like that in the TCP sender?

Detlef