What do you think about the evolution of Media Transports: The newest flavour is QUIC
A fairly technical question, top of mind for me this week, given it is IETF week. Hosted in Philly, I thought it would be great to ask this question.
Over the past 30 years, media has been delivered over UDP, then TCP, back to UDP.
For example -- Streaming protocols used to be over UDP (using RTSP, real-time streaming protocol, the Real Media Player was boss), then it was TCP (using HTTP and variants, thanks to Flash and then HTML5 via YouTube and Netflix), now we are back to UDP (using WebTransport and QUIC, via YouTube, Netflix, TikTok).
QUIC is emerging, W3C/WHATWG are making the browser APIs more flexible for both streaming (webtransport) and for real-time media -- What are your thoughts on the future transport for real-time media? Or maybe you have question?
A brief update from Philly:
Media over Quic Working Group is getting chartered to work on media streaming (ingest and distribution) -- The charter was ratified, needs to be confirmed on the mailing list.
There was some discussion of picking a use-case as the current charter is quite wide and that sometimes becomes contentious. Upcoming discussions will hopefully result in narrowing down the charter.
Multicast using Unicast was discussed in the QUIC Working group, basically sending the exact same packet on a unicast fanout, this is not typically easy to do on TCP. As TCP works on segments and not on packets, which means the intermediaries need to be content aware for doing TCP segment caching, i.e., recombine TCP segments into content that can be cached. In the case of QUIC, since it works on packets ands streams, there is an intuition of those content boundaries.
RTP over QUIC, was adopted as a working group draft, which signals that there is sufficient consensus to move ahead with the current proposal and that the community starts to work towards finalising this.0