[Scone] Re: Discussion on TRAIN and SCONE

["DRUTA, DAN" <[e-mail]>]

I’d like to add my perspective into this with support for a more flexible approach on the advice.
The goal is to convey to the application a policy value that it would act upon and it is not a one to one mapping to the encoding options it would have to choose from (or limit to).
That is because on the network side is just data rate to and from an endpoint. This can and will most likely include multiple streams. The client has to make the decision to take action and adjust the behavior of the app to meet that network advice.
Globally, the rate limits can vary significantly and any restrictions to the value will have direct implications on the adoption of SCONE as others already mentioned.
In addition to that, we want this to be as efficient as possible so any negotiations and round trips to stabilize the rate would create unnecessary chatter and have a significant impact on the data plane infrastructure.
In fact, I think we need to start talking about how to optimize the SCONE signals. Focus on the frequency needs and types of traffic that need to enforce it.

Dan


From: Gorry Fairhurst <[e-mail]>
Sent: Tuesday, December 10, 2024 9:23 AM
To: Brian Trammell (IETF) <[e-mail]>; Watson Ladd <[e-mail]>
Cc: Ted Hardie <[e-mail]>; Marcus Ihlar <marcus.ihlar=[e-mail]>; [e-mail]
Subject: [Scone] Re: Discussion on TRAIN and SCONE

On 10/12/2024 16: 08, Brian Trammell (IETF) wrote: Greetings, all, A couple of points inline (as an individual path signals enthusiast, no chair hat): On 9 Dec 2024, at 15: 57, Watson Ladd <watsonbladd@ gmail. com> wrote: <snip> With

On 10/12/2024 16:08, Brian Trammell (IETF) wrote:
Greetings, all,

A couple of points inline (as an individual path signals enthusiast, no chair hat):


On 9 Dec 2024, at 15:57, Watson Ladd <[e-mail]><mailto:[e-mail]> wrote:

<snip>

With my implementor hat on, I really appreciate the simplicity of the TRAIN format. However, I fear that it will be very difficult to convince operators to design their policies around a table of pre-configured values. Keeping the table of values relevant over time might also be a challenge.


I don't think we should focus on what the network element operators could say; there's quite a lot of variability possible and there are, unfortunately, vendors who would love to charge for the knobs, bells, and whistles to send complicated signals.

Instead I think we have to focus on the receiver of the signals and the question of "What can the endpoint do with the information?" and, even more specifically on "What can the application do with the information?"  Are there really likely to be more than 64 distinct responses from the application to the information that there is a shaper in the path?  For video, I think the answer is probably "no", because the number of steps up or down in video quality is rarely infinite.

ISTM the following two statements can be (and probably are) simultaneously true:

(1) There are (far) fewer than 64 grades of actionable rate information for our reference problem (adaptive bitrate video). Basically nobody makes 64 different bit rates of video available. I don’t have any intuition or data on whether there are even 64 different bit rates of video currently deployed in the (p99.9) Internet, but I suspect not.

(2) There are (far) more than 64 distinct rate limits (measured in bits-per-second) configured in the Internet.

One of the things I’d like to understand (either through measurement or modeling) is how much (2) matters. If we used a TRAIN-like approach and defined “Price is Right”[1] rules on the exposed rate limit (“path sets codepoint representing the highest bandwidth available without going over the actually configured limit”), how much bandwidth efficiency would we be leaving on the table?

([1]: https://en.wikipedia.org/wiki/The_Price_Is_Right<https://urldefense.com/v3/__https:/en.wikipedia.org/wiki/The_Price_Is_Right__;!!BhdT!gvaAhlZkEdNihdW7aG4mIPgbD5fsOer_p_IYDMr4MxygBZPxlYwB05nHWgGTz_0loBfJkuSgXKCWrRzB-Q$> for people without an overexposure to American culture)


It's not the number of responses of an application but the responses of applications. Conceptually I get advertising the limit and letting the application adapt much more than approaches signalling a particular response.

>From a deployability/simplicity standpoint, I find this argument convincing. Approaches requiring a more complex negotiation than “here’s some information about the path you’re on” (or indeed, “about this traffic”, though the latter has a whole bunch of sharp edges and we have a long history of learning why it only works in very restricted deployments) tend to explode the set of things that can go wrong (whether accidentally or due to abuse), which in turn lengthens the deployment timeline, perhaps considerably.

Or, in other words: “ECN was specified a quarter century ago”.

If we want the analogy, then the first round of ECN deployment didn't work out because people had sofware that assumed old semantics that predated ECN. That we are not repeating here for sure.

The second issue was the first ECT(0) signal "tell me once each RTT if you''re congested" should have been better and provided slightly more info - we don't want to repeat that mistake in SCONE by being just slightly too restrictive in how the signal is communicated/used.

Sure there are somewhat less than 64 credible limits, (but there are more than 8). I'm following Matt on this, one value may not be quite enough, and 6 bits for two or three values seems like we're engineering ourselves into a future problem.

Best wishes,

Gorry

Cheers,

Brian
Gorry



At the cost of some round trips, I think you could get an application below a network restriction with the spin bit and one extra bit.  If the extra bit is set, your network consumption is too high to be supported by the network, so you should lower the video resolution requested or sent.  If the spin bit flips and the extra bit is still set,  it has to be lowered again one more step. Once the bit is unset, your network consumption fits within the shaper's constriction and you should continue with that video resolution (if it is unset at the beginning of the application-level connection, you started within the bounds of the network constriction).

Obviously, that's  not the perfect answer, because we do not want to spend the round trips this implies it might take to get within the bounds.  But the actual behavior of the application in response to this signal is very simple, so sending complicated information to elicit that response probably isn't worth it.
regards,

Ted Hardie
Path signal enthusiast

_______________________________________________
Scone mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
_______________________________________________
Scone mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>




_______________________________________________

Scone mailing list -- [e-mail]<mailto:[e-mail]>

To unsubscribe send an email to [e-mail]<mailto:[e-mail]>