[e2e] Policing TCP flows

[Dennis Ferguson]

Greg,

> 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.

I'll buy the factor, but I think there's something wrong that attributing
great importance to small factors like that (as opposed to the 0.5ms RTT LAN
case, where the difference to the same approximation is a factor of 1000)
especially because the drop rate in either case as a fraction of packets
sent is likely to be fairly modest.  If decreasing the already-low flow
control loss rate by a factor of 5 were of primary importance then wouldn't
we also conclude that:

- we should actually increase the buffer size from 96,000 bytes to
  500,000 bytes, since a 2.5 second queue will decrease the packet
  drop rate by another factor of 5.

- we should insist that everyone use an MSS of 300 bytes since, for a
  given queue byte length, this will reduce the drop rate by another
  factor of 5

- we should never implement RED or any other queue management scheme
  which attempts to moderate the average length of that (shaped) queue
  while keeping the delay-bandwidth pipe full since this will inherently
  increase the packet loss rate as well

If you make minimizing congestion control packet loss rates your primary
measure of goodness you'll end up concluding that infinite buffering and
infintesimal MSSes are optimum, and that can't be right.  In practice your
queue management should be aiming to drop/mark packets at whatever rate
is required to limit the average TCP window size to that minimally needed
to fill the path's bandwidth bottleneck (in your example above that's 12.5
1500 byte packets) using some worst-case path delay estimate.  If you have
both policers and shapers attempting to do this then over longer delay paths
I think you'll find that both end up at a drop rate which differs by only
a small factor, and which as a fraction of the packets being sent is
quite modest in either case.  It is only on paths with a very short
uncongested round trip that the policer loss rate starts to look stupid.

> > 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.)

The reason I'm not a fan of policers is that, while it is hard to screw
up the implementation of a real queue (everyone "knows" what this should
behave like), policer implementations seem subject to an infinitely
greater degree of damage.  More than this, as a practical matter they
always look awful over the short delay paths people use for testing in
their labs, and life is a bit short to spend explaining why this test
may not be indicative of real-life performance in a large network.  On
the other hand, over long-haul paths I believe good policers and
good shapers can produce similar results and that the difference between,
say, a 1% and a 2% flow control drop rate won't bother anyone too much.

Dennis Ferguson