Re: QUIC use with multicast

[Gyan Mishra <[e-mail]>]

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

On Fri, Jan 17, 2020 at 5:23 AM David Waring <[e-mail]>
wrote:

> 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.
> >
> > 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: [phone]
> >
> > Email: [e-mail] <mailto:[e-mail]>
> >
> >
> >
> --
> David Waring, Project Software Engineer, BBC Research & Development
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]