Re: [Ice] Benjamin Kaduk's Discuss on draft-ietf-ice-pac-04: (with DISCUSS and COMMENT) - COMMENT

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 22 April 2020 12:16 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 357C23A0ADE; Wed, 22 Apr 2020 05:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ZKgs07ckB8Do; Wed, 22 Apr 2020 05:16:29 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10087.outbound.protection.outlook.com [40.107.1.87]) (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 112FF3A0ADB; Wed, 22 Apr 2020 05:16:28 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FaQuDDVY7qWDEFvkkI2tKdyb23Iak4OWNerkZEooPLP3ZM5EZxkrbD+LlLC+A2nsJxT+73Iq2QskaimzYIVV3zRzEbUdaw6/rpGdcMU2tkHrCt4kmKTaO+sypaCeYZiEg4d5KtkBUfq/QCPQLIA0TsxdtGbAZh1Y/KJLKVMHmSPYMSarSmCENCWJH4qk9LkG0cWWOMBHwFT0aLtz7sF2MIhk3pjShWxyqoedOPr89w6kX6k/C3Iwdxd9L7wILttOc2tUFZ26mleqnYavLdWGh2rUXxCGA0zJiwa7un+M1Y+UdeVgQExhUJYIAyZQHDSJoNXELEtMLwoH/6HSocNwZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pEl1sp1jlspnf+ay3kH6LyQn1frmGHpwvUjGSanY4AU=; b=IdnlMOsuphas1xxS82CUYb1YJXgH6OfGDqgDCMcavQm+9Od1v7CS8ToQOJZ+mFuJpvbA4OXJW1MPI9IM+a+G1P3VZpvvIKsQgReMeOcHpgT91e5H8P8gthnj5u4qffBnJ6ivqseuEJO6/gKPdRcmTAKqoUUatJbZCJXFDtO2X9Iyz3EIWtnpcgUYuoseKz1/cg1TSGNmjPAK+f7e79dCbmirk04thZ7/TEa+EXzufh924CZiJQ+gkE0oEhqPWyNF8RfJv5e9Lkc1ltSnkcjWjXoMCU2uqWcQxT6GSVa5Hbk4QgqJiYRnRSb5yetMIMC4xrmneTXYyRX32F8Tt6QWcA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pEl1sp1jlspnf+ay3kH6LyQn1frmGHpwvUjGSanY4AU=; b=FwJynByepw2f4BkpeJukiQBDgSH3XGOxuEHW1h/hNK5ANLU3bx4rhoDXl3b0ruriQwtUGVY6wMDQY2PuBuCQsVRSpXWcLTVv5iLRUVvsTAmJBSV8zAp3VgmmsSPBnWcqI1JIj6FCxMGktuFzKhHzMidvd0c1Ovw6DcuxTTfhUKg=
Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB6226.eurprd07.prod.outlook.com (2603:10a6:20b:154::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.6; Wed, 22 Apr 2020 12:16:26 +0000
Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::b929:4e5c:6b46:3ccc%7]) with mapi id 15.20.2937.012; Wed, 22 Apr 2020 12:16:26 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ice-pac@ietf.org" <draft-ietf-ice-pac@ietf.org>, "ice-chairs@ietf.org" <ice-chairs@ietf.org>, "ice@ietf.org" <ice@ietf.org>, Nils Ohlmeier <nohlmeier@mozilla.com>
Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-ice-pac-04: (with DISCUSS and COMMENT) - COMMENT
Thread-Index: AQHWGJ/Y4A/WcviANkSOtezds/34Xg==
Date: Wed, 22 Apr 2020 12:16:26 +0000
Message-ID: <D2659A05-4833-4A07-B512-7143025CCB81@ericsson.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [188.127.223.154]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e64932d9-2b31-4819-e1dc-08d7e6b6faff
x-ms-traffictypediagnostic: AM0PR07MB6226:
x-microsoft-antispam-prvs: <AM0PR07MB6226EE5E408B819254B2A4F993D20@AM0PR07MB6226.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03818C953D
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR07MB3987.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(39860400002)(346002)(396003)(366004)(36756003)(110136005)(76116006)(2616005)(33656002)(66476007)(66946007)(64756008)(26005)(4326008)(6486002)(54906003)(66556008)(66446008)(186003)(44832011)(478600001)(2906002)(8676002)(81156014)(8936002)(316002)(66574012)(71200400001)(6512007)(6506007)(86362001)(5660300002); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: fnVGznZIczFZghbo5QremyDGNxOMeE/Uots4q8jAKjPt2qn0tfneUUVzdtRlq++Q51J/EYs7Rbb7s6EeyrSCsB0mApvybhrz8zQPCju7H+zlF7zFqGnKQx7qWAetgp7WfNsiFttflfOy8hbGAaYlxs3dQwuTD0I133hNhLUVHjNxsjePDQ7RvonJCA9xwc6CVTzGHK0og2QUDxH/GqI3nfyYIKivylb7K5sn7iOlnCRwK71kcaW/6v4Z8ipTbsLTjeHJcRw9CIJqy5scvFl99PSpnTTiJ551y2LqBhLhyCZOzehs/bCvevE9R0PY/wj625QZX4czZLIvkMSVzr6XUL6hPUV+y/+wmbf6um1rIx62talIyHoi6eVtnaSmuuMWnOqAgzBHlDM46gPsYoj4jhiwV0LRVK/aZoospRYuS6gYM3cNaQL8lTYa/XabrDBK
x-ms-exchange-antispam-messagedata: aSIeQASdQzFyGprioqpJAoJNyqToQwZcX1tQK9M+y+EXRkVboYnZY9qiHGrvR68ij03NpnEilktztifJlZtr74ZkTeao02SyBW7Tjtg2JDyyQW4lfkw8W73SJHh0NJ0lN0w3zc1yTXi9ZbilQbstpQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <3AB196A2E7FC994A8ED6A92E1EFE79B6@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e64932d9-2b31-4819-e1dc-08d7e6b6faff
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2020 12:16:26.4974 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: H/+0QJQ6z8jvuSy6gMG1xtr6McGG0xFAr95FjdxL9gDqEkGSiq36k4Fzwxhy7GT1F3VH3ROJwSptSeEX4W/CeMfpmu+NJeHwrHObc3saZuM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6226
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/53f5L-HnmSCLkGjAl2ZKUAXDmwA>
Subject: Re: [Ice] Benjamin Kaduk's Discuss on draft-ietf-ice-pac-04: (with DISCUSS and COMMENT) - COMMENT
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 22 Apr 2020 12:16:31 -0000

Hi Benjamin,

In this reply I will address your COMMENT issues.
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
>    [I also had Éric's question about the Updates relationship, so thanks for
>    that thread.]
>    
>    Section 4
>    
>       While the timer is running, the ICE agent MUST NOT set the state of a
>       checklist to Failed, even if the checklist has no pairs left to
>       check.  As a result, the ICE agent will not remove any data streams
>       or set the state of the ICE session to Failed as long as the timer is
>       running.
>    
>    This is, IIUC, the crux of the Discuss point -- how does this affect Setion
>    7.2.5.4 of RFC 8445?
  
Please see my other reply. Section 7.2.5.4 is what the draft modifies.
  
---

>       When the timer eventually elapses, the ICE agent MUST resume typical
>       ICE processing, including setting any checklists containing only
>       Failed pairs to the Failed state, as usual, and handling any
>    
>    I don't think "containing only Failed pairs" is exactly the criterion used
>    by RFC 8445.
  
Correct. 

What about the following suggested text:

   "When the timer eventually elapses, the ICE agent MUST resume typical
   ICE processing, including setting the state of a checklist to Failed if there
   are no pairs left to check,  and handling any consequences as indicated
   in [RFC8445], Section 8.1.2.  Naturally, if there are no such checklists,
   no action is necessary."

---

>       One consequence of this behavior is that in cases where ICE should
>       fail, e.g., where both sides provide candidates with unsupported
>       address families, ICE will no longer fail immediately, and only fail
>       when the PAC timer expires.  However, because most ICE scenarios
>       require an extended period of time to determine failure, the fact
>       that some specific scenarios no longer fail fast should have minimal
>       application impact, if any.
>   
>   Are there any scenarios that are guaranteed to fail both with and without
>    PAC that could be special-cased to still fail fast?  (The example given of
>    "unsupported address families" does not seem like it is one, off the top of
>    my head.)
  
ICE-PAC does not guarantee success. ICE-PAC only makes an ICE agent wait for additional candidates in cases where it currently would declare Failure, but such additional candidates may of course never come.

Also, as described in Section 8.1.1 of RFC 8445, and ICE agent can decide to terminate the ICE processing whenever it wants, and it could of course do that before there are valid pairs for all streams - no matter if the PAC timer is used or not. But, ICE-PAC addresses that in the last paragraph of Section 4 (related to your comment below).

---
  
>       MAY use the PAC timer to do so.  As always, the controlling ICE agent
>       retains full discretion, and MAY decide, based on its own criteria,
>       to nominate pairs prior to the timer elapsing.
>    
>    nit(?): I'd consider going with "PAC timer" again here at the end of the
>    sentence.
    
I can do that.

---
    
Regards,

Christer