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

Re: Getting rid of UDP

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 05 Mar 2018 23:01:37 +0000
Message-ID: <CAJrXDUFyu4pJADSPDOWYdEqC=XELgUTQRyHnjHTdXNu=b2ULOA@mail.gmail.com>
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
Cc: IƱaki Baz Castillo <ibc@aliax.net>, WebRTC WG <public-webrtc@w3.org>
On Mon, Mar 5, 2018 at 2:54 PM Bernard Aboba <Bernard.Aboba@microsoft.com>

> 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.
Received on Monday, 5 March 2018 23:02:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 5 March 2018 23:02:13 UTC