Re: Why QUIC is better than sliced bread

> On Mar 5, 2018, at 11:57 PM, Peter Thatcher <pthatcher@google.com> wrote:
> 
> I agree entirely with the transport/security/media split and that this is a change to clean things up.
> 
> I thought about this years ago with media over DTLS/SCTP, since it would largely accomplish the same thing.  But I couldn't get over how many round trips would be needed to set it all up.  Then QUIC came along and solved that problem. 
Won't DTLS 1.3 provide a 0-RTT connection setup similar to QUIC? Adding a 0-RTT connection setup for
SCTP is straight forward, since you don't need the cookie protection when running on top of DTLS.

Best regards
Michael
> 
> On Mon, Mar 5, 2018 at 2:52 PM Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
> 
> 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 23:05:16 UTC