[j-nsp] inbound policing

[Wim Derijnck]

Hi,

As it happens I've just done some testing myself, UDP and TCP continues stream 
using two servers running iperf.  Two juniper routers in between with fe 
connections. My findings are the opposite, it's actually difficult to reach 
the bandwidth limit.  For TCP you see the output below, it's an average over 
5 seconds, if you make the burst size larger it only has an influence for the 
first packets which are buffered, enlarging the tcp window size on the 
servers has no effect. (Policer is set to to cut-of at 5Mb/s and I'm using 
scu filtering--> filtering based on source address)

juniper6:/ # iperf -s -i 5
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  6] local 192.168.1.10 port 5001 connected with 192.168.20.20 port 1279
[ ID] Interval       Transfer     Bandwidth
[  6]  0.0- 5.0 sec  2.81 MBytes  4.71 Mbits/sec
[  6]  5.0-10.0 sec  2.69 MBytes  4.51 Mbits/sec
[  6]  0.0-10.1 sec  5.52 MBytes  4.59 Mbits/sec


For UDP I found that when sending 100Mbit/s a lol of packets are dropped and I 
get an output of around 4.88Mb/s, a little higher then with a TCP stream. 
When sending exactely just 5Mb/s of UDP traffic the policer cuts off at just 
5Mb/s (Second example) The Bandwidth output is an average over  2 seconds 
this time.

juniper6:/ # iperf -s -u -i 2
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 64.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.10 port 5001 connected with 192.168.20.20 port 1261
[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total 
Datagrams
[  3]  0.0- 2.0 sec  1.29 MBytes  5.39 Mbits/sec  0.257 ms 7537/ 8454 (89%)
[  3]  2.0- 4.0 sec  1.16 MBytes  4.87 Mbits/sec  0.452 ms 7621/ 8450 (90%)
[  3]  4.0- 6.0 sec  1.16 MBytes  4.89 Mbits/sec  0.473 ms 7626/ 8457 (90%)
[  3]  6.0- 8.0 sec  1.16 MBytes  4.89 Mbits/sec  0.380 ms 7643/ 8474 (90%)
[  3]  8.0-10.0 sec  1.16 MBytes  4.88 Mbits/sec  0.400 ms 7628/ 8458 (90%)
[  3]  0.0-10.2 sec  5.94 MBytes  4.86 Mbits/sec  15.761 ms 38056/42295 (90%)
[  6] local 192.168.1.10 port 5001 connected with 192.168.20.20 port 1261

[ ID] Interval       Transfer     Bandwidth       Jitter   Lost/Total 
Datagrams
[  6]  0.0- 2.0 sec  1.19 MBytes  5.00 Mbits/sec  0.056 ms    0/  850 (0%)
[  6]  2.0- 4.0 sec  1.19 MBytes  5.00 Mbits/sec  0.331 ms    0/  850 (0%)
[  6]  4.0- 6.0 sec  1.19 MBytes  5.00 Mbits/sec  0.240 ms    0/  851 (0%)
[  6]  6.0- 8.0 sec  1.19 MBytes  5.00 Mbits/sec  0.291 ms    0/  850 (0%)
[  6]  8.0-10.0 sec  1.17 MBytes  4.90 Mbits/sec  0.332 ms   17/  850 (2%)
[  6]  0.0-10.0 sec  5.94 MBytes  4.98 Mbits/sec  0.294 ms   17/ 4253 (0.4%)


Juniper has a formula for buffer size and it comes down to 26kbyte per Mbit 
but the effect is minimal.
regards,
Wim Derijnck



On Monday 30 August 2004 19:36, Richard A Steenbergen wrote:
> On Mon, Aug 30, 2004 at 09:27:04AM -0700, Paul Goyette wrote:
> > > More than likely it is just the nature of the beast, policers can't be
> > > perfectly accurate. He might also be able to get more exact performance
> > > by tuning the burst limit, though "to what" is something I'm not even
> > > going to try and touch. Why Juniper hasn't added an "auto-burst-limit"
> > > directive or some kind of bandwidth/delay calculator with recommended
> > > values to the CLI is still beyond me. :P
> >
> > Maybe for the exact same reason that you won't "try and touch it"?  :)
>
> Well I've at least seen recommended formulas tossed around here, based on
> bandwidth, delay, and mtu size, which I can't seem to remember. This would
> at be one step better than a completely random number wouldn't it? :)