IETF Logo Mail Archive

Re: [quicwg/base-drafts] unrecoverable loss pattern leads to deadlock (#2863)

Kazuho Oku <notifications@github.com> Mon, 01 July 2019 00:18 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01321201E2 for <quic-issues@ietfa.amsl.com>; Sun, 30 Jun 2019 17:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
X-Spam-Status: No, score=-6.596 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, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 jD4RYuIM5uDk for <quic-issues@ietfa.amsl.com>; Sun, 30 Jun 2019 17:18:08 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09E01201DA for <quic-issues@ietf.org>; Sun, 30 Jun 2019 17:18:08 -0700 (PDT)
Date: Sun, 30 Jun 2019 17:18:07 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1561940287; bh=5hniK49v3GN0DsmyF+xXGHLwJ5Hg8IHSuQQ7eOb9dxs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=AX6F4ADDUw1lbwly3dMVVGWgmhy3DyxKOFO0jbzoTxw8gog1B+ETa1TqTkWQ8EIeJ AIqwFyqYT2La9SX4cpA0MX6AT6x4OAqU6UIRpWV9S7rydoIZ1zTyKehQY4DhXe9IXX oZNf6+3Q3L0H80XqV/oG37K9akMefSNCyTz4IiBg=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7OGAHQKQ35THOBJ2V3E2B37EVBNHHBXDZPBM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2863/507079412@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2863@github.com>
References: <quicwg/base-drafts/issues/2863@github.com>
Subject: Re: [quicwg/base-drafts] unrecoverable loss pattern leads to deadlock (#2863)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d19513f8493d_73683fa83cccd96c242390"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/L4ymK07lxG1Wje4W2e2DFrum1Rs>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jul 2019 00:18:11 -0000

@martinthomson 
> In this scenario, the client will continue retransmitting the last cryptographic handshake flight. That sounds terrible. But if it ever has cause to send 1-RTT data (as it does in Marten's example, which I'm not sure is relevant), then it will retransmit that data on PTO. When that is eventually acknowledged, that will confirm the handshake.

Agreed. IIRC, the assumption in the design team was that the client would have something to send.

> Would it be enough to say that "unless an endpoint sends some ack-eliciting data in 1-RTT packets, the handshake might remain unconfirmed indefinitely" and leave it at that?

+1. We may hint that "a client MAY send a PING packet to confirm the handshake."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2863#issuecomment-507079412

v2.31.3 | Report a Bug | By Email | System Status