One of the major benefits of the IP protocol is that it is hardware agnostic. IP can operate over a variety of hardware layers such as ethernet, fiber and WiFi. The true power of IP becomes apparent when we connect a LAN within a broadcast facility to a fiber connection to their local ISP. From the perspective of the user, they have no knowledge that the IP datagram leaving their device has traversed across many different hardware layers to reach its destination.

Interconnectivity between sites does not have to be limited to single connections. Multiple layer-2 links between facilities not only provide resilience, but also the opportunity to balance loads between the data connections and reduce the possibility of congestion.

IP Flows Are Not All The Same

It may not be immediately obvious but not all IP flows behave the same. When we speak of a flow then we’re referring to a continuous stream of IP packets with the same IP source and destination numbers, and in the case of UDP or TCP then we also include the source and destination port numbers. This gives unique combinations of IP source and destination addresses with their associated UDP or TCP port source and destination addresses. It is these unique combinations that make up a flow.

We may be able to make an abstracted comparison between IP flows and signal paths in the traditional broadcast sense, but there are major differences, primarily because IP is packet switched and broadcast connectivity such as SDI and AES is circuit switched. Furthermore, IP was designed as a transactional delivery system where every packet can be treated in isolation within the link in a network, unlike SDI and AES where we look at the whole delivery stream. This is most evident when we consider layer-2 switches and layer-3 routers where the switch/router only has knowledge of the next hop in the network and doesn’t have a whole view of the network. To solve this challenge, we need to move to SDNs (Software Defined Networks), which will be the subject of future articles.

IP relies on a whole host of other protocols such as OSPF (Open Shortest Path First) to deliver packets to the next link in the network. This works as the IP router keeps a table of “next hop” ports so that it knows which router in the chain to send the packet to. If the network is reasonably small then the number of switches/routers is minimal, however, as the network grows to include other buildings, cities, and even countries, the number of switching and routing devices increases, along with the need to maintain the routing tables. Life is a little easier within closed and private networks as the network administrator has the option of manually updating routing tables to optimize routes and paths, but this is generally a huge undertaking that requires a deep knowledge of the network, and the devices connected to it.

Packet & Circuit Switching

Another difference between IP and SDI/AES networks is that IP packets are time division multiplexed where a slot cannot be guaranteed resulting in potential packet loss, whereas SDI/AES is synchronous with guaranteed availability for the data. This is a major difference but one that facilitates the scalability and flexibility that IP networks deliver. But it does have some major consequences for broadcast engineers that need to be considered.

Suggesting packet loss in a broadcast environment is akin to heresy. However, the reality is that data loss, even in SDI and AES, does occur. But we don’t notice it for two reasons: firstly, we’re not generally looking for it, and secondly, the implication of losing a few samples of video or audio is usually so small that we don’t notice them, mainly since SDI and AES are both uncompressed. SDI does have a CRC flag which broadcasters can monitor, but how often does this happen in reality? In IP networks packet loss is a fact of life. It happens for a whole multitude of reasons, including interference caused by electromagnetic noise, but principally, if a data link has no space for a packet to be inserted into it, then it’s simply deleted forever. This is the consequence of congestion.

Measuring datarates in layer-2 and layer-3 networks requires two fundamental measures to be taken: datarate and data throughput. Datarate is similar to the measurements we make in SDI/AES environments where we can say an SDI link has a datarate of 1.485Gbps. As the SDI network is synchronous and circuit switched, we know that the datarate of the video and audio components can be guaranteed, so there is no appreciable data loss. In effect, the datarate and data throughput are the same. This is not true for packet switched networks such as IP as it’s entirely possible to have a very high datarate, but a very low effective data throughput. In the context of broadcasting, the data throughput represents the amount of video and audio data that is delivered to the destination device.

Congestion Collapse

Back in 1986 the first incidence of congestion collapse was documented. An NFSNET backbone dropped its capacity of 32Kbits/s to 40bits/s. In other words, the data throughput dropped from 32Kbits/sec to 40bits/s. This was attributed to an early form of TCP that resent lost packets in a network to guarantee packet delivery with little regard for congestion control. The devices attached to the network simultaneously resent their lost packets which caused oversubscription on the link, which caused packet loss, which resulted in the source devices resending the lost packets, further adding to the oversubscription of the link and hence packet loss. So, the datarate was high as the link was working correctly, but the data throughput was incredibly low as the amount of usable data reaching the destination was just a few packets a second. This was fixed in TCP by Jacobson and Floyd with their congestion control algorithm which randomly decreases the rate at which lost packets are resent before ramping up the send rate to maximize the link utilization when throughput has been established. The sending devices didn’t simultaneously resend lost packets; hence the risk of congestion collapse was significantly reduced.

Network Congestion Optimization

In modern networks it’s unlikely that congestion collapse will happen again using TCP due to the amount of research and optimization that has gone into this field during the past forty years. However, in broadcasting we’ve started to adopt UDP streaming using systems such as RIST and SRT as TCP streaming causes variable and unpredictable latency. UDP packets are continuously sent to the destination and the RIST/SRT type protocol detects any lost packets and resends them. At a very simplistic level, because these protocols do much more than just stream video and audio, they are simulating TCP. One of the challenges of TCP is that it causes indeterminate and variable latency as packet resend is influenced by packet loss which is largely indeterminate due to the dynamic nature of the network. UDP-type streaming protocols overcome this by relaxing congestion control, that is, the very mechanism that maintains data throughput, but in doing so they greatly improve latency.

UDP streaming protocols within a broadcast environment certainly have their place and both RIST and SRT are proving their worth. But teams adopting them, especially when using the protocols to connect remote teams should always be aware of how the protocols are behaving.  

If congestion collapse does occur, then a network engineer can look at the ports of a router or switch and very quickly determine that the datarates are correct and the data links are operating correctly, but at the same time the picture and sound could be breaking up and distorting. It’s only when the network/broadcast engineer monitors the data throughput will they realize that congestion collapse could have occurred.

Again, UDP-type protocols such as RIST and SRT have made huge contributions to remote broadcasting as the relaxation of congestion control significantly reduces latency, which is to be applauded. But when using these protocols network and broadcast engineers must be very careful when implementing bandwidth management because if the network becomes over subscribed then congestion collapse can occur. This is further compounded if traditional TCP services are mixed with RIST/SRT streams, especially when the data link capacity reaches its maximum.

Within IT networks, datarate and data throughput are very different, and both need to be measured and understood by broadcast engineers. This becomes even more apparent when UDP-type streaming protocols are employed to distribute media streams between sites as we have a whole host of independent and dynamic systems that have the potential to start influencing each other, this requires the network/broadcast engineer to understand at a deeper level what is going on inside their networks. Wireshark is your best friend!