[e2e] Policing TCP flows

[Olivier Bonaventure]

Reuven,
> 
> please be patient with me. I'm a newbie here:
> 
> Simply stated, I want to know what the effect of "policing"
> tcp traffic would be, compared to "shaping" it.

>From a TCP performance point of view, policing is worse than shaping
for TCP. The main reason is that when you delay a packet, TCP
adjusts easily since the rtt increases while when you drop a 
packet, TCP is forced to react as if congestion occured.
 
However, from an operational point of view, it is much easier
for a router to perform policing than shaping and thus policing
is much more often deployed than shaping.

> a) Is the smooth rate unstable towards the burst per RTT? I mean, supposing the
> window is slightly increased, such that the policer discards a single packet-
> does the congestion response of tcp drive it to the burst pre RTT, or does it
> pull itself back into the "smooth rate" state?
>

See http://www.ietf.org/rfc/rfc2963.txt?number=2963 for a simple shaper that
surprisingly works well with a diffserv policer

> b) Suppose there are several tcp flows being policed together?
> 
> c) any literature on this subject?  I saw some papers about how ABR is bad for tcp,
> but is this really the same thing?

For TCP over ATM (CBR variant, VBR variant and GFR variant), you can have a look
at :

Integration of ATM under TCP/IP to provide services with minimum guaranteed bandwidth, 
O. Bonaventure, Ph.D. thesis, University of Liège, Belgium, October 1998
http://www.info.fundp.ac.be/~obo/doc/PhD-OlivierBonaventure.ps.gz


Olivier

-- 
http://www.infonet.fundp.ac.be