Periodic rate drop with CWND control enabled.

Open
  • Is something wrong?
#45 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
25/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Stale
Domain
networking

Research direction

Start with ScreamTx::Stream::updateTargetBitrate() and ScreamTx::getTotalTargetBitrate(), comparing behavior with openWindow true and false. Inspect the CWND control around cwnd and RtpQueue clearing, then reproduce on the described two-machine local subnet while monitoring bitrate, cwnd, and queue-clearing events; the issue is resolved when the periodic dips and unrecovered minimum-rate state are explained or corrected.

Written by the indexing model from the issue text.

Description

Hello, I am having an issue with periodic excessive rate drop when trying to use scream with ScreamTx::openWindow = false

For verification, I have set up both the sender and receiver on two machines in a local subnet, to eliminate network bandwidth variations. I have several cameras with separate streams using the prioritization functionality.

Stable with ScreamTx::openWindow = true

The transmission is very stable when running with ScreamTx::openWindow = true

Below is the output of a little statistic that I am collecting on ScreamTx::Stream::updateTargetBitrate() to visualise the incidence of different updating scenarios. I print it every 25k calls of said function.

At the bottom (of this image) is a "histogram" of ScreamTx::getTotalTargetBitrate(). You can see that in this setup, in the span of 15M calls, the bitrate remains near the maximum values limited by maximum bitrates. This was measured for about 30+ minutes.

Stats - window_open--true__l4s_enabled--false

Dipping with ScreamTx::openWindow = false

When enabling CWND control, the target bitrate stays at the same stable maximum level most of the time, but very regularly dips. Sometimes the dip reaches a medium low level and recovers after a short moment, sometimes it dips all the way to minimum bitrates and struggles to recover for tens of seconds. After half an hour or so, it gets stuck in clearing the RtpQueue and never recovers at all.

Here is the same statistic with CWND control. It can be seen that the bitrate has been all over the place, and stayed near minimum 9% of the time.
It can also be seen that many clearings of RtpQueue have been performed due to excessive delay (not Loss or Ecn events), which, I guess is due to cwnd dropping to the minimum (5000) and packets not getting sent thereby. Under normal operation, i observed the cwnd value to be around 130'000.
Stats - window_open--FALSE__l4s_enabed--false - DEEP DIP 1

Here is an example of the bitrates dropping a little bit for a short while and then going all the way down for a longer time.
NW_load - window_open--FALSE__l4s_enabed--false - DEEP DIP 1

Question

Are there any obvious things I should try changing or any other values I should monitor to get a clue?

These coefficients are currently set to:
kLossBeta = 0.8
kEcnCeBeta = 0.9

Dominant language
Shell
Stars
222
Forks
69
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EricssonResearch/scream

All issues in EricssonResearch/scream

Similar issues

More Shell/Bash issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.