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

[Ritesh Kumar]

On 9/25/06, Fred Baker <fred at cisco.com> wrote:
>
>
> On Sep 25, 2006, at 3:42 PM, Ritesh Kumar wrote:
>
> > The paper presents many details but the gist is that when TCP is
> > paced, it takes very little time for the bottleneck queue to build
> > up from nothing to the full queue size.
>
> actually, I'm not sure that ack clocking that worked perfectly (all
> traffic is evenly paced throughout the RTT) or pacing that worked
> perfectly would behave much differently in any given RTT. The big
> issue with pacing in every RTT is that it is every RTT - you never
> step back to being ack clocked and as a result are not responsive to
> the millisecond-to-millisecond variations inherent in the network.


On the other hand, such millisecond to millisecond variations in the network
might not be because of the network but because of some systems specific
issues with end systems, delayed acks, queueing at multiple points in the
network path etc. It is hard to say that ack clocking really reflects the
*network* (and by network I mean the link and its queue) conditions at the
millisecond timescale; and that's a different debate altogether :)
Your point about perfect ack clocking is also very interesting. I wonder if
a certain level of "tweaking" to congestion avoidance is required to work
with a certain level of "perfection" achieved in ack clocking. As mentioned
in the previous paper, perfectly paced TCP doesn't behave very well compared
to "regularly" ack clocked TCP. Who knows how optimal is the behavior of
"regularly" ack clocked TCP (given the reno congestion avoidance algorithms)
is in the first place?
I am sorry if the above paragraph seems a little too vague.

Ritesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20060925/66fe20fe/attachment.html