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.

Diagnosing Packet Level Problems

It may seem obvious, but to solve problems at the packet level requires access to the packets that will contain the “answers” you are looking for (you cannot analyze what you cannot see). Two common hardware-based methods of accessing packets are (1) using an external TAP (‘test access point’) or (2) putting your analyzer inline. Let’s explore each method…

An external tap is a device that essentially “copies” the traffic in question and sends that traffic out separate ports to an analyzer. In the case of a copper tap (with “RJ-45” ports), this is done electrically in hardware, whereas on fiber optic links, a non-powered optical splitter can be used. In the diagram below, a “full duplex tap” is pictured. There are two ports for the “active link”; one for connection to the “upstream” device and one for connection to the “downstream” device. Two other ports are provided for output to a dual-port analyzer. If this device were tapping a full-duplex 1 Gig link, ostensibly there could be two gigs of traffic being output to the analyzer (one up + one down). The alternative type of tap would be an “aggregating tap” – where the upstream/downstream traffic is joined together and sent out a single output port. The downside of this approach is the likelihood of exceeding the capacity of the output port (and the capacity of a single port analyzer) if utilization exceeds 50% (ex: 600Mbps upstream + 600 Mbps downstream = too much traffic if the output port is 1 gig). Also, a dual port analyzer is required – there’s no way an off the shelf laptop can handle this kind of traffic.


Inline mode is, well, pretty obvious. This requires using an analyzer that is architected with multiple ports that support going inline between two active devices on the network (say, between a VoIP phone and an access layer switch, for example). All traffic to/from an endpoint is routed through the analyzer itself where an INTERNAL tap that copies the traffic into the analyzer’s capture buffer. In the case of the OptiView XG Network Analysis Tablet, this ensures full line-rate capture of 100% of the packets.


Both methods eliminate the risk of dropping packets during analysis. (Presuming, of course, that your analyzer is capable of full line rate capture.) Physical layer packet errors are also routed to the analyzer (which does NOT happen when using SPAN.) 

A downside to either method is that the link will have to be broken to insert either the tap or the inline analyzer (if the tap had not been installed earlier).  “Everybody hold on while I disconnect the server” may not be a viable approach, but if the network is “on fire”…well, desperate times call for desperate measures as they say. 

We’ll explore SPAN (another packet access method) in another tech tip…

    UC projects: time to review QoS

    Are you planning or executing a Voice Project?  Now is a good time to initiate or refresh your company’s QoS policy.  Quality of Services (QoS) policies are in place to help ensure high quality voice and video communications, prioritize traffic delivery, optimize bandwidth and reduce bottlenecks.  The use of Differentiated Services Code Points (DSCP), as defined in RFC 2474 and 2475, provides a packet field in the IP header to be used in network traffic to assign a code that identifies the priority with which a packet is to be delivered. 

    Many organizations have created Quality of Service policies that define priority levels for optimizing delivery of networked applications and protocols.  Latency intolerant applications, such as voice and video, may be assigned the highest priority.  Revenue, customer or patient impacting services, like Customer Resource Management and/or Electronic Medical Records may have a secondary priority assignment.  Less time-sensitive applications such as e-mail and web surfing may be given a best effort assignment. 

    Whenever a company undertakes an update or rollout of a Voice-related project, it is a good time to review an existing QoS policy or an opportunity to establish and implement a new one.  Many companies have established best practices as they undertake such projects that includes:

    • Performing an audit – of your networked applications and protocols.  As one network engineer put it “it’s kinda hard to define and implement a QoS policy if you don’t know what you have running through your network.”
    • Taking action based on results of the audit – use the information gathered to
      • Determine the specific Classes of Service you want to use given the number and types of applications and protocols discovered.
      • Evaluate and rectify anomolies uncoverd during audit, e.g. retired application services, rogue viruses, traffic mis-configurations.
    • Establishing a periodic review  – to optimize delivery of the services per the QoS settings and determine if different applications should be moved to different priorities or if the organization could benefit from establishing another QoS category.