Increased Jitter when E1 link is fully utilised

exonetinf1nity · ‎01-25-2009

Greetings, i have noticed recently that when our 2Mbit/s E1 link is fully utilised Jitter and Average Jitter increase to ~30 - 60 as viewed from a 7941G handset, when the link is idle both these values hover between 0 - 5.

Now we arnt having any voice quality problems and MOS scores are always above 4 but i was wandering if i could somehow reduce this and work towards an optimal configuration.

The link tends to be fully utilised when people are downloading large web files like service packs.

The current config as below has been built to sustain 10 concurrent G711 calls and shape web traffic to 1Mbit/s.

!

class-map match-any voiceControl

match protocol sip

class-map match-any voiceMedia

match protocol rtp audio

match access-group name voiceRtp

class-map match-any webTraffic

match protocol http

match protocol smtp

class-map match-any voiceRemark

match ip dscp ef

match ip dscp cs3

match ip dscp af31

!

policy-map webControl

class webTraffic

shape average 1000000

policy-map voiceQos

class voiceMedia

priority 1000

set dscp ef

class voiceControl

bandwidth percent 5

set dscp af31

class voiceRemark

set dscp default

class class-default

fair-queue

!

interface FastEthernet0/0

bandwidth 2048

ip address **************

speed 100

full-duplex

service-policy output webControl

!

interface Serial0/0/0

bandwidth 2048

ip unnumbered FastEthernet0/0

service-policy output voiceQos

!

ip access-list extended voiceRtp

permit udp any any range 16384 32767

Any advice would be much appreciated.

Regards

Joseph W. Doherty · ‎01-25-2009

If your MOS is acceptable, you might leave well enough alone. However, a couple of things you might try including setting tx-ring-limit to minimum value on your interfaces (this will minimize hardware buffering FIFO queuing - later IOSs, I've read, better set this value for VoIP), and/or decreasing maximum or usual MTU. For the latter you can use the ip tcp adjust-mss command in the serial interface. This reduces serialization and hardware buffering FIFO delay.

Don't forget, you should consider both directions (which really requires setings on both ends of the WAN link, not just one WAN router (and possibly other network devices too, e.g. LAN).

PS:

In you configuration, you're shaping WEB traffic on LAN facing(?) interface, outbound. It will certainly shape traffic being placed on the LAN, but if the intent is to regulate inbound WEB traffic on the WAN link, it won't really control inbound data bursts on the WAN link. Further, since you're shaping rather than policing, incoming WEB traffic will likely see less drops and not slow their data transmission rates.

Much better would be controlling outbound WEB traffic on the other side of the WAN link.

exonetinf1nity · ‎01-25-2009

All very useful information, in terms of manually setting the MTU would it be feasible to define both the MSS and MTU values as below.

interface FastEthernet0/0

ip tcp adjust-mss 1452

!

interface Serial0/0/0

mtu 1492

!

Ill also try changing from shaping to policing.

Regards

Nicholas Matthews · ‎01-25-2009

A couple of things to check:

Check the 'show policy-map interface' to make sure that your Remark isn't catching some voice you don't expect. For instance, some SIP providers will use a different port range. You should be matching on match protocol rtp, but it's worth checking.

Is it possible that the jitter is happening in the provider network? It may be worth getting a packet capture on both ends of the WAN link to make sure you're not oversubscribing your voice-queue in the provider network.

-nick

exonetinf1nity · ‎01-26-2009

Thank you Nick, i have checked the above, all seems to be ok, im engaging with the provider at the moment to better gauge there support for this configuration.

Regards

Joseph W. Doherty · ‎01-26-2009

You could set your MSS and MTU as you note, but I like to avoid decreasing MTU since it can lead you into fragmentation issues. (Assuming most of the traffic of high bandwidth usage is TCP, you only really need to decrease the MSS.) Also, there wouldn't be much difference between standard Ethernet 1460/1500 vs. your 1452/1492. I would suggest about 1/3 of the standard MSS. (Which isn't too far from "Internet" [RFC879] standard MSS/MTU [536/576] when PMTU isn't working when leaving the local subnet. Also something you might want to check, i.e. whether packets are full standard sized or not.)

As too changing from shaping to policing, it should drop sooner, but practically I also found it still not very effective for trying to regulate upstream bandwidth. If you don't control the other side of the WAN link, see if your provider will cooperate to support your QoS policy.

For an E1, the best approaches are insuring the interface hardware's FIFO buffer isn't a problem and controlling both sides of the link's egress.

PS:

Nick mentions a good point about provider's WAN performance. If your serial link is a dedicated p2p leased line, it shouldn't be an issue, but often WAN clouds (e.g. ATM, FR, MPLS) can be.

exonetinf1nity · ‎01-26-2009

Thank you for the points raised, as mentioned above im going to engage with the provider and see whether there policies are compatible with the one im using at my end.

I also appreciate the points raised about having control at each end of the WAN link.

Something i didnt mention earlier but this policy applies to the edge router, would the policy on the CME router which sites behind an ASA5510 need to match that of the edge device?

At present switch ports connected to both the CME system and the firewall are set to trust DSCP.

Regards

Joseph W. Doherty · ‎01-26-2009

When supporting VoIP, the whole path should be considered. It's not just a question of setting or trusting DSCP markings, but whether all the path's network devices insure best treatment of VoIP packets.

I.e., yes your CME router and ASA firewall should be properly configured, but so might all switches.

paolo bevilacqua · ‎01-26-2009

By all means I recommend against reducing MTU on serial circuits. In most cases you will be only making worst due to the added overhead of fragment headers, and not reach any benefit.

As long you have no degradation in voice or packets delay/loss, the QoS you're doing is acceptable. To investigate properly, look at the stash of show policy interface, etc.

exonetinf1nity · ‎01-26-2009

Thank you all for your comments, it's helped to put my worries to rest.

Regards

paolo bevilacqua · ‎01-26-2009

I mean "set" for "stash" ?!? But it gives the idea anyway LOL.

Thanks for the nice rating and good luck!

Mohamed Sobair · ‎01-26-2009

Hello,

When a queue Packet is full, Cisco IOS software has no place to put extra traffic and as such the packet have to be dropped, this behaviour is called a Taildrop behaviour.

In this case,u have 2 possible solutions:-

1- Applying Congestion avoidance Mechanism, to avoid Global TCP Synchronization and Drops Packet from the most aggressive flow. (This should be applied for all TCP Traffic).

2- If you applying Queing along with shaping at the same Interface, you will need to have a herarichal Policy (Nested Policy) in the serial Interface.

This assuming you have ur MQC properly configured, You should classify and Mark at the Ingress (Inbound direction) , and set your QoS policy apllied at the egress (Outbound Direction).

HTH

Mohamed