QUIC replacing RTP

[Alex]

Hi,

about a month ago the webrtc product management stated that an opportunity for evolving webrtc would be replacing RTP with QUIC as transport protocol:

https://bloggeek.me/google-webrtc-interview-niklas-blum/

It would be interesting to see. Is there a plan/timeline when to possibly expect QUIC replacing RTP?

[Sergio Garcia Murillo]

Hi,

I think you're talking about using QUIC for datachannels instead of sctp.

BR

Sergio

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8cf3b937-d500-4983-a348-a488269cad76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex]

I mean using QUIC for the MediaTransport as it is mentioned in the interview.

QUIC could have several advantages over RTP such as multiplexing.

[pablo platt]

https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-quic-00

On Sat, Aug 26, 2017 at 12:50 AM, Alex <a.brau...@gmail.com> wrote:

I mean using QUIC for the MediaTransport as it is mentioned in the interview.

QUIC could have several advantages over RTP such as multiplexing.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ba8d9e10-146d-40cb-a486-14ffbf49ee5b%40googlegroups.com.

[Lorenzo Miniero]

I really hope not.

L.

Il giorno sabato 26 agosto 2017 00:27:29 UTC+2, pablo ha scritto:

https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-quic-00

On Sat, Aug 26, 2017 at 12:50 AM, Alex <a.brau...@gmail.com> wrote:

I mean using QUIC for the MediaTransport as it is mentioned in the interview.

QUIC could have several advantages over RTP such as multiplexing.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Sergio Garcia Murillo]

Well, according to the draft, it is not about replacing RTP with QUIC, but transporting RTP over QUIC.

What I fall to see is any reference to what problem does it try to address or what are the benefits over UDP/DTLS.

Best regards

Sergio

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CANdLC8WabVW-9vO9gqJfHUVVNw8qAFVahQj3Qrmziop%2ByBbCWw%40mail.gmail.com.

[Alex]

One advantage I can see is multiplexing: When having multiple streams between two peers, QUIC and RTP show different behavior:

- RTP packetizes the media frames on a per-stream basis, which means that media frames of each stream are packetized individually

- QUIC is able to multiplex the media frames between two peers, meaning frames are packetized together in one packet, which results in less packet header overhead

Another advantage might be quicker connection setup time, depending on how QUIC will be integrated (currently, e.g. for the DTLS over UDP, 2 round trips are needed, vs 0 RT with QUIC)

Am Samstag, 26. August 2017 09:48:55 UTC+2 schrieb Sergio Garcia Murillo:

Well, according to the draft, it is not about replacing RTP with QUIC, but transporting RTP over QUIC.

What I fall to see is any reference to what problem does it try to address or what are the benefits over UDP/DTLS.

Best regards

Sergio

El 26/8/2017 0:27, "pablo platt" <pablo...@gmail.com> escribió:

https://tools.ietf.org/html/draft-rtpfolks-quic-rtp-over-quic-00

On Sat, Aug 26, 2017 at 12:50 AM, Alex <a.brau...@gmail.com> wrote:

I mean using QUIC for the MediaTransport as it is mentioned in the interview.

QUIC could have several advantages over RTP such as multiplexing.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/ba8d9e10-146d-40cb-a486-14ffbf49ee5b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Sergio Garcia Murillo]

Couple of things, at least the draft talks about rtp over quic, so the rtp packetization still applies.

RTP does multiplexing already (with bundling), what you are describing IMO is packet aggregation. Aggregating packets doesn't makes sense for video as you typically have to split one media frame into several packets to respect udp mtu.

Aggregating video packets will only make sense if coming from different streams, so mostly will happen only in sfu->browser, so it will be a marginal improvement IMO.

Regarding the setup time, I assume that you will still need ICE for NAT traversal ( correct me if I am wrong) and we had 0 rtt in webrtc already ( via srtp sdes), but it had to be changed to fulfill the security requirements of not exchanging keys in signalling. I assume similar impact on quic (if not please correct me).

So, IMO, QUIC doesn't makes sense for webrtc media, especially due to the huge impact it will have to migrate to it.

Best regards

Sergio

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/65fa2e03-cb1f-4b25-80a1-217dfa844195%40googlegroups.com.

[Lorenzo Miniero]

Il giorno sabato 26 agosto 2017 22:02:07 UTC+2, Sergio Garcia Murillo ha scritto:

Couple of things, at least the draft talks about rtp over quic, so the rtp packetization still applies.

RTP does multiplexing already (with bundling), what you are describing IMO is packet aggregation. Aggregating packets doesn't makes sense for video as you typically have to split one media frame into several packets to respect udp mtu.

Aggregating video packets will only make sense if coming from different streams, so mostly will happen only in sfu->browser, so it will be a marginal improvement IMO.

Regarding the setup time, I assume that you will still need ICE for NAT traversal ( correct me if I am wrong) and we had 0 rtt in webrtc already ( via srtp sdes), but it had to be changed to fulfill the security requirements of not exchanging keys in signalling. I assume similar impact on quic (if not please correct me).

So, IMO, QUIC doesn't makes sense for webrtc media, especially due to the huge impact it will have to migrate to it.

+1

L.

 

Best regards

Sergio

[Iñaki Baz Castillo]

On Sat, Aug 26, 2017 at 10:01 PM, Sergio Garcia Murillo
<sergio.gar...@gmail.com> wrote:
> Couple of things, at least the draft talks about rtp over quic, so the rtp
> packetization still applies.
>
> RTP does multiplexing already (with bundling), what you are describing IMO
> is packet aggregation. Aggregating packets doesn't makes sense for video as
> you typically have to split one media frame into several packets to respect
> udp mtu.
>
> Aggregating video packets will only make sense if coming from different
> streams, so mostly will happen only in sfu->browser, so it will be a
> marginal improvement IMO.
>
> Regarding the setup time, I assume that you will still need ICE for NAT
> traversal ( correct me if I am wrong) and we had 0 rtt in webrtc already (
> via srtp sdes), but it had to be changed to fulfill the security
> requirements of not exchanging keys in signalling. I assume similar impact
> on quic (if not please correct me).
>
> So, IMO, QUIC doesn't makes sense for webrtc media, especially due to the
> huge impact it will have to migrate to it.

Just super agreed. Most of the RTP "limitations" (not really so) are
due the fact that RTP is designed to be carried over UDP, and AFAIK
QUIC also goes over UDP so the same fragmentation policy and rules
must be applied. Adding an extra layer can just change when
fragmentation/assembly happens, but from the point of view of
efficiency it's the very same.

Regarding the "multiplexing", well... we already have too many stuff
to demultiplex RTP streams/tracks (MID header extension, RID header
extension, SSRC, etc). Adding yet another multiplexing layer on the
bottom wouldn't help much IMHO.

Regards.

--
Iñaki Baz Castillo
<i...@aliax.net>

[Oscar Divorra]

+1

I'm not thrilled by the idea of having to face a migration to Quic from RTP, with the prospect of expected potential improvements. It may be an option to play with it on P2P to explore benefits, but I wouldn't expect an immediate interest from SFU providers for it.

Best,

Òscar

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfkkfa6qkRsDhePW%2BgGnG9T6zayZ5C%3DT%2BVG-m3X1ce-7zg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

---

Òscar Divorra, PhD

Media Cloud Engineering Lead & Spain Manager

Tokbox Inc. - a Telefónica company

08019 Barcelona - Spain

Cell: +34.689.575.393

[Peter Thatcher]

There are two things going on in relation to QUIC and WebRTC:

1.  We are working in the ORTC W3C CG to add support for QUIC data channels.  It's partially already in the spec and we're making progress on the design there, and we've made some progress in the implementation in Chrome (nothing exposed yet to web pages).  See the ORTC CG for more details.   

2.  We are experimenting with seeing if media can be sent directly over QUIC without RTP and how well that can work, but since QUIC IETF WG is still in progress and has decided to focus on the QUIC core and HTTP as its first use case, it's premature to be propose anything publicly.   We hope to propose something someday, but not yet.