Subject: Re: [Wish] [AVTCORE] Video ingest over QUIC

From: Maxim Sharabayko <[email-masked]>
Date: Thu, 15 Jul 2021 14:00:19 +0000

@Alan, cool draft, thanks for sharing!

@here
It would be extremely interesting to see a dedicated mailing list and a working group established to discuss options for live contribution over QUIC.

We at Haivision have started evaluating QUIC Datagrams as an underlying transport for the Secure Reliable Transport (SRT) protocol [1].
In such a combination QUIC provides a network transport known to CDNs and ISPs, allowing to route and load balance the traffic, while SRT is used for latency-aware live streaming at sub-second latencies and loss recovery based on ARQ and/or FEC.
An RFC draft preview "Tunneling SRT over QUIC" is available here [2].

We've also done a PoC using the quicly [3] library to assess the approach and check for technical difficulties like possible conflicts between SRT's and QUIC's CC. The results are exciting!

We would be happy to present our work to the IETF community.

[1] - https://tools.ietf.org/html/draft-sharabayko-srt-00
[2] - https://haivision.github.io/srt-rfc/draft-sharabayko-srt-over-quic.html
[3] - https://github.com/h2o/quicly

-- Maxim

________________________________
From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Mike English <[email-masked]<mailto:[email-masked]>>
Sent: 14 July 2021 19:09
To: Victor Vasiliev <vasilvv=[email-masked]<mailto:vasilvv=[email-masked]>>
Cc: Roberto Peon <fenix=[email-masked]<mailto:fenix=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Alan Frindell <afrind=[email-masked]<mailto:afrind=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Kirill Pugin <[email-masked]<mailto:[email-masked]>>; Luke Curley <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [Wish] [AVTCORE] Video ingest over QUIC

I would personally be very interested in a "video over QUIC" working group or mailing list.

The directness of this draft is perhaps what's most interesting to me.
In particular, the absence of out-of-band signaling / session establishment stands in striking contrast with another UDP-based media ingest option: WebRTC.

The signaling needed for session establishment (and the diversity of implementations for such signaling) has historically been a barrier for WebRTC adoption as an ingest protocol outside of the browser context. WISH-WG is working to improve that situation for WebRTC of course, but a new QUIC-based ingest protocol presents an opportunity to sidestep some of those known-issues by making an architectural decision up front about whether that style of session management is necessary in a video contribution workflow.

I'm hoping others with more experience on these lists can speak to the history and tradeoffs associated with those approaches, but I just wanted to call attention to the aspect of the draft that seemed most notable to me as an operator of a low latency streaming platform where WebRTC egress and ingest capabilities are provided, but where RTMP is still the de facto ingest protocol of choice for many users.

Thanks for sharing this work!
-Mike

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 15 Jul 2021 19:53:03 +0200

Wouldn't it be best to present the draft at the next DISPATCH meeting to
create a WG/mailing list/etc?

Best regards
Sergio

El jue, 15 jul 2021 a las 19:29, Maxim Sharabayko (<
[email-masked]>) escribió:

> It would be extremely interesting to see a dedicated mailing list and a
> working group established to discuss options for live contribution over
> QUIC.
>
>
>
> We at Haivision have started evaluating QUIC Datagrams as an underlying
> transport for the Secure Reliable Transport (SRT) protocol [1].
>
> In such a combination QUIC provides a network transport known to CDNs and
> ISPs, allowing to route and load balance the traffic, while SRT is used for
> latency-aware live streaming at sub-second latencies and loss recovery
> based on ARQ and/or FEC.
>
> We've also done a PoC using the quicly [3] library to assess the approach
> and check for technical difficulties like possible conflicts between SRT's
> and QUIC's CC. The results are exciting!
>
>
>
> [2] -
> https://haivision.github.io/srt-rfc/draft-sharabayko-srt-over-quic.html
>
> ------------------------------
>
> *From:* QUIC <[email-masked]> on behalf of Mike English <
> [email-masked]>
> *Sent:* 14 July 2021 19:09
> *To:* Victor Vasiliev <vasilvv=[email-masked]>
> *Cc:* Roberto Peon <fenix=[email-masked]>; [email-masked] <
> [email-masked]>; [email-masked] <[email-masked]>;
> [email-masked] <[email-masked]>; Alan
> Frindell <afrind=[email-masked]>; [email-masked] <[email-masked]>;
> Kirill Pugin <[email-masked]>; Luke Curley <[email-masked]>
> *Subject:* [EXTERNAL] Re: [Wish] [AVTCORE] Video ingest over QUIC
>
>
>
> In particular, the absence of out-of-band signaling / session
> establishment stands in striking contrast with another UDP-based media
> ingest option: WebRTC.
>
> The signaling needed for session establishment (and the diversity of
> implementations for such signaling) has historically been a barrier for
> WebRTC adoption as an ingest protocol outside of the browser context.
> WISH-WG is working to improve that situation for WebRTC of course, but a
> new QUIC-based ingest protocol presents an opportunity to sidestep some of
> those known-issues by making an architectural decision up front about
> whether that style of session management is necessary in a video
> contribution workflow.
>
> I'm hoping others with more experience on these lists can speak to the
> history and tradeoffs associated with those approaches, but I just wanted
> to call attention to the aspect of the draft that seemed most notable to me
> as an operator of a low latency streaming platform where WebRTC egress and
> ingest capabilities are provided, but where RTMP is still the de facto
> ingest protocol of choice for many users.
>
> Maxim Sharabayko
> Senior Software Developer
>
>  <https://www.haivision.com/>
>
>
>
>
> --
> Wish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wish
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Thu, 15 Jul 2021 13:10:33 -0700

Yes I think DISPATCH would be right avenue for exploring this further.

Best
  Nils Ohlmeier

> On Jul 15, 2021, at 10:53, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> Wouldn't it be best to present the draft at the next DISPATCH meeting to create a WG/mailing list/etc? 
> 
> Best regards
> Sergio
> 
> El jue, 15 jul 2021 a las 19:29, Maxim Sharabayko (<[email-masked] <mailto:[email-masked]>>) escribió:
> [1] - https://tools.ietf.org/html/draft-sharabayko-srt-00 <https://tools.ietf.org/html/draft-sharabayko-srt-00>
> [2] - https://haivision.github.io/srt-rfc/draft-sharabayko-srt-over-quic.html <https://haivision.github.io/srt-rfc/draft-sharabayko-srt-over-quic.html>
> [3] - https://github.com/h2o/quicly <https://github.com/h2o/quicly>
>  
> 
> -- Maxim
> 
>  
> 
>  
> 
> From: QUIC <[email-masked] <mailto:[email-masked]>> on behalf of Mike English <[email-masked] <mailto:[email-masked]>>
> Sent: 14 July 2021 19:09
> To: Victor Vasiliev <vasilvv=[email-masked] <mailto:vasilvv=[email-masked]>>
> Cc: Roberto Peon <fenix=[email-masked] <mailto:fenix=[email-masked]>>; [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>; Alan Frindell <afrind=[email-masked] <mailto:afrind=[email-masked]>>; [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>; Kirill Pugin <[email-masked] <mailto:[email-masked]>>; Luke Curley <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/wish <https://www.ietf.org/mailman/listinfo/wish>
> -- 
> Wish mailing list
> [email-masked]

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 16 Jul 2021 09:10:38 +1000

Given the size of this it might even be a good idea to get a bof together. It looks like there are lots of overlapping use cases and designs. First step would be to work out how many protocols are really needed here. It seems likely that at least some proposals have true overlapping requirements, but there might be cause to build more than one protocol.

For instance, Alan's proposal makes some assumptions about timeliness and reliability that suggest near real time ingest. WISH appears to bias even more towards real time. And I haven't really read all of these yet... But reliability didn't need to be a non-goal.

On Fri, Jul 16, 2021, at 06:10, Nils Ohlmeier wrote:
> > El jue, 15 jul 2021 a las 19:29, Maxim Sharabayko (<[email-masked]>) escribió:
> >> @Alan, cool draft, thanks for sharing!____
> >> __ __
> >> @here____
> >> It would be extremely interesting to see a dedicated mailing list and a working group established to discuss options for live contribution over QUIC.____
> >> __ __
> >> We at Haivision have started evaluating QUIC Datagrams as an underlying transport for the Secure Reliable Transport (SRT) protocol [1].____
> >> In such a combination QUIC provides a network transport known to CDNs and ISPs, allowing to route and load balance the traffic, while SRT is used for latency-aware live streaming at sub-second latencies and loss recovery based on ARQ and/or FEC.____
> >> An RFC draft preview "Tunneling SRT over QUIC" is available here [2].____
> >> __ __
> >> We've also done a PoC using the quicly [3] library to assess the approach and check for technical difficulties like possible conflicts between SRT's and QUIC's CC. The results are exciting!____
> >> __ __
> >> We would be happy to present our work to the IETF community. ____
> >> __ __
> >> [1] - https://tools.ietf.org/html/draft-sharabayko-srt-00____
> >> [2] - https://haivision.github.io/srt-rfc/draft-sharabayko-srt-over-quic.html____
> >> [3] - https://github.com/h2o/quicly____
> >> __ __
> >> -- Maxim____
> >> __ __
> >> __ __
> >> *From:* QUIC <[email-masked]> on behalf of Mike English <[email-masked]>
> >> *Cc:* Roberto Peon <fenix=[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; Alan Frindell <afrind=[email-masked]>; [email-masked] <[email-masked]>; Kirill Pugin <[email-masked]>; Luke Curley <[email-masked]>
> >> *Subject:* [EXTERNAL] Re: [Wish] [AVTCORE] Video ingest over QUIC____
> >>  ____
> >> -Mike____
> >> __ __
> >> __ __