Re: [quicwg/base-drafts] Discarding Initial context too soon leads to deadlock (#3395)

Christian Huitema <> Sat, 25 January 2020 02:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23D831200D8 for <>; Fri, 24 Jan 2020 18:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.596
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zMHxu5upOYNC for <>; Fri, 24 Jan 2020 18:16:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90CAB12001B for <>; Fri, 24 Jan 2020 18:16:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7FDC6520A73 for <>; Fri, 24 Jan 2020 18:16:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1579918560; bh=/ZmMP1RbWSl6f9BMDATkriANC40S3Kt3rs6L+nu2DhM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=CgwZpVxrTvWB1dW5/mmmw02eBTPwSSxSjuvd6HJwfMcDvrWhVn4CEKRQjiO7H3Waw 8HCYFV3wWZL/rcHsnYVviwWNv5ouFkPTYegkhCTkcgsjJ/cE9HPXIkJnykKGFXk6PX X2nHke3bokm/glfzWML6z9zrIoEHCExb4KgVGlD8=
Date: Fri, 24 Jan 2020 18:16:00 -0800
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3395/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Discarding Initial context too soon leads to deadlock (#3395)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e2ba4e071517_700c3fa653acd968651c7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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: Sat, 25 Jan 2020 02:16:05 -0000

My server has a somewhat radical approach to anti-amplification: it just does not retransmit anything before the client address is validated. That's a good way to find edge cases, such as getting the first packet from the server and missing all the other packets, which would logically elicit acks of their own. That also means that bundling a ping with a server packet is not appropriate.

Regarding the recovery text: yes, if the client keeps repeating the ACK-only handshake packet, that will break the deadlock. But then, few stacks will naturally repeat ACK-only packets and few server stacks will acknowledge them, which was my point about adding "ACK-eliciting". In my case, the deadlock is broken when client will eventually repeat the Initial packet, and that will work. But it would not if I deleted the Initial context.

So I do think we need a bit of a warning in this section. Either my suggestion about ack-eliciting, or if you prefer a pointer to the relevant section in the recovery draft.

At a minimum, I would like to see a small warning in the text 

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