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

Peter Thatcher <pthatcher@google.com> Fri, 12 October 2018 15:14 UTC

Return-Path: <pthatcher@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8CA130E30 for <rtcweb@ietfa.amsl.com>; Fri, 12 Oct 2018 08:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Level:
X-Spam-Status: No, score=-17.501 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKp28mCdtDRq for <rtcweb@ietfa.amsl.com>; Fri, 12 Oct 2018 08:14:02 -0700 (PDT)
Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F92130DCB for <rtcweb@ietf.org>; Fri, 12 Oct 2018 08:13:58 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id i8-v6so12590748wmg.0 for <rtcweb@ietf.org>; Fri, 12 Oct 2018 08:13:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=etlBKbGm6Rx8jUhwiuTFvHYu0MfcO87t/ldv6ckv7zE=; b=kbBh2vZCT06dAV3ddSrKPchglwtC8qRWjrgpG1GC3QjX9AXBxSApO3aKOtzujZ1GJH NuaKnRCqMOOIKiLpGPK0amWRJB6IHtvqv0lyw6V0VrOXiQFEOWW5z9ZfJNtom9rVUMth srAF3yf6cO4smgde0l/2PxMpQUxisblBkAKKgyCCmJD0MulxYe/FnS8SVUeAZK+mM6nd A02AV7eei3jIPsSy7umZW+OCNqoRBLDTnCKdcbOj4iiCZ/ezz/JDHJ3xqztfpYQtVnHA WV2BiJHi//Y+F18B0VtqjPKvciwJluxjT2iBwYlIagr2XtbQIQQ+QfI2r1qurIdAV6O6 dUlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=etlBKbGm6Rx8jUhwiuTFvHYu0MfcO87t/ldv6ckv7zE=; b=OpntbBYDHqGdlAgE97zi1OZgqbzkFJPBe25CJhkE6S1hYJ2RTJIF2NpgBL+D3opYlG /cg3I355huQiMIXrNxz7MgDZCMaJEOfoZDouf4lg5M+slz+Cv25H74c9nDkYjqyolQ/I hMwvyN4YYK9vZomCfC9HOS8zOhwVV2GbSIt+rQSqMXzuVl8ZIKIfdyJFQbk7gljxYKPI vEuKqj8O2Jxn+7Z4tZRh7F3Ch70ZMrL2Zk1WmT7hFsR6dSCrIMYrZNcW2t6iuYjfUnnn 1h9m19N6qXScK+EDKyRAeBfX9VsMKaKHKUBbnZ8PL3eoVvuxGRN6EJWjFV+Mj/L6M9zx 5+pw==
X-Gm-Message-State: ABuFfojpb9Q5Gk/8nn7AMfL1jjGFfVnWQkUl2gk3sIojpHY2R7JIqLrh V9/RaE1Yz9RZvVRBhk1F8GRIzkwn0U8tfXND67EepA==
X-Google-Smtp-Source: ACcGV634Ej7c20K7On6ejzP2cAt8eLYIXpqP4/04vMUVSZ5LAKuB4CO37p/gwM5vXcwoWcgRzkxkf0aZRDqFdo1DeUI=
X-Received: by 2002:a1c:838a:: with SMTP id f132-v6mr5822773wmd.51.1539357236687; Fri, 12 Oct 2018 08:13:56 -0700 (PDT)
MIME-Version: 1.0
References: <15d3b114-5c04-61c4-8a62-61d8a414143d@nostrum.com> <7D1A35C5-FF09-4F93-ABA8-74D877952EF0@iii.ca> <46E40ED2-D289-4C0F-8C0B-82A5980B2692@ericsson.com> <E05D7CB4-832E-4221-ADFE-D8F317EEA8F1@iii.ca> <CAJrXDUGpmZKGQXF0p1hjQv_F=5dQoJLUCT7+6y-=uzwcRv1Ncw@mail.gmail.com> <CAOJ7v-36OvrLo1ud3Uc2Edjk1n2kmY=2bkda-w5kVMVn2QfUVg@mail.gmail.com>
In-Reply-To: <CAOJ7v-36OvrLo1ud3Uc2Edjk1n2kmY=2bkda-w5kVMVn2QfUVg@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 12 Oct 2018 08:13:43 -0700
Message-ID: <CAJrXDUEToHCk0ERJSGMuoq+6vgySp8RsA5Ee5AZf4wOqsE_wNw@mail.gmail.com>
To: Justin Uberti <juberti=40google.com@dmarc.ietf.org>
Cc: pthatcher=40google.com@dmarc.ietf.org, mmusic@ietf.org, art@ietf.org, clue@ietf.org, ice@ietf.org, RTCWeb IETF <rtcweb@ietf.org>, Cullen Jennings <fluffy@iii.ca>, Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="00000000000047047205780989dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/i5kmQWrCPPMv_8Ful0FD7zTGeTk>
Subject: Re: [rtcweb] [MMUSIC] [Ice] [art] [clue] ICE, ICE-bis, and Cluster 238
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Oct 2018 15:14:04 -0000

On Thu, Sep 27, 2018 at 4:21 PM Justin Uberti <juberti=
40google.com@dmarc.ietf.org>; 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: https://github.com/rtcweb-wg/jsep/pull/851

I've also added the ice2 processing and added ice2 to the examples in the
same PR.

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


> On Wed, Sep 19, 2018 at 9:52 PM Peter Thatcher <pthatcher=
> 40google.com@dmarc.ietf.org>; 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 <fluffy@iii.ca>; wrote:
>>
>>>
>>> On Sep 7, 2018, at 1:25 AM, Christer Holmberg <
>>> christer.holmberg@ericsson..com <christer.holmberg@ericsson.com>>; 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
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>> _______________________________________________
>
>
>> Ice mailing list
>> Ice@ietf.org
>> https://www.ietf.org/mailman/listinfo/ice
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>