Add counters that support deployment of L4S #792
Conversation
These counters also depend on RFC8888 being deployed.
|
Interesting stuff |
This is the explainer for the counters proposed in the PR.
|
@jesup any concerns with this? |
| * Number of packets received with ECT(1) marking | ||
| * Number of packets received with CE marking | ||
| * Number of packets reported as lost in RFC8888 reports | ||
| * Number of packets reported as lost in one RFC8888 report but later reported as arrived |
There was a problem hiding this comment.
Another counter useful would be RFC 8888 feedback send interval. Cumulative RFC 8888 feedback sent and Cumulative RFC feedback interval. Avg interval could be computed using those 2 stats.
|
I dont think there is any overlap with the other FEC stats, since we did not have loss recovery stats before. Re: RTCP interval, is the implementation of RFC8888 going to be compound packets or non-compound? former means we can reuse RTCP intervals for calculating the reporting interval. |
|
I think just counting the number of 8888 reports sent would be a better stat than the interval; the average interval can be computed from the increase in the count between two measurements. |
Co-authored-by: Dominique Hazael-Massieux <[email protected]>
| but a later report for the same packet has the R bit set to 1. | ||
| Only reported if support for the "ccfb" feedback mechanism has been negotiated. | ||
| </p> | ||
| </dd> |
There was a problem hiding this comment.
should we change the name from *ButRecovered to *ButReceivedLater because these packets were perhaps received late not recovered by retx or fec.
| <p> | ||
| Total number of RTP packets for which an [[RFC8888]] section 3.1 report has been sent with a zero R bit. | ||
| Only reported if support for the "ccfb" feedback mechanism has been negotiated. | ||
| </p> |
There was a problem hiding this comment.
Should we soften the metric from *AsLost to *NotReceived because R={0,1} can occur due to re-ordering. fractionLost and other packetLost metrics already capture the RTP/RTCP metrics.
|
Will be presented in the March 25 WEBRTC meeting. |
These counters also depend on RFC8888 being deployed.
An explainer for the design is included.
Fixes #793
Preview | Diff