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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Tue, 21 April 2020 23:02 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ice@ietf.org
Delivered-To: ice@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3283A0E2E; Tue, 21 Apr 2020 16:02:57 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ice-pac@ietf.org, ice-chairs@ietf.org, ice@ietf.org, Nils Ohlmeier <nohlmeier@mozilla.com>, nohlmeier@mozilla.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.127.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158751017647.30301.357634044784320489@ietfa.amsl.com>
Date: Tue, 21 Apr 2020 16:02:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/C8RJq54qlwwv57RhtjiMMlCB5A8>
Subject: [Ice] Benjamin Kaduk's Discuss on draft-ietf-ice-pac-04: (with DISCUSS and COMMENT)
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 21 Apr 2020 23:03:02 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ice-pac-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ice-pac/



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


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

   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.

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

   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.