Re: [Ice] Peter's review of ICEbis - removal of lower-priority candidate pairs (5.1.2.5)

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 29 May 2017 06:13 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 E4A551292F5 for <ice@ietfa.amsl.com>; Sun, 28 May 2017 23:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.322
X-Spam-Level:
X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 YQSI1iCo-0KT for <ice@ietfa.amsl.com>; Sun, 28 May 2017 23:13:21 -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 80C3F128DF3 for <ice@ietf.org>; Sun, 28 May 2017 23:13:21 -0700 (PDT)
X-AuditID: c1b4fb30-4163b9a0000007db-15-592bbbff3a18
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.8B.02011.FFBBB295; Mon, 29 May 2017 08:13:19 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0339.000; Mon, 29 May 2017 08:13:19 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Peter Thatcher <pthatcher@google.com>, "ice@ietf.org" <ice@ietf.org>
Thread-Topic: [Ice] Peter's review of ICEbis - removal of lower-priority candidate pairs (5.1.2.5)
Thread-Index: AQHS2EKqcQ1YVitsS0inpnvCjV/idA==
Date: Mon, 29 May 2017 06:13:19 +0000
Message-ID: <D5519609.1D367%christer.holmberg@ericsson.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.19]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2AEAD88C925E9B4B82A8B7B6693687CC@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2J7uO7/3dqRBq8/Klh8u1BrcW35a1YH Jo8Fm0o9liz5yRTAFMVlk5Kak1mWWqRvl8CVcWTCTeaCYxwVkz+1MjcwXmTrYuTkkBAwkdj8 +DNLFyMXh5DAEUaJzRe+gyWEBBYzSvx6KtTFyMHBJmAh0f1PGyQsIuAhsfnNcrASYYFkia2z NjGClIgIpEjsPVYGUaIn8eHdDHYQm0VAVeLHyeXMIDavgLXE4fevwGxGATGJ76fWMIHYzALi EreezGeCOEdAYsme88wQtqjEy8f/WEHGiwLNfLffEyKsKNH+tIERolVHYsHuT2wQtrVEV8dJ qLi2xLKFr6HWCkqcnPmEZQKjyCwk22YhaZ+FpH0WkvZZSNoXMLKuYhQtTi1Oyk03MtJLLcpM Li7Oz9PLSy3ZxAiMjoNbfhvsYHz53PEQowAHoxIPL8d67Ugh1sSy4srcQ4wSHMxKIrxTy4FC vCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1MEZvZ+R32za/ M3SPX2HMsbxo961Vs9r6mnf5JaU8773No39zuTdXbUed0HHumKPnn74NvRa6ku1HiY/tJ9Wb Nxs3i3wVFqmr9JM0cNnx81Tuuc0PVGZZfYmakHNN9vUc+yfro057ScatDGLmvTT39q2tfFds Im/Z2d0trvyQ9l24tPvwiuaMAiWW4oxEQy3mouJEAIk6dcGKAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/IQSwaxumnAt5ipTlN1zinfbVmrs>
Subject: Re: [Ice] Peter's review of ICEbis - removal of lower-priority candidate pairs (5.1.2.5)
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: Mon, 29 May 2017 06:13:23 -0000

Hi,

> - If we remove lower-priority candidate pairs across check lists, what
>happens if a certain check list is starved because all of its candidate
>pairs are lower priority?
> One option might be to say the limit is per check list.  Another is to
>recognise that it might happen but live with it.

My understanding was always that the limit is per check list, but I agree
it may not be very clear.

Perhaps we could modify the text as below:

   In order to limit the attacks described in Section 15.4.1, an agent
   MUST limit the total number of connectivity checks the agent performs
   across all CHECK LISTs to a specific value, and this value MUST be
   configurable. A default of 100 is RECOMMENDED.  This limit is
   enforced by, within each CHECK LIST, discarding the lower-priority
candidate 
   pairs of that CHECK LIST, until there are less than a total of 100
candidate 
   pairs in the CHECK LIST SET. The discarding of candidate pairs SHOULD be
   distributed equally throughout the CHECK LISTs in the CHECK LIST SET.


Regards,

Christer