[Scone] Re: 64 steps

[Abhishek Tiwari <[e-mail]>]

Hi Martin:


Thank you for beginning this discussion.


Let’s consider the question:  “How many bits do we need to codify the rate advice?”


In my opinion the methodical way of answering this question will be for the working group to first understand all the requirements and necessary data that have bearing on this question. I am going to start stating some of the requirements and required data below that have come up in my various discussions with content providers, communication service providers and equipment manufacturers:



  1.  Need to specify how to measure the rate advice in addition to the rate advice itself: Since we intend to send rate advice from the network to the endpoint, we need to make sure that the procedure of measuring that rate advice is clear and consistently interpreted by the two parties: (1) the network and (2) the endpoint. From a scale deployment and adoption point of view, the two parties should be able to independently measure the same rate. Otherwise this can lead to confusion and render the rate advice signal useless. To achieve this unambiguity we need to also codify answers to the following questions:

     *   What is the time averaging window used to measure the rate?

     *   Since video traffic is bursty, will this time averaging window stay the same or be variable? If variable, how do we specify it?

     *   Are we specifying the average rate, Median rate, 75th percentile rate, 95th percentile rate?

     *   Do we specify both the median rate and the peak rate?

  1.  Global survey of current network throttling policies: The working group needs to have this data to make sure that the number of bits we allocate can work in practice. I was given an action by the chairs in the December interim to bring this data to the working group in 2025. Using our existing http connections, we (Meta) have CDN/client based measuring techniques that enable us to estimate the throttling policies over several ASNs around the world. We are planning to compile this into a report (with anonymized ASNs) that we will publish prior to the IETF 122 meeting in Bangkok. I am sure other large content providers can also measure this data and I encourage collaboration on collecting this data. These throttling policies are derived from subscriber plans and/or network management considerations and/or network investment considerations, and/or radio access network efficiency considerations. If we do not use this data, we may end up ignoring some of these considerations, which could later hamper the scale deployment of the standard that we create.
  2.  Application considerations: Currently the driving application for the working group is video traffic but a growing and very important format here is Short Form Video for which as Matt pointed out pre-fetching is necessary to maintain user QoE. Such applications will need burst allowance. Similarly we also need to forecast what kinds of rates will be minimally required for decent QoE of new application classes like AR/VR, Metaverse, 3D video streaming that may become viral in the coming years. I think the quantitative analysis that you presented is a good first step to understand application considerations.
  3.  Network considerations: Christian has pointed out CPU consideration for processing a large number of bits by the network device.


I encourage others to bring up considerations that I may have missed.



At this time, all of us can agree that the number of bits to codify rate advice has to be bounded, but I think we should decide exactly what that bound should be once we have all the above data.

Best Regards

Abhishek Tiwari Ph.D.
Systems Lead
Meta Network Infrastructure
Meta Platforms Inc.
[e-mail]<mailto:[e-mail]>






From: Martin Thomson <[e-mail]>
Date: Wednesday, February 5, 2025 at 4:38 PM
To: [e-mail] <[e-mail]>
Subject: [Scone] 64 steps
I appreciate that there is a desire to have great expressiveness in signals.  I sat down today and did some basic sketching to see what 64 codepoints might get us in terms of concrete rate signals.

Let's start with the assumption that this is video delivery.  I found a paper suggesting that you could do video in 64kbps, so let's put that as the low point.  8k video at 120fps in 4:4:4 uncompressed is 120 Gbps, which might be a reasonable high point, but let's just round up to a clean 1Tbps.

Hitting powers of two across this range (2^16 to 2^40) takes 25 codepoints, but that might be limiting in those areas where we see a lot of real-world activity.  I doubt that anyone is happy with rate limiting at the ends of those ranges.  Still, we can start with assigning codepoints across those powers of 2.

More realistically, video is compressed and runs in a fairly narrow range around sort of 2-20 Mbps.  I found some suggestions that 40Mbps of AV1 gets you pretty reasonable 8k performance.  Video performance at 1/100th of that is pretty grim and the 25 points above already cover that 0.5Mbps and 1Mbps, but you can take the remaining codepoints and dedicate 11 to the range from 0.5Mbps to 8Mbps in 0.5Mbps increments, skipping those that are already powers of two.  Then add 11 more to the populate the gaps between 8Mbps and 20Mbps and 9 more to take it up to 40Mbps in 2Mbps increments.

That's 56 values, with 7 spare (we need one for "infinity" or no signal).  And I was being generous.  64kbps is low enough that no self-respecting network operator would be capping that low.  Similarly, the likelihood that we'll see this sort of signaling for network throughput of 1Tbps seems like a bit of a stretch.  There's probably room to cut in several places and recover a few of these.  And we could spend those spare values to get more resolving power somewhere, extending the range above 40Mbps, below 1Mbps, or inserting finer resolving power elsewhere.

Does someone have a case for greater precision than this?

_______________________________________________
Scone mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]