Re: Why QUIC is better than sliced bread

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.

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 ]