Mailing List Archive

policer useless
I've searched through the archives for this list and found a few mentions of
this problem but no real solutions or useful answers.

I'm trying to use a policer to limit a certain customer on a FastEthernet
interface to say 4Mbps:

filter test {
policer p1 {
if-exceeding {
bandwidth-limit 4m;
burst-size-limit 1m;
}
then discard;
}
term limit {
then {
policer p1;
accept;
}
}
}


No matter what I do, a single FTP session never even remotely reaches 4 Mbps
with this configuration, it is around 3.1 Mbps. Tried all possible
configurations of burst size limit, from small values to big values with only
slight variations in speed.

I do understand that the policer is working like CAR on Cisco's, but a simple

rate-limit output 4096000 768000 1536000 conform-action transmit exceed-action
drop

on a Cisco results in an exact limit of 4 Mbps, even for a single FTP session
I get exactly the expected result, while I can not find a working
configuration for JunOS.

Even if I try to run multiple parallel FTP sessions through our Juniper, the
sum of all sessions also never reaches 4 Mbps but stays at around 3.1 Mbps.

I tried other values (smaller and bigger) for the policed bandwidth and no
matter what I try I never get the configured speed. I even looked at the
Juniper whitepaper which talks about policing and it as an example of 256k
bandwidth-limit and 2k of burst-size-limit. With such a configuration, a FTP
transfer yields a mere 11 Kbps instead of the expected 256 Kbps.

So, to clear this up, can anybody supply me the bandwidth-limit values and
burst-size-limit values that would give me a 4 Mbps on a fast ethernet
interface?
policer useless [ In reply to ]
On Wed, Sep 11, 2002 at 01:53:33PM +0200, Blaz Zupan wrote:
> I've searched through the archives for this list and found a few mentions of
> this problem but no real solutions or useful answers.
>
> I'm trying to use a policer to limit a certain customer on a FastEthernet
> interface to say 4Mbps:

You're doing policing, which sabotages TCP's congestion avoidance
mechanisms. A problem VERY well known since the days of the IMPs. :-)

Basically, you have no chance. You need to do queuing... with
policing you're totally lost.

Policing is OK to have a "safety ceiling", but not for "limiting
regular traffic down to agreed levels".

We basically need a very easy knob in JunOS to configure egress AND
ingress queuing to a specific traffic level, but that knob doesn't
exist.


Best regards,
Daniel
policer useless [ In reply to ]
> You're doing policing, which sabotages TCP's congestion avoidance
> mechanisms. A problem VERY well known since the days of the IMPs. :-)

Ok, but isn't Cisco's rate-limit also policing? rate-limit on IOS works just
fine for me. I always though the difference between traffic-shape and
rate-limit on Cisco's was that traffic-shape was buffering packets and sending
them out at the expected rate on the other side, while rate limiting will be
the equivalent of JunOS policing, basically just throwing away all packets
above the agreed level. So, either IOS rate-limit is not the same as JunOS
policing or JunOS policing is not working as well as IOS rate-limit is.

> Basically, you have no chance. You need to do queuing... with
> policing you're totally lost.

Translation: I can't use a Juniper box in my case and need to move all those
sub-rate service customers to a Cisco box?

> Policing is OK to have a "safety ceiling", but not for "limiting
> regular traffic down to agreed levels".

Ok, I see. Basically, if we have lots of customers with slow links downstream
an interface, policing would work fine for us (limiting the aggregate
bandwidth available to those customers to an agreed level) but if those
customers have fast links and there's not that so many of them (i.e. if they
have a fast ethernet connection to our Juniper), policing will be basically
useless as it will heavily interfere with TCP.
policer useless [ In reply to ]
On Wednesday, Sep 11, 2002, at 10:14 US/Eastern, Daniel Roesen wrote:

> You're doing policing, which sabotages TCP's congestion avoidance
> mechanisms. A problem VERY well known since the days of the IMPs. :-)
>
> Basically, you have no chance. You need to do queuing... with
> policing you're totally lost.

I would love to see some Juniper folks comment on this. Is there
really no way to configure a policer and see acceptable TCP throughput
(and associated congestion avoidance)? What's the suggested
configuration for policing a single customer interface down to a lower
rate, especially if that customer delivers lots of TCP traffic?

- Jason
policer useless [ In reply to ]
On Wednesday, Sep 11, 2002, at 10:14 US/Eastern, Daniel Roesen wrote:

> You're doing policing, which sabotages TCP's congestion avoidance
> mechanisms. A problem VERY well known since the days of the IMPs. :-)
>
> Basically, you have no chance. You need to do queuing... with
> policing you're totally lost.

I would love to see some Juniper folks comment on this. Is there
really no way to configure a policer and see acceptable TCP throughput
(and associated congestion avoidance)? What's the suggested
configuration for policing a single customer interface down to a lower
rate, especially if that customer delivers lots of TCP traffic?

- Jason
policer useless [ In reply to ]
Try multiplying the rate you want by 1.25; I don't recall the exact number,
but this is approximately the factor between bytes on the line and bytes
required to transport them on J-cells thru the shared memory.


Rubens Kuhl Jr.


----- Original Message -----
From: "Blaz Zupan" <blaz@inlimbo.org>
To: <juniper-nsp@puck.nether.net>
Sent: Wednesday, September 11, 2002 8:53 AM
Subject: [j-nsp] policer useless


| No matter what I do, a single FTP session never even remotely reaches 4
Mbps
| with this configuration, it is around 3.1 Mbps. Tried all possible
| configurations of burst size limit, from small values to big values with
only
| slight variations in speed.
|

| So, to clear this up, can anybody supply me the bandwidth-limit values and
| burst-size-limit values that would give me a 4 Mbps on a fast ethernet
| interface?
policer useless [ In reply to ]
> Try multiplying the rate you want by 1.25; I don't recall the exact number,
> but this is approximately the factor between bytes on the line and bytes
> required to transport them on J-cells thru the shared memory.

Actually I tried setting the policer to 8m, the result was a transfer rate of
390 kbytes/s. I find no logic in this...
policer useless [ In reply to ]
I connected a Smartbits(R) with 2 fastethernet cards to a M10 with a =
fastethernet PIC.

Blasting 100Mbit/s small (64 byte) *raw IP* packets thru the box i get =
pretty accurate results.=20

smartbits -> fe-1/0/0.0 <-> fe-1/0/3.0 <- smartbits

With no policing 100% thruput (obviously)

bandwidth-limit 8m+burst 100k 7995400 bps
bandwidth-limit 2m/100k 1983448 bps
bandwidth-limit 4m/100k 3997240 bps
bandwidth-limit 256k/2k 244040 bps

This is using 1 static source/destination IP address on each smartbits =
port (10.5.5.5 and 10.6.6.6) routed thru the box (directly connected =
networks)

--
Markus =C5berg
Oy LM Ericsson Ab
E-mail: markus.aberg@ericsson.com
=20


-----Original Message-----
From: Blaz Zupan [mailto:blaz@inlimbo.org]
Sent: 11. syyskuuta 2002 21:56
To: Rubens Kuhl Jr.
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] policer useless


> Try multiplying the rate you want by 1.25; I don't recall the exact =
number,
> but this is approximately the factor between bytes on the line and =
bytes
> required to transport them on J-cells thru the shared memory.

Actually I tried setting the policer to 8m, the result was a transfer =
rate of
390 kbytes/s. I find no logic in this...

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp
policer useless [ In reply to ]
Please contact Juniper support so they may assist in configuring
policing suitably for your application.

Thanks,
Robert.

On Wednesday, September 11, 2002, at 11:56 AM, Blaz Zupan wrote:

>> Try multiplying the rate you want by 1.25; I don't recall the exact
>> number,
>> but this is approximately the factor between bytes on the line and
>> bytes
>> required to transport them on J-cells thru the shared memory.
>
> Actually I tried setting the policer to 8m, the result was a transfer
> rate of
> 390 kbytes/s. I find no logic in this...
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
policer useless [ In reply to ]
Hi Markus,


I think the problem that Blaz is seeing has to do with the windows =
size
and the burst-size being used. I ran into this problem before and if I
recall recorrectly, I was using a small burst burst-size close to the =
MTU
which I think was 1500 which gave me poor results. Noticing the window =
size
being requested from the PC, what was occuring was that it was allowing =
the
traffic to burst and then it would drop it. It would then renegotiate =
the
window size and would have to retransmit a lot of traffic over again. =
This
cause the performance to be very poor. My solution was to increase the
burst-size to atleast 10x the MTU to get the results that I was looking =
for,
otherwise, I would see the same issues Blaz is seeing. My 2 cents.


Thanks,

Mario Puras
SoluNet Technical Support=20



-----Original Message-----
From: Markus =C5berg (LMF) [mailto:Markus.Aberg@lmf.ericsson.se]
Sent: Thursday, September 12, 2002 10:48 AM
To: juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] policer useless


I connected a Smartbits(R) with 2 fastethernet cards to a M10 with a
fastethernet PIC.

Blasting 100Mbit/s small (64 byte) *raw IP* packets thru the box i get
pretty accurate results.=20

smartbits -> fe-1/0/0.0 <-> fe-1/0/3.0 <- smartbits

With no policing 100% thruput (obviously)

bandwidth-limit 8m+burst 100k 7995400 bps
bandwidth-limit 2m/100k 1983448 bps
bandwidth-limit 4m/100k 3997240 bps
bandwidth-limit 256k/2k 244040 bps

This is using 1 static source/destination IP address on each smartbits =
port
(10.5.5.5 and 10.6.6.6) routed thru the box (directly connected =
networks)

--
Markus =C5berg
Oy LM Ericsson Ab
E-mail: markus.aberg@ericsson.com
=20


-----Original Message-----
From: Blaz Zupan [mailto:blaz@inlimbo.org]
Sent: 11. syyskuuta 2002 21:56
To: Rubens Kuhl Jr.
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] policer useless


> Try multiplying the rate you want by 1.25; I don't recall the exact
number,
> but this is approximately the factor between bytes on the line and =
bytes
> required to transport them on J-cells thru the shared memory.

Actually I tried setting the policer to 8m, the result was a transfer =
rate
of
390 kbytes/s. I find no logic in this...

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp
policer useless [ In reply to ]
On Thu, Sep 12, 2002 at 04:47:30PM +0200, Markus Ã…berg (LMF) wrote:
> I connected a Smartbits(R) with 2 fastethernet cards to a M10 with
> a fastethernet PIC.
>
> Blasting 100Mbit/s small (64 byte) *raw IP* packets thru the box i
> get pretty accurate results.

We're talking about TCP performance, not connectionless datagram
throughput. You're measuring the wrong thing. :-)


Best regards,
Daniel
policer useless [ In reply to ]
At 06:45 PM 9/12/2002 +0200, Daniel Roesen wrote:
>On Thu, Sep 12, 2002 at 04:47:30PM +0200, Markus =C5berg (LMF) wrote:
> > I connected a Smartbits(R) with 2 fastethernet cards to a M10 with
> > a fastethernet PIC.
> >
> > Blasting 100Mbit/s small (64 byte) *raw IP* packets thru the box i
> > get pretty accurate results.
>
>We're talking about TCP performance, not connectionless datagram
>throughput. You're measuring the wrong thing. :-)

I believe that Markus has measured whether the policer (which is
apparently what Blaz had configured on his box) does indeed police
traffic to the expected levels. Markus indicates that it seems to
do so. I'm not sure this is an issue or "right" or "wrong", but rather,
how should Blaz configure his box to get the desired behavior.
Clearly, as you have pointed out, behavior of a TCP connection
when policed is different from the behavior when it is shaped (or
"queued" per some of the other messages in this thread).
Claiming that policing is completely useless is certainly within
your rights, however there are plenty of service providers who
choose to police traffic (whether using routers, frame relay switches,
etc.) and of course, lots of TCP traffic flows through these devices.

dave
policer useless [ In reply to ]
> I think the problem that Blaz is seeing has to do with the windows size
> and the burst-size being used. I ran into this problem before and if I
> recall recorrectly, I was using a small burst burst-size close to the MTU
> which I think was 1500 which gave me poor results. Noticing the window size
> being requested from the PC, what was occuring was that it was allowing the
> traffic to burst and then it would drop it. It would then renegotiate the
> window size and would have to retransmit a lot of traffic over again. This
> cause the performance to be very poor. My solution was to increase the
> burst-size to atleast 10x the MTU to get the results that I was looking for,
> otherwise, I would see the same issues Blaz is seeing. My 2 cents.

Actually, I tried with the burst-size set to 15000 (10x the MTU), 1m and some
other settings, but even with a very high burst-size (equaly to the
bandwidth-limit, for example), the result is not what I would expect.
policer useless [ In reply to ]
> I believe that Markus has measured whether the policer (which is
> apparently what Blaz had configured on his box) does indeed police
> traffic to the expected levels. Markus indicates that it seems to

Actually I agree on this. I have a ISP connected to us and am policing him at
40 Mbps and he *does* reach this limit - apparently because an ISP's traffic
pattern is made up of lots of TCP, UDP and other traffic flows. But trying to
get a single TCP flow to reach the policed transfer rate does not seem to
work. I've read the various explanations posted on this list and I'm trying to
understand why I don't see the same behaviour with Cisco's CAR (rate-limit)
which is supposed to be the same as JunOS policing.

> do so. I'm not sure this is an issue or "right" or "wrong", but rather,
> how should Blaz configure his box to get the desired behavior.

Agreed.

> Clearly, as you have pointed out, behavior of a TCP connection
> when policed is different from the behavior when it is shaped (or
> "queued" per some of the other messages in this thread).

Agreed on this as well, as I said in another post, I'm not comparing JunOS
policing to Cisco traffic shaping (which would be comparing apples to
oranges) but I am comparing Cisco CAR to JunOS policing, which is (at least to
my understanding) supposed to be the same thing.

> Claiming that policing is completely useless is certainly within
> your rights, however there are plenty of service providers who
> choose to police traffic (whether using routers, frame relay switches,
> etc.) and of course, lots of TCP traffic flows through these devices.

Exactly, and I'm not saying policing is useless, I'm saying that policing as
I'm currently expericing it in my test is useless - I'm trying to find out why
this is so and reading through the archives of this list and don't think I'm
alone. :-)
policer useless [ In reply to ]
> Please contact Juniper support so they may assist in configuring
> policing suitably for your application.

I have been contacted by Sean Capshaw from Juniper who requested more
information and offered help. I'll follow up with him and post the results to
this list for all those interested in them.
policer useless [ In reply to ]
Jason,

Daniel's statement below is a generic statement regarding policing vs.
shaping. Nothing to do w/ implementations. As for the original
problem, I'm not prepared to make any general statements regarding the
results (not sure if anyone else is either), because I don't think we
know enough about the details of the test. There are just too many
possible variables. I think we're getting the original test details
from Blaz and someone should post the result.

Anyway, It is possible to configure policing and see acceptable TCP
throughput. For example, I setup the test below:

fe-1/0/0
+-------+
+----+ | | +----+
| +---------+ R22 +---------+ |
+----+ | | +----+
Thunky +-------+ PC2
fe-1/0/1

-PC2 does FTP get from Thunky
-3 tests - no policer, 4m policer (same config as Blaz Zupan), and 256k
policer
-policer is applied input to fe-1/0/0
-packets are going into q0 on fe-1/0/1 w/ default scheduling

(on the client)
average throughput for no policer =3D 5737.16Kbytes
average reported throughput for 4m policer =3D 467.07 Kbytes
average reported throughput for 256k policer =3D 28.35 Kbytes

During this test, while using the "monitor interface traffic" command, I
saw the following output bps on fe-1/0/1:

...
4401936 bps
3071256 bps
5108616 bps
3629104 bps
2831680 bps
5512072 bps
2986784 bps
3111328 bps
3907872 bps
4159016 bps
...

The config I used wasn't fancy.

filter test {
policer rate_limit {
if-exceeding {
bandwidth-limit 4m;
burst-size-limit 1m;
}
then discard;
} =20
term one {
then {
policer rate_limit;
accept;
}
}
} =20

Hope this helps,
Andy




>-----Original Message-----
>From: Jason Parsons [mailto:jparsons@saffron.net]
>Sent: Wednesday, September 11, 2002 1:17 PM
>To: Daniel Roesen
>Cc: Blaz Zupan; juniper-nsp@puck.nether.net
>Subject: Re: [j-nsp] policer useless
>
>
>
>On Wednesday, Sep 11, 2002, at 10:14 US/Eastern, Daniel Roesen wrote:
>
>> You're doing policing, which sabotages TCP's congestion avoidance
>> mechanisms. A problem VERY well known since the days of the IMPs. :-)
>>
>> Basically, you have no chance. You need to do queuing... with
>> policing you're totally lost.
>
>I would love to see some Juniper folks comment on this. Is there=20
>really no way to configure a policer and see acceptable TCP throughput=20
>(and associated congestion avoidance)? What's the suggested=20
>configuration for policing a single customer interface down to a lower=20
>rate, especially if that customer delivers lots of TCP traffic?
>
> - Jason
>
>_______________________________________________
>juniper-nsp mailing list juniper-nsp@puck.nether.net
>http://puck.nether.net/mailman/listinfo/juniper-nsp
>