QoS for outbound traffic

[tetu04]

Hello,

One of our customers has 2 T1's that terminate into a NeteVanta 838 (provided by carrier) and provide Ethernet handoffs to the Adtran908e. For quite some time I have been monitoring their calls and I have been noticing a lot of calls receiving lower MOS scores due to packet loss. The site only has around 28 phones and a 3Mbit pipe of dedicated internet access with prioritized voice traffic from the carrier. I have asked the carrier to investigate this issue and explain why packet loss still occurs under all these circumstances. They replied by saying that they manage the download QoS/CoS and we need to manage the upload to guarantee EF. They also said that this customer is bursting 3300bytes within 20 seconds of having the counters cleared at the prem site and this is affecting the calls regardless of voice traffic prioritization. I have enabled the following QoS map on the router and they carrier still notices the bursts.

ip access-list extended qos-match-coredial

  permit udp any  host x.x.x.x ( <-- voice server)

qos map qos-map-coredial 10

  match ip list qos-match-coredial

  priority percent 3

  set dscp 46

interface eth 0/2

  description Connection to OUTSIDE

  speed 100

  ip address  x.x.x.x  x.x.x.x

  media-gateway ip primary

  qos-policy out qos-map-coredial

  no shutdown

The bandwidth of eth 0/2 is set to 100000Kbit, 100Mb/s full-duplex. I just need some suggestions how to improve that QoS map. Should I hardcorde the interface with 3Mbit and then specify the priority percent? Should I use max-reserved-bandwidth and traffic-shape-rate in the config?

Thanks in advance,

Adrian

[Anonymous]

Tetu04,

Thanks for posting!  Yes, you should generally have a traffic shape rate applied for QoS to any ethernet interface where the bandwidth might bottleneck or be policed upstream.  Below is a configuration you might try.

ip access-list extended qos-match-coredial

  permit udp any  host x.x.x.x ( <-- voice server)

!

qos map qos-map-coredial 10

  match ip list qos-match-coredial

  priority percent 50

  set dscp 46

!

interface eth 0/2

  qos-policy out qos-map-coredial

  traffic-shape rate 3000000

The priority percentage is up to you, but should be based on the maximum number of concurrent calls you expect, and the voice codec in use.  Feel free to reply on this thread if you have further questions.

Thanks!

David

[tetu04]

David,

I was actually able to get the qos map implemented correctly

qos map qos-map-coredial 10

  match ip list qos-match-coredial

  priority unlimited

  set dscp 46

interface eth 0/2

  description Connection to OUTSIDE

  speed 100

  ip address  207.238.229.154  255.255.255.252

  ip packet-capture glf-traffic-capture

  media-gateway ip primary

  traffic-shape rate 3000000

  max-reserved-bandwidth 100

  qos-policy out qos-map-coredial

  no shutdown

ip access-list extended qos-match-coredial

  permit udp any  host 64.94.197.230

  deny   udp any  any eq 5060

*********************************

greatlakes.ta908e-1#sh qos map interface eth 0/2

eth 0/2

qos-policy out: qos-map-coredial

  map entry 10

     match ip list qos-match-coredial

     set DSCP value to 46

     priority bandwidth: unlimited

       note: since unlimited, other qos bandwidths cannot be assured

     packets matched: 1143794, bytes matched: 288725884

   map entry default

     packets matched: 4492079, bytes matched: 1523550066

     packets dropped: 97, bytes dropped: 145666

     5 minute offered rate 1336104 bits/sec, drop rate 0 bits/sec

At this point the carrier doesn't see us bursting anymore and they also do not see any EF drops or any packet loss on their local loop. The low MOS calls still exist as before and the customer is still complaining. Is there any information within the Adtran device that I can obtain that provides proof that this issue is a result of the carrier’s network? At this point, the carrier will do nothing about it until I obtain proof. I have copied call examples from nCommand that clearly shows low MOS score, packet loss and reason of degradation but it is still not enough proof. I will go on site and run some packet capture and hopefully some bad calls will appear and I can show them the packet loss in the RTP Stream Analysis. If you have any other suggestions, please advise.

Thanks,

Adrian

[Anonymous]

Tetu04,

The QoS on the Adtran is only going to help with the outbound audio flow.  I think a packet capture, and RTP stream analysis, is a good idea to show exactly how the packets are arriving at the Adtran unit.  Outside of VQM, we often check "show voice quality-stats" for further calls statistics.  We recommend R10.5.3 firmware when using this command since some improvements to the output were made starting with R10.5.0.  A low delay and low jitter network will usually result in no discards, no drops, and average and maximum delay of 50ms.  Below is a link to a document that goes over the statistics in more detail.  See page 15.

Understanding Call Quality Statistics in AOS

Thanks!

David

[Anonymous]

Tetu04,

Were you able to get the packet capture and do any RTP analysis within Wireshark?  Feel free to leave an update on here or any additional questions you may have.

Thanks,

David

[tetu04]

Hello David,

I went on site and ran multiple packet captures. The packet captures clearly show the packet loss in the RTP stream analysis. The packets cross two different networks until they reach the SIP server provider's voice server. As I mentioned above, I have been working with the T1 provider. I have sent them all the captures and after QoS maps were applied on both ends, they concluded that their network is clean and the packet loss has to happen somewhere upstream. I am in the process of hearing back from the second ISP provider to see what their results indicate.

[Anonymous]

Tetu04,

I went ahead and flagged this post as "Assumed Answered".  If any of the responses on this thread assisted you, please mark them as Correct or Helpful as the case may be with the applicable buttons.  This will make them visible and help other members of the community find solutions more easily.  If you still need assistance, I would be more than happy to continue working with you on this - just let me know in a reply.

Thanks!

David