You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add counters that support deployment of L4S (#792)
* Add counters that support deployment of L4S
These counters also depend on RFC8888 being deployed.
* Create l4s-explainer.md
This is the explainer for the counters proposed in the PR.
* Remove internal note
* Minor edits
* Fix missing dt
Co-authored-by: Dominique Hazael-Massieux <[email protected]>
* Add feedback counts to explainer
* Add ccfb counters to webrtc-stats.html
as per discussion on the PR.
---------
Co-authored-by: Dominique Hazael-Massieux <[email protected]>
# Explainer - RFC8888 and L4S stats support in webrtc-stats
6
+
7
+
This explainer gives the background for the proposal to add stats to webrtc-stats to support the deployment of L4S and its prerequisite reporting format, RFC8888.
8
+
9
+
## What is L4S
10
+
11
+
L4S is a strategy for packet scheduling and marking in the Internet that is intended to make the Internet better for latency-sensitive applications that are capable of and willing to rapidly respond to signals that indicate queue buildup.
12
+
13
+
The elements constituting L4S, seen from an application, are:
14
+
15
+
16
+
17
+
* The data sender marks outgoing packets with the bit pattern ECT(1) (01) (rather than the default, “no signal” (00)
18
+
* Network elements, when observing queue buildup, change the ECT(1) bit pattern to the CE (Congestion Experienced) bit pattern (11).
19
+
* The data recipient reflects the bits observed on each packet back to the sender, using the RFC8888 reporting format
20
+
* The data sender adjusts its send rate according to the observations in the report
21
+
22
+
23
+
## What we need to diagnose
24
+
25
+
There are a number of scenarios we want to diagnose:
26
+
27
+
28
+
29
+
* CE-aware chokepoints: ECT(1) gets sent and received, the occasional CE gets received, and reflected back to the sender, which adjusts bitrate accordingly
30
+
* Bleaching: ECT(1) gets sent, but the recipient sees “No signal”
31
+
* Network drops: Packets marked with ECT(1) get dropped, packets without it get through
32
+
* CE-less chokepoints: We observe packet loss, but no CE markings.
33
+
34
+
We may also want to look at packet loss vs packet reordering - when packets are lost, the reports will contain loss markings; when packets are reordered, later reports will overlap the previous reports and add info on packets previously reported as missing.
35
+
36
+
37
+
## Suggested counters and where to attach them
38
+
39
+
The following counters are proposed:
40
+
41
+
Attached to RTCSentRtpStreamStats:
42
+
43
+
44
+
45
+
* Number of packets sent with normal markings (this can be calculated from PacketsSent - Ect1PacketsSent, so no explicit counter is needed)
46
+
* Number of packets sent with ECT(1) markings
47
+
48
+
Attached to RTCReceivedRtpStreamStats:
49
+
50
+
51
+
52
+
* Number of packets received with normal markings
53
+
* Number of packets received with ECT(1) marking
54
+
* Number of packets received with CE marking
55
+
* Number of packets reported as lost in RFC8888 reports
56
+
* Number of packets reported as lost in one RFC8888 report but later reported as arrived
57
+
58
+
Attached to RTCRemoteInboundRtpStreamStats (which is a subclass of RTCReceivedRtpStreamStats):
59
+
60
+
61
+
62
+
* Number of packets sent with ECT(1) but reported as “no marking” (Bleached)
63
+
64
+
Data in RTCRemoteInboundRtpStreamStats are computed based on a sender’s knowledge of the outgoing packets + data from remote reports (RR or RFC8888 reports). Computing “bleached” packets requires having both info on the sent packet and info on the RFC8888 report available.
65
+
66
+
Attached to RTCTransportStats:
67
+
68
+
* Number of RFC 8888 format feedback messages sent
69
+
* Number of RFC 8888 format feedback messages received
70
+
71
+
These numbers will allow monitoring of the frequency of RFC 8888 reporting.
72
+
73
+
74
+
## How to diagnose scenarios from these numbers
75
+
76
+
Diagnosing is performed at the sending endpoint.
77
+
78
+
79
+
80
+
* CE-aware chokepoints: ECT(1) is sent, ECT(1) and CE are in reports, reported ECT(1) + CE + lost add up to the number of sent packets (modulo in-flight). Bleaching stays at zero.
81
+
* Bleaching: ECT(1) is sent, but “no marking” is reported. Number of sent packets and number of received packets + lost are roughly equal.
82
+
* Network drops: Packets sent with normal and ECT(1) are both above zero, but packets received are only normal, not ECT(1), and correspond to the number of normal packets. (NOTE: This is a failure scenario for deploying L4S)
83
+
* CE-less chokepoints: ECT(1) is sent and received, but CE counter remains at zero. Number of packets reported as lost in RFC8888 reports is above zero.
84
+
85
+
If excessive reordering occurs, the “reported later” counters will go up; the precise interpretation of that number depends on the strategy used for scheduling RFC8888 reports (longer intervals will allow more reordered packets to be recovered without this being visible in the reports).
0 commit comments