Download PDF
IP Video traffic has different behavior than that of voice and data. Underestimating the impact of IPTV Video flows on a network can lead to network architectures with built-in systemic limitations that can lead to transient loss events that can plague IPTV systems.
Summary
Service providers that deploy IPTV services, fundamentally rely on their IP networks to transport live IP Video without loss. Without this basic underlining capability there is no IPTV system. IPTV systems with significant transient loss suffer not just from poor quality with the customer base but significant operational issues in both frustration and cost. With everything riding on this fundamental responsibility it may be surprising to learn that many IP networks and IP network components that are being used for IPTV transport have never been tested with live video flows. Some may respond with, so what, these routers and systems have been tested with line rate data generators and have been working in large networks without issue in the past. Isn’t video just high bandwidth data and at worst like higher speed voice traffic?
Why is IPTV/IP Video different?
Live video that is packetized to be transported over an IP network creates a traffic flow with different behaviors and requirements compared to data and voice traffic. It may also be surprising to learn that in many cases IP Video traffic can cause switched IP devices to experience loss at well under line rate conditions. The assumptions for QoS that have evolved under IP data transport and to a lesser extent very low bitrate voice flows do not necessarily translate for the higher bitrate IPTV/IP Video flows. Underestimating the complexity of how network queues handle these new traffic patterns can lead to network designs that build-in systemic limitations that can lead to transient loss events that can plague IPTV/IP Video systems.
Understanding the nature of IP Video is critical to understanding the limits and operations of a well-architected IPTV/IP Video network. This paper will discuss the basic nature of IP Video traffic flows, the issues that these patterns of traffic flows can cause in a switched IP device, measurements that can be used to understand how well a router is performing when carrying IPTV/ IP Video loads and finally a test methodology that can be used to verify and validate switch IP devices and tune their QoS settings.
IPTV/IP Video Traffice and the Queue
An IP network, at its basic core, is a series of packet queues (memory buffers) that ebb and fill to accommodate routing and aggregation of information packets as they are moved from point A to point B.
Figure 1. Simple Queues and Networks
These queues are basically memory buffers that hold packets for a small amount of time while the path out of the router or switch is freed or cleared. Quality of Service (QoS) is the policies that dictate which packets are pulled from the queue and sent out of the device.
QoS is also responsible for the policing of which packets are deemed worthy enough to enter into the queue and if the queue is full, which packets get discarded.
Queues being just memory are finite resources and can easily fill under the right conditions. When a queue is full more sophisticated logic is used to prioritize which packets to kick out of the queue and which packets to let into the queue, this is also done by the QoS policies.
This is, of course, a simple explanation of queue theory and implementation but consider that in an IP network there are hundreds if not thousands of these queues in operation inside each router and edge device. Some have large and some small amounts of memory but all have to be working correctly to get a packet from point A to point B. We take for granted that these queues work at all. Larger pipes, larger queues and QoS work well. However consider the IP Video flow. If even one of those queues fills a loss event will occur.
This could happen in the queue of the first aggregation router, in the core with other prioritized traffic, at the edge or in the 10/100 routers before the set top box. Loss at any queue or link anywhere from the encoder to the decoder will result in degraded video service. The conditions that cause those queues to ebb and fill are enhanced with IPTV/IP Video flows. No longer can we take for granted that queues just work, theses devices need to be tested, tuned and understood so that stable and robust IPTV/IP Video systems can be architected.
Queues and Cumulative IP Jitter Example
Architecting and configuring queues for IPTV/IP Video flows on its surface seems simple. If you have a CBR (constant bitrate) 3.75Mb/s IP Video flow, say a digital broadcast program like ESPN, one may conclude that you need to reserve or account for 3.75Mb/s of bandwidth from the transport channel to provide good quality delivery service. However looking at it at the packet level, packets can bunch together to create instantaneous higher and lower bitrates for small periods of time. Over longer intervals of time, say 1 second, the average bitrate will be 3.75 Mb/s, but it is this bunching effect that causes queues to fill and ebb even though the offered load at first seems to be simply 3.75 Mb/s.
Let’s look at this more closely. Consider that the ideal IP Video flow has packets that enter the IP network at a packet rate consistent with the 3.75Mb/s payload and the pattern emerges to look like “beads on a string”. Under these ideal conditions and for the 3.75Mb/s flow, each packet carries a payload of 1316 bytes of video (typically Transport Stream) with a 2.8ms inter-packet gap.
Figure 2. Ideal 3.75 Mb/s IP Video Flow
Clearly, any router or IP device that sees this flow will see a 1362 byte IP packet every 2.8ms, plenty of time between packets to pass other IP traffic. How long will this pattern continue? If it is ESPN, a very long time. Another property about IP Video is that, unlike voice and data, these traffic patterns continue for long periods of time. This is very significant later in the example being described.
Going back to the IP Video traffic pattern, what if we move some of the packets within the flow closer and further from each other. Like beads on a string, it is easy to visualize that if we move every odd packet close to each even packet that this should not affect the payload (ESPN). Across a 1 second period the delivered bitrate for this IP Video flow (ESPN) is still 3.75 Mb/s.
Figure 3. One Packet Burst 3.75 Mb/s IP Video Flow
It is easy to see how and why an encoder or VoD server may choose to inject the IP Video flow onto the IP network like this. Perhaps the encoder or VoD server has internal hardware limitations that present 2KB of video data for every opportunity to send IP packets, perhaps to operate with several live flows the encoder is forced to only let the network card transmit once in a while. Whatever the reason there is nothing invalid about this pattern and it would be expected to work. For the router this new IP traffic pattern creates a mini packet burst followed by a gap.In this pattern the arrival of packets to the router queue has changed. Now the router will see two packets with no space between them followed by a larger time (~5.6ms).
Again this pattern seems benign, perfectly valid, and within specifications of Ethernet and IP. Let’s now consider three ideal IP Video flows (say ESPN, ABC, and TNT). For this example, these three flows will enter an aggregation router, one on each port, and all flows will be directed out a single down stream port. Also, let’s say this router has a queue or memory enough for 1362 bytes (or 1 IP Video packet).
Figure 4. Three Ideal 3.75 Mb/s IP Video Flows into Aggregation Router
Notice that in figure 4, if the packets are staggered so that the router sees only one packet from any port at any one time, there are no issues. The packet that arrives at the router first gets passed through the queue with no stopping and gets clocked out of the downstream port. From this traffic pattern you can see that if each IP Video flow is 3.75 Mb/s this pattern of routing will continue for a long time. Because the video payload is ultimately tied to precision clocks (PCR, etc), the bitrate of the flows are very accurate and tend to drift very slowly. So this pattern could stay hitting the router in this manner for as long as the video plays -- a long time.
The next example combines this router situation with a change in packet arrival to the router using the same three ideal IP Video flows.
Figure 5. Three Ideal 3.75 Mb/s IP Video Flows Lined up into Aggregation Router
In figure 5, it can be seen that if each IP Video packet arrives at the same time this router will drop packets. Why? The IP Video is the same four flows and the flows are ideal. Clearly, the router cannot clock more than one packet in at the inbound rate and out at the same rate. So if another packet arrives at the same time, one of the two packets needs to be stored in memory (or the queue) and wait until the outbound port is available so that packet can be clocked out.
If three packets arrive on different ports destined for one output port of the same speed and the router can only hold one packet, then one packet is dropped. Note that no matter what the link speed of this router is, make it 10GbE, with a queue of one packet and this packet arrival scenario, one packet every (~2.8ms) will be dropped!
How long will this loss pattern continue? As long as the video plays and the relative arrival times of these streams align -- and with precision timing from the encoders drift between these flows could be low.
The next example combines this router situation with a change in traffic pattern to the two packet burst IP Video flow pattern.
Figure 6. Four Bursty 3.75 Mb/s IP Video Flows Lined up into Aggregation Router
In figure 6, it can be seen that the loss situation is even worse than before. Increasing the instantaneous packet bitrate by having two packets back to back creates a more difficult congestion condition for the router, even though the spacing between the two packets is ~5.6ms. The router has to deal with over-subscription for an instant, use the queues then do nothing for a time. This pattern repeats over and over due to the nature of the IP Video flow.
Realistic IPTV/IP Video Deployments
These examples are simplified, basic models that illustrate the fundamental behavior of IP Video flows and IP routing technology. Realistic IPTV/IP Video deployments are much larger scales of these examples.
A moderate IPTV/IP Video deployment has 150 to 300 digital broadcast IPTV flows carried over multicast IP. These are multiplied many times throughout the core and edges of the system. Additionally, these types of deployments have VoD services that can add anywhere from 2-5 GbE of 3.75 Mb/s to 2.5 Mb/s IP Video flows transported over unicast IP. Adding other revenue generators like local commercial insertion, HD channels and services and other streaming media, an IPTV network can have hundreds of live video flows transported throughout the service area.
A deployment can have several encoders and rate shapers for different types of video service (off-air, satellite, local TV, etc), different service packages, etc. Many ports of VoD and commercial insertion units and other devices like servers add video service to the IP Network. Each of these devices can impose different patterns of IP Video flow transport onto the network with different bitrates (each based in video clocking) and each can change behavior as firmware changes and loads grows.
These flows then enter into the network and aggregate -- at each step a queue can hold packets making the pattern of these flows change (become more or less bursty) as they pass through the network. Add in converged traffic and the chances that transient conditions for queues filling and creating the conditions to cause loss increases.
Given the scale of these systems there seems to be two critical requirements. First, is the ability to measure the burstiness of live flows, taking into account loss, so devices putting IP Video on the network can be measured as it pertains to each live IP Video flow. Second, is the creation of a test plan that models this realistic video traffic and characterizes IP switching devices and networks for their ability to deal with bursty IP Video traffic under increasing IP Video loads and bitrates.
RFC 4445 - Media Delivery Index (MDI)RFC 4445 (MDI) is a measurement that can be performed on live IP Video traffic on a per flow basis. The MDI measurement has been in use for several years and is ideal for measuring the patterns of these IP Video flows in operational and lab networks. MDI uses the behavior of the video payload to compare the IP packet arrival to the payload bitrate. This measurement is expressed as Delay Factor (DF), the amount of time the video flow has to be buffered to accommodate the cumulative IP jitter seen at that point in the network, per unit time.
MDI also tracks media loss rate (MLR). MLR is how many media packets are lost per second. With IP Video transport methods this is sometimes hard to measure as many flows are transported over UDP with no IP packet sequence data available, so inspection of the payload is required to determine missing data.
MDI is expressed as DF:MLR. MDI works very well when measuring live flows out of encoders and other video devices. And because it can be performed on live video flows, the same IP Video flow can be measured at several points across the network in real-time. So, distributed, dynamic and real-time measurement of a live IP Video stream through a network gives you a very clear picture of potential queue usage and performance.
Figure 7. RFC 4445 – MDI on a Live IPTV Network
Figure 7 shows a basic block diagram of an IPTV deployment. This figure shows that all IP Video flows are measured at the headend for MDI but also deep packet inspection is performed to ensure the video is good going into the network. Notice that flow EPSN HD has loss (15:7, 7 media packets lost per second) at the headend. When loss or any payload issue is seen at the headend, it is seen everywhere in the deployment. Isolating it to the headend helps operations target where to deploy engineering to fix issues.
Figure 7 also shows that throughout the network just MDI is used on each flow to determine what the IP network is doing to the flow. The two examples in this figure show that at switch A there is loss on NBC and at switch B and C there is increased MDI-DF, an indicator the queues are being used that change the timing pattern of the flow (that can lead to loss).
Figure 7 shows how MDI being measured, simultaneously, on live IP Video flows can quickly help isolate a video issue from an IP issue and the location of the problem. Additionally, because measurements can be done live, QoS issues can be tuned and corrected dynamically using MDI (DF:MLR) to show flow pattern changes per flow.
It is also helpful and necessary to measure these flows simultaneously. Queue behavior and QoS can be complex and one flow may be good while others that should be good hit the queue differently and are “bad”, this can be seen in the examples above where one flow always is good while the others are periodically experience loss.
It is also common that even if a router does not drop a packet it can change the DF (burstiness) of the IP Video flow, making it harder for the router downstream to accommodate that flow. This cascade behavior is critical because queues can be used to fix loss but could create MDI-DF just high enough to overflow another queue in the chain. Loss is loss and the entire IP route needs to be aware.
It is also significant to note that the IP network cannot change the payload. The network can only change a packet’s arrival timing or drop it (out of order, duplicates, etc), exactly what MDI measures. So if the video payload is good going into the network and the network does not drop any packets, the quality at the decoder is the same as it is at the encoder. Cumulative IP jitter does not affect the quality of the video; it is a cause of loss. So MDI-DF can be used as an indicator of how well a network will transport an IP Video flow.
Many times these events are transient so loss comes and goes and no one knows why. So testing is recommended to both qualify each component in the network and the network and system itself. This testing must consider the scale of the real deployments.
MDI Characteristic Curves and Router Tests for IPTV/IP Video Flows
MDI Curves are graphs that are produced from following the test method of injecting real IP Video flows with certain flow patterns creating known MDI-DF into IP Switching devices and measuring the results. By increasing the number of flows and the burstiness (MDI-DF), the limits of the device can be charted.
These curves and other data collected for these types of tests can help understand limits in queues to compare devices before purchase and to tune QoS in advance of deployment.
Figure 8a. MDI Curve Test Step Load Chart
(3.75 Mb/s and 2.5 Mb/s flows) of a Simple Router
Figure 8b. MDI Curve (3.75 Mb/s flows) of a Simple Router
Figure 8c. MDI Curve (2.5 Mb/s flows) of a Simple Router
Figure 8d. Simultaneous MDI Measurements of all live flows from a Simple Router
Figure 8 shows a MDI Curve of a simple router that is aggregating two GbE ports to one down stream GbE output port. Two IP Video flows are played into the device under test, the first is a 3.75 Mb/s IP Video flow into port 1 and the second is a 2.5 Mb/s IP Video flow into port 2. Both get aggregated and sent out port three to a measurement device.
The input MDI-DF on both IP Video flows is set to 4ms (4:0) and the number of flows, unique IPTV streams, starts at 2 per port. Then the number of flows is increased to 12, 22, 32, 42 and finally 52. The input MDI-DF remains at 4:0 and at each increase of flows a full MDI measurement is performed on each flow simultaneously and stored.
Ideal MDI-DF for the 2.5 Mb/s flow is 4.2:0 and for the 3.75 Mb/s is 2.8:0. Note, packing video in an IP packet requires buffering so this DF is the time required to buffer these flows due to the IP packet.
Then the test increases the MDI-DF of all input IP Video flows to 6:0 and the number of streams is repeated (2, 12, 22, 32, 42, 52). The range of input DF, in this test, goes from 4, 6, 8, 10 and 12.
At each point there are MDI measurements for all flows seen at the output port. This data is available for detailed analysis of queue performance but MDI Curves show an overview and quick inspection of how the test device performed.
MDI Curves plot the maximum MDI-DF of all the flows for a given step in the test. When any loss is detected the curve stops. Figure 8 shows that as the number of flows increases at higher input DF the less flows get through the device under test without loss.
Notice also that having this easy to read plot, the MDI Curve tells the user what MDI-DF can be tolerated without loss. So because MDI is used in IPTV deployments in monitoring, the information in these graphs can be used to set thresholds. And for well-tuned networks, this can help predict issues before loss happens.
ConclusionIP Video is unlike voice and data. IP Video traffic has rate and clocking behaviors that many IP routing devices and IP networks have never seen before. This new traffic requires a deeper understanding so QoS models can account for this new technology.
Adding bandwidth will not necessarily solve the issue as it did in the past with voice and data. A more sophisticated understanding and architecting of queues is required.
Underestimating the complexity of how network queues handle IP Video traffic patterns can lead to network designs that build-in systemic limitations which, in turn, can lead to transient loss events that can plague IPTV/IP Video systems.
Simultaneous measurement of live IP Video flows using MDI can help in monitoring, troubleshooting and testing of IPTV networks for IP Video. Understanding IP Video and MDI can help architect a better quality assurance system by separating video issues from IP issues. Make sure video payload is good going into the network and then MDI is the quality measurement everywhere within the IP network.
Understanding the nature of IP Video is critical to understanding the limits and operations of a well-architected IPTV Video network. Using measurements like RFC 4445 and test methodologies that exercise IP Video devices and routers under realistic IP Video load conditions will help unravel the mystery of IP Video flow performance and lead to better built systems that are easier and less expensive to maintain.
IneoQuest Technologies, Inc.
170 Forbes Boulevard - Mansfield, MA 02048
Toll free: 1 866-464-4636 -Fax: 508-339-4727
IneoQuest UK Office (44) (0) 20 7193 7847
www.ineoquest.com
Download
