Re: Why QUIC is better than sliced bread

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.

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 ]
>
>