[j-nsp] policing TCP traffic

[Jason Parsons]

I will try that, but I'm a little confused about why the performance 
would suffer only at the 15 and 20M rates, but not at 5M, 10M, or 25M 
(per my original email).  Maybe it's some artifact of packet size?

We'll try a policer such as:

firewall {
     policer test-policer {
         if-exceeding {
             bandwidth-limit 15M;
             burst-size-limit 47000;
         }
         then {
             count policer-drop;
	   discard;
         }
     }
     family inet {
         filter filter-name                  {
             policer test-policer {
                 if-exceeding {
                     bandwidth-limit 15M;
                     burst-size-limit 47000;
                 }
                 then {
		 count policer-accepted;
                     accept;
                 }
             }
         }
     }
}

This is on a fast ethernet, by the way.

Thanks.
  - Jason

On Friday, Aug 30, 2002, at 19:33 US/Eastern, Robert O'Hara wrote:

> Hi Jason,
>
> To some extent, I am theorizing, because I am not in front of your
> 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.
> 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).
> 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'.
> 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.
>
> 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
>
> Systems Engineer
>
> Juniper Networks - 'Every Bit IP'
>
> .........................................
> . Email:       rohara@juniper.net       .
> . Cell:        603.498.8119             .
> . Westford Office: 978.589.0127         .
> .........................................
>
> -----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
> 15M and 20M levels?  I'm looking for a plausible explanation of why TCP
> throughput is so much lower than the policing level at these two rates.
>
> Thanks again.
>   - Jason Parsons
>
>
>> ==> summary_15m_tcp_output.txt <==
>> Avg. bw per round =  11.2200 Avg. delay per round =   3.5190 ms
>>                                         ^^^^^^^
>> ==> summary_20m_tcp_output.txt <==
>> Avg. bw per round =  11.5500 Avg. delay per round =   3.4150 ms
>>                                         ^^^^^^^
>