Re: [quicwg/base-drafts] Clarify client anti-amplification response (#3445)

ianswett <> Mon, 10 February 2020 17:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19CEB12001B for <>; Mon, 10 Feb 2020 09:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 LjphglUaSWLp for <>; Mon, 10 Feb 2020 09:50:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5EDF212001A for <>; Mon, 10 Feb 2020 09:50:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BF037E0FDD for <>; Mon, 10 Feb 2020 09:50:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1581357003; bh=bZiI+9K0v5MBz//cJjAja1dopJ/9uRQ1Vd5lWmQLLIs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iTN9RjzTPGBRPPBRDHKMNW+eOb/6XHchH/7u/8ED7Q1UShzdeKGCtIRFE7N7OcZlX CNIIs/y7f3Qp4tgoqigWMhiSVGpVlB9wThkJC/qpwPovmAWf/EOiquq0Cbdnvz8X8P FZXEav/wzcnMijQFYMnxOQrKN7phvDwRzOi+vBcc=
Date: Mon, 10 Feb 2020 09:50:03 -0800
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3445/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Clarify client anti-amplification response (#3445)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e4197cbaeeaa_20233f8f17acd95c535de"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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: Mon, 10 Feb 2020 17:50:08 -0000

ianswett commented on this pull request.

> @@ -1626,14 +1626,14 @@ payloads of at least 1200 bytes, adding padding to packets in the datagram as
 necessary. Sending padded datagrams ensures that the server is not overly
 constrained by the amplification restriction.
-Packet loss, in particular loss of a Handshake packet from the server, can cause
-a situation in which the server cannot send when the client has no data to send
-and the anti-amplification limit is reached. In order to avoid this causing a
-handshake deadlock, clients MUST send a packet upon a probe timeout, as
-described in {{QUIC-RECOVERY}}. If the client has no data to retransmit and does
-not have Handshake keys, it MUST send an Initial packet in a UDP datagram of
-at least 1200 bytes.  If the client has Handshake keys, it SHOULD send a
-Handshake packet.
+Loss of an Initial or Handshake packet from the server can cause a situation in
+which the server cannot send due to the anti-amplification limit
+and the client has no data to send because client Initial data has been
+acknowledged and it does not yet have Handshake data to send. In order to avoid

Thanks, I tried to rewrite based on your suggestion.  Tell me what you think.

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