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.


Submitted by Edge Member - Steve Draper

Before you go looking at IP Routes, OSPF or EIGRP configurations or other less likely problems, remember to always suspect the physical layer first:

  • Do you have an Ethernet link light?  If not, why? 
  • Do you have ANY lights at all on the device?  If not, check power!  

This may seem elementary or in some cases even silly but it should be the FIRST thing you verify before moving on to other possibilities. Some estimates are that between 75 – 85 percent of all troubles are found at the physical layer.

Key questions BEFORE your investigation:

  • Do we have a working one of these to compare? What are the differences between them?
  • What is the health of the path from that device into the network? To the WAN/Internet?
  • Begin the process of elimination…i.e., Connect the suspect device directly to a switch with a known working (known good) patch cord
  • What time and date did this begin?
  • Has there been and event such as a power surge or brown out that coincided with this trouble?
  • Is the device’s Real Time Clock (RTC) in synch with NTP? (that is, can we believe the log times?
  • What other event happened at that time?  (Fred changed the water in the fish tank above the router).
  • Use the “show log” command starting with the site’s router, then move on to other devices.

Can we:

  • See a before and after snapshot? (compare prior test result reports)
  • Ping the device’s own IP address? (test its own stack/NIC, verify network layer connectivity)
  • Ping the device’s Default Gateway?
  • Swap components (Cable, Switch, WAP) 

    Critical Protocols in UC

    VoIP and Unified Communications services depend on signaling protocols to establish a call or connection. These protocols performs basic call setup functions, number translation, feature negotiation, and call management. If the receiving device is available, the call server contacts it and instructs both the caller and called devices to establish a peer-to-peer UDP path to carry RTP audio/video traffic (Real-time Transport Protocol – RFC 3550). Call signaling protocols can be either standards-based or vendor / proprietary-based.

    Standard-based Signaling Protocols

    • H.323 - International Telecommunications Union (ITU) designed the H.323 protocol suite to define how multimedia, such as video and audio travel over a packet-switched network. Although widely deployed due to its early availability, it is now being replaced in many situations by SIP.
    • MGCP - Media Gateway Control Protocol, an IETF standard (RFC 3435), operates at the backbone of the network and typically used by network elements like call agents which routes calls between gateways and the PSTN (public switched telephone network).
    • SIP - Session Initiation Protocol was produced by the IETF as an IP standard (RFC 3261) for call/session set up, modification and termination. SIP has broad applicability in enabling voice and video connectivity, as well as instant messaging, across the IP based Internet, enables better interoperability among vendors, easier application development, and easier operation through firewalls.

    Proprietary Signaling Protocols

    Several VoIP vendors offer proprietary signaling protocols in addition to supporting one or more standards-based protocols.  A couple of the most commonly deployed include:

    • SCCP - The Skinny Client Control Protocol is a proprietary signaling protocol used by Cisco Systems.
    • Extended H.323 - Avaya’s proprietary signaling protocol which is based on the standard H.323. 

    The time required for the Call Manager Servers using signaling protocols to successfully establish the call can have significant impact on user experience. To manage this part of a VoIP implementation requires tools that closely monitor performance of signaling protocol-related metrics such as call set-up times, incomplete/failed calls and errors.