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