[e2e] Policing TCP flows

[Vinay Bannai]

Reuven,

You bring very interesting issues to light. At least in the cases where I
have had to deal with rate limiting with or without shaping buffers, I found
the TCP performance was nowhere close to the rate that was set on the port
when there was no shaping done. Here are salient points from my experience 

1) If you do not have shaping buffers, single flow TCP performance varies
wildly when you try to pump data at the rate that is set
2) If you have longer RTT, the variation is little less but there is still
some variation
3) Multiple TCP flows helps to achieve data rate close to the rate limit
that is set
4) Increasing burst size (not the shaping buffer size) for the policer also
tends to achieve data rate close to the rate limit, when the rate is set to
a high value. At a lower rate, increasing burst size causes variations.
5) In other words, having a shaping buffer for the policer help prevent
dropped packets (they may be delayed a little) and help get much better TCP
performance

Thanks
Vinay

-----Original Message-----
From: Reuven Zeitak [mailto:reuven.zeitak at nativenetworks.com] 
Sent: Tuesday, June 18, 2002 8:31 AM
To: end2end-interest at postel.org
Subject: [e2e] Policing TCP flows

Dear all,

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.

Naively, tcp squirts "bursts" into the network, which get spread
out by the network properties. Then self clocking sets in, and tcp
sends packets at the speed of ack.

Policers just discard packets that are non conforming, but the conforming
packets are not paced according to the policer's rate.  It seems to
me that a single tcp flow that is going through a single policer, will
settle
down to something like one policer allowed "burst" per RTT instead of 
adjusting itself to a smooth packet rate ( please excuse my terminology).

On the other hand, a stream that is running at a smooth rate, and is
conforming,
will send ack's at the correct speed, and ( window growth notwithstanding)
the correct
rate is maintained.

For completeness, I'll note that if the flow was "shaped", there are no
"bursts", since
the spread is set by the shaper, not by the entire network.

questions:

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?

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?

Thank you for your patience

reuven