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

Kazuho Oku <notifications@github.com> Tue, 14 January 2020 03:20 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6193120071 for <quic-issues@ietfa.amsl.com>; Mon, 13 Jan 2020 19:20:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DnOJvo0pSTR for <quic-issues@ietfa.amsl.com>; Mon, 13 Jan 2020 19:20:26 -0800 (PST)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0B412001B for <quic-issues@ietf.org>; Mon, 13 Jan 2020 19:20:26 -0800 (PST)
Date: Mon, 13 Jan 2020 19:20:25 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1578972025; bh=IZv3eDaR5PUxSGNe/s3fZy3Ms9KoQuwtrgtz/WXBjbI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=mUkY2JmvyH2aWDCg3bgrpz/2mSkLnOYGJaIlOVPrL/PzSklVSZgCHXad5AfvJMNyb E8hyCNW5k9zQt/Bd0PmsC+fr02bO/vNgKbBtqrGXFm6M0N6iEt9LNxx2Jb1uYzyMTh q+U3EcocCk1khn4jFDfaguSc7UzuzRv3LwMrHWVg=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7A4SVSMYCOCRDVKDF4FJS7TEVBNHHCBMO65M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3333/573980810@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3333@github.com>
References: <quicwg/base-drafts/issues/3333@github.com>
Subject: Re: [quicwg/base-drafts] Padding outside QUIC packet (#3333)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1d33796f9e5_7ddf3fcab30cd95c38488c"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/cpXnZYsgIP7MT6cmQTTnqZm9NbA>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2020 03:20:28 -0000

It seems that the text regarding the amplification limit ([Section 8.1](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-8.1-2)) 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 https://github.com/quicwg/base-drafts/issues/3333#issuecomment-573730981).

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](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-12.2-3). 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 are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3333#issuecomment-573980810