[Scone] Re: What is SCONE experimentation and interpop?

[Mirja Kuehlewind <[e-mail]>]

Hi Lucas,

it sounds like you are focused in your testing assumption on the adaptive bitrate algorithms in the endpoints. I think if you want to test that part, you actually don’t need any signaling. You simulate a shaper and configure a fixed throughput limit in the endpoints. That’s it.

The part we are interested in testing is the integration into the network, specifically the mobile network. While today the shaping limits are usually static (eventually based on subscription), we would also like to experiment with more dynamic limits. This requires the signaling from the network and also some kind of real or simulated mobile network.

I’m not sure I understand your proposal to use HTTP headers below. How would a network node be able to provide any throughput advise through (encrypted) http headers?

On availability of MASQUE implementation: The Google quiche stack has an open source MASQUE implementation which is actually easy to experiment this. We just recently used this in some testings. Also we are planning to open our implementation but no promises yet as this is really a matter of resources.

Mirja



From: Lucas Pardue <[e-mail]>
Date: Wednesday, 27. November 2024 at 09:48
To: "[e-mail]" <[e-mail]>
Subject: [Scone] Re: What is SCONE experimentation and interpop?

To follow up here.

Imagine you are a researcher that isn't Meta or YouTube. You have extensive experience is testing client side adaptive bitrate algorithms in dash.js [1] or equivalent. You want to run experiments on the Scone approach by running browser-based tests using a minimal patches (probably against open source code).

Using QUIC-level signals or MASQUE level signals does not help this researcher. The signals are too low-level to be exposed today within a browser environment. This creates a barrier.

To overcome that barrier, I'm proposing we do something even simpler. Pass the signals using means already readily available and accessible. Possible options;

* OOB configuration - provide the client with some configuration object. This could be built into a patch, or fetched from some config server.
* HTTP headers on the data flow - served on player load, manifest or media segments, offering some level of runtime signal change.
 * A control plane server - e.g. long polling an HTTP resource, WebSocket server etc, that can push updates to a user agent with minimal latency.

Finally, imy opinion that if experiments mandate data flows via a MASQUE proxy, you're going to waste people's time setting up and tuning it. I'm going to be skeptical of any results that come from this. Especially if the final solution the WG decides is not MASQUE based. Hence, I'm suggesting options that have minimal effect on the data flow.

Cheers
Lucas

[1] - https://dashjs.org/

On Thu, Nov 21, 2024, at 00:33, Lucas Pardue wrote:
Hello SCONE pros,

Firstly, apologies for only just joining _any_ mailing list related to this work. I've tried to catch up on the archives as best I can. But read any questions or comment as ignorance rather than rhetorical.

Secondly, I wasn't able to attend the 121 meeting in person, and so couldn't follow up on the question in the title of the thread.

So I understand we are focused on signalling a throughput value and that a client or server can somehow act on that to "do better". And that there I'd likely a shaper in the mix.

During the 121 meeting there were comments that some experimentation could be easier with MASQUE (even if the final signal format was completely different). I commented in the chat that, IMHO, the state of readily available MASQUE proxies and clients that can use them is actually pretty poor. While there are many production services* using protocols defined by the MASQUE WG (e.g. CONNECT UDP, CONNECT-IP) they are not necessarily suitable for running collaborative testing like I might imagine people want to do. Especially, IMO, with respect to something that independent researchers can pick up and play with.

However, maybe I'm missing something because others don't seem to agree. Therefore, I'm raising this thread to better flesh out what people think experimentation and interop would be.

For example, assume in theory we are focused on how client javascript HAS video playback can adapt to receiving a signal about L4 path properties (throughput for now). I don't see what value a MASQUE proxy brings here. We can simplify the experiment by just putting those signals in HTTP headers from the origin. Vice-versa if we care about a server adapting.

In my experience, there are already numerous test benches for video streaming that insert L4 traffic shaping between client and server (e.g Liux Traffic Control, ns3 or whatever). Adding MASQUE just seems like an awkward hump to reusing those.

But like I said, maybe I'm missing something. Anyone care to collaborate on the experimental design before we decide methodology?

Cheers
Lucas


* my employer has some that I am deeply familiar with