DownTrack scoring when RR is not received. #1664
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Got more complicated than I would like, but the main challenge is distinguishing between publisher traffic stopping vs subscriber not sendint RTCP Receiver Report. Split out the send and receiver report snapshot on down track. This is directionally okay. As we want to report what we are sending to analytics. Till now, what is reported to analytics also depended on what was reported in receiver report. Once that is split out, can check for streaming. If publisher has run dry, we will not be sending anything. If we are sending data, then look for long interval without receiver report and treat it like no report and score it poor. Scoring runs on receiver report based snap shot purely. Also, increase the no receiver report interval to 30 seconds to give enough headroom.
boks1971
commented
Apr 28, 2023
| packetsLost = intervalStats.packetsLost | ||
| } | ||
| intervalStats := r.getIntervalStats(uint16(then.extStartSN), uint16(now.extStartSN)) | ||
| packetsLost := intervalStats.packetsLost |
There was a problem hiding this comment.
Cleaning these up. If receiver report based delta is needed, DeltaInfoOverridden should be used. So, cleaning these up.
boks1971
commented
Apr 28, 2023
| } | ||
| r.snapshots[snapshotId] = then | ||
| } | ||
|
|
||
| var startTime time.Time | ||
| if override && r.params.IsReceiverReportDriven { | ||
| startTime = r.lastRRTime |
There was a problem hiding this comment.
Lock snap shots to receiver report time. Without that, maxPPS calculation was off as the window durations were offset between receiver report and snap shots.
paulwe
approved these changes
Apr 28, 2023
boks1971
added a commit
that referenced
this pull request
Jun 9, 2023
Reversing a bit of #1664. That PR did two snapshots (one based on what SFU is sending and one based on combination of what SFU is sending reconciled with stats reported from client via RTCP Receiver Report). That PR reported SFU only view to analytics. But, that view does not have information about loss seen by client in the downstream. Also, that does not have RTT/jitter information. The rationale behind using SFU only view is that SFU should report what it sends irrespective of client is receiving or not. But, that view did not have proper loss/RTT/jitter. So, switch back to reporting SFU + receiver report reconciled view. The down side is that when receiver reports are not receiver, packets sent/bytes sent will not be reported to analytics. An option is to report SFU only view if there are no receiver reports. But, it becomes complex because of the offset. Receiver report would acknowledge certain range whereas SFU only view could be different because of propagation delay. To simplify, just using the reconciled view to report to analytics. Using the available view will require a bunch more work to produce accurate data. (NOTE: all this started due to a bug where RTCP was not restarted on a track resume which killed receiver reports and we went on this path to distinguish between publisher stopping vs RTCP receiver report not happening) One optimisation to here here concerns the check to see if publisher is sending data. Using a full DeltaInfo for that is an overkill. Can do a lighter weight for that later.
boks1971
added a commit
that referenced
this pull request
Jun 9, 2023
* Use receiver report stats for loss/rtt/jitter. Reversing a bit of #1664. That PR did two snapshots (one based on what SFU is sending and one based on combination of what SFU is sending reconciled with stats reported from client via RTCP Receiver Report). That PR reported SFU only view to analytics. But, that view does not have information about loss seen by client in the downstream. Also, that does not have RTT/jitter information. The rationale behind using SFU only view is that SFU should report what it sends irrespective of client is receiving or not. But, that view did not have proper loss/RTT/jitter. So, switch back to reporting SFU + receiver report reconciled view. The down side is that when receiver reports are not receiver, packets sent/bytes sent will not be reported to analytics. An option is to report SFU only view if there are no receiver reports. But, it becomes complex because of the offset. Receiver report would acknowledge certain range whereas SFU only view could be different because of propagation delay. To simplify, just using the reconciled view to report to analytics. Using the available view will require a bunch more work to produce accurate data. (NOTE: all this started due to a bug where RTCP was not restarted on a track resume which killed receiver reports and we went on this path to distinguish between publisher stopping vs RTCP receiver report not happening) One optimisation to here here concerns the check to see if publisher is sending data. Using a full DeltaInfo for that is an overkill. Can do a lighter weight for that later. * return available streams * fix test
hautvfami
pushed a commit
to Stark-Industries-Ltd/livekit
that referenced
this pull request
Jul 21, 2023
hautvfami
pushed a commit
to Stark-Industries-Ltd/livekit
that referenced
this pull request
Jul 21, 2023
* Use receiver report stats for loss/rtt/jitter. Reversing a bit of livekit#1664. That PR did two snapshots (one based on what SFU is sending and one based on combination of what SFU is sending reconciled with stats reported from client via RTCP Receiver Report). That PR reported SFU only view to analytics. But, that view does not have information about loss seen by client in the downstream. Also, that does not have RTT/jitter information. The rationale behind using SFU only view is that SFU should report what it sends irrespective of client is receiving or not. But, that view did not have proper loss/RTT/jitter. So, switch back to reporting SFU + receiver report reconciled view. The down side is that when receiver reports are not receiver, packets sent/bytes sent will not be reported to analytics. An option is to report SFU only view if there are no receiver reports. But, it becomes complex because of the offset. Receiver report would acknowledge certain range whereas SFU only view could be different because of propagation delay. To simplify, just using the reconciled view to report to analytics. Using the available view will require a bunch more work to produce accurate data. (NOTE: all this started due to a bug where RTCP was not restarted on a track resume which killed receiver reports and we went on this path to distinguish between publisher stopping vs RTCP receiver report not happening) One optimisation to here here concerns the check to see if publisher is sending data. Using a full DeltaInfo for that is an overkill. Can do a lighter weight for that later. * return available streams * fix test
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Got more complicated than I would like, but the main challenge is distinguishing between publisher traffic stopping vs subscriber not sending RTCP Receiver Report.
Split out the send and receiver report snapshot on down track. This is directionally okay. As we want to report what we are sending to analytics. Till now, what is reported to analytics also depended on what was reported in receiver report.
Once that is split out, can check for streaming.
If publisher has run dry, we will not be sending anything.
If we are sending data, then look for long interval without receiver report and treat it like no report and score it poor. Scoring runs on receiver report based snap shot purely.
Also, increase the no receiver report interval to 30 seconds to give enough headroom.