W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2018

Re: Why QUIC is better than sliced bread

From: Michael Tuexen <michael.tuexen@lurchi.franken.de>
Date: Tue, 6 Mar 2018 10:00:36 +0100
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, WebRTC WG <public-webrtc@w3.org>
Message-Id: <59AAFF6C-9553-462F-80C9-3A49846D01E8@lurchi.franken.de>
To: Peter Thatcher <pthatcher@google.com>
> On Mar 6, 2018, at 12:14 AM, Peter Thatcher <pthatcher@google.com> wrote:
> 
> On Mon, Mar 5, 2018 at 3:04 PM Michael Tuexen <michael.tuexen@lurchi.franken.de> wrote:
> > 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?
> 
> Yes.
>  
> 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.
> 
> 
> If that happens and SCTP gets BBR or other real-time friendly congestion control, then it will be a lot more reasonable to use for media.
It should not be a problem to implement BBR for SCTP when BBR becomes more stable... I think someone already
implemented it:
https://docs.google.com/document/d/1RWEKpxjF4-K8-w1DhQrcZFb1ICtDY9hY3x9t54XIWf4/edit#heading=h.3dkbvhnlpzf4

Best regards
Michael
> 
> A set of low-level  APIs we make should make it so the app can choose which transport it wants: either DTLS+SCTP or QUIC or SRTP (within limits; we probably don't want an SRTP data channel).  
>  
> 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 Tuesday, 6 March 2018 09:01:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 March 2018 09:01:23 UTC