Re: Handshake timeout failures?

Martin Duke <martin.h.duke@gmail.com> Tue, 09 July 2019 21:32 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC9212006F for <quic@ietfa.amsl.com>; Tue, 9 Jul 2019 14:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4nyVVH_00eYW for <quic@ietfa.amsl.com>; Tue, 9 Jul 2019 14:32:13 -0700 (PDT)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 D73F512000E for <quic@ietf.org>; Tue, 9 Jul 2019 14:32:12 -0700 (PDT)
Received: by mail-wm1-x332.google.com with SMTP id s3so231983wms.2 for <quic@ietf.org>; Tue, 09 Jul 2019 14:32:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S0nu+r4K55KM3icNxjkvgI9D4Hj9LCg2z+cpgJooBLA=; b=LkzUfSqb1wPb1VL/JPWPtGkIWUVRpSAn+EmL3NVs+yVRq2yIM5YUDRSP500Fj+y0Fa fzvr5vUnSG/hcMfa9K1VEZZb+SyB7b4PohCmCWw3WimOWBYydO7bhJDOgivSzqzjCzXN vC6kRoV3JiDUVmEyne3DdrtwI4lXmH3KIrZ4S6LZqmgZkWLgeRrhDFmrklUYVNFChg7+ Q9rcEum7RZ9zuHqaDd+wqZSvJlmrxhE23+CQteb/0VIm3fki6qDyJQe50TWKDvL+wEpa +sSq/KtLVbT/fdLd6r79QC+CLR7sFW92g1peNN5xyKCMzASrxCjcftEiWnBPCFZMEuA9 hGRw==
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=S0nu+r4K55KM3icNxjkvgI9D4Hj9LCg2z+cpgJooBLA=; b=aQTxsP7X9HirbiVcyJOpzdgzTULZ2BRnaq1gzILZGLAH8YbYWDtRZMALG7de9QTk+E q3e0Pq8/S5J5ZzAj34RCu6O0II7eT3KAQ23ClAjpFkwwHuY41bLzglkQAvn65m9vp47F 9Xw4YJUr83HjI85lYaQyzi40dU7Znc9KSDNAiZOKuI3jBS01hlUGQRXWRYnUQvJROvCQ OtB25cizYiSiwcM+KwyP9q8WzOALy9LS0hAuL8BVs5wea+MIqEoY4j6R/iB02b8jTGs2 AIY6HkotWY4heuBj084ZIpr5picQWthZ0Eu/nlLUk3MFw9XmXL/rtk+YN6n6tJZKG9Ic mwgw==
X-Gm-Message-State: APjAAAUGvXDMkkuTFVRrR2tF51+VARxt2RhSPFh9e7PjCq+FOve/2dQJ EekUBMOOS3zZryTGoSmq6rQyDesj8yCzyw2hyjzJU28I
X-Google-Smtp-Source: APXvYqxipSkuAWjTzvubgfNQoHIXpggWWh49qCW6avoW2d7hHQfnxsA4smmYKGxNUjK79F4GX5HQ+Ik8TwQvzn0KFk0=
X-Received: by 2002:a1c:eb17:: with SMTP id j23mr1540595wmh.151.1562707931242; Tue, 09 Jul 2019 14:32:11 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxQJGTjtD91XH1+oko4WS5HV-0yqSgvMaABb79SNN7nzUQ@mail.gmail.com> <BYAPR21MB133486ABBED83A6907776708B3F60@BYAPR21MB1334.namprd21.prod.outlook.com> <CAKcm_gMqGnq=0S=GaNLZm0tS=vfUDF3yDX7Zu=mEpwvYTfKs6Q@mail.gmail.com> <MW2PR2101MB104918091B075CA105BF20E8B6F10@MW2PR2101MB1049.namprd21.prod.outlook.com>
In-Reply-To: <MW2PR2101MB104918091B075CA105BF20E8B6F10@MW2PR2101MB1049.namprd21.prod.outlook.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Tue, 09 Jul 2019 14:31:59 -0700
Message-ID: <CAM4esxRjdw9Q+jZt0SycMAy3YFAMPO3g3L2uFRyriv0bQMO-KQ@mail.gmail.com>
Subject: Re: Handshake timeout failures?
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000021242c058d464bed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/wHUSO4SmVIWuDtufkOEy9pn2X6A>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jul 2019 21:32:15 -0000

OK, I'll file an issue

On Tue, Jul 9, 2019 at 2:27 PM Praveen Balasubramanian <pravb@microsoft.com>
wrote:

> Agreed. One consideration in picking a min bound is VM live migration
> where its desirable to have at least one retry post the blackout period. I
> wonder if we should add text specifying a minimum value for both handshake
> timeout and idle timeout.
>
>
>
> *From:* QUIC <quic-bounces@ietf.org> *On Behalf Of * Ian Swett
> *Sent:* Monday, July 8, 2019 7:23 PM
> *To:* Nick Banks <nibanks=40microsoft.com@dmarc.ietf.org>
> *Cc:* IETF QUIC WG <quic@ietf.org>; Martin Duke <martin.h.duke@gmail.com>
> *Subject:* Re: Handshake timeout failures?
>
>
>
> I think some text on both a handshake timeout(that's presumably shorter
> than a standard idle timeout) and a dead path timeout would be helpful,
> even if it's not normative.
>
>
>
> On Mon, Jul 8, 2019 at 5:56 PM Nick Banks <nibanks=
> 40microsoft.com@dmarc.ietf.org> wrote:
>
> The WG talked about dead path timeouts for a little bit (in Tokyo I think)
> but, at the time, decided to leave it to implementations. I personally
> think having a dead path timeout description in the text would be a good
> idea. I’d be happy to revisit the discussion.
>
>
>
> - Nick
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
> [HxS - 18936 - 16.0.11901.20042]
>
>
> ------------------------------
>
> *From:* QUIC <quic-bounces@ietf.org> on behalf of Martin Duke <
> martin.h.duke@gmail.com>
> *Sent:* Monday, July 8, 2019 4:34:00 PM
> *To:* IETF QUIC WG <quic@ietf.org>
> *Subject:* Handshake timeout failures?
>
>
>
> Is there somewhere in the drafts where we provide suggestions about how to
> time out connections when not yet established? I believe the Idle Timeout
> section applies specifically to established connections.
>
>
>
> This need not be intensely prescriptive, but it would be nice to have some
> guidelines on how not to fail too quickly.
>
>