Subject: QUIC use with multicast

From: Gyan Mishra <[email-masked]>
Date: Thu, 16 Jan 2020 21:05:32 -0500

QUIC WG

Has anyone ever tried using QUIC with multicast RTP UDP streamed using QUIC
transport.

Multicast has always been problematic with use on the internet MBONE and
even on intranets due the unreliable UDP RTP transport for MPEG4 MPEG-TS
and even newer protocols MPED-DASH abs and HLS multicast has struggled with
using UDP transport.

Multicast has thus required stringent end to end QOS in profile guaranteed
scheduling bandwidth hop by hop PHB to ensue no drops to avoid dropping of
I frame resulting in client frozen window and buffering.

Since QUIC is a secure reliable transport and supports unidirectional flows
it would be a perfect fit for multicast.

This would be a game changer for multicast as over the internet which you
don’t have any QOS guarantee.

Kind regards

Gyan

-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: [email-masked]

---

From: David Waring <[email-masked]>
Date: Fri, 17 Jan 2020 10:23:32 +0000

Hi Gyan,

You might want to look at
https://datatracker.ietf.org/doc/draft-pardue-quic-http-mcast/
which looks at using HTTP/3 in QUIC over IP multicast.

It not as simple as just using QUIC in multicast. As you point out, 
there are unidirectional streams, but these are encapsulated within a 
bidirectional QUIC session. The bidirectional nature is required to make 
the protocol reliable. Unfortunately bidirectional doesn't work well 
with multicast.

The draft above makes the stream truly unidirectional by removing the 
ack system on the QUIC multicast session, which removes the reliability, 
but also means that the session no longer needs to send anything back 
from receiver to sender. A separate bidirectional unicast session is 
used to fill in any gaps in the data streams received.

Another solution, which we considered as too complex at this stage, is 
to use multipath, with the unicast session being setup but using a 
second unidirectional multicast path to deliver the majority of shared 
content (live video stream for example). This would however require a 
separate packet number space for the multicast stream in order to share 
that path between multiple connections, which complicates the ack system 
and isn't catered for in the current incarnation of QUIC. But this is 
something we may look into in the future.

Regards,
David

On 17/01/2020 02:05, Gyan Mishra wrote:
> 
> QUIC WG
> 
> Has anyone ever tried using QUIC with multicast RTP UDP streamed using 
> QUIC transport.
> 
> and even newer protocols MPED-DASH abs and HLS multicast has struggled 
> with using UDP transport.
> 
> Multicast has thus required stringent end to end QOS in profile 
> guaranteed scheduling bandwidth hop by hop PHB to ensue no drops to 
> avoid dropping of I frame resulting in client frozen window and buffering.
> 
> Since QUIC is a secure reliable transport and supports unidirectional 
> flows it would be a perfect fit for multicast.
> 
> This would be a game changer for multicast as over the internet which 
> you don’t have any QOS guarantee.
> 
> Kind regards
> 
> Gyan
> 
> 
> -- 
> 
> Gyan  Mishra
> 
> Email: [email-masked] <mailto:[email-masked]>
> 
> 
> 
-- 
David Waring, Project Software Engineer, BBC Research & Development

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 17 Jan 2020 12:28:23 +0000

Hi Gyan,

Speaking as an individual, and author on the above mentioned I-D, I think
you've touched on quite a few interrelated topics in quite a succinct
question. Teasing them apart a little bit, the things that stand out to me
are listed below. Many of turn out not to be QUIC specific, or even
multicast specific, and are probably better addressed in various other IETF
WGs or areas; some under active discussion right now.

* Interdomain multicast on unmanaged networks (including ingress to or
egress from cloud providers). Covering both vanilla MBONE-like deployments,
or some kind of tunnelling between publisher and subscriber
* Multicast in managed networks.
* Multicast in WiFi networks.
* "Congestion control" or how to avoid detrimental over subscription.
Covering both accidental and malign causes.
* Management and Operability of multicast and video-oriented traffic more
generally.
* Loss detection and recovery. Including tunable FEC.
* Discoverability, handover and fallback.
* Confidentiality, Authentication and Integrity.
* Unidirectional transports (of at least one path in a "connection").
* Mapping of application layers to QUIC. For your example, RTP over QUIC
might be achievable via encapsulation in DATAGRAM[] frames or a
more-specific TRP application mapping document e.g.
draft-rtpfolks-quic-rtp-over-quic-01.

Cheers
Lucas

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 17 Jan 2020 18:33:14 -0500

Thanks David

Glad to hear that QUIC WG is looking at this gap that exists with today’s
 udp RTP multicast unreliable transport and a means of leveraging QUIC to
make it reliable.

I read the draft mentioned QUIC-http-multicast, which provides a means via
http/3 to carry multicast in QUIC, however since multicast has to be
unidirectional, a special QUIC profile is created that eliminates ACK by
receiver for multicast to work  which makes it an unreliable transport and
unfortunately in the same boat as RTP udp based multicast.

I would be very interested in developing the possible multipath draft
described as using a separate unicast control channel for the connection
establishment carrying the ACK and a separate  data channel carrying the
live video stream.

Just an idea.

Is it possible to use the datagram draft below for the live video data
channel and use the main QUIC transport draft for the bidirectional control
channel.

The QUIC transport channel would provide control mechanism to provide
feedback in quality from the RTCP packets at the receiver end to retransmit
packets over the datagram channel.

https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/

Kind regards

Gyan

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 17 Jan 2020 23:56:57 +0000

Hey Gyan,

Picking up on one thing:

>  udp RTP multicast unreliable transport and a means of leveraging QUIC to

Just to be clear here, the gap you describe is not covered by an item in
the QUIC charter. draft-pardue-quic-http-mcast is an Individual Draft and
not a QUIC Working Group document.

Cheers
Lucas