edge, tech-tips Tech Tips | NETSCOUT

The Edge Tech Tips

Short (mostly), quick and easy-to-read technical tips for network pros.

The Impact of Network Packet Loss and QoS on UC&C

Authored by Chris Greer

Unified Communications and Collaboration services have become a critical IT component for most business processes. UC&C combines messaging, voice, video, and data services into one platform, enabling employees and other personnel to quickly interact on projects regardless of their physical location or access method. UC&C can be hosted in a cloud or hybrid environment.

Like all services running over data networks, UC&C performance is susceptible to latency, delay, jitter and of course, packet loss.

When implementing and supporting UC&C, there are questions that may arise regarding how well packet loss is tolerated. What is an acceptable amount of network packet loss? At what point does it begin to impact the performance of sensitive network services such as Unified Communications and Collaboration?

How does packet loss impact UC&C Services?

UC&C services are typically delivered over a myriad of protocols and conversations, all working together to bring voice, video, data, messaging and more into one platform. As an example, Skype for Business utilizes more than 52 ports to deliver services to end users, some over UDP and others over TCP.

When packet loss is present on the network, the first UC&C components to be impacted are voice and video. Not only do these services generate the bulk of the bandwidth used by UC&C, they also are typically supported by connectionless streaming protocols which do not retransmit lost data. If a network connection is dropping these packets, the users will experience delays and service degradation.

Services that are delivered over TCP can also suffer due to packet loss, despite the retransmission capabilities of the protocol. Depending on the timing of the loss in the TCP stream, retransmissions can take up to three seconds to be sent, which will cause the service to lag or even disconnect when excessive.

How much packet loss is considered excessive? This has been a common question when implementing a UC&C solution, especially in a hybrid environment. According to one study, Skype for Business begins to suffer after 0.2% of traffic loss. This makes sense since these services are both sensitive and complex.

With such a low tolerance for packet loss, network engineers need to be vigilant about monitoring the network for links that have output drops, discards, and layer two errors, as well as ensuring they have implemented a solid QoS policy for UC&C. If just one switch or router in the path does not have the proper policy configuration, this can dramatically impact the quality of UC&C.

Make Sure to Monitor

Most, if not all organizations who implement UC&C will be utilizing a service provider network to connect them to cloud-based endpoints supporting the system. Network Engineers will not have visibility and control over these networks, so monitoring the performance of UC&C over the systems they have access to becomes even more critical. This will enable them to avoid the finger-pointing game with an ISP when the quality drops.

UC&C has become a critical component for doing business in many organizations. Make sure not to leave high quality to chance. Comb the network for signs and symptoms of packet loss before implementing UC&C, and monitor after deployment to ensure smooth sailing.

Want to get ahead of performance issues? Conduct a clean-up effort to stop the band-aids.

Download our Unified Communications Clean-up guide

Testing Power over Ethernet

As you prepare to either install new power sourcing equipment (PSE), which could be a PoE enabled switch or mid-span injector or you are working with an existing one, here’s a few things to keep in mind to ensure a smooth deployment.   

When provisioning the PSE for the various powered devices (PD) such as VoIP phones, security cameras, Wi-Fi access points and badge scanners to name a few, it is important to calculate the overall power requirement for all devices you are planning to connect to a given PSE to ensure it doesn’t get oversubscribed.  The chart below provides you with the level of power that is required at the PD depending on which IEEE standard you are working with.

While it’s ok to test the PoE voltage directly at the PSE, best practice is to test for the wattage or voltage level at the wall jack where the PD plugs in.  This is important because PoE will dissipate as it traverses the cable so you want to ensure the power at the wall jack is what is required per PD.

Keep in mind that PoE is subject to the same cable distance limitation as standard Cat 5, which is 100 meters or 328 feet.  If the physical cable is out of specification and longer than the TIA standard, power may be too weak by the time it reaches the PD.

Common PoE Issues to watch out for:

  • PoE is subject to the same distance limitations as standard network cable runs - 100m/328ft
  • Incompatibility between powered device (PD) and power sourcing equipment (PSE)
  • Switch over subscribed from a PoE perspective
  • Switch provisioning of PoE
  • Power limited per port
  • Cable faults

To get information on Troubleshooting PoE view our recorded webinar here.

Monitoring the Transport Layer

A considerable part of monitoring the Transport Layer is actually looking for symptoms, which suggest problems at lower layers.  These symptoms often relate to retransmissions and difficulty in achieving high throughput because the TCP slow-start process is not able to reach its full potential for large transfers. If the lower layers are operating without problems, less-than-optimum performance may sometimes be traced to Transport layer configuration parameters. Changing the window size for hosts performing large transfers may be helpful if simple bandwidth and file size calculations suggest that a large transfer should have taken considerably less time even when zero windows are not observed.  Dropped packets suggest buffering or queuing problems, flapping routes, and so on. 

If monitoring suggests that further investigation is warranted, use of one or more of the following would be the next step in either isolating the source of the problem or further characterizing the problem:

 

  • SNMP analysis of infrastructure devices along the path, checking for errors and utilization statistics
  • Flow protocol analysis of utilization statistics
  • Console access to infrastructure devices along the path, checking for errors and utilization statistics

 

If no errors or bandwidth problems are discovered, protocol analysis often the next step in discovering the cause. In a few cases the problem is due to Layer 4, but more often it is a lower-layer problem showing as a Layer 4 symptom.

Network and Application Troubleshooting Guide, Second Edition

VoIP Basics - Defining Codecs

Codecs are an important element in quality Voice over IP (VoIP) communications and video conferencing. Codec comes from the combination of COder/DECoder and defines the way analog voice (audio) is compressed and converted into digital IP packets as they flow over IP network infrastructure and are then decompressed into analog audio for the receiver on the other side of the conversation.Codecs play a role in both the quality of voice sound as well as the bandwidth consumed by the session.

There are several different standards-based and proprietary Codecs commonly used today.

  • G.711 – This ITU standard Codec is uncompressed and thus consumes higher bandwidth than other Codecs so is recommended for areas with higher available bandwidth. This will also mean the quality will be better.Two versions of this are available – U-law that is compatible with the T1 standards used in North America and Japan and A-Law which conforms to E1 requirements used broadly around the world. This is a royalty free codec.
  • G.722 – This ITU standard, with the highest consumption of bandwidth among the most common Codecs, has exceptional quality. As all patents have expired, this is a royalty free codec.
  • G.729 – One of the most commonly used Codec in VoIP, it offers good voice quality while having low bandwidth requirements.  Use of this Codec will require a license.

Issues related to Codecs can impact the quality that users experience.  For instance if remote offices are bandwidth constrained, configuring G.722 could exacerbate the congestion issue due to the high bandwidth demands G.722 require. A failed international call could be tied to not enabling G.729 as a negotiated codec. Determining the reason for call quality issues in this part of a VoIP implementation requires tools that closely monitor performance of codec-related metrics.

    Pages