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

Benjamin Kaduk <kaduk@mit.edu> Fri, 24 April 2020 02:25 UTC

Return-Path: <kaduk@mit.edu>
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 4223F3A0DC8; Thu, 23 Apr 2020 19:25:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 rbu8gk7sFb-q; Thu, 23 Apr 2020 19:25:56 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5E7343A0DC7; Thu, 23 Apr 2020 19:25:56 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03O2PnPh004858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 23 Apr 2020 22:25:51 -0400
Date: Thu, 23 Apr 2020 19:25:49 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Christer Holmberg <christer.holmberg@ericsson.com>
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>
Message-ID: <20200424022549.GT27494@kduck.mit.edu>
References: <D2659A05-4833-4A07-B512-7143025CCB81@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D2659A05-4833-4A07-B512-7143025CCB81@ericsson.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/wpck_8KwWZ5oz7pLusu4uOnz_kI>
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: Fri, 24 Apr 2020 02:25:58 -0000

On Wed, Apr 22, 2020 at 12:16:26PM +0000, Christer Holmberg wrote:
> 
> 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."

I don't see any obvious problems with this.  (I think when I made this
comment I was looking at "For each checklist in the checklist set, if all
of the candidate pairs are in either Failed or Succeeded state, and if
there is not a valid pair in the valid list for each component of the data
stream associated with the checklist, the state of the checklist is set to
Failed." from https://tools.ietf.org/html/rfc8445#section-7.2.5.4 but your
new text covers relevant things.)

> ---
> 
> >       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).

Thanks for these clarifications.  (To be clear, I was just wondering if the
"some specific scenarios [that] no longer fail fast" could be optimized by
special-casing a specific case that will always fail even with PAC, so as
to still fail fast, but I don't think there's anything to do here.)

-Ben

> ---
>   
> >       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
>     
>