[j-nsp] policing TCP traffic

[Robert O'Hara]

Hi Jason,

To some extent, I am theorizing, because I am not in front of your=20
test setup, but....  as noted, I think the burst-limit is set too high.
I guess the
thing to remember is that the larger you make your burst-limit, the
longer the delay will be for traffic that burst-above the bandwidth
limit.
100Mb is really big for a bandwidth-limit of 15 or 20Mb.

As you burst above your bandwidth limit of 15 or 20 Mb, the buffer you
have defined is
way too generous, and may be impacting tcp end to end.

This, in turn, is probably causing tcp global synchronization and
causing the end
stations to back off and the throughput is bound to drop off from the
sender while the
window gets renegotiated and the traffic climbs back to it's potential.
Without enough acks coming back to the sender, the sender cannot
take advantage of the pipe until it renegotiates a bigger window.

It's just a guess, but it wouldn't surprise me if that is what is
happening.  100Mb is a huge burst-limit for 15 or 20 mb rate. =20
Perhaps higher rates can work with that large a burst-limit  In fact, I
am surprised it accepted that as an in-range value, but I am not in
front of a router at the moment, so I am not sure what the acceptable
range is there.

I would send a predefined amount of traffic, look under traffic stats
and count the packets on the inbound
interface (absolute value), and the outbound interface (what made it
through). =20
Also, I'd add an extra counter to your filter for visibility - read
on...

When you do 'show firewall' you will see a counter named 'test-filter'.=20
This counter associated  with this policer and is counting the packets
dropped/discarded.
You can add a 'then count' statement to a named counter after you
perform the
'then discard' and this will show a count of the packets that make it
through
the policer. =20

The main thing to remember is that the policer is an algorithm that has
guidelines for use.
It's designed to be used for all bandwidth rates, and the burst-limit
parameter is designed
to be tweaked appropriately for various bandwidth rates.

Let me know how you progress with this.  I am interested in your
results.

Thanks,

Bob O'Hara =20

Systems Engineer

Juniper Networks - 'Every Bit IP'

.........................................
. Email:       rohara@juniper.net       .
. Cell:        603.498.8119             .
. Westford Office: 978.589.0127         . =20
.........................................

-----Original Message-----
From: Jason Parsons [mailto:jparsons-juniper@saffron.org]
Sent: Friday, August 30, 2002 3:59 PM
To: Robert O'Hara
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] policing TCP traffic


Thanks for the information Bob.

Do you have any comment about the performance of these filters at the=20
15M and 20M levels?  I'm looking for a plausible explanation of why TCP=20
throughput is so much lower than the policing level at these two rates.

Thanks again.
  - Jason Parsons


> =3D=3D> summary_15m_tcp_output.txt <=3D=3D
> Avg. bw per round =3D  11.2200 Avg. delay per round =3D   3.5190 ms
>                                         ^^^^^^^
> =3D=3D> summary_20m_tcp_output.txt <=3D=3D
> Avg. bw per round =3D  11.5500 Avg. delay per round =3D   3.4150 ms
>                                         ^^^^^^^