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

Will Hawkins <> Mon, 13 January 2020 05:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A2EB120052 for <>; Sun, 12 Jan 2020 21:41:37 -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 kHajB-T4A7yI for <>; Sun, 12 Jan 2020 21:41:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EC0F120018 for <>; Sun, 12 Jan 2020 21:41:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 406BA1C06E9 for <>; Sun, 12 Jan 2020 21:41:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1578894094; bh=v3G+Coz67ef8AwE/ddezGlPaK9gbtViMKkNbTZ7CNec=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=M453iVZ3P0IxwYNsycYt7cCSS/NlCmXbrDI2/omr3LvRnsKyg43YZqFJGsZvQW3ZG qo1G2sgWC+6WKlSR3tyActdKnwvkJKDTT+vxHXdjxrwf1vM8OZGdMA+0bAgjPRxaGT QO7LxAXRoK9rG5AXvYK6vu89agzlyMOWgM4MHElo=
Date: Sun, 12 Jan 2020 21:41:34 -0800
From: Will Hawkins <>
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_5e1c030e3079f_43e13fd52eecd9648424fd"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: hawkinsw
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, 13 Jan 2020 05:41:37 -0000

> only says that padding is done by PADDING frame.
> But it looks like it is a common practice to add 0 or garbage outside QUIC packet to fill remaining UDP packet payload to expand packet size.

Just FYI: Adding 0-value bytes outside QUIC packets to fill remaining UDP datagram is the way that neqo currently performs padding. Of course, as @ekr says, it only does this when it is possible (there are only QUIC packets with long headers in the datagram).

> If it is a good practice (and/or recommended), I think draft should say something about it.
> It might slightly simplify the implementation.
> Padding in this way has different properties than PADDING frame; for example, it does not contribute to in-flight bytes.

  I, too, think it would be nice to have some clarification like this in the standard.  

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