Re: [quicwg/base-drafts] Anti-amplification limits should count junk too (#3340)

Kazuho Oku <> Tue, 04 February 2020 13:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A49C0120128 for <>; Tue, 4 Feb 2020 05:27:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.682
X-Spam-Status: No, score=-3.682 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_MED=-2.3, 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 cu_dBuIKoC6H for <>; Tue, 4 Feb 2020 05:27:27 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69D4A120123 for <>; Tue, 4 Feb 2020 05:27:27 -0800 (PST)
Date: Tue, 04 Feb 2020 05:27:26 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1580822846; bh=Q7P7mq9l/rSrXoIgr55HBvXuF+03e+YlfqH8JN6lTnQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Gtl5fs4M+uehoCiUCg5NuzC1aeMj3UxfBfP43X85L3qvFwFVMdLqno40q03hefHGG hZm4wJgdiDoM6mpRlzRKODTo37N7qjnvG1/wME9nubiiz1jh/RsCFXXpymSP5CL8ea zpV5INSz1M8JDRAZ/sb+sQwZe+6lMgoAAHC4CSGI=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3340/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Anti-amplification limits should count junk too (#3340)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e39713ea9f2c_28dd3fbd302cd96872476"; 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
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: Tue, 04 Feb 2020 13:27:28 -0000

> And the PTO is never armed for 0-RTT, so the probe packets would not be 0-RTT. That being said, I'm a bit concerned those are SHOULDs and not MUSTs.

Yeah, I am concerned that it might be fragile to rely on the behavior of recovery. Moreover, if the client has large amount of data to send, it'd me natural for that client to continue sending datagrams, each of them consisting of a tiny Initial packet and a large 0-RTT packet.

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