[e2e] Are Packet Trains / Packet Bursts a Problem in TCP?
fred at cisco.com
Mon Sep 25 15:55:08 PDT 2006
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.
My thought is that there are a few cases where you would like to use
a pacing algorithm to deal with momentary events, like when some
implementations get their input blocked and so throw away ACKs for a
while and then suddenly get an Ack that appears to permit them to
send a large volume all at once. Using some appropriate trigger, such
as "the current combination of effective window and available data
permits me to send more than N segments in a burst", I would hope it
would send whatever it chose to send at approximately cwnd/srtt.
As Bob says, systems often have fairly obnoxious timing signals
available to them. One might hope that this could get fixed :-(
More information about the end2end-interest