IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 21 July 2017 19:33 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 003D1129461 for <ice@ietfa.amsl.com>; Fri, 21 Jul 2017 12:33:28 -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 oYcd0YqToVPG for <ice@ietfa.amsl.com>; Fri, 21 Jul 2017 12:33:26 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 B7A9C12785F for <ice@ietf.org>; Fri, 21 Jul 2017 12:33:25 -0700 (PDT)
X-AuditID: c1b4fb30-71bff70000001664-29-5972570379ec
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 67.29.05732.30752795; Fri, 21 Jul 2017 21:33:23 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.91]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Fri, 21 Jul 2017 21:33:22 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Bernard Aboba <bernard.aboba@gmail.com>, "ice@ietf.org" <ice@ietf.org>
Thread-Topic: [Ice] Re-nomination and candidate pair switching in RFC 5245bis
Thread-Index: AQHTAVLWZKFTuK8SBEu+L6K9B+u4LqJenhrQ
Date: Fri, 21 Jul 2017 19:33:23 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CC942F3@ESESSMB109.ericsson.se>
References: <CAOW+2dtaHB+3LyiN75YG6Dd9tsUFvcBWaizZUxTm1=YjMrSRdA@mail.gmail.com>
In-Reply-To: <CAOW+2dtaHB+3LyiN75YG6Dd9tsUFvcBWaizZUxTm1=YjMrSRdA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CC942F3ESESSMB109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZGbE9UJc5vCjS4MAzE4sN+/4zW3y7UOvA 5LFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZXR9W89e0JdY8f/dW8YGxj1xXYwcHBICJhIt m4u6GLk4hASOMErc/HmSDcJZzCjxobGPHaSITcBCovufdhcjJ4eIgJfEthM/mUDCwgI+Ejf/ SkOEfSWaJq5igrCNJO48nM0OYrMIqEqsWnqHGcTmBaq52T0VzBYSCJCYu7qRDWQMp0CgxIyu GpAwo4CYxPdTa8DGMAuIS9x6Mh/MlhAQkFiy5zwzhC0q8fLxP1YIW0micckTVoj6fIk3U55B rRKUODnzCcsERuFZSEbNQlI2C0nZLKArmAU0Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sq RtHi1OKk3HQjI73Uoszk4uL8PL281JJNjMCoObjlt8EOxpfPHQ8xCnAwKvHwTvAoihRiTSwr rsw9xCjBwawkwjvJFyjEm5JYWZValB9fVJqTWnyIUZqDRUmc13HfhQghgfTEktTs1NSC1CKY LBMHp1QDo/Ql7RMSNrcm3AnM9DZimHvB9ej6K4U3KlXu/QrnZxDsS2s+75+yTWhLSf4qi99V ESdkpPaqaC6c0HnhzaeuHT5TXI8xN8uoZZfPMSlf8ITDahtXhljCIocAR18DtoCXrScuLvLU bniy8fb+VT7Lg5IK3nnKss4+tLh9TdyOi7Fz5+8uPZy0TomlOCPRUIu5qDgRAAI23pOWAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/gvIqpG0c3PS6ms6YVAVYdUYA7Po>
Subject: Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis
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: Fri, 21 Jul 2017 19:33:28 -0000

Hi Bernard,

Support of 5245bis is also negotiated, using the “ice2” ICE option.

Also, my understanding was that endpoints supporting RFC 7675 might maintain consent on pairs currently not used for media, in order to be able to re-nominate in case consent for the currently nominated pair expires. However, RFC 7675 does not explicitly say anything about that.

Regards,

Christer

From: Ice [mailto:ice-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: 20 July 2017 14:22
To: ice@ietf.org
Subject: [Ice] Re-nomination and candidate pair switching in RFC 5245bis

During the ICE WG meeting today, there was discussion of whether RFC5245bis should indicate that it is possible to re-nominate pairs (proposed by Peter), or whether it is possible to switch from one interface to another (Cullen).  While these capabilities are desirable, attempting to add them to RFC 5245bis without negotiation has the potential to break interoperability with existing RFC 5245 implementations.

In my experience, this is an area where RFC 5245 implementations have very different interpretations. For example, some implementations (e.g. ones that did not support aggressive) discard non-selected candidate pairs after nomination. These implementations (e.g. particularly ones included in previous product releases) cannot be assumed to change their behavior after RFC 5245bis is published.  This raises the possibility that that interoperability could be impacted.

Since in practice the desired candidate pair switching capabilities are most likely to be supported in WebRTC implementations supporting Trickle ICE, my recommendation is to think of candidate pair switching as a Trickle ICE capability.   Since Trickle-ICE support is negotiated, clarifications relating to candidate-pair switching can be linked to that negotiation.

This provides a potential way forward that bypasses potential interoperability issues.  For example, if text on candidate-pair switching is to be added to (either to RFC 5245bis or Trickle-ICE) then the text could say that support for these behaviors can only be assumed if they are explicitly negotiated. The Trickle-ICE document could then create normative requirements for support of the new behaviors by stating that support for them is mandatory when supporting full-Trickle.

v2.23.0 | Report a Bug | By Email