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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 24 April 2020 07:37 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 015783A0E50; Fri, 24 Apr 2020 00:37:36 -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 FjOsFPNIdQRs; Fri, 24 Apr 2020 00:37:34 -0700 (PDT)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30072.outbound.protection.outlook.com [40.107.3.72]) (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 443633A0E4D; Fri, 24 Apr 2020 00:37:31 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ly4vjj44zc1tUckme1ZOKF2u8VR3/mGf79Arq4NIB5HZVACcePVBPZU25BUtFN7Nxl5+/T1x4wT5fb9EMyH6JtyrrMqb5v17S1vogHmv1X1hacrMZZqtEKt+Jzlijhvb1UFeoIGMfrtQNfl0CDkE/RrCgmhXVsAOolGx1HlpG2ULDDKn5RPEkEIFlJFJMWPsOx9WD1IcoGvsOJRHqmpc9Hk2I5UFpImZt5fm2HHEU1+HmaH5H3Rw2MjZkUoW/WNLSeY4TT/FLYZ1ARY1lsIn9K+61ak1C9e98uR5g6QQLTsFPnTTLRYyzqphQV+9tjphklQtZbJpeLMLU2hVY3BOaA==
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=U539nj+U0X5GlRexdgUWQebjzhJF8UGeFg4PJ3syh1Q=; b=oHQVvNNakoDqhqpBQwwfEJP9BFSnq1LREkTsTTehW+GUcVXIIk1vgmtm8XFOBjsRSZrYAYtXM3r0ciGEtCdn0I5vq0N1Aal1eppjgnAIOE+uqmgMZu0UKKZngF4MOt7iHJBmev4hS1SPx5s5qz/MjwVMA1x2Y1qpeD1V9EMXcqEwNjRrxMcpk8F6U4arRGnGhDz3JZohBhkNQHQjolqrgBWMAoJ035lFDYk9gfDwyrqtXRRIIcs0C4lm+fCej3FiGZb+pHLVBP0oayRnmpcCBKX2CVZ20OXaz1/ssqG3f0Kq2SX+0QT0xLy4vcV7gL0zYuobIuf7kyuchX6NgKn/Tg==
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=U539nj+U0X5GlRexdgUWQebjzhJF8UGeFg4PJ3syh1Q=; b=JLSGYeiX2OghD/hLHxDXuj8reSrRn+pa9raCga6On2GlUvJfYwxQ3s3ICYCSJRmQLNmGYRdclUgrnZmyONcNKrt+qPYQs65+2YAf7d+xe02/6QIaieqCuwjbpRMOCnNN0BZJrWREJajkH+bKww5NYVPKzF6YLo8okRfpIoKHuyE=
Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (2603:10a6:208:46::31) by AM0PR07MB6114.eurprd07.prod.outlook.com (2603:10a6:208:113::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.11; Fri, 24 Apr 2020 07:37:30 +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.020; Fri, 24 Apr 2020 07:37:30 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "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) - DISCUSS
Thread-Index: AQHWGJMh51smdeuAxkK5VW50oM5mAaiHjKqAgACK5IA=
Date: Fri, 24 Apr 2020 07:37:30 +0000
Message-ID: <6FEC7CD4-6D8B-488D-A93C-6EA92E57F344@ericsson.com>
References: <ECD8AE15-61B3-49DD-9744-9779D6C58634@ericsson.com> <20200424022023.GS27494@kduck.mit.edu>
In-Reply-To: <20200424022023.GS27494@kduck.mit.edu>
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: e67ca074-6b71-40b5-915b-08d7e8225823
x-ms-traffictypediagnostic: AM0PR07MB6114:
x-microsoft-antispam-prvs: <AM0PR07MB6114E059DC16D1C6DD84712393D00@AM0PR07MB6114.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 03838E948C
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)(39860400002)(346002)(366004)(396003)(136003)(376002)(2906002)(91956017)(66446008)(4326008)(66946007)(186003)(44832011)(6506007)(8676002)(66556008)(6486002)(316002)(64756008)(2616005)(76116006)(81156014)(26005)(5660300002)(6916009)(54906003)(66476007)(966005)(6512007)(478600001)(33656002)(36756003)(8936002)(71200400001)(86362001); 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: UMwQOUG1qpJjIavoXTRHprdLEZ+taIbMM/w3nrl5d94EQihZz1sPSelo9in7is53WQdLbRbvAE++dR5DOkM8KLeq1U11fQ0DGBMpfETzior+V74jwdZaxPcRZrMP+Lt72qmmEK6bR6lwCcQLDLyQe3GnWyGzTJ9ZjZXX6d4NjR+uuUd8gIAzI+G6HQ62yillYHc4r4sWmFaolJffVO6mkvgbx777YFUQwlSv7C03coqDGqxwXjpJDSFHHYAtfPP5GwxyhfnovphByxU6WbdH/Sq0OswFcujMca+Er2/67npMXtBQhS9iBcPppKWqP/8KJlF8nw3ZigYSyDj6FYZUzbdDcB3mZ3i3c/Zi9cHctankEQilWvGL1FVaaSW7R0tuVNj0wyB8HrpHlXCUcQ5hqBPbubsO2nXxPcEz/J7+YwJYOyyGcHGOzZU4j4c5xdQ4x4TicqpMBOThUcQ7SkJKiv3RmZ5dE4WFPV/rJk5M6ILu6FSB/3L/iwwRGhglGbeYIoHUkoqN3eOW+PJ/Aj71NA==
x-ms-exchange-antispam-messagedata: ZBCKV2Yc4C4ZVzt+geTF9b1zHRnld/vWRn1CdxYbrdblwYvsFgHwjw5cJCTLcAyNbTUDWPNyGD3kWIbxAsDxuuNJMOzDiWCl7x/khRTAAbI0mkxSoVKmboZv4HF6BUEFe5Wu/0EJHpgYYNEAn09hpg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <CB34088C4A75944994FDCC849027281C@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e67ca074-6b71-40b5-915b-08d7e8225823
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2020 07:37:30.0872 (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: zprMQSie6i5o+hDecdb60rQM3nowtwz4DLB1SR3o6hN7TY14qcSxGz2VhlBnkumT+ohXwGcsivU2D1jshKzfrFx09otx0/SRcKhyfKg6p9w=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6114
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/j1x0Tb1T0m2NmKdqbv2z9mI_iUI>
Subject: Re: [Ice] Benjamin Kaduk's Discuss on draft-ietf-ice-pac-04: (with DISCUSS and COMMENT) - DISCUSS
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: Fri, 24 Apr 2020 07:37:36 -0000

Hi,

    ----------------------------------------------------------------------
         DISCUSS:
    ----------------------------------------------------------------------
     
    >> >    I think we may have to be more specific about updates to the RFC 8445 state
    >> >    machine, namely whether we are specifying a new state for a checklist to be
    >> >    in (vs. keeping it somehow in the "Running" state and modifying the
    >> >    procedures for that state) and describing what happens in Section 7.2.5.4
    >> >    when all candidate pairs in the checklist are Failed or Succeeded but the
    >> >    PAC timer has not expired.  In other words, the combination of 8445 and this
    >> >    document need to be consistent about what the ICE state machine is.
    >> >    In contrast, Trickle is pretty clear about which conditions in which
    >> >    sections of [rfc5245bis] are updated and how, but we don't seem to provide
    >> >    the same level of detail.
    >> 
    >> I don't think we need a new state, but instead stay in the Running state while the PAC timer is still running.
    >> 
    >> So, I guess we can make it more explicit that we stay in the Running state, as the text currently only say that the state is not set to Failed.
    >>
    >> Perhaps something like:
    >> 
    >> OLD:
    >> 
    >>    "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.
    >> 
    >> NEW:
    >> 
    >>   “While the timer is still running, the ICE agent MUST NOT update a checklist state 
    >>   from Running to Failed, even if there are no pairs left in the checklist 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. 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."
    >
    > That may well be enough; I don't have the ICE state machine very fresh in
    > my mind right now :)
    >
    > It looks like in https://tools.ietf.org/html/rfc8445#section-6.1.4.2 if
    > we're forced to stay in the Running state by PAC, then we'll hit step 4 and
    > its "abort these steps" behavior ... which would just leave us still
    > Running and waiting for the next timer to expire, right?  That seems
    > correct to me.
    
    Yes.

    Regards,

    Christer