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

Justin Uberti <> Sat, 13 October 2018 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50F44128766 for <>; Fri, 12 Oct 2018 18:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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, URIBL_BLOCKED=0.001, 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 ePL-xfp2LGYw for <>; Fri, 12 Oct 2018 18:08:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B089A130934 for <>; Fri, 12 Oct 2018 18:08:44 -0700 (PDT)
Received: by with SMTP id w200-v6so20620385itc.4 for <>; Fri, 12 Oct 2018 18:08:44 -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=ZvnkrFDKS2tvIfI4jJqEb63gbq43fw9zgj6Fo/uFPGQ=; b=HY9k6sPH8AwHFqiTqDrKoZrt2+oiGv4wnkLgO2EJ2X+Xwe/NuVMJLDF+BXs+8UVrqv OwU35yytFJ8BahZEQqzcm9ClCZEbzJeGmaZChOncxBqwIx+W6ML5SIIwgeIKjOZ2wMZ0 VC9z0R0oRWHcN3al4nNBQbf0xNBFhQqlb6LfxhauoHaic/0AlPJWfFjDtaa2k8Kgl0Mi C/8RLksxpqFvp6+qA6WsMwF4mMihJoByhUVTrWDJ8UGq9his1q39j7Udy4uXTj/l0UcY C3Gt0B9GxReliBZP1hCPfYgk2GLqzC5c6TRc7qfCdWyaqMEzFr1iRjOjV/A+8fkG1FwR JiaQ==
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=ZvnkrFDKS2tvIfI4jJqEb63gbq43fw9zgj6Fo/uFPGQ=; b=n2mVf7f0nayO+4lltqFssJUu73tAWn17mYouNrFEGPnGjFNZG749UbkWJ0W0BTQPUD ByWK4BXj/DYOHMiZ/z0/7sOMYP2bSOTELoY1NK9zDWgX5IP//K43i52NlgzBIDJS8ylf JzFASlGy6aJwGzWZJx7TBveozxzC2fL9hf4Hs8XythZ8cafljSDBYDf/EHhJO5i0o8GR 2UF3iN6LkxygJHxvfTfNeJ99s4wd7z+4yK2LR6ATjT/kyHaDVzLNoDr/WCNUups417JT qOa0/BlQnogEgeLfRSl5HtVVZAfccMguHDYhy11vvK88+BIU+b1xtP2pEvua0qtdQQKE O9Wg==
X-Gm-Message-State: ABuFfogCUK0BffKdlO+roJzWyKROxftvEvmGQOR8Zt5GCGptJsw+1LBu ygb7H/n8y/IZn4FOmIheWNA242cj6ckLDuO8GeNGSw==
X-Google-Smtp-Source: ACcGV63ndaLILfkWGr55imIClvCOJ3JtTzCJeZ4VsYmNIX8q2gBRPm1dEyM+CcrCiwJIiVQ5Ia89iSVo6PHpklJ2piM=
X-Received: by 2002:a24:fc02:: with SMTP id b2-v6mr6257023ith.45.1539392923522; Fri, 12 Oct 2018 18:08:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Justin Uberti <>
Date: Fri, 12 Oct 2018 18:08:29 -0700
Message-ID: <>
Cc: Peter Thatcher <>,,,,, RTCWeb IETF <>, Cullen Jennings <>, Christer Holmberg <>
Content-Type: multipart/alternative; boundary="00000000000060d8e5057811d87f"
Archived-At: <>
Subject: Re: [rtcweb] [MMUSIC] [Ice] [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: Sat, 13 Oct 2018 01:08:47 -0000

On Fri, Oct 12, 2018 at 8:14 AM Peter Thatcher <pthatcher=>; wrote:

> On Thu, Sep 27, 2018 at 4:21 PM Justin Uberti <juberti=
>>; wrote:
>> I agree with Peter. Chrome's implementation is already closer to 8445
>> than 5245, so I don't see any issues associated with snapping this cluster
>> to 8445 (aside from the work involved).
>> On that topic, note that JSEP will need a few more changes than just the
>> addition of the 8445 reference and note; the examples will have to be
>> updated, as will the logic regarding generation of offers and answers and
>> their parsing (to deal with the new ice-option). These changes will be
>> modest but probably will need to be done by the authors.
> I've updated the references to 8445 (and to draft-ietf-mmusic-ice-sip-sdp)
> in this PR:
> I've also added the ice2 processing and added ice2 to the examples in the
> same PR.

Thanks for doing this, Peter.

> What did you mean by "and note"?  Is there something more needed?

The note in question is the text that Adam mentioned in the original email:

*While this specification formally relies on [RFC8445], at the time of its
publication, the majority of WebRTC implementations support the version of
ICE described in [RFC5245], and use a pre-standard version of the trickle
ice mechanism described in [RFCXXXX]. The use of the "ice2" attribute
defined in [RFC8445] can be used to detect the version in use by a remote
endpoint and to provide a smooth transition from the older specification to
the newer one. *

I do think we need text similar to this to be added to S 5.11 (processing
an answer) in JSEP.

>> On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher <pthatcher=
>>>; wrote:
>>> 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
>>> versions.
>>> 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
>>> either.
>>> 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
>>> _______________________________________________
>>> Ice mailing list
>> _______________________________________________
>> mmusic mailing list