Short technical exchange explaining why TCP is unsuitable for real-time communication (RTC). Speakers emphasize TCP's lossless, in-order delivery causes head-of-line blocking and requires paying the cost of retransmission/reordering even when real-time codecs can tolerate loss or prefer per-packet recovery strategies.
This should be a simple question. Why don't we like TCP for rtc?
The standard answer for that is because HEAD of line blocking. So TCP is a lossless protocol, which is great because if you do something, you don't need to take care as an application developer. But the problem is that this loss causes a packet in a sequence of packets to be lost. And before you can read the thing that's coming at the top of the line, you need to read everything that came before it. And for the systems the way we have designed them, that is not a requirement we have for RTC because our codecs deal with loss for audio or we have ways to recover individual packets, depending on our needs.
The way I see it is it's the same, but slightly different. If you look at tcp. TCP is a lossless protocol, which means that it has its own retransmission mechanism. It also does reordering on its own. So everything comes in the same sequence. It's like it does everything you want. The problem is what happens if you don't want some of the things that it gives you now. If you don't want them, you still pay for them if you use tcp. So the cost of TCP when you want to do things in real time is too high for us to use when there is packet loss on the network, which is why we don't like it.
Meta rebuilt AV1 for mobile scale. Should smaller teams follow? | Chats with Arin
