EricssonResearch / EricssonResearch/scream

Periodic rate drop with CWND control enabled.

Open
#45 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
Shell
Stars
217
Forks
69
PR merge metrics
No merged PRs in 30d

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](https://user-images.githubusercontent.com/25366469/168829755-a0735368-6a18-4156-a90d-5c41a7eee5ff.png)

## 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](https://user-images.githubusercontent.com/25366469/168835079-8669e84e-a468-430b-983d-ab9c792783ba.png)

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](https://user-images.githubusercontent.com/25366469/168836117-6eac5591-c040-4da6-b1c3-41187cc684d3.png)

## 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`

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.