In the last article, we took a deeper look at the packet analyzer Wireshark. In this article, we continue the theme of looking at a network from a broadcast engineers’ point of view so they can better communicate with the IT department, and look at what IT engineers mean by a networks Quality of Service (QoS).
Broadcast engineers are accustomed to point-to-point, reliable, guaranteed bandwidth circuits. An SDI cable will guarantee 270Mbps for SD and 1.5Gbps for HD. Digital audio circuits will guarantee 2.5Mbps for uncompressed 48Khz sampled 24bit word stereo.
Computer networks do not offer this level of guarantee as they are shared packet switched systems and use best effort delivery mechanisms. A stream of video or audio is divided up into packets of 1500 octets to fit in an IP datagram, which is generally inserted into an ethernet packet. Each of these packets is streamed in sequence at the video or audio data-rate, and sent through the network to its destination using a best effort mechanism.
Routers and switchers vary enormously in their sophistication and data handling speeds. The routing protocols they support and ability to provide services such as multicasting also vary. Consequently, if a datagram is sent from a camera to a vision mixer, through a network, we cannot guarantee, or even predict how long it will take to get there, whether it will get there, or whether it will be in sequence.
Each datagram has a sequence number within its header enabling the receiver to re-order the packets within its input buffer. The packets can be received out of sequence if a route is temporarily interrupted and the datagrams sent by a different path, resulting in some packets taking longer than others. The receiver can re-order them, but if some packets take too long to arrive then they may be dropped as they will fall outside of the input buffer window.
Input buffers are usually of a fixed size and are used to re-time and re-order packets causing delays for video and audio streaming. If the buffer is too big then there will be an unacceptable delay, possibly even seconds. If the buffer is too small, then a disproportionate number of packets will be dropped as their arrival will fall outside of the buffer window.
To meet the demands of video and audio streaming, IT have adopted the term QoS, adding an element of control to packet arrival. Another term used is rate shaping. Essentially, QoS is helping us distribute a synchronous stream over an asynchronous network.
When IP and TCP were originally designed, there was no consideration or provision for synchronous services such as streamed audio and video.
Two strategies are available to help us reliably stream audio and video over an IT network; extra provision and packet prioritization.
Differential Services Code Point
Extra provision is providing more bandwidth than we need. If streamed audio service requires 2.5Mbps, extra provisioning would demand 5Mbps or even 10Mbps. Clearly this is wasteful of bandwidth and doesn’t scale. The bandwidth requirements and switching speeds become absurd when we start looking at HD and UHD video.
Packet prioritization takes advantage of information inside the IP header. The Type of Service (ToS) field, recently renamed as Differential Services Code Point (DSCP), belongs to a packet prioritization model called differentiated services. This information is used by the router to help it determine its routing order.
If many streams are being switched to one port, then the router is left to decide which packets take priority over others. This might be a round-robin type strategy, or first come first served. Higher end routers use buffers to temporarily store datagrams as they enter the device. Algorithms within the router interrogate the datagram, extract information such as the DSCP value, and decide its priority when sending to the next hop in the network.
The prioritization causes delay and packet loss within a network. If a buffer becomes overloaded, then it drops packets. Variations in delay give rise to jitter, both long and short term. Solving this problem is the essence of QoS.
Packet prioritization relies on routers within a network all agreeing on a prioritization strategy. Video should take priority over audio which should take priority over HTTP traffic. Within closed private networks this may be possible, however, once we move into public networks the prioritization becomes less predictable. Some network providers might not even provide QoS or bit rate shaping, resulting in a complete mess.
Packet prioritization relies on switchers performing deep analysis of the datagram to extract the necessary DSCP values, and even looking at the stream itself to determine whether it is audio or video, resulting in delays and bottlenecks within the router. This is further compounded when we look at encrypted packets as the router will not be able to decode any of the payload and will not determine if it’s switching video or audio.
Multi-Protocol Label Switching (MPLS) is designed to overcome these problems. MPLS is provided by a network supplier and is largely transparent to the end user, as a datagram enters the MPLS network the ingress router adds a label to the packet, this is used by all subsequent routers within the providers’ network to prioritize and route that datagram.
Routing efficiency is improved as switchers use the label for prioritization and routing, but don’t interrogate the datagram further, improving throughput and reducing complexity. As QoS is an intrinsic part of MPLS it forms a fundamental part of the routing method instead of being an unwelcomed add on.
QoS is a Fundamental Consideration
Interoperability between network providers is maintained, to be part of an MPLS system all providers must agree on using the same QoS strategies to guarantee streaming of video and audio.
MPLS can adopt many different types of layer 2 connections including ethernet, ATM and DSL. Combined with multivendor interoperability, MPLS is extremely flexible and lends itself well to broadcasting, especially when backhauling cameras and microphones from remote outside broadcasts.
As IP grows within broadcast facilities QoS will become a fundamental consideration, and decisions on whether to use protocols such as MPLS will need to be taken at an early stage, especially when choosing network providers who may or may not be able to provide MPLS.
You might also like...
In the previous Cloud Broadcasting article, we looked at Agile software development and its relevance to cloud computing. In this article, we delve further into Cloud-Born systems and investigate the differences between public and private clouds and where you might…
Broadcasters, and production facilities that have significant investments in large-scale SDI plants are going to face technical and budgetary challenges as they transition to newer IP-based topologies. The need to support current SDI workflows during the transition will be key…
In the previous Cloud Broadcasting article, we took a very brief look at cloud security and its advantages over traditional datacentre systems. In this article, we delve further into Cloud Born systems and investigate the new requirements for software development…
IP and Video Go Together. While OTA broadcasters await an IP delivery system, production tasks march ever closer toward IP-centric environments. So, where does an IP solution make sense today? Are manufacturers any closer to delivering the solutions they promised…
In the last article on Cloud Broadcasting we looked at reliability and the client-server model in Amazon Web Services high availability zones. In this article, we look more at cloud security, a very emotive word in the IT community.