[e2e] Policing TCP flows

[Dennis Ferguson]

Greg,

> the TCP connection gets the same amount of throughput ("goodput") in both 
> cases, but the "badput" is radically different.  policing incurs lots more 
> badput.
> 
> if you look at plots from traces, what you see is that with policing, the RTT 
> is very low, so the "probe-until-drop" cycle is very short, so you get lots of 
> these cycles in the same elapsed time.  with shaping, the RTT is 
> (artificially) high, so the "probe-until-drop" cycle is very long and you get 
> fewer of these cycles in the same elapsed time.  since the amount of data 
> transmitted is the same (in this "same elapsed time"), with policing you drop 
> lots more packets.
> 
> if you hate dropped packets, you'll hate policing.

Somehow this sounds to me like a special-case observation, however.  The
necessary length of a queue is supposed to be on the order of the
delay-bandwidth product of the path, which means that in a "normal" case
an absolutely full queue shouldn't do more than double the RTT.  Furthermore,
RED and other congestion feedback schemes (or their policer equivalents) are
supposed to moderate the queue occupancy such that the congested queue
length remains some fraction of full under stable load conditions, so
a queuing discipline which is better than fill-and-drop should usually
increase the RTT only by some fraction (substantially less than 2) under
congestion if it is behaving properly.

I hence suspect you may have made your observations on traffic between
two hosts which were very close together such that the uncongested RTT
was tiny and any queue at all represented a significant increase in the
RTT relative to the uncongested number.  If you did the experiment over
a long haul path instead I suspect you would get a significantly
different result.

Dennis Ferguson