10 ms·

One of the solutions they mention is underutilizing links. This is probably a good time to mention my thesis work, where we showed that streaming video traffic

One of the solutions they mention is underutilizing links. This is probably a good time to mention my thesis work, where we showed that streaming video traffic (which is the majority of the traffic on the internet) can pretty readily underutilize links on the internet today, without a downside to video QoE! https://sammy.brucespang.com https://sammy.brucespang.com

clbrmbr 2y ago
Can you comment on latency-sensitive video (Meet, Zoom) versus latency-insensitive video (YouTube, Netflix)? Is only the latter “streaming video traffic”?
- flapjack 2y ago
  We looked at latency-insensitive like YouTube and Netflix (which were a bit more than 50% of internet traffic last year [1]). I'd bet you could do something similar with Meet and Zoom–my understanding is video bitrates for those services are lower than for e.g. Netflix which we showed are much lower than network capacities. But it might be tricky because of the latency-sensitivity angle, and we did not look into it in our paper. [1] https://www.sandvine.com/hubfs/Sandvine_Redesign_2019/Downloads/2024/GIPR/GIPR%202024.pdf https://www.sandvine.com/hubfs/Sandvine_Redesign_2019/Downlo...
  - mikepavone 2y ago
    > Meet and Zoom–my understanding is video bitrates for those services are lower than for e.g. Netflix For a given quality, bitrate will generally be higher in RTC apps (though quality may be lower in general depending on the context and network conditions obviously) because of tradeoffs between encoding latency and efficiency. However, RTC apps generally already try to underutilize links because queuing is bad for latency and latency matters a lot for the RTC case.
- sulandor 2y ago
  the term “streaming video" usually refers to the fact that the data is sent slower than the link capacity (but intermittently faster than the content bitrate) op used the term presumably to describe "live content" eg. the source material is not available as a whole (because the recording is not finished); which can be considered a subset of "streaming video" the sensitivity in regard to transport characteristics stems from the fact that "live content" places an upper bound for the time required for processing and transferring the content-bits to the clients (for it to be considered "live").
aidenn0 2y ago
Packet switching won over circuit switching because the cost-per-capacity was so much lower; if you have to end up over-provision/under-utilize links anyways, why not use circuit switching?
- crest 2y ago
  Because the cost is a lot lower. Paying a few percent of overcapacity doesn’t change that.
  - aidenn0 2y ago
    TFA suggest a 900% overcapacity, not a few percent. I just skimmed GP's article but it seems to suggest a ~100% overcapacity for streaming-video specifically.
    - nine_k 2y ago
      "100% overcapacity" is also known as "50% load factor". It's common knowledge to run your API nodes at 20%-60% CPU load, no more, exactly to curb tail latency.
      - sambazi 2y ago
        just think about your competitive edge if you could manage to cramp more load w/o affecting latency
        jdougan 2y ago
        Depends on what you have to pay (and not just in money) to get there.
- nine_k 2y ago
  A physical circuit costs a lot, so much more that it's not even funny. You can deploy a 24-fiber optical cable and allow many thousand virtual circuits to run on it in parallel using packet switching. Usually orders of magnitude more when they share bandwidth opportunistically, because the streams of packets are not constant intensity. Running thousands of separate fibers / wires would be much more expensive, and having thousands of narrow-band splitters / transcievers, also massively expensive. Phone networks have tried that all, and gladly jumped off the physical circuits ship as soon as they could.
sambazi 2y ago
> my thesis work, where we showed that streaming video traffic [...] can pretty readily underutilize links on the internet today, without a downside to video QoE! was slightly at a loss in what exactly needed to be shown here until i clicked the link and came to the conclusion that you re-invented(?) pacing. https://man7.org/linux/man-pages/man8/tc-fq.8.html https://man7.org/linux/man-pages/man8/tc-fq.8.html
- flapjack 2y ago
  I would definitely not say that we re-invented pacing! One version of the question we looked at was: how low a pace rate can you pick for an ABR algorithm, without reducing video QoE? The part which takes work is this "without reducing video QoE" requirement. If you're interested, check out the paper!
  - sambazi 2y ago
    > One version of the question we looked at was: how low a pace rate can you pick for an ABR algorithm, without reducing video QoE? that is certainly an interesting economical optimization problem to reason about, though imho somewhat beyond technical merit, as simply letting the client choose quality and sending the data full speed works well enough. addition: i totally agree that things have to look economical in order to work and that there are technical edge-cases that need to be handled for good ux, but i dont't quite see how client-side buffer occupancy in the seconds range is in the users interest.
- nsteel 2y ago
  Did you read the linked paper which talks a lot about TCP pacing? https://sammy.brucespang.com/sammy.pdf https://sammy.brucespang.com/sammy.pdf
  - sambazi 2y ago
    i did not read that paper with a focus on adaptive bitrate selection for video streaming services that came out 8 years after the pacing implementation hit the kernel. thx thou

clbrmbr 2y ago

Can you comment on latency-sensitive video (Meet, Zoom) versus latency-insensitive video (YouTube, Netflix)? Is only the latter “streaming video traffic”?

flapjack 2y ago
We looked at latency-insensitive like YouTube and Netflix (which were a bit more than 50% of internet traffic last year [1]). I'd bet you could do something similar with Meet and Zoom–my understanding is video bitrates for those services are lower than for e.g. Netflix which we showed are much lower than network capacities. But it might be tricky because of the latency-sensitivity angle, and we did not look into it in our paper. [1] https://www.sandvine.com/hubfs/Sandvine_Redesign_2019/Downloads/2024/GIPR/GIPR%202024.pdf https://www.sandvine.com/hubfs/Sandvine_Redesign_2019/Downlo...
- mikepavone 2y ago
  > Meet and Zoom–my understanding is video bitrates for those services are lower than for e.g. Netflix For a given quality, bitrate will generally be higher in RTC apps (though quality may be lower in general depending on the context and network conditions obviously) because of tradeoffs between encoding latency and efficiency. However, RTC apps generally already try to underutilize links because queuing is bad for latency and latency matters a lot for the RTC case.
sulandor 2y ago
the term “streaming video" usually refers to the fact that the data is sent slower than the link capacity (but intermittently faster than the content bitrate) op used the term presumably to describe "live content" eg. the source material is not available as a whole (because the recording is not finished); which can be considered a subset of "streaming video" the sensitivity in regard to transport characteristics stems from the fact that "live content" places an upper bound for the time required for processing and transferring the content-bits to the clients (for it to be considered "live").

aidenn0 2y ago

Packet switching won over circuit switching because the cost-per-capacity was so much lower; if you have to end up over-provision/under-utilize links anyways, why not use circuit switching?

crest 2y ago
Because the cost is a lot lower. Paying a few percent of overcapacity doesn’t change that.
- aidenn0 2y ago
  TFA suggest a 900% overcapacity, not a few percent. I just skimmed GP's article but it seems to suggest a ~100% overcapacity for streaming-video specifically.
  - nine_k 2y ago
    "100% overcapacity" is also known as "50% load factor". It's common knowledge to run your API nodes at 20%-60% CPU load, no more, exactly to curb tail latency.
    - sambazi 2y ago
      just think about your competitive edge if you could manage to cramp more load w/o affecting latency
      - jdougan 2y ago
        Depends on what you have to pay (and not just in money) to get there.
nine_k 2y ago
A physical circuit costs a lot, so much more that it's not even funny. You can deploy a 24-fiber optical cable and allow many thousand virtual circuits to run on it in parallel using packet switching. Usually orders of magnitude more when they share bandwidth opportunistically, because the streams of packets are not constant intensity. Running thousands of separate fibers / wires would be much more expensive, and having thousands of narrow-band splitters / transcievers, also massively expensive. Phone networks have tried that all, and gladly jumped off the physical circuits ship as soon as they could.

sambazi 2y ago

> my thesis work, where we showed that streaming video traffic [...] can pretty readily underutilize links on the internet today, without a downside to video QoE! was slightly at a loss in what exactly needed to be shown here until i clicked the link and came to the conclusion that you re-invented(?) pacing. https://man7.org/linux/man-pages/man8/tc-fq.8.html https://man7.org/linux/man-pages/man8/tc-fq.8.html

flapjack 2y ago
I would definitely not say that we re-invented pacing! One version of the question we looked at was: how low a pace rate can you pick for an ABR algorithm, without reducing video QoE? The part which takes work is this "without reducing video QoE" requirement. If you're interested, check out the paper!
- sambazi 2y ago
  > One version of the question we looked at was: how low a pace rate can you pick for an ABR algorithm, without reducing video QoE? that is certainly an interesting economical optimization problem to reason about, though imho somewhat beyond technical merit, as simply letting the client choose quality and sending the data full speed works well enough. addition: i totally agree that things have to look economical in order to work and that there are technical edge-cases that need to be handled for good ux, but i dont't quite see how client-side buffer occupancy in the seconds range is in the users interest.
nsteel 2y ago
Did you read the linked paper which talks a lot about TCP pacing? https://sammy.brucespang.com/sammy.pdf https://sammy.brucespang.com/sammy.pdf
- sambazi 2y ago
  i did not read that paper with a focus on adaptive bitrate selection for video streaming services that came out 8 years after the pacing implementation hit the kernel. thx thou