webrtc-stats icon indicating copy to clipboard operation
webrtc-stats copied to clipboard

Published 20 hours ago • verified publisher icon w3c

statistics for BWE probes?

Open fippo opened this issue 5 years ago • 9 comments

webrtc.org uses either all-padding packets (when RTX is not negotiated) or RTX packets as a way to probe the bandwidth. Prior to Chrome fixing this issue at least the padding variant of this was quite visible in the statistics.

https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-headerbytesreceived is less ideal for this since this includes a linear component (the rtp header) and a burst-y one (the padding probes). I'm not sure how this would work for RTX.

Can/should we have something like bandwidthProbeCount and bandwidthProbeBytesSent / Received?

fippo avatar Dec 09 '19 15:12 fippo

image As mentioned above this is visible but it makes the graph quite hard to interpret.

fippo avatar Dec 09 '19 18:12 fippo

Not entirely sure that it's worth it, but somewhat logical that you'd want to see a separation between "header bytes that you can't avoid" and "header bytes that you can avoid by tuning BWE". But that's not the only possible purpose for padding.

I think we should recommend a PR against the experimental stats repo to add "paddingBytesSent/Received" (and find a suitable definition to link to). Stats shouldn't take a position on what the purpose of sending/receiving these bytes is.

alvestrand avatar Dec 11 '19 16:12 alvestrand

paddingBytesSent/Received... is probably the way to go.

vr000m avatar Dec 11 '19 16:12 vr000m

Two things you might want to know:

  1. How much of headerBytesSent is actual "header" versus "padding". This could be solved with a paddingBytesSent. Is this what we want to do?

  2. The other thing you might want to know is "how much bytes are sent because of probing", would a probingBytesSent make any sense?

henbos avatar Dec 11 '19 16:12 henbos

padding is just the legacy pre-"do it as rtx" way of probing so paddingBytesSent won't cut it because how do you identify probing on rtx then?

probingBytesSent and probingPacketsSent would be good

fippo avatar Dec 11 '19 20:12 fippo

If you had probingBytesSent, would you still care about the destinction between header and padding?

henbos avatar Dec 11 '19 23:12 henbos

theoretically: yes practically: padding is used by webrtc.org only for probing so... no :-)

fippo avatar Dec 12 '19 08:12 fippo

Probing can be done in several ways -- RTX, FEC, duplication of packets, padding (non-media data) etc. what is it that you are trying to measure?

vr000m avatar Dec 12 '19 13:12 vr000m

Trying to get an estimate for the BWE probe overhead (service wide) which as you say is accomplished in many ways.

Bonus: being able to visualize it live in the browser (webrtc-internals) is much easier than processing some dump after the fact ;-)

fippo avatar Dec 23 '19 17:12 fippo