Re: [Ice] Éric Vyncke's No Objection on draft-ietf-ice-pac-04: (with COMMENT)

Barry Leiba <barryleiba@computer.org> Tue, 21 April 2020 17:35 UTC

Return-Path: <barryleiba@gmail.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 67C433A0938; Tue, 21 Apr 2020 10:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.218
X-Spam-Level:
X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 5R8znoXDP0jT; Tue, 21 Apr 2020 10:35:21 -0700 (PDT)
Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E51983A08E0; Tue, 21 Apr 2020 10:35:14 -0700 (PDT)
Received: by mail-il1-f174.google.com with SMTP id r2so7537308ilo.6; Tue, 21 Apr 2020 10:35:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=d2V26s2IiXGmC+Iqwv5+/FDvd6lNN944Y5kwHdmRbrA=; b=JFmthxbX70KWvmGa9Cr7N1W1UgInGcoBVQXRlWsPzT/tQAV+CzevNZQjNUU9XDQhzd b7e+C4K5eldCjNQymeBsBesbT+y1FuFVjprYM4/6RchayJ/br4319foUqgK3spxIadHw XfwvXFrv4/uvx25fPKZiY2Q+Dd532tzKE6zYoKxS2XjQGusM4KmPgOYln255zYGiUF5L S8zCvseWIdhp4jZDjpSD96QRH6Y9WnAmU6RlKh0jITwNSSV2rjiD0m1vipkSOljiUd6X O8Lf8DxvvwNHNNsKEVtnlAboRXKf+WOmeCef01XVnLwmy6D2pkaiwP5OcPOa69wXZHVr mVbg==
X-Gm-Message-State: AGi0PuazUDwaLgvsUmHZG7JAYerxUwUaIQ+loLN5LY8rLGBRvRbQTIs0 aATwcneXmVZQeox1QASfBcWjy1Xz9ooHYyTbM1A=
X-Google-Smtp-Source: APiQypIbL+fP+MEhBXRvxz5rmwHz2GpjlgukJmRYjxhN+Idz0NdhPSuG9g5zKEjpgYUEdZJ9N6SzNThpE19slddBwcE=
X-Received: by 2002:a92:ca81:: with SMTP id t1mr3144424ilo.187.1587490513784; Tue, 21 Apr 2020 10:35:13 -0700 (PDT)
MIME-Version: 1.0
References: <158747937967.30818.11917169559141666632@ietfa.amsl.com> <79EF9BAD-FA0C-4019-AF2C-A3A8FFC988A4@ericsson.com>
In-Reply-To: <79EF9BAD-FA0C-4019-AF2C-A3A8FFC988A4@ericsson.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Tue, 21 Apr 2020 13:35:02 -0400
Message-ID: <CALaySJKPnvDUP=JVG0mJS6WKYRpqUZ-LH4uS+3mNpzG+O8s5OQ@mail.gmail.com>
To: Christer Holmberg <christer.holmberg=40ericsson.com@dmarc.ietf.org>
Cc: Éric Vyncke <evyncke@cisco.com>, The IESG <iesg@ietf.org>, Nils Ohlmeier <nohlmeier@mozilla.com>, "ice-chairs@ietf.org" <ice-chairs@ietf.org>, "draft-ietf-ice-pac@ietf.org" <draft-ietf-ice-pac@ietf.org>, "ice@ietf.org" <ice@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/isJTO4-wRUDDA3hUp9ZBVviL56I>
Subject: Re: [Ice] Éric Vyncke's No Objection on draft-ietf-ice-pac-04: (with 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: Tue, 21 Apr 2020 17:35:32 -0000

>     > I also wonder why section 1 talks about 'race conditions' while the issue is
>     > related to a too short default time-out or in the use cases of section 3. (in
>     > my mind, 'race conditions' is an unusual sequence of events).

For what it's worth, a "race condition" is simply a case where results
differ based on the order that things happen (depending upon "who wins
the race").  If the results of something are different depending upon
factors such as which entity has more latency at the moment, which
process got swapped out at the wrong time, or just who happened to get
a "better" time-slice just now, we have a race condition.

In the case described in the document, if a candidate gets its "name"
in while the endpoint is still processing things, that candidate is
considered; if it's a little too late, say because of network latency
or slower processing somewhere or the like, then it doesn't get
considered.  That sounds like a race condition to me.

Barry