On 9/25/06, <b class="gmail_sendername">Fred Baker</b> <<a href="mailto:fred@cisco.com">fred@cisco.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On Sep 25, 2006, at 3:42 PM, Ritesh Kumar wrote:<br><br>> The paper presents many details but the gist is that when TCP is<br>> paced, it takes very little time for the bottleneck queue to build<br>> up from nothing to the full queue size.
<br><br>actually, I'm not sure that ack clocking that worked perfectly (all<br>traffic is evenly paced throughout the RTT) or pacing that worked<br>perfectly would behave much differently in any given RTT. The big<br>issue with pacing in every RTT is that it is every RTT - you never
<br>step back to being ack clocked and as a result are not responsive to<br>the millisecond-to-millisecond variations inherent in the network.</blockquote><div><br>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 :)
<br>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?
<br>I am sorry if the above paragraph seems a little too vague.<br></div><br></div>Ritesh<br>