Re: QUIC use with multicast

[Ian Swett <[e-mail]>]

On Fri, Jan 17, 2020 at 6:33 PM Gyan Mishra <[e-mail]> wrote:

>
> 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/
>
>
Yes, I think that's a sensible design.

>
> 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] <(301)%20502-1347>
>> >
>> > 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] <(301)%20502-1347>
>
> Email: [e-mail]
>
>
>
>