Application signaling

[martinthomson]

An application that receives a request from the network will need to pass that information on to its peer. In many cases, this can be done using proprietary mechanisms that the application developer can just make up. But that is not always possible.

We should discuss whether it makes sense to implement generic controls for important protocols. MOQ, HTTP, and WebRTC (or maybe RTCP) seem to be good candidates for consideration. The problem inherent in that is that the scoping of the signal could be difficult. Think about HLS or DASH where the overall rate is what matters, but you have multiple individual transactions.

This sort of thing is where standards really start to deliver, but I don't see any obvious solutions.

[Kevsy]

An application that receives a request from the network will need to pass that information on to its peer.

I think a major use would be for the network to hint network context to the application, which may result in a congestion control reaction. My (quite possibly wrong) understanding is that if the hint is in-band of the QUIC session then that hint can be used to inform congestion control, which can choose to react - is that right? i.e. no need for a proprietary mechanism, at least in that example.

[SpencerDawkins]

@martinthomson, thanks for raising this question.

It's certainly worth broader discussion, but my understanding is that, at some point, we're in a race condition between what end-to-end flow control mechanisms can figure out on their own, and what a client might tell a server (in the same QUIC connection, but at the application level, rather than at the QUIC ACK level).

I'm pretty sure some people think the client can say something helpful to the server at the application level, but I'm almost positive that other people will say something like "but in one or two round trips, the server QUIC stack is going to react anyway, so why do I need to listen to other guidance from the client?"

[SpencerDawkins]

@Kevsy - I think one key point is that we might ALSO be talking about rate adaptation when we say "congestion control", but we might not be. This has been confusing as heck in AVTCORE, see the note to the reader here.

We should probably agree on that, before we try to get too far down the path discussing this issue.

[mirjak]

This is not about congestion control. If you rate-limit the traffic you should set a limit that is below what congestion control usually would allow you (otherwise you don't need it).

Regarding MT's original point, we usually talk about a maximum rate because that's what shapers enforce today. However, one point that was raised during initial discussion was that a hard limit is sometimes problematic and it would actually be beneficial if you would get more flexibility over the short term but stay under the limit over the long term. Therefore, we are also thinking about providing a "shaping period" to also provide guidance over which time period the rate needs to be below the requested rate. We are experimenting with this right now.

[SpencerDawkins]

@mirjak,

This is not about congestion control. If you rate-limit the traffic you should set a limit that is below what congestion control usually would allow you (otherwise you don't need it).

Yes, exactly.

Regarding MT's original point, we usually talk about a maximum rate because that's what shapers enforce today. However, one point that was raised during initial discussion was that a hard limit is sometimes problematic and it would actually be beneficial if you would get more flexibility over the short term but stay under the limit over the long term. Therefore, we are also thinking about providing a "shaping period" to also provide guidance over which time period the rate needs to be below the requested rate. We are experimenting with this right now.

I recognize that SCONEPRO is talking about feedback at a different timescale, but this sounds a lot like L4S Scalable Throughput, where a response to changing path conditions doesn't have to be drastic ("equivalent to drop").

So, I like it.

Would work on a shaping period be in scope for SCONEPRO, or something done elsewhere (perhaps CCWG), that an operator deploying SCONEPRO can make use of?

[SpencerDawkins]

@martinthomson and @mirjak - I want to follow up on this issue. I'm not sure whether Martin's original ask ("We should discuss whether it makes sense to implement generic controls for important protocols") is related to what we're talking about later in the thread (a shaping period).

If I can get feedback about that, I'll know better how to proceed - one possible next step would be "create an issue to figure out whether we want a shaping period, and if so, would that be in scope for SCONEPRO?", but I don't want to lose track of @martinthomson's original ask.