Is communication done per-flow, per-device, per-something else?

[mjoras]

This came up in the side meeting. The motivating use-case is meant to communicate information that is effectively device-scoped in practice, e.g. the network device may be communicating information that comes from a user's plan information limiting video quality to 2Mbps.

If that information is communicated per flow, then an application could open up numerous connections and then potentially get the same limit for each, "bypassing" the restrictions.

Does the charter need to address this point about whether a per-flow communication mechanism is the only one to be standardized, and address the potential for "gaming" it?

CC @ihlar

[SpencerDawkins]

This is about "gaming the system". We don't need an answer before the BOF, but it would be good to assert that this is a solvable problem at the BOF, if anyone asks

[ihlar]

I think it will be difficult to solve gaming in the protocol design. My preferred approach would be to communicate per-flow and let the network device handle any detection and reaction to gaming attempts as it sees fit.

[SpencerDawkins]

Tl;dr - I agree with @ihlar on this. I suspect that if we do anything about this, it will be much better for us to put it in the proposed SCONEPRO Protocol Manageability draft proposed in PR 14.

I don't think mandating specific reactions is likely to succeed, because reasonable reactions to flow behavior are likely to change over time. We have a lot of experience with proposals in this space that start out describing normative behavior, and end up saying "we're giving you a hint. One thing you might do when you get this hint is X".

If we don't mandate specific reactions, I'm confused about how we could tell people we've prevented gaming.

[Kevsy]

Also agree with @ihlar - and to note that per-flow is preferable to per-packet (which would be prohibitively expensive for a network).

[danwing]

A nuance is network operators want some "gaming" to occur -- or some applications to not use SCONE. Bandwidth testing applications, for example, need to run 'full speed' so the human feels the network is delivering its promised low latency and high bandwidth. As SCONE progresses, we should hope bandwidth testing applications also use SCONE and provide a way for the human to test SCONE-throttled flows and full-speed flows.

Without full speed flows, users will feel their existing LTE is not worth upgrading to 5GUW or 6G or 8G or whatever-is-fancy-this-year.

[Kevsy]

It would be interesting to see how SCONE impacts user experience in challenging cellular conditions (cell edge, rapid mobility, indoors, cell congestion etc.) . In these conditions the comparison is not so much SCONE-throttled flows vs full-speed flows (because you won't achieve 'full speed' vs optimal conditions) but rather SCONE vs non-SCONE.

[VMatrix1900]

A nuance is network operators want some "gaming" to occur -- or some applications to not use SCONE. Bandwidth testing applications, for example, need to run 'full speed' so the human feels the network is delivering its promised low latency and high bandwidth. As SCONE progresses, we should hope bandwidth testing applications also use SCONE and provide a way for the human to test SCONE-throttled flows and full-speed flows.

Without full speed flows, users will feel their existing LTE is not worth upgrading to 5GUW or 6G or 8G or whatever-is-fancy-this-year.

If the speed of the SCONE-throttled flow can be tested, then we do not need SCONE protocol to request it, right? Host can run an iPerf over SCONE-throttled flow and set the maxium rate by its own.

[danwing]

If the speed of the SCONE-throttled flow can be tested, then we do not need SCONE protocol to request it, right? Host can run an iPerf over SCONE-throttled flow and set the maxium rate by its own.

Haha, sure!

SCONE-signaled flows are not necessarily throttled. So "letting it rip", as with iperf, is not a viable test of SCONE. Consider for example a bandwidth-testing application (e.g., Ookla, Netflix's fast.com, or myriad of others) which do purposefully run as fast as possible, and are necessary from both the user's and ISP's perspective so the user is happy with their fancy new phone running on the latest 3GPP infrastructure. Those have to run fast and have to show good round-trip times.

In contrast, a SCONE signal is telling a cooperative video streaming application how much bandwidth it should use, so that the subscriber does not exhaust their monthly data quota, which is the ISP's way to enforce some sharing of the limited bandwidth available to all subscribers.

A SCONE test application would use the SCONE signal to request an appropriate bandwidth flow from a server, just like a video streaming application. A quality SCONE test would also exercise the flow for variable bit rate video, including exercising variations in how many packets appear within a single NTP-synchronized second and a few that are early or late to account for clock drift and account for (minor) bufferbloat from sender to the ISP's network. (I say 'minor' because network cores do not build deep buffers.)

[jlivingood]

Is the SCONE signal even useful if it is on a per-device basis? For example, if it signals that ISP X will shape the device's video streaming at 25 Mbps. But the sector of the access network the device is on can only support 10 Mbps at peak hour. So in this case, is the signal even useful?

And if there are regular times when the signal is not useful, because available bandwidth is less that the signaled rate, why not continue to rely solely upon HTTP adaptive streaming to adjust rate according to available throughput from moment to moment?

[Kevsy]

Is the SCONE signal even useful if it is on a per-device basis?

I believe it would be on cellular mobile, due to allocated frequency bandwidth (e.g. at cell edge or indoors) and local environmental interference being device-specific.

why not continue to rely solely upon HTTP adaptive streaming to adjust rate according to available throughput from moment to moment?

We tested with DASH video and found an improvement using [https://datatracker.ietf.org/doc/html/draft-flinck-mobile-throughput-guidance-04](Mobile Throughput Guidance) under cell congestion / device in poor coverage...as I recall there was little benefit when the device was in an uncontested network with strong signal. Albeit this was 2017 and with TCP.

[SpencerDawkins]

So, please help me out here. I THINK the center of gravity has shifted from per-device network properties to "maximum achievable bandwidth for a video" (this is how the current working version of the charter describes "per-flow", if I understand correctly).

Is that clear enough in the current working version of the charter? Is any text change needed to make that more clear?

[Kevsy]

I think maximum throughput of a video flow to a given device is the primary use case - and that the device context has to be taken into account for the network (at least, a cellular network) to arrive at that estimate. Ideally the same mechanism can be used to signal other network conditions/hints and the charter appears to support that.

I think the per-device context is implicit in the current list of properties in the charter. We could add:

'Associativity with a device: The network properties may be calculated on a per-device basis, for example in a cellular network where network conditions may vary significantly between devices'

The other aspect could be any data cap the user has as part of their network subscription (again this is probably more relevant for cellular):

'Associativity with a user subscription: The network properties may be calculated on a per-subscriber basis, for example where the subscriber is nearing the limit of a contractual data cap' (NB I'm not sure how that would translate to 'maximum throughput', maybe it should be discussed as another potential signal)

PS I've raised #77 (with associated PR #78) to change 'maximum achievable bandwidth' to 'maximum achievable throughput'

[ihlar]

closed by #84