IETF
cellar
cellar@jabber.ietf.org
Friday, July 30, 2021< ^ >
Room Configuration
Room Occupants

GMT+0
[17:58:23] spencerdawkins joins the room
[17:58:30] James Gruessing joins the room
[17:59:02] dennis joins the room
[18:01:21] csp joins the room
[18:02:04] afrind joins the room
[18:02:13] Jonathan Lennox joins the room
[18:02:23] Mirja joins the room
[18:02:28] magnus.westerlund joins the room
[18:02:44] <Jonathan Lennox> Can someone paste the link to the CodiMD here?
[18:02:51] <James Gruessing> https://codimd.ietf.org/W_IANtwnRLmYOkvfbQoOJA?edit#
[18:03:10] ikir joins the room
[18:03:26] Luke Curley joins the room
[18:03:27] jgh joins the room
[18:03:43] Nick Banks joins the room
[18:04:16] samhurst joins the room
[18:04:37] Michael Thornburgh joins the room
[18:05:01] max joins the room
[18:05:05] James Gruessing leaves the room
[18:05:17] James Gruessing joins the room
[18:05:35] Jordi (FB) joins the room
[18:05:50] Alex Converse joins the room
[18:06:25] Mathis joins the room
[18:08:19] suhas joins the room
[18:09:06] christian joins the room
[18:09:12] Roberto P joins the room
[18:09:37] <spencerdawkins> I see the pointers to drafts in the agenda. Are the slides available?
[18:10:30] <Roberto P> It'll get posted later.
[18:10:35] ikir leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:11:10] afrind leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:11:42] cellar joins the room
[18:12:02] Michael Thornburgh leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:13:21] <samhurst> +q
[18:13:51] Will Hawkins joins the room
[18:14:01] Luke Curley leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:14:11] <spencerdawkins> Roberto- thanks!
[18:14:22] Alex Converse leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:14:23] <suhas> +q
[18:14:36] <christian> +q
[18:14:42] <Will Hawkins> Do all the open connections cause load on the server?
[18:14:45] afrind joins the room
[18:14:50] <Will Hawkins> I mean, streams. Sorry!
[18:14:59] Michael Thornburgh joins the room
[18:15:01] lpardue joins the room
[18:15:05] Jana Iyengar joins the room
[18:15:07] dragana joins the room
[18:15:13] Alex Converse joins the room
[18:15:16] <Roberto P> Nope. No different than processing a bunch of stream data, just using a different way of sending the address
[18:15:38] Luke Curley joins the room
[18:15:38] <csp> Is there content format negotiation? (e.g., something similar to SDP offer/answer)
[18:15:45] <Will Hawkins> Are those streams closed immediately after the frame is received?
[18:16:33] <afrind> == cutting the queue ==
[18:18:09] ikir joins the room
[18:18:27] <cellar> my questions were:
[18:18:53] <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?
[18:19:05] <cellar> As the session setup is done on the same connection as the media flow, how is load balancing meant to be done?
[18:19:38] <cellar> Have you considered to implementing the transport on top of  WebTransport instead of just QUIC?
[18:20:27] <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
[18:21:12] <ikir> > Is there content format negotiation? (e.g., something similar to SDP offer/answer)
no, format is defined by frame type and codec ID
[18:21:19] <suhas> ikir  that might provide simple mapping to WebRTC object constructs in a way, isn't it
[18:21:41] max leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:21:59] <ikir> suhas can you clarify?
[18:22:21] <spencerdawkins> Is it correct that the current SRT draft reflects SRT over UDP, not over QUIC? I was confused about that.
[18:22:39] <ikir> > Have you considered to implementing the transport on top of  WebTransport instead of just QUIC?
What would be benefit?
[18:22:47] <afrind> spencerdawkins: there'
[18:22:59] <afrind> 's a separate draft that uses quic datagram
[18:23:03] <suhas> ikir  sorry, i was referring to having constructs like trackId for media types, exposes nice mapping to somethihg like webrtc api
[18:23:08] <ikir> > Are those streams closed immediately after the frame is received?
yes, in multi-stream mode
[18:23:40] ranjeeth joins the room
[18:23:52] km joins the room
[18:24:33] martin.duke joins the room
[18:24:58] James Gruessing leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:27:25] Nick Banks leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:27:48] <spencerdawkins> @afrind - ah, I didn't check on July 28 :D
[18:27:59] <ikir> suhas yes, I think it would be possible to cover webrtc API 😃
[18:28:11] <martin.duke> Has he mentioned disabling either QUIC or SRT congestion control, or are there two layers running?
[18:28:36] James Gruessing joins the room
[18:28:54] Nick Banks joins the room
[18:29:09] Ying joins the room
[18:29:35] <afrind> i don't think he mentioned it.
[18:30:38] Will Hawkins leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:30:54] <Jana Iyengar> +1
[18:30:56] <christian> +q
[18:30:56] <Jana Iyengar> +q
[18:30:58] max joins the room
[18:31:08] <martin.duke> +q
[18:31:44] <afrind> == cutting the queue ===
[18:32:02] BEHCET SARIKAYA joins the room
[18:32:12] <lpardue> +1 to jana's comment on substitution/duplication
[18:32:24] <martin.duke> -q
[18:32:51] <BEHCET SARIKAYA> anybody knows if SRT is implemented in python?
[18:33:49] <cellar> +q
[18:34:10] <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
[18:34:15] cellar leaves the room
[18:34:28] Sergio Garcia Murillo joins the room
[18:34:57] chi.jiun.su joins the room
[18:35:17] <samhurst> BEHCET SARIKAYA I know that the reference SRT implementation on Github is written in C++, I'm not aware of any Python implementations
[18:35:54] <BEHCET SARIKAYA> Thanks Sam
[18:35:57] <Luke Curley> lpardue yeah, the main issue is that layering CC algorithms on top of each other hurts the final bitrate
[18:35:59] <Jana Iyengar> "What's PMTUD?" — a bat signal just went out — waiting to see if Gorry Fairhurst descends on Maxim
[18:36:09] <christian> @lpardue the CC issues become interesting if you use datagram for audio and video, but send data over quic streams
[18:36:17] <ikir> lpardue , yeah we did turn off QUIC CC as well, to test RUSH + RMCAT vs WebRTC
[18:37:02] <BEHCET SARIKAYA> In the slides I saw some python reference? mention of python functions, etc.
[18:37:25] Nick Banks leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:37:59] suhas leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:38:19] <lpardue> good reply points all 🙂
[18:38:22] <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.
[18:38:25] James Gruessing leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:39:03] <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
[18:39:26] suhas joins the room
[18:39:41] <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
[18:40:33] <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.
[18:40:40] max leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:40:48] <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.
[18:41:04] <Luke Curley> QUIC is ACK based, while RTP is NACK based and SRT is a mix
[18:41:09] <suhas> ikir  do you have public info on RUSH and CC interactions
[18:41:21] <Luke Curley> I think that's a pretty fundamental difference and why people try to disable QUIC CC
[18:41:43] <BEHCET SARIKAYA> RTP/RTCP : very important making them work in Quic is going to be revolutionary :)
[18:42:03] <ikir> Luke Curley is SRT a mix? I thought it's NACK based
[18:42:08] <Jana Iyengar> That's unfortunate. The ACK-based vs NACK-based is a red herring. CC is CC, either way.
[18:42:35] <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.
[18:43:08] <Luke Curley> ikir the SRT folks are here to correct me but as far as I know, SRT has NACK, ACK, and ACK ACK
[18:43:16] <magnus.westerlund> For those applications that care about which packets is missing. Like for Retransmission.
[18:43:19] <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.
[18:43:43] <Jana Iyengar> Agreed, Christian, but that has very little to do with ACK or NACK based
[18:43:48] <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
[18:44:06] <christian> Sure. CC is also based on delays, ECN marks, etc.
[18:44:14] <Jana Iyengar> Yes
[18:44:24] <suhas> ikir  thank you
[18:44:48] max joins the room
[18:44:49] <magnus.westerlund> And I think RTP has extensions for reporting all of this metrics.
[18:45:04] <christian> +q
[18:45:17] Nick Banks joins the room
[18:45:27] <csp> +q
[18:45:51] <suhas> afrind is this session recorded ?
[18:45:57] <afrind> no
[18:47:04] <Jana Iyengar> @afrind: Are we in general discussion?
[18:47:07] <afrind> sure
[18:47:46] Victor Vasiliev joins the room
[18:48:54] James Gruessing joins the room
[18:50:30] <lpardue> +q
[18:50:37] <Jana Iyengar> +q
[18:51:30] <afrind> == cutting general discussion queue ==
[18:51:55] <BEHCET SARIKAYA> I have a big question: what is ingest?
[18:52:07] <Luke Curley> +q
[18:52:21] <BEHCET SARIKAYA> Was not explained so far in this meetingf
[18:52:27] <Jana Iyengar> @Behcet — the thing before digest
[18:52:41] max leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:52:44] <Victor Vasiliev> +q for where to keep discussion
[18:52:57] <Luke Curley> yeah that was my +q too
[18:53:18] <magnus.westerlund> Behcet Inget is the ingestion of media from an client into a media processing/distribution system.
[18:53:27] <Jonathan Lennox> Ingest is uploading (usually live) media to a server, for distribution.
[18:53:46] dennis leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:54:32] <James Gruessing> +q on what should we do
[18:54:33] max joins the room
[18:54:42] <BEHCET SARIKAYA> so you mean live video on quic
[18:54:48] km leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:54:51] <BEHCET SARIKAYA> like zoom on quic?
[18:55:07] km joins the room
[18:55:39] <magnus.westerlund> Live streaming, field reporters into TV production.
[18:55:39] <spencerdawkins> Too late to be in Q?
[18:56:08] <Luke Curley> can I request that we don't limit the group to ingest only?
[18:56:19] <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.
[18:56:20] <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.
[18:56:25] Nick Banks leaves the room: Disconnected: BOSH client silent for over 60 seconds
[18:56:26] <ikir> Luke Curley +1
[18:56:45] <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 ..
[18:57:36] <lpardue> media over QUIC transport technology, or MQTT for short
[18:57:46] <jgh> +1 lpardue
[18:57:47] <Jana Iyengar> hah
[18:57:56] <ikir> lol
[18:58:04] <ikir> not confusing at all 😃
[18:58:40] <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.
[18:58:54] <magnus.westerlund> So there are a lot of question of scope here.
[18:59:06] <ikir> magnus.westerlund format that solve problem that we care about 😉
[18:59:11] <spencerdawkins> I'm cutting the current jabber room for the minutes - please check the minutes for anything after this
[18:59:15] <Jonathan Lennox> Proposed wg name: Media over Quic (moq)
[18:59:19] <Jonathan Lennox> Or ml name
[18:59:22] Sergio Garcia Murillo leaves the room: Stream reset by peer
[18:59:29] <Luke Curley> all of these use-cases are for live media
[18:59:40] <lpardue> QUIC Transport Inclusive of Media Elelements. QuicTIME for short
[18:59:51] <samhurst> lpardue Haha
[19:00:04] <martin.duke> Is that an Apple trademark?
[19:00:06] <BEHCET SARIKAYA> haha
[19:00:11] <magnus.westerlund> Yes, but there appear to be different requirements on what formats are needed.
[19:00:26] <Victor Vasiliev> Yeah, the key questions are, from the top of my head, (1) ingestion-vs-serving-vs-both, (2) what media framing (RTP, MKV, variable, etc), (3) what transport mechanisms to use
[19:00:26] <ikir> Apple's, QuicKtime
[19:01:22] <Mirja> thx. Interesting meeting!
[19:01:26] martin.duke leaves the room
[19:01:32] BEHCET SARIKAYA leaves the room
[19:01:39] Victor Vasiliev leaves the room
[19:01:55] <ikir> magnus.westerlund hopefully we  can format that works for all/most cases
[19:03:24] <magnus.westerlund> @ikir We can wish, but I think it is going to be a challenge and one of the more political parts in this work.
[19:05:34] Ying leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:05:40] csp leaves the room
[19:05:58] James Gruessing leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:06:26] spencerdawkins leaves the room
[19:06:26] Luke Curley leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:09:03] Michael Thornburgh leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:12:32] Jordi (FB) leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:13:32] jgh leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:14:43] Alex Converse leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:14:59] suhas leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:15:43] max leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:16:51] samhurst leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:17:10] afrind leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:18:35] ikir leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:22:29] km leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:36:14] <Roberto P> The first step would be agreeing on what the problems are that need to be solved.
[19:36:38] <Roberto P> i.e. the goals.
[19:47:39] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:47:52] Roberto P joins the room
[19:49:50] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:50:01] Roberto P joins the room
[19:53:15] lpardue leaves the room
[19:53:51] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:54:02] Roberto P joins the room
[19:56:48] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[19:57:02] Roberto P joins the room
[19:59:48] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:00:02] Roberto P joins the room
[20:00:34] Mathis leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:01:38] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:02:01] Roberto P joins the room
[20:04:43] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:05:05] Roberto P joins the room
[20:12:49] magnus.westerlund leaves the room
[20:13:49] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:14:02] Roberto P joins the room
[20:16:48] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:16:57] Roberto P joins the room
[20:25:50] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:26:01] Roberto P joins the room
[20:30:43] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:31:05] Roberto P joins the room
[20:33:37] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:33:48] Roberto P joins the room
[20:50:47] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:51:03] Roberto P joins the room
[20:55:46] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[20:56:03] Roberto P joins the room
[20:59:25] Mirja leaves the room
[21:04:37] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:05:08] Roberto P joins the room
[21:08:37] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:08:57] Roberto P joins the room
[21:11:49] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:12:02] Roberto P joins the room
[21:13:43] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:14:05] Roberto P joins the room
[21:16:47] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:17:03] Roberto P joins the room
[21:19:48] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:20:02] Roberto P joins the room
[21:21:29] christian leaves the room: Disconnected: closed
[21:22:49] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:23:02] Roberto P joins the room
[21:25:48] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:26:02] Roberto P joins the room
[21:47:47] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:48:03] Roberto P joins the room
[21:50:37] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:50:46] Roberto P joins the room
[21:53:37] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:54:09] Roberto P joins the room
[21:56:37] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[21:56:46] Roberto P joins the room
[22:00:28] Roberto P leaves the room: Disconnected: BOSH client silent for over 60 seconds
[22:00:32] ranjeeth leaves the room
[22:20:26] christian joins the room
[22:27:18] Jana Iyengar leaves the room
[22:37:47] dragana leaves the room
[22:39:25] Jana Iyengar joins the room
[23:38:37] Jonathan Lennox leaves the room
[23:45:39] christian leaves the room: Disconnected: closed
Powered by ejabberd - robust, scalable and extensible XMPP server Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!