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

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ó:

> @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]>
> *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
>
>
>
> 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
>
>
>
>
>
>
>
> Maxim Sharabayko
>
> Senior Software Developer
>
>  <https://www.haivision.com/>
>
>
>
>
> --
> Wish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wish
>

---

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

@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!

[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.

---

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]