368 views
 owned this note
# Video Ingest over QUIC side meeting ## Friday, Jul 30, 2021 11:00-12:00 ### Administrivia 5 min total * Attendance sheets - please register attendance at the bottom of the minutes * Agenda bashing * Meeting Chat: cellar room on jabber.ietf.org * Slide pointer will be provided after the meeting ### Reliable (unreliable) streaming protocol Kirill Pugin - 10 min [Draft](https://www.ietf.org/archive/id/draft-kpugin-rush-00.html) [Slides]( https://github.com/afrind/draft-rush/blob/main/meeting-materials/RUSH%20Reliable%20(Unreliable)%20Streaming%20protocol.pdf) ### SRT over QUIC Datagram Maxim Sharabayko - 10 min [SRT over QUIC Draft](https://datatracker.ietf.org/doc/html/draft-sharabayko-srt-over-quic) [SRT Draft](https://tools.ietf.org/html/draft-sharabayko-srt-00) [Slides](https://github.com/afrind/draft-rush/blob/main/meeting-materials/Tunnelling%20SRT%20over%20QUIC%20IETF111.pptx) ### RTP over QUIC Datagram Jörg Ott - 10 min [Draft](https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic) [Slides](https://github.com/afrind/draft-rush/blob/main/meeting-materials/RTP-over-QUIC-IETF111.pdf) ### General Discussion 15 minutes ### Logistics and next steps 10 minutes # Notes ## Agenda bashing: - RTP, streaming are we going to decide one way or the other? - Zoom Chat disabled, using the IETF Jabber room for CELLAR. Use +q for asking questions. ## Kirill presents RUSH - has been presented in a couple of other meetings, so going fast - defines two modes. - Normal mode has similar behavior to RMTP over TCP, which includes problems like head of line blocking - Multistream mode sends every new frame on a QUIC bidirectional stream - Sam Hurst - is the "frame" a QUIC frame or a media frame? Media. - Suhas - Bidirectional means you can return information to the server - Did you consider QUIC datagrams? They weren't in the picture at the time, but I like QUIC streams :D - makes the application developer life easier: no need to worry about retransmissions - Martin Duke - is audio synchronized with video in any way? No. Letting the endpoint handle that - Christian - do you support multiple media streams? We didn't that - not on the same connection. ## Maxim presents SRT over QUIC Datagrams - SRT is a sub-second latency live contribution and distribution protocol operating on top of UDP as a transport. The protocol offers stream multiplexing, bidirectional data transmission with mechanisms for packet loss recovery within a fixed end-to-end latency constraint. - Roughly speaking you could think of SRT as of something similar to RTP over UDP with RTCP and latency management, congestion control, etc. combined into one protocol. - SRT is content agnostic and thus can transmit any type of content in its payload - CDNs know how to handle and route QUIC traffic, while SRT can provide low-latency live workflows on top, stream multiplexing and access control (a client can identify itself and tell what it wants to do: receive live stream, ingest live stream, upload a file, etc.) - We have several related works, and may have more to follow - PoC using Fastly quicly library to provide QUIC datagtam transport - integrated into srt-xtransmit application for testing - [SRT over QUIC draft](https://datatracker.ietf.org/doc/draft-sharabayko-srt-over-quic/) submitted on July 28 - [SRT Protocol Overview (SVA 2020)](https://www.youtube.com/watch?v=MFJeyInLKZY) ### Q&A: - Jana: no retransmission with DATAGRAM: did you run experiments with QUIC normal connections? - we have not run these experiments. But they are on our list. - Did you experiment with Congestion Control? - disabled CC in quicly. For the first round of experiments we didn't want QUIC to apply CC in order to reduce the scope. SRT has it own CC. But it is a topic yet to discover. - Christian: MTU Discovery: did you do it in SRT or rely on QUIC? - we ran into problems with the default 1316 bytes of payload, and went down to 1128 bytes payload (6 MPEG-TS packets). ## Jörg presents RTP over QUIC Datagram - similar to hurst draft from BBC, in the sense that both are using datagrams - draft is https://datatracker.ietf.org/doc/html/draft-engelbart-rtp-over-quic - RTCP information is usually per-packet, but might not get per-packet feedback from QUIC - Metaquestions - RTP congestion control interaction with QUIC - hybrid reliability for video ingest - design is orthogonal to headers and packet formats - RTP is, in fact, old, but has a rich ecosystem of resources ## Q&A: - Victor - the last proposal is relying on feedback from the QUIC layer, which is discouraged - Christian - we're going to try a variety of designs - we have three. What are the benchmarks? - Jorg - could use RMCAT test framework - Colin - we have a pretty sophisticated way of describing payload format in RTP, and has hooks for offer/answer negotiation. We would be wise to tie into those payload layouts, no matter what we do with wire formats - Justin channels Jonathan Lennox - before we dive into performance, decide what the goals are. How much stuff can we reuse? - Murray - where has this been discussed? RUSH is new. SRT has been around since 2017. Has also been discussed in AVTCORE. - Roberto - interesting exploration is figuring out what goals are similar across use cases. Is video a thing, or is it an example? - Lucas - thank you for doing this. Don't have a strong answer about where this work should be, but look forward to the future - Jana - two sets of things going on. Having this conversation in one room would be super useful. Not sure what that means - How do you do video, and - how to map existing formats on top of video. ## Follow-up - Is there interest? 73 people in a side meeting - Do we want our own mailing list? - Is there an existing working group for it? - to AVTCORE for now, please? - Take it to DISPATCH? - BOF or clear charter for a working group - Murray, Zahed - this could be ART, if there's not too much QUIC as part of the discussions, but we do need TSV expertise - Luke: let's not make this ingest-specific - ### Attendees: Alan Frindell, Facebook Luca Niccolini, Facebook Chris Lemmons, Comcast Spencer Dawkins, Tencent America Magnus Westerlund, Ericsson James Gruessing, No Affiliation Colin Perkins, University of Glasgow Will Hawkins, University of Cincinnati Sam Hurst, BBC R&D Suhas Nandakumar, Cisco Dennis Sädtler, OBS Project Nick Banks, Microsoft Michael Thornburgh, Twitch Alex Converse, Twitch Zaheduzzaman Sarker, Ericsson Matt Joras, Facebook Max Stoller, Twitch Jonathan Lennox, 8x8 / Jitsi Ali C. Begen, Ozyegin University Victor Vasiliev, Google Renan Dincer, Cloudflare Daniel Havey, Microsoft Hannu Flinck, Nokia Ying Yin, Google Maxim Sharabayko, Haivision Maria Sharabayko, Haivision Jörg Ott, TUM Lucas Pardue, Cloudflare # From Jabber (1:02:44 PM) Jonathan Lennox: Can someone paste the link to the CodiMD here? (1:02:51 PM) James Gruessing: https://codimd.ietf.org/W_IANtwnRLmYOkvfbQoOJA?edit# (1:03:10 PM) ikir [_p8oriefs16nadll@guest.xmpp-trial1.ietf.org/mHox1to7] entered the room. (1:03:26 PM) Luke Curley [2jvrcqc0w-cqf-np@guest.xmpp-trial1.ietf.org/y2Fw2hTB] entered the room. (1:03:26 PM) jgh [chxcght5zaekhkbs@guest.xmpp-trial1.ietf.org/E2yA_zZu] entered the room. (1:03:43 PM) Nick Banks [zdogoyu2uqejgchz@guest.xmpp-trial1.ietf.org/5EblgyYe] entered the room. (1:04:16 PM) samhurst [enl5g5mz87l_fpkl@guest.xmpp-trial1.ietf.org/XsRstEbB] entered the room. (1:04:37 PM) Michael Thornburgh [7h6oqlu1u5tk86i1@guest.xmpp-trial1.ietf.org/rcFxV4iJ] entered the room. (1:05:01 PM) max [d0etuu-dgq7n1_zw@guest.xmpp-trial1.ietf.org/t_5IvbjR] entered the room. (1:05:05 PM) James Gruessing left the room. (1:05:17 PM) James Gruessing [ooydeb374jipblsq@guest.xmpp-trial1.ietf.org/k1XsrR8q] entered the room. (1:05:35 PM) Jordi (FB) [gs4kay5ysowj9zg1@guest.xmpp-trial1.ietf.org/Kdp0LUbS] entered the room. (1:05:50 PM) Alex Converse [3bth41sym1scsevs@guest.xmpp-trial1.ietf.org/KGb6CYgE] entered the room. (1:06:25 PM) Mathis [d0mgz3hplcitqace@guest.xmpp-trial1.ietf.org/6Nh8549I] entered the room. (1:08:19 PM) suhas [mekfz9sdufhyasda@guest.xmpp-trial1.ietf.org/u-jCUxc_] entered the room. (1:09:10 PM) christian [christian@getdnsapi.net/gajim.DWQ88XKT] entered the room. (1:09:12 PM) Roberto P [grmocg@xmpp-trial1.ietf.org/converse.js-109387522] entered the room. (1:09:37 PM) spencerdawkins: I see the pointers to drafts in the agenda. Are the slides available? (1:10:30 PM) Roberto P: It'll get posted later. (1:10:35 PM) ikir left the room (Disconnected: BOSH client silent for over 60 seconds). (1:11:10 PM) afrind left the room (Disconnected: BOSH client silent for over 60 seconds). (1:11:42 PM) cellar [murillo@jabbim.com/converse.js-59695079] entered the room. (1:12:02 PM) Michael Thornburgh left the room (Disconnected: BOSH client silent for over 60 seconds). (1:13:21 PM) samhurst: +q (1:14:09 PM) Will Hawkins [wxof_6c00d6hyysr@guest.xmpp-trial1.ietf.org/JTy0pKRc] entered the room. (1:14:09 PM) Luke Curley left the room (Disconnected: BOSH client silent for over 60 seconds). (1:14:11 PM) spencerdawkins: Roberto- thanks! (1:14:22 PM) Alex Converse left the room (Disconnected: BOSH client silent for over 60 seconds). (1:14:23 PM) suhas: +q (1:14:36 PM) christian: +q (1:14:42 PM) Will Hawkins: Do all the open connections cause load on the server? (1:14:45 PM) afrind [pe5puswg75aja3px@guest.xmpp-trial1.ietf.org/bgignI-R] entered the room. (1:14:50 PM) Will Hawkins: I mean, streams. Sorry! (1:14:58 PM) Michael Thornburgh [coxqtzh65pvvehyr@guest.xmpp-trial1.ietf.org/y0Jc2vNj] entered the room. (1:15:01 PM) lpardue [lucaspardue@jabber.hot-chilli.net/converse.js-98833280] entered the room. (1:15:05 PM) Jana Iyengar [janaiyengar@jabber.no/this] entered the room. (1:15:07 PM) dragana [dragana@jabber.de/converse.js-101571835] entered the room. (1:15:12 PM) Alex Converse [f-qpsnroz-xyiddj@guest.xmpp-trial1.ietf.org/9e3vVbMW] entered the room. (1:15:16 PM) Roberto P: Nope. No different than processing a bunch of stream data, just using a different way of sending the address (1:15:38 PM) Luke Curley [rgrhpgsa7aad7s-_@guest.xmpp-trial1.ietf.org/MqKWCdDH] entered the room. (1:15:38 PM) csp: Is there content format negotiation? (e.g., something similar to SDP offer/answer) (1:15:45 PM) Will Hawkins: Are those streams closed immediately after the frame is received? (1:16:33 PM) afrind: == cutting the queue == (1:18:08 PM) ikir [a8ylletwks-p2kql@guest.xmpp-trial1.ietf.org/9khBkK7J] entered the room. (1:18:27 PM) cellar: my questions were: (1:19:09 PM) magnus.westerlund: The media format here appears unclear. There was statement about timestamps, but in which way are they included. Are this some RTP or ISO base media format that has been used? (1:19:09 PM) cellar: As the session setup is done on the same connection as the media flow, how is load balancing meant to be done? (1:19:38 PM) cellar: Have you considered to implementing the transport on top of WebTransport instead of just QUIC? (1:20:27 PM) ikir: > The media format here appears unclear. There was statement about timestamps, but in which way are they included. Are this some RTP or ISO base media format that has been used? It's in audio/video frame, each audio frame has track ID, timestamp and codec ID (1:21:12 PM) ikir: > Is there content format negotiation? (e.g., something similar to SDP offer/answer) no, format is defined by frame type and codec ID (1:21:18 PM) suhas: ikir that might provide simple mapping to WebRTC object constructs in a way, isn't it (1:21:41 PM) max left the room (Disconnected: BOSH client silent for over 60 seconds). (1:21:59 PM) ikir: suhas can you clarify? (1:22:21 PM) spencerdawkins: Is it correct that the current SRT draft reflects SRT over UDP, not over QUIC? I was confused about that. (1:22:39 PM) ikir: > Have you considered to implementing the transport on top of WebTransport instead of just QUIC? What would be benefit? (1:22:46 PM) afrind: spencerdawkins: there' (1:22:59 PM) afrind: 's a separate draft that uses quic datagram (1:23:03 PM) suhas: ikir sorry, i was referring to having constructs like trackId for media types, exposes nice mapping to somethihg like webrtc api (1:23:08 PM) ikir: > Are those streams closed immediately after the frame is received? yes, in multi-stream mode (1:23:40 PM) ranjeeth [ranjeeth@xmpp-trial1.ietf.org/-J6PJXr4] entered the room. (1:24:12 PM) km [kiran.ietf@xmpp-trial1.ietf.org/converse.js-138279610] entered the room. (1:24:32 PM) martin.duke [martin.duke@jabber.today/306419194-tigase-780] entered the room. (1:24:58 PM) James Gruessing left the room (Disconnected: BOSH client silent for over 60 seconds). (1:27:25 PM) Nick Banks left the room (Disconnected: BOSH client silent for over 60 seconds). (1:27:48 PM) spencerdawkins: @afrind - ah, I didn't check on July 28 :D (1:27:59 PM) ikir: suhas yes, I think it would be possible to cover webrtc API 😃 (1:28:11 PM) martin.duke: Has he mentioned disabling either QUIC or SRT congestion control, or are there two layers running? (1:28:36 PM) James Gruessing [unglwwib0zhn-7r6@guest.xmpp-trial1.ietf.org/7KnLc4FB] entered the room. (1:29:12 PM) Nick Banks [nfnopbfybfym5cus@guest.xmpp-trial1.ietf.org/J5cxr5AQ] entered the room. (1:29:12 PM) Ying [6snevjxvhs_oafwy@guest.xmpp-trial1.ietf.org/b7m3aR-N] entered the room. (1:29:35 PM) afrind: i don't think he mentioned it. (1:30:38 PM) Will Hawkins left the room (Disconnected: BOSH client silent for over 60 seconds). (1:30:53 PM) Jana Iyengar: +1 (1:30:55 PM) christian: +q (1:30:56 PM) Jana Iyengar: +q (1:30:58 PM) max [47t-2f6hslpzzkfg@guest.xmpp-trial1.ietf.org/EjMAkTLO] entered the room. (1:31:08 PM) martin.duke: +q (1:31:44 PM) afrind: == cutting the queue === (1:32:01 PM) BEHCET SARIKAYA [sarikaya@lightwitch.org/Behcets-MacBook-Pro] entered the room. (1:32:12 PM) lpardue: +1 to jana's comment on substitution/duplication (1:32:24 PM) martin.duke: -q (1:32:51 PM) BEHCET SARIKAYA: anybody knows if SRT is implemented in python? (1:33:49 PM) cellar: +q (1:34:10 PM) lpardue: the ability to disable CC in QUIC layer keeps popping up. A common design for a QUIC CC circuit breaker, if needed, seems potentially useful (1:34:17 PM) cellar left the room. (1:34:28 PM) Sergio Garcia Murillo [murillo@jabbim.com/converse.js-59695079] entered the room. (1:34:57 PM) chi.jiun.su [chi.jiun.su@lightwitch.org/gajim.WP23Y17X] entered the room. (1:35:17 PM) samhurst: BEHCET SARIKAYA I know that the reference SRT implementation on Github is written in C++, I'm not aware of any Python implementations (1:35:53 PM) BEHCET SARIKAYA: Thanks Sam (1:35:57 PM) Luke Curley: lpardue yeah, the main issue is that layering CC algorithms on top of each other hurts the final bitrate (1:35:59 PM) Jana Iyengar: "What's PMTUD?" — a bat signal just went out — waiting to see if Gorry Fairhurst descends on Maxim (1:36:09 PM) christian: @lpardue the CC issues become interesting if you use datagram for audio and video, but send data over quic streams (1:36:17 PM) ikir: lpardue , yeah we did turn off QUIC CC as well, to test RUSH + RMCAT vs WebRTC (1:37:02 PM) BEHCET SARIKAYA: In the slides I saw some python reference? mention of python functions, etc. (1:37:25 PM) Nick Banks left the room (Disconnected: BOSH client silent for over 60 seconds). (1:37:59 PM) suhas left the room (Disconnected: BOSH client silent for over 60 seconds). (1:38:19 PM) lpardue: good reply points all 🙂 (1:38:21 PM) Jana Iyengar: @lpardue — that's one of the config switches I want for MASQUE. In general, it's just a bit more involved to think about doing that for just DATAGRAMS, since they could be mixed in with STREAM frames otherwise. (1:38:24 PM) James Gruessing left the room (Disconnected: BOSH client silent for over 60 seconds). (1:39:10 PM) Jana Iyengar: I suppose you could think of the DATAGRAM flow and the other STREAM flows as competing congestion controllers if you kept the DGRAM flow out of the QUIC connection's CC (1:39:26 PM) suhas [tjxhsdjfcc45vjui@guest.xmpp-trial1.ietf.org/p0uNAZV_] entered the room. (1:39:41 PM) Luke Curley: I would prefer a world where QUIC CC is good enough for all datagram use-cases, but it's always going to be contested (1:40:33 PM) magnus.westerlund: What is QUIC CC, the spec defines a RENO based. People have implemented Cubic, BBR etc. So there are really not one CC in use. (1:40:40 PM) max left the room (Disconnected: BOSH client silent for over 60 seconds). (1:40:48 PM) Jana Iyengar: @Luke — that's actually not hard. The separation between loss recovery (or send scheduling) and CC in QUIC is helpful in this regard. CC's goal is to get you a pipe, the scheduler decides _what_ to send. (1:41:04 PM) Luke Curley: QUIC is ACK based, while RTP is NACK based and SRT is a mix (1:41:09 PM) suhas: ikir do you have public info on RUSH and CC interactions (1:41:21 PM) Luke Curley: I think that's a pretty fundamental difference and why people try to disable QUIC CC (1:41:42 PM) BEHCET SARIKAYA: RTP/RTCP : very important making them work in Quic is going to be revolutionary :) (1:42:03 PM) ikir: Luke Curley is SRT a mix? I thought it's NACK based (1:42:08 PM) Jana Iyengar: That's unfortunate. The ACK-based vs NACK-based is a red herring. CC is CC, either way. (1:42:35 PM) magnus.westerlund: I would debate your statement about RTP. RTP supports, ACK, NACK, failure, the RMCAT feedback format etc. So it is depends on what you implement and want to use. NACK has been default due to the multi-party nature of RTP. (1:43:08 PM) Luke Curley: ikir the SRT folks are here to correct me but as far as I know, SRT has NACK, ACK, and ACK ACK (1:43:16 PM) magnus.westerlund: For those applications that care about which packets is missing. Like for Retransmission. (1:43:19 PM) christian: CC is not quite CC either way. For data, it is OK to vary datarate widely in order to test the conection. For real-time, not so much. (1:43:43 PM) Jana Iyengar: Agreed, Christian, but that has very little to do with ACK or NACK based (1:43:48 PM) ikir: suhas not any public data yet, we had presented some data on CC: https://datatracker.ietf.org/meeting/106/materials/slides-106-iccrg-experiments-at-facebook-with-copa-00 (1:44:09 PM) christian: Sure. CC is also based on delays, ECN marks, etc. (1:44:15 PM) Jana Iyengar: Yes (1:44:24 PM) suhas: ikir thank you (1:44:47 PM) max [bsgawnaahloatjkr@guest.xmpp-trial1.ietf.org/fnc5yCtC] entered the room. (1:44:48 PM) magnus.westerlund: And I think RTP has extensions for reporting all of this metrics. (1:45:04 PM) christian: +q (1:45:17 PM) Nick Banks [t-u5bv5zwvq2hysm@guest.xmpp-trial1.ietf.org/BxGwh9_W] entered the room. (1:45:27 PM) csp: +q (1:45:51 PM) suhas: afrind is this session recorded ? (1:45:57 PM) afrind: no (1:47:03 PM) Jana Iyengar: @afrind: Are we in general discussion? (1:47:07 PM) afrind: sure (1:47:46 PM) Victor Vasiliev [b0rgs7ksmuj_qxos@guest.xmpp-trial1.ietf.org/dYFpQkYZ] entered the room. (1:49:14 PM) James Gruessing [4em2bidlkbnfiuxc@guest.xmpp-trial1.ietf.org/XmQwrqB-] entered the room. (1:50:30 PM) lpardue: +q (1:50:37 PM) Jana Iyengar: +q (1:51:30 PM) afrind: == cutting general discussion queue == (1:51:54 PM) BEHCET SARIKAYA: I have a big question: what is ingest? (1:52:07 PM) Luke Curley: +q (1:52:21 PM) BEHCET SARIKAYA: Was not explained so far in this meetingf (1:52:27 PM) Jana Iyengar: @Behcet — the thing before digest (1:52:41 PM) max left the room (Disconnected: BOSH client silent for over 60 seconds). (1:52:44 PM) Victor Vasiliev: +q for where to keep discussion (1:52:57 PM) Luke Curley: yeah that was my +q too (1:53:18 PM) magnus.westerlund: Behcet Inget is the ingestion of media from an client into a media processing/distribution system. (1:53:26 PM) Jonathan Lennox: Ingest is uploading (usually live) media to a server, for distribution. (1:53:46 PM) dennis left the room (Disconnected: BOSH client silent for over 60 seconds). (1:54:32 PM) James Gruessing: +q on what should we do (1:54:33 PM) max [rbzqimuzus0w2f4n@guest.xmpp-trial1.ietf.org/jTEVIkUM] entered the room. (1:54:42 PM) BEHCET SARIKAYA: so you mean live video on quic (1:54:48 PM) km left the room (Disconnected: BOSH client silent for over 60 seconds). (1:54:51 PM) BEHCET SARIKAYA: like zoom on quic? (1:55:07 PM) km [kiran.ietf@xmpp-trial1.ietf.org/converse.js-138279610] entered the room. (1:55:39 PM) magnus.westerlund: Live streaming, field reporters into TV production. (1:55:39 PM) spencerdawkins: Too late to be in Q? (1:56:07 PM) Luke Curley: can I request that we don't limit the group to ingest only? (1:56:18 PM) Jana Iyengar: I think this is a natural thing that folks have been interested in doing for a while and work is clearly happening already. Doing this in the IETF makes sense to me. I agree with Zahed: wherever it sits, it will need AVT and QUIC folk in the room. (1:56:20 PM) magnus.westerlund: Zoom as conferencing could potentially be built on this also. But I think there is a question of exactly how low latency requirements one have. (1:56:25 PM) Nick Banks left the room (Disconnected: BOSH client silent for over 60 seconds). (1:56:26 PM) ikir: Luke Curley +1 (1:56:44 PM) suhas: +1 on - we should work on this problem statement. May be we need to define problem area/use-cases that we aim to address .. +1 on doing work in this area .. (1:57:36 PM) lpardue: media over QUIC transport technology, or MQTT for short (1:57:46 PM) jgh: +1 lpardue (1:57:47 PM) Jana Iyengar: hah (1:57:56 PM) ikir: lol (1:58:04 PM) ikir: not confusing at all 😃 (1:58:40 PM) magnus.westerlund: On the high level question here. Is what part of the system are we targeting. What media formats are we are targeting, is it RTP Payload formats, MPEG TS, ISO-based media formats. On top of that is the negotiation that where WISH is working specific. Then we have the lower layer transport quesiton of how to actually send the media over QUIC. (1:59:10 PM) magnus.westerlund: So there are a lot of question of scope here. (1:59:10 PM) ikir: magnus.westerlund format that solve problem that we care about 😉 (1:59:11 PM) spencerdawkins: I'm cutting the current jabber room for the minutes - please check the minutes for anything after this (1:59:15 PM) Jonathan Lennox: Proposed ml name: Media over Quic (moq)