I can try taking notes - will be my first time for an IETF meeting but I can give it a go
", "time": "2023-02-23T16:05:52Z"}, {"author": "Dale Worley", "text": "I'm not hearing any audio, though the browser and Meetecho think I've got sound enabled and Meetecho reports multiple kbps. I heard the previous speaker.
", "time": "2023-02-23T16:17:11Z"}, {"author": "Jonathan Lennox", "text": "Dale, is that still the case?
", "time": "2023-02-23T16:19:14Z"}, {"author": "Dale Worley", "text": "Yes, and toggling the immediately obvious controls doesn't fix it. I am getting the notifications as to who is speaking.
", "time": "2023-02-23T16:20:12Z"}, {"author": "Dale Worley", "text": "Ugh, my UI problem. The \"Mute Audio\" icon in the upper left is \"mute audio to me\" whereas the same icon in the lower right is \"mute audio I am generating\".
", "time": "2023-02-23T16:22:23Z"}, {"author": "Sam Hurst", "text": "My audio glitched out for a moment there - what doesn't matter (so I can add it to the notes)
", "time": "2023-02-23T16:33:03Z"}, {"author": "Rui Paulo", "text": "we can also tell the other side to disable CC via QUIC transport parameters
", "time": "2023-02-23T16:50:17Z"}, {"author": "Joerg Ott", "text": "That would mean that a QUIC library without RTP would be able to signal that, too, which we may not want to suggest. No CC at all would not be a good idea.
", "time": "2023-02-23T16:51:10Z"}, {"author": "Peter Thatcher", "text": "This isn't really about \"disabling QUIC CC\". This is more about \"the congestion control for the RTP packets is done using feedback other than QUIC feedback\". Whether it's \"in QUIC\" or \"out of QUIC\" is an implementation detail. The real question for a standard is: what feedback is being used. Is it QUIC feedback or RTP/RTCP feedback?
", "time": "2023-02-23T16:54:30Z"}, {"author": "Joerg Ott", "text": "Right, I am saying only that you should not be allowed to negotiate turning off QUIC CC inside QUIC transport parameter negotiation
", "time": "2023-02-23T16:55:39Z"}, {"author": "Peter Thatcher", "text": "For example, in the WebRTC world, we don't standardize googc. We standardize transport-wide-cc (or whatever was the result of trying to standardize it :).
", "time": "2023-02-23T16:56:01Z"}, {"author": "Peter Thatcher", "text": "I agree it doesn't make sense to negotiate turning off QUIC CC.
\nIt might make sense to negotiate some kind of QUIC version of REMB, though.
", "time": "2023-02-23T16:56:58Z"}, {"author": "Harald Alvestrand", "text": "well, we failed to find the resources to actually propose transport-cc for standardization, so that kind of died.....
", "time": "2023-02-23T16:57:10Z"}, {"author": "Harald Alvestrand", "text": "the proper view is probably that we should have a congestion limitation as part of QUIC, but a decision on what to send next (or decide not to send) as part of the application.
", "time": "2023-02-23T16:58:21Z"}, {"author": "Peter Thatcher", "text": "Options for feedback:
\nA. REMB style: have the receiver tell the sender a number. Probably need a timestamp similar to the RTP abs-send-time header extension attached to each packet for the receiver to make a good calculation.
\nB. transport-wide-cc style: have the receiver send per-packet receive timestamps in ACKs. Let the sender do the calculation.
I think in either case, extending QUIC will be much better than doing this above QUIC.
", "time": "2023-02-23T17:02:25Z"}, {"author": "Peter Thatcher", "text": "I think this works for B: https://www.ietf.org/archive/id/draft-smith-quic-receive-ts-00.txt
", "time": "2023-02-23T17:03:52Z"}, {"author": "Joerg Ott", "text": "B. is what we have in the draft
", "time": "2023-02-23T17:05:15Z"}, {"author": "Joerg Ott", "text": "including quite a bit of discussion on what to inherit from the QUIC layer
", "time": "2023-02-23T17:05:40Z"}, {"author": "Vidhi Goel", "text": "How big is the Pframe?
", "time": "2023-02-23T17:06:12Z"}, {"author": "Joerg Ott", "text": "Of course, good ol' RTCP is also an option when you need something that QUIC doesn't give you (yet)
", "time": "2023-02-23T17:06:29Z"}, {"author": "Peter Thatcher", "text": "Joerg: That sounds like a good approach. Why don't we just try and implement that with, say, googcc, and see if it works well? I'm guessing it will. What more do we need?
", "time": "2023-02-23T17:07:08Z"}, {"author": "Mo Zanaty", "text": "MOQ has a similar need / delimma. That argues for solving this within the QUIC CC and feedback layer, not above it.
", "time": "2023-02-23T17:07:53Z"}, {"author": "Peter Thatcher", "text": "And I'd like googc to work in WebTransport as well.
", "time": "2023-02-23T17:08:14Z"}, {"author": "Mo Zanaty", "text": "For receive timestamp extensions to QUIC, there is also Christian's original proposal: https://datatracker.ietf.org/doc/draft-huitema-quic-ts/
", "time": "2023-02-23T17:09:10Z"}, {"author": "Peter Thatcher", "text": "If anyone is interested in adding support for https://www.ietf.org/archive/id/draft-smith-quic-receive-ts-00.txt and googcc to an impl of QUIC in Rust, let me know. I'm interested in making that work.
", "time": "2023-02-23T17:10:30Z"}, {"author": "Joerg Ott", "text": "Peter: we implemented quite a bit of this, and it seemed to work. But the details of QUIC CC interaction remain.
", "time": "2023-02-23T17:10:43Z"}, {"author": "Joerg Ott", "text": "Let's chat offline about this (I will have to disappear shortly for boarding my flight)
", "time": "2023-02-23T17:11:22Z"}, {"author": "Vidhi Goel", "text": "I can work on congestion control issues
", "time": "2023-02-23T17:13:29Z"}, {"author": "Peter Thatcher", "text": "Joerg: I'm interested to see how far you got
", "time": "2023-02-23T17:13:50Z"}, {"author": "Peter Thatcher", "text": "If anyone wants to chat QUIC CC offline, send me an email (pthatcher@microsoft.com)
", "time": "2023-02-23T17:15:25Z"}, {"author": "Joerg Ott", "text": "We'll reach out.
", "time": "2023-02-23T17:15:44Z"}]