[Scone] Re: Number of sessions is needed for the SCOPE

[Vasilenko Eduard <[e-mail]>]

One clever guy commented offline that SCONE is for mobile-only, hardware forwarding is out of the scope – I am wasting people's time.
Then Ted’s comment that “we do not want to account for the network capabilities – they have just to supply what we demand” is possible.
Indeed, just performance signaling is enough, because a software node is capable of tracing every flow separately and signaling proper CIR/PIR per every flow, no need for any “divider”.
Moreover, UPF may signal completely different PIR/CIR per flow or subscriber, not everybody is equal.
Then sorry for my disturbance, I agree that the number of sessions is not needed for such a use case.

As I stated already, UPF (GGSN before) was never accelerated in hardware (one vendor has failed in such an attempt).
Mobile traffic forwarding is still 7x more expensive compared to BRAS/BNG. No business case yet for hardware acceleration.
Hence, it is possible to assume for the reasonable future that UPF would calculate PIC/CIR per flow (or per session or per subscriber).
Especially now, because UPF has been moved from “custom hardware” to “VM on the COTS”. Custom x86 hardware had a chance of replacement by some accelerated hardware, but VM has a smaller chance – it breaks the Mobile-Cloud architecture that is not prepared for heterogeneous resources yet. Such flexibility has been lost in the migration to the Mobile-Cloud.

IMHO: If it is only for software, then it is an augmentation of some per-flow scheduler (for example FQ-CoDEL). FQ-CoDEL scheduler applies PIR/CIR restrictions directly (per flow of per group of flows), but additionally signals PIR/CIR to the host for faster convergence.
Of course, SCONE signaling should not be strictly restricted to FQ-CoDEL. There were a few other “per-flow software schedulers” that could do the same.
SCONE implementation makes sense together with any flow-based scheduler.

If UPF would inform OTT CDN about per flow or per subscriber limit, then CDN would converge faster to it (and stay easily around the optimal point).
IMHO: Mobile is a big part of our life. “Mobile-only” restriction for the solution is not a big problem.
The bigger problem would be to motivate vendors and ISPs to put it into production.
There are chances because UPF and CDN are just software, no need for hardware replacement.
I am not sure that a business case exists here, but if it would not be tried – we would never know.
Eduard
From: Ted Hardie <[e-mail]>
Sent: Thursday, November 28, 2024 18:59
To: Vasilenko Eduard <[e-mail]>
Cc: [e-mail]
Subject: Re: [Scone] Number of sessions is needed for the SCOPE

Hi Vasilenko,

On Wed, Nov 27, 2024 at 8:00 AM Vasilenko Eduard <[e-mail]<mailto:[e-mail]>> wrote:
Hi Ted,
Should this signal (to decrease/increase the video quality) be “proactive” or “reactive”?
Should the signal “please decrease rate” be after something bad happens (some threshold crossed)? What should this threshold measure? (queue length? Interface utilization?)


I don't think the scone protocol needs to care about the network operator's  process for determining the current shaper behavior.  It needs to report it in a way that is actionable by the client.  As Mirja notes, some of these are basically static; some of them may be or may become dynamic, but the impact on the protocol requirements for scone don't extend to working out why the operator put in a specific restriction.

regards,

Ted



Hi all,
If the signal is proactive, then it is not needed to send it too often – a few seconds could be enough accuracy, high-speed scheduler performance does not change at all, flow’s number volatility is not very high.
Unfortunately, it would just improve the CC accuracy (CC could play around the optimal point +- a few percentages), but would not eliminate the need for reactive CC.
Actually, it would improve 2 things:
- “convergence” would be greatly improved, the host would immediately jump close to the optimal point and stay on it. Nice feature, especially for short flows.
- goodput would be improved (even against the “state of the art CCs”) because the host would not need to decrease performance by 30% (or 15%?) after the ECN, 2-3% decrease would be enough because the host knows the optimal point with not bad accuracy.

CCWG believes that 1 ms additional latency is not possible to eliminate for reactive congestion management.
IMHO: Because the reactive signal should be as fast as possible, even RTT is a problem.
More information (from the bottleneck) would probably change not much for reactive management (in proximity to the optimal point).
Because we are still breaking the automation theory that claims that the “control loop” should be X times faster than “managed system volatility”. For CC, we still have a “control loop” that is X times slower, not faster.
1ms latency is possible to eliminate only by signaling scheduler rate, not queue length. If ECN is raised after the scheduler reaches 98%, then the queue may never build up. Unfortunately, we would lose 2% of the network performance.
IMHO: 2% less network performance as a payment for 0 additional latency is a good tradeoff. But it is very disputable, 2% of the overall Internet infrastructure cost is good money.
IMHO: we could do nothing for reactive management (around optimal point) above functionality already presented by ECN. Because the problem is a fundamental problem of automation theory – it has no solution.

Hence, my assumption is that you are trying to solve only proactive management. i.e. helping the host to know the optimal point proximity in advance.
The primary specification signals “I am the router in transit, I have the bottleneck scheduler performance 1.6Tbps”.
I have seen it as an attempt to go to proactive congestion management. What else it could be?
If not, then sorry – I did not participate in the BoF, I may have misunderstood the objectives.
Eduard
From: Ted Hardie <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, November 26, 2024 19:01
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Scone] Number of sessions is needed for the SCOPE

Going through this thread, I think the high order bit is that the signal must be one that allows the client to make a useful change to handle the network restriction.  In the motivating use case of video flows, the presumption is that the change will be to shift from one video resolution to another lower rate one from among those offered.

Note that changing the requested video resolution is an action taken at the application layer, so we have to think about this as something that will be exposed as application API, rather than as feedback into the networking stack.

regards,

Ted Hardie

On Fri, Nov 22, 2024 at 1:10 PM Vasilenko Eduard <vasilenko.eduard=[e-mail]<mailto:[e-mail]>> wrote:
Hi Experts,
IMHO: you are missing the critical parameter in the SCONE specification: the number of sessions on the bottleneck scheduler (it looks like the scheduler is called “flow policy” in the draft).

Per-flow performance is not possible for hardware routers and switches – it is too expensive, hardware routers are 3x cheaper, switches are 5x cheaper compared to flow-based devices (FW, IPS, DPI, LB, etc).

Per-scheduler performance (possible for routers and switches) is useless without knowing how many flows are sharing it. It is a divider to understand what is possible to push for the particular flow on the host.

Of course, it is a big challenge to how hardware routers or switches would calculate the number of sessions. But better to push the problem out of SCOPE territory.
It would be possible to say: “SCOPE will be ready when the hardware router would be ready”. (if ever)

IMHO: it is better to include “the number of sessions” in the SCOPE specification.

PS: Software routers are typically multi-functional our days (IPS, DPI, and everything else on board), flow-based forwarding is possible.
Moreover, all 3GPP wireless IP forwarding is based on software only – no acceleration has been done for 3GPP.
Unfortunately, fixed broadband is based on BRAS/BNG which is actually a hardware router – it could not be flow-based.

Best Regards
Eduard Vasilenko
Senior Architect
Network Algorithm Laboratory
Tel: [phone]

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