Re: [clue] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster 238
Justin Uberti <juberti@google.com> Sat, 13 October 2018 01:08 UTC
Return-Path: <juberti@google.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344C5130E96 for <clue@ietfa.amsl.com>; Fri, 12 Oct 2018 18:08:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
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=ham 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 IDvlCY7BCuAs for <clue@ietfa.amsl.com>; Fri, 12 Oct 2018 18:08:44 -0700 (PDT)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 ABD83128766 for <clue@ietf.org>; Fri, 12 Oct 2018 18:08:44 -0700 (PDT)
Received: by mail-it1-x12c.google.com with SMTP id c23-v6so21350935itd.5 for <clue@ietf.org>; Fri, 12 Oct 2018 18:08:44 -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=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; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZvnkrFDKS2tvIfI4jJqEb63gbq43fw9zgj6Fo/uFPGQ=; b=cm7Lpn8b9ST9haKKhbEtNA1anB5pQyrl0ZdCj7c5F+5FSEl/SOBE9mqB5xIcDIHW8p Kudzl0i04vjzJEMeluNSnfBs33KVW8IPniusQR/N0jFgYOrhIQSJQ3eJhMMBWtOKYtgT MRLQgcmmFLvGb/B88mlN3AG9mYd60RhHuTuQSqtbWvJ5E4khrTl6pUvEkK1lw57IBjGZ JPd2rhLpOzW/UM70heaDRCAi5NR18XH/EjPUjzaz8gF9v3lw6+6wxioX6YT83PBamwXH o5dx6HZsCB4kPtIrTXzQmhdupFWFQbEjzD9xowUg956aMnHRT2MwKmBzRMlu4jatGNGV 8rcQ==
X-Gm-Message-State: ABuFfohBErF6LZCgIdN5JUdm8Eq1lL28XCV55/9ZIYFOWTprCCe3g+gS FMeZ7vQmcEMehTA1e+FFjCkvviwpP+Cj3XqOHIq3rQ==
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: <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> <CAJrXDUEToHCk0ERJSGMuoq+6vgySp8RsA5Ee5AZf4wOqsE_wNw@mail.gmail.com>
In-Reply-To: <CAJrXDUEToHCk0ERJSGMuoq+6vgySp8RsA5Ee5AZf4wOqsE_wNw@mail.gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 12 Oct 2018 18:08:29 -0700
Message-ID: <CAOJ7v-3mk+Qg9-dnZ+-=csOFEVwjNLVqib_NfGp_64=4HxZJNA@mail.gmail.com>
To: pthatcher=40google.com@dmarc.ietf.org
Cc: Peter Thatcher <pthatcher@google.com>, 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="00000000000060d8e5057811d87f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/60tw-1sIffNexAS5UVHlzs1Y-rU>
Subject: Re: [clue] [MMUSIC] [Ice] [art] ICE, ICE-bis, and Cluster 238
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=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= 40google.com@dmarc.ietf.org> wrote: > > > 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. > 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= >> 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 >> >
- Re: [clue] [Ice] ICE, ICE-bis, and Cluster 238 Christer Holmberg
- [clue] ICE, ICE-bis, and Cluster 238 Adam Roach
- Re: [clue] [art] ICE, ICE-bis, and Cluster 238 Charles Eckel (eckelcu)
- Re: [clue] ICE, ICE-bis, and Cluster 238 Roni Even (A)
- Re: [clue] ICE, ICE-bis, and Cluster 238 Adam Roach
- Re: [clue] ICE, ICE-bis, and Cluster 238 Roni Even (A)
- Re: [clue] ICE, ICE-bis, and Cluster 238 Adam Roach
- Re: [clue] ICE, ICE-bis, and Cluster 238 Christer Holmberg
- Re: [clue] ICE, ICE-bis, and Cluster 238 Christer Holmberg
- Re: [clue] ICE, ICE-bis, and Cluster 238 Harald Alvestrand
- Re: [clue] ICE, ICE-bis, and Cluster 238 Adam Roach
- Re: [clue] ICE, ICE-bis, and Cluster 238 Roni Even (A)
- Re: [clue] [art] ICE, ICE-bis, and Cluster 238 Christer Holmberg
- Re: [clue] ICE, ICE-bis, and Cluster 238 Cullen Jennings
- Re: [clue] [rtcweb] ICE, ICE-bis, and Cluster 238 Bernard Aboba
- Re: [clue] [art] ICE, ICE-bis, and Cluster 238 Adam Roach
- Re: [clue] [art] ICE, ICE-bis, and Cluster 238 Christer Holmberg
- Re: [clue] [rtcweb] ICE, ICE-bis, and Cluster 238 Christer Holmberg
- Re: [clue] [MMUSIC] [art] ICE, ICE-bis, and Clust… Cullen Jennings
- Re: [clue] [art] ICE, ICE-bis, and Cluster 238 Cullen Jennings
- Re: [clue] [art] ICE, ICE-bis, and Cluster 238 Christer Holmberg
- Re: [clue] [Ice] [MMUSIC] [art] ICE, ICE-bis, and… Christer Holmberg
- Re: [clue] [MMUSIC] [art] ICE, ICE-bis, and Clust… Bernard Aboba
- Re: [clue] [Ice] [art] ICE, ICE-bis, and Cluster … Nils Ohlmeier
- Re: [clue] [rtcweb] ICE, ICE-bis, and Cluster 238 Nils Ohlmeier
- Re: [clue] [MMUSIC] [rtcweb] ICE, ICE-bis, and Cl… Christer Holmberg
- Re: [clue] [Ice] [art] ICE, ICE-bis, and Cluster … Christer Holmberg
- Re: [clue] [MMUSIC] [art] ICE, ICE-bis, and Clust… Peter Thatcher
- Re: [clue] [Ice] [MMUSIC] [art] ICE, ICE-bis, and… Justin Uberti
- Re: [clue] [MMUSIC] [Ice] [art] ICE, ICE-bis, and… Adam Roach
- Re: [clue] [MMUSIC] [Ice] [art] ICE, ICE-bis, and… Peter Thatcher
- Re: [clue] [MMUSIC] [Ice] [art] ICE, ICE-bis, and… Justin Uberti
- Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE… Sergio Garcia Murillo
- Re: [clue] [rtcweb] [MMUSIC] [Ice] [art] ICE, ICE… Christer Holmberg