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 protected]> 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 protected] <mailto:[email protected]>>) 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 > <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 protected] <mailto:[email protected]>> on behalf > of Mike English <[email protected] <mailto:[email protected]>> > Sent: 14 July 2021 19:09 > To: Victor Vasiliev <[email protected] > <mailto:[email protected]>> > Cc: Roberto Peon <[email protected] > <mailto:[email protected]>>; [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>>; [email protected] > <mailto:[email protected]> <[email protected] > <mailto:[email protected]>>; Alan Frindell > <[email protected] <mailto:[email protected]>>; > [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>; > Kirill Pugin <[email protected] <mailto:[email protected]>>; Luke Curley > <[email protected] <mailto:[email protected]>> > 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 > <logo-h.png> <https://www.haivision.com/> > > > > > -- > Wish mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/wish > <https://www.ietf.org/mailman/listinfo/wish> > -- > Wish mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/wish
