Re: [quicwg/base-drafts] Clarify PTO packets count towards amplification limit (#3539)

Martin Thomson <notifications@github.com> Mon, 23 March 2020 04:42 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 96D8A3A05AC for <quic-issues@ietfa.amsl.com>; Sun, 22 Mar 2020 21:42:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.696
X-Spam-Level:
X-Spam-Status: No, score=-1.696 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, SPF_PASS=-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 SZXtbj518LZw for <quic-issues@ietfa.amsl.com>; Sun, 22 Mar 2020 21:42:56 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFF7C3A05AA for <quic-issues@ietf.org>; Sun, 22 Mar 2020 21:42:55 -0700 (PDT)
Date: Sun, 22 Mar 2020 21:42:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1584938574; bh=S3l2s65/A9sC8p8OfupaEk6TF97FNmwmewO3U8rCyIg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XQ+Qt2jDZxemv1G4wt6MJPOMHo/3lOawtFRgad1P24IkAZNL5cy3GtxEXCkm3N2GR ZTr320aiB/yHemfwELcV89ETCU7I1cXGwdcvswzEu67YKxDTpFg8aMkECZ5VRMcG94 TSN2/rcnxHj3FhCWVs7k7u5k8s2XJ+dUDxLEeiUQ=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7GUDJKITLFV5PPMUV4QQPU5EVBNHHCF2MO7I@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3539/review/379129293@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3539@github.com>
References: <quicwg/base-drafts/pull/3539@github.com>
Subject: Re: [quicwg/base-drafts] Clarify PTO packets count towards amplification limit (#3539)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e783e4e8b7ad_3f803fdee8ecd9643765"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/CujiNLINcQCQCjWh3sFLTTPgU9w>
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: Mon, 23 Mar 2020 04:42:58 -0000

martinthomson approved this pull request.

Not sure how to split the difference between the limit applying to the packet that was just sent (causing PTO to be armed) or the packet that arming the PTO timer implies.

Personally, I would have put the test at the point that you send a packet, but that's not how this is structured, and you do have "because packets sent on PTO count against the anti-amplification limit", which captures the important concept neatly.

> @@ -558,6 +545,23 @@ keys are discarded, the PTO and loss detection timers MUST be reset, because
 discarding keys indicates forward progress and the loss detection timer might
 have been set for a now discarded packet number space.
 
+#### Before Address Validation
+
+Until the server has validated the client's address on the path, the amount of
+data it can send is limited to three times the amount of data received,
+as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no data can be sent,

```suggestion
as specified in Section 8.1 of {{QUIC-TRANSPORT}}. If no additional data can be sent,
```

When you arm the timer, you might be sending a packet that is within the limit, but the next packet might exceed the limit.

I don't know if this should be adjusted somehow, but this might help.

-- 
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/pull/3539#pullrequestreview-379129293