Why QUIC is better than sliced bread


So to be clear, QUIC as it is today still might need a few things (like done is a feature) but I’m talking about what I believe QUIC might become vs where it is today …

Lets start with the pragmatic:

You can get media over TCP to sound/look OK some of the time, and you can get it to work lots of the time, but you can’t get it to sounds great all the time. You can get media over UDP to sound/look great but you can’t get it inbound through a firewall all of the time. 

Yes, I understand that QUIC is over UDP, but QUIC is changing the equation for firewalls and firewalls are adopting support for allowing QUIC at an substantial rate. At this point, you need to be brave to bet that QUIC will fail. 

Moving to the more academic:

In RTP we totally botched the way it was split between app and transport. The transports parts of it should have been a new transport protocol (like UPD or TCP) and the media applications parts should have been layered above that, and the security in between the two. This is a chance to clean up that architecture misfit. We can’t make QUIC it’s own transport because of how the internet is ossified so it needs to be over UDP but for all architectural purposes, it is its own protocol. Some great features are 1) runs in user space 2) includes congestion control and session levels security at the right layer 3) design for extensibility 4) an app that everyone wants ( cat videos ) is going to force it to deploy. 

With that all said:

Yah, I still think we will need UDP &  TCP fallback for many years while this deploys. 

[ And as requested for Inaki, this does not mention codecs, or api which are an orthogonal topic ]

Received on Monday, 5 March 2018 22:50:04 UTC