Re: [quicwg/base-drafts] Padding outside QUIC packet (#3333)

ekr <> Tue, 14 January 2020 04:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 82F2012001A for <>; Mon, 13 Jan 2020 20:07:57 -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_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 5JQ-eVaw_-in for <>; Mon, 13 Jan 2020 20:07:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DB92120019 for <>; Mon, 13 Jan 2020 20:07:55 -0800 (PST)
Date: Mon, 13 Jan 2020 20:07:54 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578974874; bh=AWliWcbXWBTfopJLLkl9XbSEXkEb+nv1M64p69RxCIY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=sceXONKXPd+d5XsdxCOWz8v8tt5RtzRiFxqBFRuzOJUziWKMc24dK7EEY+fGDz4Gf /2xvHfVWNZ/o+X0zraU5lZKjQb+HeJoGnAI905Am8gQAVp+rO/4z+diDkqAqM5fX5E nL3rq+sa/wDwrHiRq7dwjmBz63gafd+3yXh5KsiE=
From: ekr <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3333/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Padding outside QUIC packet (#3333)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1d3e9a7eef9_5c573fcb938cd964100797"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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, 14 Jan 2020 04:07:57 -0000

I concur with Kazuho. My understanding had always been that the
amplification liit was on the UDP datagram, more or less for the reasons
Kazuho lays out here.

On Mon, Jan 13, 2020 at 7:20 PM Kazuho Oku <> wrote:

> It seems that the text regarding the amplification limit (Section 8.1
> <>)
> has been last changed in response to #1863
> <> which is marked as
> editorial.
> While the intension of the change was to clarify that the amplification
> limit applies at the QUIC packet level (rather than UDP datagram level), I
> think @nibanks <> might be correct in pointing
> out that our understanding have been the contrary (see #3333 (comment)
> <>
> ).
> Consider the case where a client is using 0-RTT. When building the first
> datagram consisting of an Initial and a 0-RTT packet, the only way the
> client can build the datagram in one-pass is by first building the Initial
> packet, then the 0-RTT packet due to the ordering requirement
> <>.
> As it is hard to tell the size of the 0-RTT packet before building it, the
> most likely outcome is that the 0-RTT packet would be padded. However, the
> server might not be able to process the 0-RTT packet, when it has lost it's
> resumption secret.
> That means that if we are to say that the amplification limit is applied
> at the QUIC packet layer (for the QUIC packets that are only processed
> successfully), the client might end up in having very little room. I do not
> think that is a good outcome.
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <>,
> or unsubscribe
> <>
> .

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