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

[Maxim Sharabayko <[e-mail]>]

@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 <[e-mail]<mailto:[e-mail]>> on behalf of Mike English <[e-mail]<mailto:[e-mail]>>
Sent: 14 July 2021 19:09
To: Victor Vasiliev <vasilvv=[e-mail]<mailto:vasilvv=[e-mail]>>
Cc: Roberto Peon <fenix=[e-mail]<mailto:fenix=[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Alan Frindell <afrind=[e-mail]<mailto:afrind=[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Kirill Pugin <[e-mail]<mailto:[e-mail]>>; Luke Curley <[e-mail]<mailto:[e-mail]>>
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