I'm not sure an enterprise policy is appropriate - I see the same
problem with sunsetting the policy as with sunsetting the stat in
general, and usage of enterprise policies is (as far as I know)
far more opaque to us than origin trials or Finch feature usage.
On Mon, Jan 30, 2023 at 11:13 AM Henrik Boström
<h...@chromium.org> wrote:
On Friday, January 27, 2023 at 7:24:58 PM UTC+1 Johnny
Stenback wrote:
Is there an enterprise policy in place for this deprecation
already? If not, adding one seems appropriate given the
challenges of rolling out even simple fixes in some
enterprise environments.
One does not exist at the moment but I can add one
<https://chromium.googlesource.com/chromium/src/+/HEAD/docs/enterprise/add_new_policy.md>.
Thanks,
Johnny
On Fri, Jan 27, 2023 at 5:16 AM Henrik Boström
<h...@chromium.org> wrote:
Delaying the enabled-by-default to M112 is fine by me but
I'll wait for a resolution here before taking action.
Currently it is enabled-by-default in Canary.
On Friday, January 27, 2023 at 12:41:23 PM UTC+1
philipp...@googlemail.com wrote:
Am Fr., 27. Jan. 2023 um 11:49 Uhr schrieb Henrik Boström
<h...@chromium.org>:
*Contact emails*
h...@chromium.org, h...@chromium.org
*Background*
I attempted to remove this feature before but had forgotten
to file an intent to deprecate, background here
<https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/>.
*
*
*Specification*
The getStats() API spec is here
<https://w3c.github.io/webrtc-stats/> and it contains all the
metrics. The deprecated metrics are also listed, but in the
obsolete section
<https://w3c.github.io/webrtc-stats/#obsolete-rtcmediastreamtrackstats-members>.
There's an open issue to remove obsolete metrics from the
spec as soon as they are unshipped from modern browsers. This
is considered a blocker for the document to reach Proposed
Recommendation status.
*
*
*Summary*
WebRTC is a set of JavaScript APIs (spec
<https://w3c.github.io/webrtc-pc/>) that allow real-time
communication between browsers. For the relevant metrics
being removed, we're only talking about the WebRTC use case
that is sending or receiving audio or video (typically Video
Conferencing use cases), not the data channel use cases that
is a popular WebRTC use case, since data channel only use
cases would never have any tracks/streams.
*
*
RTCPeerConnection.getStats() returns a map of
string-to-objects, where each object is one of the
dictionaries defined in the stats spec. The reason an app
calls getStats() is mostly to report quality metrics (send
and receive resolutions, bitrates, glitches, video QP, etc)
which can be important for A/B experimentation. It can also
be used in a way that impacts app logic or even UX inside the
app. Most common use case I can think of: poll getStats() at
10 Hz and render volume bars for each participant based on
volume levels from stats objects.
The deprecation in question is to remove some stats objects
that were made obsolete several years ago: all metrics on the
"track" dictionary have been moved to non-obsolete objects
("inbound-rtp", "outbound-rtp", "media-source"). Reasons for
wanting to deprecate include:
* Spec-compliance: needed for browser implementations to
align and for the spec to become Proposed Recommendation.
* Web compat: Firefox never implement "track" or "steam"
<https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental&label=master&aligned>
due
to them being obsolete.
* Performance: the duplicated metrics make up ~40% of the
stats report size, which can be a significant number of
bytes in larger meetings and it is common for apps to
poll getStats() 10 times per second.
* Tech debt: unblock removal of 1400 LOC.
In the meantime, the obsolete metrics is duplicated in
several places of the stats report.
*
*
*Risks*
*- Impossible to properly measure usage*
Because stats objects are exposed as JavaScript dictionaries,
and because apps have to iterate all objects of the stats
report in order to find the ones they are interested in or if
they just dump all the data without filtering, there is no
way to measure how big the dependency is on track in the real
world.
*
*
While we lack use counters, we have some positive signs:
* Because Firefox does not have "track" or "stream" stats,
any app that can run on Firefox already exercises the
paths of these not existing.
* An experiment to "unship deprecated metrics" has been
running at 50% Canary since October
<https://groups.google.com/a/chromium.org/g/blink-dev/c/RsIktnGhHqw/m/3iqjODsMBwAJ>,
giving developers testing Canary a heads-up. Nobody
complained until the experiment reached Stable.
* We got to 50% Stable in M109 and while we're in the
process of rolling it back now due to breaking
twilio-video.js
<https://github.com/twilio/twilio-video.js/issues/1968>,
it's interesting to note that this is the only breakage
we are aware of (that does not mean there aren't more
breakages, but I believe this at least says something
about the severity).
*- Selenium et al typically starts browsers from fresh
profiles and hence does not know the finch trial seed*
The most likely explanation for breakage is not testing
Canary or test environments not having access to Finch
experiments. This makes the behavior on Stable a surprise.
*- To have a Reverse Origin Trial or not to have a Reverse
Origin Trial?*
Migrating should require so few lines of code (look for
stats.type == 'inbound-rtp' instead of stats.type == 'track',
for example) that it seems to be a bigger hurdle for a
developer to enroll in the trial than to simply fix their code.
*
*
*- Compatiblity risk*
There is one particular metric out of all metrics that, if
you run Safari, does not exist on "inbound-rtp" yet. This can
be a problem, but again is probably not a big problem because
this particular metric was never implemented on Firefox so
apps already need to survive without it, and it is very easy
to write a fallback path for the Safari case:
let trackIdentifer = null; // In Firefox this will never be
set regardless.
if (inboundRtp.trackIdentifier) {
// Spec-compliant browser.
trackIdentifier = inboundRtp.trackIdentifier;
} else if (inboundRtp.trackId) {
// Fallback-path for Safari or 1+ year old Chromium browsers.
trackIdentifier =
report.get(inboundRtp.trackId).trackIdentifier;
}
*
*
*Proposal*
Rollback to 0% Stable but keep the "unship deprecated"
experiment at 50% Canary/Beta. Wait for Twilio to fix their
issue and do another rollout attempt. Keep a slower rollout
pace next time.
I see limited amount of value in a Reverse Origin Trial since
it appears to be more effort to register to the trial than to
fix the issue, if you are affected.
I do prefer to have the feature enabled-by-default in M111+
and overwrite that default via Finch rather than the other
way around as to not "turn off the fire alarm" for non-Finch
testing environments. I realize that is not perfect (what if
you run in a non-Finch environment) but it would reduce
overall risk.
Thank you Henrik. I agree with one suggestion: only do
default-off in M112+ (which is branching so you would just
need to revert this commit
<https://chromiumdash.appspot.com/commit/3a4d52f365df03413a856ea20366b36e8fb8ea0b>
on
the M111 branch).
This gives developers another month to update (which itself
should be quick) and then rolling it out to their customers
and users (which takes time).
I hope that the 50% rollout caused enough incidents (even
though you may never hear about some of them) to get the
fixes in ASAP.
cheers
Philipp
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ecf1ea6-c16c-464a-b529-439e05e4feedn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5ecf1ea6-c16c-464a-b529-439e05e4feedn%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+unsubscr...@chromium.org
<mailto:blink-dev+unsubscr...@chromium.org>.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a0b5bb9-addd-4a56-b053-1429bbaabe2dn%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a0b5bb9-addd-4a56-b053-1429bbaabe2dn%40chromium.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVG_P0ji6Z-n0DoCua4nzJZN7S48o23%3DUpx_ELerqphfUg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVG_P0ji6Z-n0DoCua4nzJZN7S48o23%3DUpx_ELerqphfUg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
