Re: [rtcweb] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238

Peter Thatcher <> Thu, 20 September 2018 04:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAE0A130EA2 for <>; Wed, 19 Sep 2018 21:52:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JngYbXxNGtnX for <>; Wed, 19 Sep 2018 21:52:41 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70534130E25 for <>; Wed, 19 Sep 2018 21:52:35 -0700 (PDT)
Received: by with SMTP id y8-v6so4252260wrh.7 for <>; Wed, 19 Sep 2018 21:52:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MuCBrULxlSFkTCiYIgkvDiJKQTD4FDrSzEewPifyWeY=; b=PNnzdO4ImT1yJAa8wsVbKaNCD5HHOvFoqOlFYh9dh0H/7BgekqmXTkxCT5v5KqOO6w 9xgkXY93hZGW+JvshbzMlSrA9o4PxyGvyQbzQlo7BVYXghVEVCHSj2aD42/zyPhMytQ5 vUQgqXswsdCdScq9v3UAylal48yXkxN3F98S1YkTnLnB8XjSSM+PYNiYRXR/Bv9zzN1Q 2SxQY2DsOQix3lV9oVvxsJ5u4T6UGXoiHR43dDhuWbldXK+TT6WRFPqI3wsaY9r97QrW zwfv7718SdJBHy1bhiIooG71fmSA0EryF3D7eVsav4baKN7Y0l6g0RsoAhMAIjf5XzAY FXOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MuCBrULxlSFkTCiYIgkvDiJKQTD4FDrSzEewPifyWeY=; b=Q29926VFCWxng/tp0aaRb9RQ7eyWx4oFse7yLiqusWd5OoF2EfUL4DZJwBfeBtIZLm Ctnqi6ogWDvNPeVah7IgqLXpWGTmdACO/IZAPkrjJe+3IIsFH+LeaOW7z1GSut2tBP0T qsuyENSClJHLrJUgqL4fpaGNS4V3m67AECtbrUJnDHqLc/NhRLsC2r4cEPnZU8/tevau OT702q9G4qMs6kJdpg2A0r0C7I+kJgJHa03h05IK/bXArhddNIn8+sStiLTb5qbgmu5E 5aGUUWrzmzojk2NfVGBKePg070lr5yeQikXpP/bV/lZCP0ZS7bWlYItnJXfOp2HmizJd mQpA==
X-Gm-Message-State: APzg51BdGi2pO67R81VTCU7fn92TCTy9XqgMvR1qwF4TTqtTxS3fVZ1u KbhRLQ26H+3SnvVcyNuGGH79YfwpBl/gHEZLfAigBQ==
X-Google-Smtp-Source: ANB0VdaazlvlTrF083O2W9DQETWh6MRrRK5ljik/DMMJTZBB06GJwgxPftH6IBFbsrdEbpJN89kFtzpEzTQLTzU2M0c=
X-Received: by 2002:adf:b3d7:: with SMTP id x23-v6mr30300083wrd.253.1537419153508; Wed, 19 Sep 2018 21:52:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Peter Thatcher <>
Date: Wed, 19 Sep 2018 21:52:20 -0700
Message-ID: <>
To: Cullen Jennings <>
Cc: Christer Holmberg <>, Applications and Real-Time Area Discussion <>, "" <>, "" <>, "" <>, RTCWeb IETF <>
Content-Type: multipart/alternative; boundary="000000000000847f730576464ad5"
Archived-At: <>
Subject: Re: [rtcweb] [MMUSIC] [art] [clue] ICE, ICE-bis, and Cluster 238
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Sep 2018 04:52:51 -0000

I'm late to the discussion, and reading through it, it seems that we have a
lot of back and forth without addressing Cullen's root issue.  Let me see
if I understand Cullen's root issue correctly.  I think it's something like:

1.  Cisco has existing code that it wants to call "WebRTC 1.0 compliant"
without changing to be compliant with 8445.

2.  Cisco has existing code that it wants to continue to interoperate with
endpoints, especially Chrome, even as they make changes to become 8445
compliant.  And they don't want to have to test against old and new

Cullen, is that accurate?

OK, so some of my thoughts:

1.  I don't think there is any interop risk here at all related to
timings.  If you're worried about the drop in minimum check interval going
from 20ms to 5ms, don't.  Just because the spec allows for going that low
doesn't mean endpoints will.  And if they do, they'll do it carefully.
Endpoints can and should still choose a value that works best regardless of
the min in the spec.  For example, Chrome is still using an interval of
48ms (we're not in a rush to lower it, but we have non-browser endpoints
that do go lower).  And if we roll out a lower value, it will be via
experiments or opt-ins and carefully tracked to make sure connectivity
rates don't drop.  If any problem were found in practice, it would be
quickly reverted.

2.  I don't think there is any interop risk here related to nomination
Chrome's default behavior has never been compliant to any spec anyway, and
it's never been an issue.  And like with ping intervals, any changes to
implementations will be done slowly and carefully.

3.  I don't think it really matters to major implementations what the
dependency graph looks like.  Whether some point to 5245 and others to 8445
or if all of them point to 8445, it doesn't matter, implementations will
behave the same either way.  Chrome, for example will adjust timings as
works well in practice (perhaps someday to below 20ms interval) regardless
of which RFCs point to 8445 and which point to 5245.  If interop issues
ever do come up, then they can be fixed.  And that has nothing to do with
which RFCs point to 5245 and which point to 8445.

5.  You're going to need to test against different versions of different
browser no matter what the RFC references are.  ICE timings and nominations
seem like the least of your testing problems.  But on the flip side, Chrome
(and I assume other browsers) have been very slow and careful when making
changes to the ICE code.

6.  FlexICE should go a long way to putting the web app in control of the
ICE behavior.  So if you are worried about what browsers will do with ICE,
I suggest supporting the FlexICE effort.  In fact, it's the result of your
proposal at TPAC in 2017 for wanting to have lower-level of control of
ICE.  If we get that into all the browsers, you won't have to worry any
more about any of this because you'll be in control (assuming you control
the web app).

Altogether, I don't see any reason to not reference 8445 everywhere, at
least not any related to interop risk and web browsers.

On Fri, Sep 7, 2018 at 9:37 AM Cullen Jennings <>; wrote:

> On Sep 7, 2018, at 1:25 AM, Christer Holmberg <
>>; wrote:
> > Cisco has implemented stuff that is WebRTC 1.0 compliant without this
> change. These gratuitous changes, years after the implementation were
> coded, with no real benefit will ensure that we are not
> > and will not become compliant with the RFC. It's unlikely we will
> upgrade to the new ICE until it has real befits.
> The main reason we did 8445 was because people had identified issues with
> 5245. The work was driven mostly by the WebRTC community, including
> yourself and the Chrome people (or, at least the Google people), and one of
> the reason it took time to finalize 8445 was because you (among others)
> wanted to make sure we get things right (by making network measurements
> etc). Are you now saying all those changes bring no benefit? Did we all
> waste our time?
> Our testing, which we do not share, dig not indicate an improvement of
> connectivity rates. I did not see results from others that did. Some of the
> early test results from others that drove this work were not reproducible
> in our testing. The one thing I think most people did find is that the more
> out of sync the pacing of the two agents was, the worse the connectivity
> was. But all of this is water under the bridge, we have old and new ice,
> people can use either. What we are talking about here is what is the
> minimum bar for WebRTC 1.0
> > It is doubtful Justin will want to implement the 8445 mechanisms of
> supporting both new and old ICE. Instead, we will move to say "works with
> Browser X version Y or later." We have watched at W3C as it moved to be
> that unless chrome does it, it rare that it becomes a standard.
> > Right here I am watching how the stuff IETF defines will be less
> relevant than the issue of what chrome implements.
> What exactly would Justin have to change?
> For us, the largest part is having to test for both old and new - it’s not
> easy to do good automated testing for ICE.
> _______________________________________________
> mmusic mailing list