[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?
detlef.bosau at web.de
Tue Sep 26 10:51:21 PDT 2006
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
> 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)
Perhaps the following will become clear, when I read the aformentioned
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?
More information about the end2end-interest