On 31 Jan 2005 10:40:44 -0500
jamal <hadi@xxxxxxxxxx> wrote:
> My experience is that you end up dropping no more than a packet in a
> burst with policing before TCP adjusts. Also depending on the gap
> between bursts, that may be the only packet you drop altogether.
> In long flows such as file transfers, avergae of one packet ever gets
Keep in mind that this does not help people with connection
heavy access patterns. If you have a lot of people doing
small transactions, ACK pacing as well as data traffic
dropping is necessary.
The heart of TCP pacing is ACK rates. All of it's data
sending is clocked via ACK arrival.
Therefore the best scheme seems to be ACK pacing along
with data dropping. The ACK pacing is the "nice" policing
where as the data dropping is the big hammer. Ideally, the
ACK pacing will produce the desired data rate and thus the
data dropping will not be necessary.
ACK pacing is more desirable also because of schemes such
as VEGAS congestion control which wish to test the limits
of a link without any data drops. It's basic idea is that
"if my delay increases, yet my throughput does not, I am
doing nothing more than eating router queue space and
therefore have gone beyond the limits of this path, back off"
I know there are problems with VEGAS, but it is a good example
to use in showing that the way to tame TCP's data sending rate
is by controlling the ACKs not by dropping the data, as a first
order method of policing.