In part 1 of this blog we reviewed what is available for the common user and what is the short coming of the solution when trying to evaluate the network availability and performance to assure consistent delivery of our media feed.

In this part we will show why we have to go further in-depth into the information gathering and the testing to make sure that the test is truly indicative of parameters that matter to the live media stream.

What do we need to do?

Our test must establish the quality and performance of the target stream in a repeatable procedure across the intended path We must apply the same protocol and same packet size while performing the test between the source and destination in order to achieve in the most accurate results. Delivered packets can then be individually inspected for performance measurements to include the number of router hops between the source and destination, consistent or variable latency, lost or replaced packets, packets arriving out of order, and other metrics exposing path performance or limitations. The test will track and measure Round Trip Time (RTT), jitter, and the time it takes to reorder packets received out of sequence. This will allow a precise packet view to expose transient events, volume of packet loss, route changes, patterns of burst events, or changes in latency.

Non-intrusive testing will allow examination of the other data sharing the network to verify that the adjacent traffic is not causing congestion or otherwise hampering path performance. The test should have the capability to compare that traffic intended for different destinations does not impact the stream being tested; a high-bitrate stream competing for the same network may add jitter to our primary stream while in transit and measurable at the destination.

We will want the test to have the capacity for evaluating multiple routes and to identify each paths’ limitations, path thresholds, and most importantly, how the paths behave collectively when combined as one link. Uniformly, what is the combined packet loss profile for multiple links and how much bandwidth can they sustain overall? What time differences are exposed between the paths so that a streaming application setting may be correctly configured?

What next?

We don’t want to just run tests without respect to the traffic of others, disregarding other services and users. Brute force tests like Speedtest or Iperf can cause harm to other data streams or the traffic of others using the network during the time of the test, and as such can overload the network causing service interruptions. It is mandatory, or at least best practice, to limit and pace the test so that as breaking points are identified, we can pause or stop the test to make a decision of how to proceed.

An easy example and resulting impact:

Let’s examine a relatively routine network problem and the resulting impact: A re-route while conducting a network test. When streaming over the Internet or to the cloud, the stream is at the mercy of the global routers and the Border Gateway Protocol (BGP) rules between them. The network route may temporarily change with the re-route information not available to the user within standard testing solutions.  A route change causes packets loss, packet reorder, a jitter spike, latency changes, burst loss or a bursty stream. An important element to the test is the ability to detect if the route traversed by the stream has changed and the consequential impact on the data packets.

Let’s add visualization to this ability:

The following capture will show the impact of a routing change on the delivered stream.

The “blue line” charts the exact number of hops each packet traversed when measured from the receiving destination. What is observed is that the link route is not consistent and changes every few seconds. These changes in the route introduce impairments to the performance of the measured data.

We record a route decrease from 18 hops to 13hops. When similar changes occurred earlier they introduce minimal impact to Jitter and Latency. However, the change at 09:29:50 does cause an impact and we can observe the following:

The “yellow” arrow points to a sudden increase in packet jitter and below that on the graph an increase in latency is recorded as well. This is because a reroute may delay the packet delivery during the route change, so new packets will arrive later and causes an increase to jitter and latency.

The “red” arrow points to a packet rate jump. The reroute at 09:29:50  introduced a delay to some of the packets that are now rushing to the destination. The “light blue” arrow indicates the result of the delay, that some packets are lost and do not reach their destination.

Why is Alvalinks StreamTest is so important?

Or, Why the Alvalinks StreamTest is so important.

The Alvalinks team created StreamTest as a crucial tool for any video delivery system, regardless of the delivery medium consisting of land lines, mobile, cable-provided Internet service, cellular bonding, satellite IP, or in particular, cloud applications. Evaluation of network behavior before going live or adding a new service is important to any organization or individual conducting video over IP. Moreover if the traffic is sensitive to network impairments ( for example JPEG-XS, or ST-2110 ), these protocols will usually apply SMPTE 2022-7 seamless switching, so testing all available routes is crucial for a successful delivery. 

AlvaLinks StreamTest focuses on analyzing all aspects of video delivery over IP networks, based on precise packet pacing from the sender side, and accurate measurement from the reception side, to detect any anomality, delivery issue, arrival time mismatch, and evaluating the behavior of each route on a packet-by-packet basis.

This “do no harm” approach focuses on effectively testing the route while monitoring the outcome against a specific threshold that will operate as a pause-button in the event of an impairment. This testing method can detect the network breaking point and allow the user to fine tune the source, conduct better route selection, or configure multi-path streaming. (Load balancing whenever available. The User can apply one of the popular protocols; RIST, SRT, Zixi, NDI or SMPTE2022-7 to conduct load balanced streaming.)

With the Alvalinks StreamTest the user has true route evaluation in a single solution, with informative graphical information comparing the source and destination streams, detection of all the outgoing and incoming streams at the source, and the same at the destination. An IT department can make good use of this precise information to improve or reduce Service Level Agreement (SLA) provisions and resulting operational expenses. The guessing game is over, vague tools may be eliminated, and we can precisely evaluate the network prior to the revenue of streaming.

A user may then apply the Alvalinks CloudRider^TM to further monitor and observe operational live streaming with the same depth of analysis to minimize down time and determine fast root cause with the industry’s best analysis tools at his fingertips.  Beyond just delivery testing, these tools continuously probe route hops and detect the flows going from source to destination and destination to source.

   
Economic incentive

Testing and pre-evaluation of the paths available to the user and their data streaming service is an important first step for successful operation. Content is king, and consistent delivery is vital for successful business. Whether you are a broadcaster, a sports event producer, a YouTuber, an influencer, or a gamer, you must know, test, and identify that the link can sustain the stream. Also important to know in advance are problems that can occur while streaming and how to fine tune the delivery protocol to accommodate the network conditions. Accommodations can include adjusting the buffer time, link latency, receive buffer size, and specifying error recovery techniques.

Ignoring these will allow impairments to affect your content and require additional time, money, and frustration to resolve the issues.

With a true and proper link evaluation tool money may be saved on SLA costs, time reduced for trouble shooting, minimization of support costs and the applications will achieve streaming success.

How does one accomplish this? Call AlvaLinks!