[e2e] Policing TCP flows

[Greg Minshall]

Dennis,

----
red: {172} dc
64 1500 * p 8 * p
96000
768000
6 k
1500000 / p
.512000
red: {173} ping XXXX
PING XXXX (YYYY): 56 data bytes
64 bytes from YYYY: icmp_seq=0 ttl=238 time=103.602 ms
64 bytes from YYYY: icmp_seq=1 ttl=239 time=100.607 ms
64 bytes from YYYY: icmp_seq=2 ttl=239 time=101.962 ms
^C
--- XXXX ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 100.607/102.057/103.602 ms
----

so, if we buffer 64 full sized packets and "let them out" (shape to) 1.5Mb/s, 
we end up with a delay of something like 500ms.  and, if we are sending cross 
country with a "natural" RTT of 100ms, then were quintupling the RTT.  i 
*think* from my look-see years ago that this means a *policer* will drop 5 
times as many packets as a shaper, at least to a zero-th approximation.  this 
is because TCP will go through its probe-till-drop cycle 5 times as often with 
a policer as with a shaper.

> This should not be taken to imply that I'm a fan of policers, by the way.

i'd *much* rather build (or buy, for that matter) a policer than a shaper, 
just because of memory costs.  but, there is such a prejudice against "packet 
drops", it might be a hard sell!  (and, to be fair, if the "cost" of the past 
from the sending host to the policer is "expensive", there is a reason to 
prefer a shaper.)

cheers, Greg