search

mjoras / SCONE-PROTOCL

Repository for files related to the topic formerly known as SADCDN.
Other
9 stars 10 forks source link

Add explanation of why SCONEPRO is still needed when L4S exists #82

Closed ihlar closed 4 months ago

ihlar commented 5 months ago

Attempt to clarify some differences with L4S.

SpencerDawkins commented 5 months ago

@fluffy and @martinthomson, could you also review this PR? @ihlar created it, in response to discussions on last week's coordination call.

SpencerDawkins commented 4 months ago

@martinthomson thinks we don't need this important information IN THE CHARTER AT ALL, so I switched the PR to a draft PR, so we won't merge it prematurely.

ihlar commented 4 months ago

I think we should consider alternative text to deal with this that is less about L4S and more about scoping sconepro. I would say something that explains scone operates at large timescale and is only a max possible bound. It is not a congestion control algorithm It can not be used as a congestion signal.

@fluffy Do you think the text on congestion control signaling in #93 sufficient in that regard? In that case we could probably close this PR.

gwhiteCL commented 4 months ago

IMO there is some nuance here that is useful in a charter, but we can simplify the statement a lot. I think the important point is that new CC technology can solve this problem in a way that is a whole lot better than existing rate shapers, which would seem to make SCONEPRO moot. How about we simplify this text to:

While new network congestion signaling (e.g. L4S ECN) could be used with rate-based marker to achieve some of these goals, it conflates signals about network congestion and policy. An unambiguous policy signal would allow an application to comply with that policy on timescales that work best for the application's QoE, while continuing to respond to congestion signals on RTT timescales.

chris-box commented 4 months ago

Hi. Matt's excellent summary to the list led me down the path that ended here.

@ihlar asked:

Do you think the text on congestion control signaling in #93 sufficient in that regard? In that case we could probably close this PR.

Personally, I don't think it is sufficient. #93 says this is out of scope: "Support for congestion signaling from the network. SCONEPRO should not be treated as mechanism to replace congestion control or rate adaptation."

The problem is that the terms "congestion signalling", "congestion control" and "rate adaption" can be applied to two very different concepts:

  1. Packet drops and/or CE marks at a bottleneck, and how the transport protocol responds to those signals.
  2. Messages from a network that advise the client the current path has reached, or is approaching, congestion.

Using Greg's terminology, concept 1 is on "RTT timescales", and I agree it should be out of scope. Concept 2 is "QoE timescales", and I can see this being useful in networks where there's no artificial (policy) limit but bandwidth can naturally vary by an order of magnitude from minute to minute. Hence I would prefer to see the charter text amended to make it clear that it's concept 1 that is out of scope. I think that was the original intention from #88.

gwhiteCL commented 4 months ago

In case anyone missed it, there was a Hackathon project this weekend experimenting with the use of SCONEPRO as congestion control. https://datatracker.ietf.org/meeting/120/materials/slides-120-hackathon-sessd-a-possible-attempt-to-use-sconepro-for-rtc-scenario-00

fluffy commented 4 months ago

I think this has become OBE ( Overcome by Events ) and closing for now. Feel free to reopen and rebase.