Are real-time congestion controllers tied to RTP or usable in QUIC stacks?

[mengelbart]

SCReAM, NADA, and GCC were specifically designed with RTP/RTCP in mind. Is it feasible to use one of these in the QUIC stack itself, or are there other alternatives that could be implemented directly in a QUIC stack to follow the recommendations given in section 7.1? One requirement that all of the RMCAT algorithms have is that they need timestamps, which could be provided by one of the QUIC timestamp extension drafts.

This came up in discussion with Gurtej and again in #83 (comment)

[goelvidhi]

IMO, it would be ideal to implement a real time rate adaptation algorithm in the QUIC stack and then expose an API for bitrate estimation to the application/framework that uses that to call into encoder. I can take this issue but do we need a PoC before making this text change?

[mengelbart]

I agree with that. I think a PoC and some experiments exploring such an implementation would be nice. I had this on my list for some time now but didn't get to implement it yet. I don't know if we need it before changing any text, but it might give some insights that could be useful to document.

[SpencerDawkins]

I said I would send this out to @LPardue and @pthatcher as a question, and failed. I promise, promise, promise ...

[LPardue]

I'm not sure what the question is - what can I help with?

[SpencerDawkins]

@goelvidhi - on this:

IMO, it would be ideal to implement a real time rate adaptation algorithm in the QUIC stack and then expose an API for bitrate estimation to the application/framework that uses that to call into encoder. I can take this issue but do we need a PoC before making this text change?

I think a POC is a fine idea, but if we have a new congestion controller, that probably starts in ICCRG, doesn't it?

[SpencerDawkins]

@mengelbart and @SpencerDawkins think that asking @LPardue and @pthatcher for clues is still the right thing to do, but not until we merge PR #134, because we're still changing the text that we want to ask about. 🙄

[SpencerDawkins]

We have now merged PR #134, and @SpencerDawkins thinks that we need to uplevel to talk about how we expect QUIC stacks, especially at the other end of a RoQ connection, to Do The Right Thing for media. We have had many ideas, and none have achieved consensus.

• "turn off QUIC congestion control and do everything in RTP" - this was rejected for excellent reasons
• "allow RoQ to configure QUIC congestion control" - at a high level, not like picking algorithms
• "use a different ALPN that says "this is RoQ, so Do The Right Thing" - this is in the draft now
• "assume that QUIC implementations that attempt to prevent increasing one-way delays for any QUIC traffic will work for media, that wants that, too" - if that's a plan, we should probably check with the QUIC working group if that's what they think, too

@SpencerDawkins thinks leaving this vaguely specified is a problem. I'm tagging this For Discussion, with IETF 118 coming up in a couple of weeks, to see whether we can make progress.

[mengelbart]

We have now merged PR #134, and @SpencerDawkins thinks that we need to uplevel to talk about how we expect QUIC stacks, especially at the other end of a RoQ connection, to Do The Right Thing for media. We have had many ideas, and none have achieved consensus.

I don't think we necessarily need the other end to cooperate on this much. If the other end is receiving media, it needs to give the correct feedback so that the sending end can do the right thing. The feedback may require timestamps, but that would be negotiated via transport parameters. Either timestamps are available or not. No need to negotiate beyond what a potential timestamp extension would specify, anyway.

* "allow RoQ to configure QUIC congestion control" - at a high level, not like picking algorithms

I think RoQ application developers need to choose the right QUIC implementation and congestion controller to use for sending media.

* "use a different ALPN that says "this is RoQ, so Do The Right Thing" - this is [in the draft](https://mengelbart.github.io/rtp-over-quic-draft/draft-ietf-avtcore-rtp-over-quic.html#name-connection-establishment-an) now

The ALPN section is there for a different reason, it is not required for congestion control, but because QUIC requires application protocols to use ALPN (or equivalent mechanisms, see Section 7 of RFC 9000 and Section 8.1 of RFC 9001).

* "assume that QUIC implementations that attempt to prevent increasing one-way delays for any QUIC traffic will work for media, that wants that, too" - if that's a plan, we should probably check with the QUIC working group if that's what they think, too

I think this is what the draft assumes, but I agree that it is probably a good idea to get more input on this (maybe from the QUIC WG, CCWG, or even ICCRG?).

[SpencerDawkins]

@mengelbart - on this ...

I don't think we necessarily need the other end to cooperate on this much. If the other end is receiving media, it needs to give the correct feedback so that the sending end can do the right thing. The feedback may require timestamps, but that would be negotiated via transport parameters. Either timestamps are available or not. No need to negotiate beyond what a potential timestamp extension would specify, anyway.

I agree on this (so far, modulo the sending end knowing what the right thing to do is), but keep reading.

[SpencerDawkins]

@mengelbart -

I think RoQ application developers need to choose the right QUIC implementation and congestion controller to use for sending media.

That's the challenge - especially if the QUIC implementation isn't tightly coupled with the application. Maybe we can say that RoQ application developers need to watch for this carefully?

[SpencerDawkins]

@mengelbart -

The ALPN section is there for a different reason, it is not required for congestion control, but because QUIC requires application protocols to use ALPN (or equivalent mechanisms, see Section 7 of RFC 9000 and Section 8.1 of RFC 9001).

Understood. The problem is that we've been thinking that we needed to do something other than just trusting the QUIC implementation to Do The Right Thing for media, and if we are using a different APLN for media, it's easy for people to conflate choosing an application instance for media with choosing an application instance that will Do The Right Thing for media.

I suspect the best way for us to handle this is actually saying something like

This document relies on the assumption that QUIC implementations will attempt to prevent increasing one-way delays when sending any QUIC traffic, and this will meet the needs of RTP over QUIC".

Does that make sense?

[LPardue]

I'm late here , sorry, and still playing catchup. I don't think I have all of the context of RoQ paged in but from this ticket, there's something about the discussion of expectations (or setting of expectations) on QUIC implementations that doesn't quite sit right with me.

This ticket is titled "Are real-time congestion controllers tied to RTP or usable in QUIC stacks?" yet Spencer asks some different questions. That feels, to me, a bit like "are electric hybrids tied to gasoline or usable in 3 phase? we need to uplevel to conversations about how efficiently divers lift and coast"

I need some more time to digest but endevour to provide a better response than this one.

[SpencerDawkins]

Hi, @LPardue -

Thanks for popping in here.

I'm late here , sorry, and still playing catchup. I don't think I have all of the context of RoQ paged in but from this ticket, there's something about the discussion of expectations (or setting of expectations) on QUIC implementations that doesn't quite sit right with me.

You are not alone. 🤔 I feel your pain (and confusion).

This ticket is titled "Are real-time congestion controllers tied to RTP or usable in QUIC stacks?" yet Spencer asks some different questions. That feels, to me, a bit like "are electric hybrids tied to gasoline or usable in 3 phase? we need to uplevel to conversations about how efficiently divers lift and coast"

My apologies for incoherence when when adding my most recent comments in the issue. AVTCORE/RoQ has moved a LONG way from early discussions, where people who talked to us were expecting RoQ endpoints to disable QUIC congestion control ("whut?" 🤨 🙄) and require specific congestion controllers in the spec.

My list upthread (which @mengelbart was responding to) was trying to capture the various places we've been, and make sure that we're all in one place now.

I THINK we're now here:

This document relies on the assumption that QUIC implementations will attempt to prevent increasing one-way delays when sending any QUIC traffic, and this will meet the needs of RTP over QUIC"

and I THINK @mengelbart agrees with that, so let's focus on that point, for now. BUT ...

I need some more time to digest but endevour to provide a better response than this one.

... please don't endeavor too hard right now - @mengelbart and I have been around and around on this topic, and we're still working on the questions we are going to ask the working group during the AVTCORE session on Wednesday. Can you hold off a bit, while we finalize our slides, and then I'll update the issue and see if I can do better?

[aboba]

There are low latency CC algorithms currently integrated into QUIC stacks, including:

1. COPA: See: https://engineering.fb.com/2019/11/17/video-engineering/copa/
2. L4S. See: https://developer.apple.com/documentation/network/testing_and_debugging_l4s_in_your_app

[pthatcher]

Another impl of COPA: https://github.com/Tencent/tquic/blob/develop/src/congestion_control/copa/copa.rs

[SpencerDawkins]

@aboba and @pthatcher - thank you both for the helpful information!

[SpencerDawkins]

From IETF 118 minutes:

Bernard: both COPA and L4S have been implemented in QUIC, although we're not sure whether they've been deployed
Randell Jesup: This draft should say "should use real-time congestion control" but can't say much more. This isn't something we can mandate, we can only request that the implementation does something appropriate.
Peter Thatcher: Should also recommend using timestamp extensions for better congestion control.
Zahed Sarker: Need some considerations on rate control/adaptation part, rather than just congestion control.
Bernard Aboba: Per frame QP (quantization parameters) can respond fast to congestion, but need to know if such mechanisms are useful here.

[SpencerDawkins]

I did add a mention of L4S.

We rephrased rate adaptation/congestion control in -08.

We're waiting for timestamps to progress enough for a normative recommendation.

Bernard mentioned COPA. Do we want to mention this, or any other possible mechanisms, in informative text?

[SpencerDawkins]

This has been resolved in PRs for several other issues.