Thursday, December 14, 2017

QoS, Shaping vs. Policing and TCP

I must have some misunderstanding of TCP as when I implement a policer on a port, it breaks TCP (but UDP works just fine.) When I change the policer on ingress to a shaper on egress, it works just fine.

I get 30Mbps for a 100Mbps policer (on a 1G port) with the max burst available in the equipment, but when I implement a shaper, everything smooths out just fine to ~92Mbps for a 100Mbps shaper.

I am running an IPerf to measure speeds and when I limit the bandwidth to ~70Mbps, it works fine on both the policer and shaper (I suppose because congestion control is not triggered.) When I bump it up to 80Mbps, it drops down to ~30 on the policer. Normally IPerf tries to send close to line speed / 1G, so I know there will be drops through both the shaper and policer. Shouldn't TCP congestion control detect the packet loss and adjust the congestion window to compensate? Since in either case I'm sending more than can go through, I know that at some point there will be drops, so why does it work in one case, but not the other? This happens both with IPerf and a file transfer (the initial problem I received.)

For some additional context, I have tried this through both an ME3400 and an Adtran device, both getting the same results with the policer. I am not going to use the Adtran because the model I'm using can't shape per EVC (and Adtran TAC has been very annoying to me lately,) but I can implement a hierarchical shaper on the Cisco and it seems to get the job done.

Can anyone tell me what I'm missing? Is there anything else I can be doing to get a policer to work?



No comments:

Post a Comment