I’ve written several times about the fourth layer of the seven-layer OSI model, the transport layer. However, recent developments on both the AV an IT sides have made it clear that this is an important layer. So, let’s revisit layer four (L4) and take a deeper look.
The transport layer has two protocols, TCP and UDP. In the theory of the seven-layer OSI model, L4 is responsible for segmentation and delivery between the end points. That is, it isn’t concerned with what happens to a segment (message) as it passes between two switches or two routers. It is concerned with how it is initially sent and how it is finally received. As most of us have learned by now, TCP is called reliable because it can retransmit lost packets. UDP does not have the capability to do that because it does not contain a sequence number to allow the receiver to determine if a packet was dropped. However, there is more to TCP than retransmissions. TCP can exercise flow control to adjust to the available bandwidth between the end stations. It can also detect a state of congestion in the network and slow its transmission or even completely stop transmitting. It does this by detecting that the network is beginning to drop segments.
Recent research has demonstrated that the current method of detecting congestion isn’t working well for TCP. It’s true that it detects congestion and retransmits lost segments. But, it also adds significant delay to delivery of the segments. Additionally, its adjustment to congestion is slow. Often dozens or hundreds of packets are dropped, when only one would signal the congested situation.
As a result, major players on the IT side have introduced technologies to try to avoid TCP’s problems. I’ve written about a few, including TCP BBR, Google’s QUIC and the active queue management techniques proposed within the IETF (Internet Engineering Task Force). On the AV side, SRT (Secure Reliable Transport) is also a method of getting some of the benefits of TCP goals but by using UDP. I would advise AV professionals to research each of these, as it will be some time before we see who the winners and who the losers are. In the meantime, here’s a list of critical questions to ask each company proposing to use of the techniques.
• If I deploy this technology, what are the benefits?
• Will I need to modify my existing devices that contain traditional TCP/IP protocol stack (Windows, Apple, Linux, etc.)?
• Is this technique headed for industry standardization?
• Is there any license or fee associated with its use?
With each of these proposed techniques, how the video is managed on the network is dependent on how the protocol works. We know traditional TCP is in trouble. But which of the new proposals might be its replacement?
Phil Hippensteel, PhD, is a regular contributor to AV Technology.
