PSA: Packet overhead to be included in target bitrates in send-side BWE

531 views
Skip to first unread message

Ali Tofigh

unread,
Feb 24, 2020, 10:15:03 AM2/24/20
to discuss-webrtc

Packet overhead, such as IP and UDP packet headers, can under certain circumstances constitute a significant portion of outbound traffic. This overhead has traditionally not been included in WebRTC bitrate calculations. By including packet overhead, WebRTC's bandwidth estimation will be able to make a more accurate estimation of the available link capacity, which  will help improve the overall quality especially in some low-bandwidth scenarios.


We plan to gradually roll out an improvement in Chrome M81 that will include packet overhead in bitrate calculations when the client is using send-side (transport-cc) bandwidth estimation (Receive-side bandwidth estimation with REMB will not be affected). More specifically, the following header sizes will be included: IP header, UDP header, SRTP authentication tag and RTP headers. 


The improvement will be rolled out gradually to the Chrome population as an A/B test starting in Chrome M81 Beta and later in Chrome M81 Stable. You can test this new behavior already now in Chrome M81 or later by specifying “--force-fieldtrials=WebRTC-SendSideBwe-WithOverhead/Enabled/” as a command line option when starting Chrome.


Note: Although this change does not affect receive-side BWE, it does change the interpretation of the bitrate in REMB [1] messages that are received by clients that are doing send-side BWE. Such REMB messages set the maximum send bitrate of clients and any server that sends REMB messages to clients that are doing send-side BWE will need to include packet overhead in the bitrates sent in REMB. Not doing so will result in lower payload bitrates sent from clients that have the field trial turned on.


The table below summarizes the technical changes. The interpretation of target bitrate will depend on whether the transport sequence number extension [2] has been negotiated for video (video-twcc) and audio (audio-twcc):


video-twcc

audio-twcc

Current interpretation of target bitrate

Future interpretation of target bitrates

no

no

Video payload

Video payload

no

yes

Audio payload

Audio payload + audio OH

yes

no

Video payload

Video payload + video OH

yes

yes

Video + audio payloads

Video and audio payloads + video and audio packet overheads


[1] https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03

[2] https://tools.ietf.org/html/draft-holmer-rmcat-transport-wide-cc-extensions-01

Philipp Hancke

unread,
Feb 24, 2020, 10:24:39 AM2/24/20
to discuss...@googlegroups.com
What is going to be the impact on Edgium and Safari?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e4a1337c-c04e-46fa-8869-a5d5687bed56%40googlegroups.com.

Alexandre GOUAILLARD

unread,
Feb 24, 2020, 12:29:03 PM2/24/20
to discuss...@googlegroups.com
To answer the question the way you asked it:
- safari (and firefox) do not have automatic roll-out, so they can decide if and when to adopt.

Now, did you mean: what will be the impact on interoperability between Chrome and Edgium, res. safari?

I suppose this also a question of interest for SFU / Gateway / Non-Browsers WebRTC clients in general since it changes the info on the wire.


To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiK7sU7j5i6Gfmgv%3DH%2BHNRAv68gPaRJZ7tkuUjw%2B6cCPtg%40mail.gmail.com.


--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------

Sergio Garcia Murillo

unread,
Feb 24, 2020, 12:35:56 PM2/24/20
to discuss...@googlegroups.com
Re. interoperability, it is a just a modification done on the sending side in the way of calculating the available bandwidth, there should be visible modification on behavior on the receiver side, nor any extra info exchanged.

BR
Sergio

Alexandre GOUAILLARD

unread,
Feb 24, 2020, 1:44:26 PM2/24/20
to discuss...@googlegroups.com
In terms of protocol, since there is no new message, signal nor keywords, there is no interoperability problem.
However, if for the same bandwidth usage the previously reported value was 5 and the new value is, say, 7, the logic might be impacted, no?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/08e8dcbb-d322-56e7-06ab-2bb9ab753b90%40gmail.com.

Ali Tofigh

unread,
Feb 24, 2020, 2:05:33 PM2/24/20
to discuss-webrtc
So to clarify a few points that were raised in this thread:

Regarding browsers other than Chrome: The rollout will not change the behavior of other browsers. If the full rollout is successful in Chrome M81, we may decide to make the feature default in the WebRTC implementation, at which point other browsers might also pick up this change. But that will be announced separately.

Also note that this does not change the REMB messages sent from Chrome nor the interpretation of REMB messages received by Chrome when receive-side bandwidth-estimation is used (for example in peer connections between Firefox and Chrome).

On Monday, February 24, 2020 at 7:44:26 PM UTC+1, Alexandre GOUAILLARD wrote:
In terms of protocol, since there is no new message, signal nor keywords, there is no interoperability problem.
However, if for the same bandwidth usage the previously reported value was 5 and the new value is, say, 7, the logic might be impacted, no?

To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.
--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.


--
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss...@googlegroups.com.

Sergio Garcia Murillo

unread,
Feb 24, 2020, 2:14:48 PM2/24/20
to discuss-webrtc
it doesn't affect remb, only transport wide cc. There is no value reported to the other side. The available bandwidth is calculated on sender taking into account the ip/rtp overhead and then set on the encoders appropriately. 

Best regards
So

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAHgZEq539BFaz3Z%3DJYYP7R3-tUtLWMDwqaYGDRHdn-nc56r4XA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages