Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 31 August 2017 06:53 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85D913201E for <ice@ietfa.amsl.com>; Wed, 30 Aug 2017 23:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level:
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 j9QwsGPhF1JQ for <ice@ietfa.amsl.com>; Wed, 30 Aug 2017 23:53:16 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2CAA1321EC for <ice@ietf.org>; Wed, 30 Aug 2017 23:53:15 -0700 (PDT)
X-AuditID: c1b4fb25-d31059c000005333-05-59a7b25adde7
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 94.B0.21299.A52B7A95; Thu, 31 Aug 2017 08:53:14 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.194]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 08:53:13 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Bernard Aboba <bernard.aboba@gmail.com>, Peter Thatcher <pthatcher@google.com>
CC: "ice@ietf.org" <ice@ietf.org>
Thread-Topic: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL
Thread-Index: AdMGx5vayPULxOekRUuarjHzPdbbFQayu7YAAAG4ewAAAKDJgAAAEW8AAAQIgIAABU5kgAABNrAAABoZ1YA=
Date: Thu, 31 Aug 2017 06:53:12 +0000
Message-ID: <D5CD8D5A.20C78%christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B4CC9ED94@ESESSMB109.ericsson.se> <CAJrXDUHGYkivt5+dnX48C8TkR9W7afoUWAPv8+MbafYNsZsFmA@mail.gmail.com> <CAOW+2duR54wenv088kZSmKJj56u8j=Qi6KzNUNrjA0=o5qhekg@mail.gmail.com> <CAJrXDUEKWCa7GsL_bSrdvVN-erROSgHJt5DO5VOZ2Qx3PQr15g@mail.gmail.com> <CAJrXDUH6vvauP8Bj2k+e5B=reTM=5C+vwD0+WidtdTRW5MpdAA@mail.gmail.com> <0447726F-82C7-43D8-99AE-5B72F0B55B6C@gmail.com> <CAJrXDUEW_N+hyceuMN_j=pA36cN69qYQzDuNoOVXuS9uuBcDtA@mail.gmail.com> <90DEFADE-5113-488A-9C0F-2073681D94B1@gmail.com>
In-Reply-To: <90DEFADE-5113-488A-9C0F-2073681D94B1@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.4.170508
x-originating-ip: [153.88.183.16]
Content-Type: multipart/alternative; boundary="_000_D5CD8D5A20C78christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsUyM2K7sW7UpuWRBh+O8Fts2Pef2eLbhVqL a8tfszowe+ycdZfdY8GmUo8lS34yBTBHcdmkpOZklqUW6dslcGXs+2xR0GVXcWzhZ/YGxrkm XYycHBICJhKP5x5m6WLk4hASOMIocf7eQXYIZwmjxM4Fv5i7GDk42AQsJLr/aYM0iAiESLyb fogVJMwsoCjxcq8aSFhYIFLi4/yHYGERgSiJt5syIaqTJD5vm8cCYrMIqEqceNgFNpBXwFqi o9sSYtE0Fonpe8+ygMQ5BWwljl5NAClnFBCT+H5qDROIzSwgLnHryXwmiIsFJJbsOc8MYYtK vHz8D2yrqICexLv9nhBhRYmdZ9uZIVoTJJa3zwezeQUEJU7OfMIygVF0FpKps5CUzUJSBhE3 kHh/DiLOLKAtsWzhayhbX2Ljl7OMELa1xIdj+1DULGDkWMUoWpxanJSbbmSsl1qUmVxcnJ+n l5dasokRGI0Ht/xW3cF4+Y3jIUYBDkYlHt5Vi5ZHCrEmlhVX5h5ilOBgVhLh3bQOKMSbklhZ lVqUH19UmpNafIhRmoNFSZzXcd+FCCGB9MSS1OzU1ILUIpgsEwenVANjppcT05rglgz3DP33 q9df3PC4W7ogh3Uro9sk6T1GU98FbXE6+jyj+z/TpKktSdYS/3Wf/Gd8nvH6Q81ts76Q53o3 Px7S5yuwfL/yl1b5Yl2HFEH28DYtWfuF2406d24o19ITYpl043/1ZqWnPpk3PHONpr+b5rSy psDnfEfme0f7zXu3vZ2txFKckWioxVxUnAgApRDmQcICAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/yZvYirMsS8oQkixGn6Fyd9uvdvA>
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" <ice.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ice>, <mailto:ice-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ice/>
List-Post: <mailto:ice@ietf.org>
List-Help: <mailto:ice-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ice>, <mailto:ice-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Aug 2017 06:53:18 -0000

Hi,

>The problem as I understand it is that RFC 5245bis is intended to be usable by non-WebRTC implementations, so it cannot mandate (or even mention??) consent.

Correct.

However, one option would be to require consent in order to do switching. Then, before the switching takes place, an endpoint would have to get consent. And, if the remote peer has released the candidate the consent would fail, and the switch can’t be done.

>If this seems silly to you (it does to me) maybe it would make more sense to assume RFC 5245bis is for use in a modern ICE implementation usable with WebRTC, because after all, isn't that what ICE developers should be working on???

I think we also want “legacy” implementations, that previously used non-ICE mechanisms, to migrate to ICE.

Regards,

Christer



On Aug 30, 2017, at 4:55 PM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:



On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>> wrote:
On Aug 30, 2017, at 12:28 PM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:
On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> wrote:
As far as "just enough" so that it isn't a hindrance: that's why I wanted to say that agents *may* switch.  It allows a renomination in the future.  Saying they MUST NOT is a hindrance.  I would be fine if the *may* requires negotiation.  That's what https://www.ietf.org/archive/id/draft-thatcher-ice-renomination-01.txt does: it negotiates "renomination".  And that's what Chrome's implementation of WebRTC does.

[BA] It seems like the document would at least need to talk about consent to include a "may". As it is, negotiating "ice2" only means that you're talking to a slightly refurbished RFC 5245 implementation. That's like the difference between a new car with driver assist (a modern WebRTC ICE implementation with Trickle) and an Edsel that's been waxed and given an oil change.

You always need to have consent to use a candidate pair.  I guess the question you're asking is how recent does the consent need to be.  But I'm not sure we need to standardize that.  If an implementation chooses to be too aggressive about switching, it will send a path that doesn't work.  In your analogy, you're worried about the driver assist doing something dumb and crashing into the Edsel.  Well, don't ship a car that crashes.  Do we need to standardize "don't switch to a candidate pair that doesn't work" (AKA don't crash)?