Re: Getting rid of UDP

On Mon, Mar 5, 2018 at 2:54 PM Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> Inaki said:
>
> "Yes, what I mean is: why is QUIC is so good for carrying audio/video?"
>
> [BA] While it's not hard to come up with a peer-to-peer QUIC API for
> WebRTC (see the WebRTC-QUIC spec), we need to remember that the QUIC
> protocol is still "work in progress".
>
> The QUIC WG is only chartered to develop an HTTP transport, not a
> transport protocol for realtime media.
>
> Do to their IESG-enforced tunnel vision, QUIC isn't even yet a complete
> substitute for the SCTP data channel, yet alone a suitable transport for
> realtime media.
>


> QUIC v1 only provides reliable transport.  You can try to fake unreliable
> by setting a timer, but that won't really give you maxRetransmits, which is
> what you need to completely support unreliable data channel over QUIC.
>


> So really, we're talking about adding an unreliable transport to QUIC and
> perhaps other things as well - which might require waiting for QUICv2.
>


I don't think the protocol needs to change for maxRetransmits to be
implemented.  It's something that can be added to an implementation without
any standardization work, I think, so I don't think QUICv2 is really needed.

Plus, timing-based unreliability is good enough for my uses so far, so I'm
not too worried about it.