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

Tatsuhiro Tsujikawa <> Sun, 14 July 2019 06:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20EE01201E4 for <>; Sat, 13 Jul 2019 23:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Status: No, score=-6.382 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_24=1.618, 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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C41n7fI7-B1A for <>; Sat, 13 Jul 2019 23:19:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2BAC31201DD for <>; Sat, 13 Jul 2019 23:19:20 -0700 (PDT)
Date: Sat, 13 Jul 2019 23:19:19 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1563085159; bh=w5YnkBZ0hG+8n9++g2njhjiHDRsuAS/tQyh5sV6faGM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=B3+6MK9WNqtpMEZYGVEZf3PEqsNI7tXUMHG0tdid4Odo67X2D/S0o5rgleGjJnNYA PfCKiLXXCbAFjHgJ+Ze5/ZUN9Ho+3PFaL05PNv/smu4Kiw6VjeZUi/ofwp3uBcjbJk w0zCpofiazBi/G6NFKryHuB++2hHBqLmeEGmQScg=
From: Tatsuhiro Tsujikawa <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2863/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] unrecoverable loss pattern leads to deadlock (#2863)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d2ac9674613c_57b53f906eecd9649880e7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: tatsuhiro-t
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 14 Jul 2019 06:19:22 -0000

If I understand the issue correctly, the problem is that server drops handshake key too early before client gets ack for its last handshake flight.  Server can ack any client Short packet without client last Handshake flight.  That means that sending any ack-eliciting 1RTT packet from client do not fix this issue.  Coalescing missing Handshake and Short packet would suffer MTU overflow as disscused in PR.
I think server has to wait for client's confirmation of handshake before confirming handshake.  It might be good idea to reconsider explicit signal again?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: