There’s an emerging pattern in the broadcast industry and beyond; when we want the best out of a network, we don’t turn to TCP.
Imagine a boss who stood over you ensuring every email you send got a reply. Imagine a boss who would stop you sending any more emails if the replies to your emails had fallen behind, who made you chase up those correspondents first for replies before letting you get on and email anyone else, or reply to their emails. Not only would the overhead in dealing with your boss be a burden, but whenever they called a moratorium on new communication in favour of chasing up old, that would seriously disrupt your ability to get work done. If someone goes on holiday for 3 days, that’s it for getting work done! You’ll have to wait until they get back before starting anything new.
So the above sounds ridiculous even for a micromanager. But this is what TCP is. It demands that every packet is accounted for and will call a halt to proceedings if it doesn’t get its way. Is there any wonder people are turning to its uninhibited cousin, UDP, to get things done?
UDP makes no claims to ensure delivery. Just like the postal service, it will do its best, but there are no guarantees. If you want to ensure the sender receives their letter, then you need to ring ahead and tell them they’re going to receive a letter. You need to agree when it’s likely to come and an a plan of action if it doesn’t arrive, such as ringing you back to tell you. This an example of how you can construct your own reliable delivery mechanism around an unreliable method. For the letter, if you get the call that “nothing’s arrived.” you can arrange to send another copy of the letter. And if you agree you’ll send one letter a day, you can dispense with the initial phone call.
Creating your own reliable delivery mechanism is exactly what RIST, SRT and QUIC do. Where their predecessors would have used TCP to send data, they use UDP. This dispenses with the micromanagement overhead and frees them to do keep data flowing even when there’s a problem. TCP continues to be horrendously useful for file-based transfer, but there’s a growing recognition that TCP has its place, but we shouldn’t be afraid to take control when we can deliver something better.