Thanks for the updates to draft-ietf-quic-ack-frequency-02 and comments

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sun, 06 November 2022 16:30 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2982C14F72A for <quic@ietfa.amsl.com>; Sun, 6 Nov 2022 08:30:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSle1pMS-0D1 for <quic@ietfa.amsl.com>; Sun, 6 Nov 2022 08:30:00 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id A5AF3C14F728 for <quic@ietf.org>; Sun, 6 Nov 2022 08:29:44 -0800 (PST)
Received: from [31.133.149.148] (dhcp-9594.meeting.ietf.org [31.133.149.148]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A5A821B00067 for <quic@ietf.org>; Sun, 6 Nov 2022 16:29:42 +0000 (GMT)
Message-ID: <63fd725c-c3ab-9124-45bb-00bee94928a1@erg.abdn.ac.uk>
Date: Sun, 06 Nov 2022 16:29:43 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:102.0) Gecko/20100101 Thunderbird/102.4.1
To: QUIC WG <quic@ietf.org>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: Thanks for the updates to draft-ietf-quic-ack-frequency-02 and comments
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/g4QfnUMcx9rruv_-FUZanbZpPnQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Nov 2022 16:30:04 -0000

Jana and Ian,

In re-reading draft-ietf-quic-ack-frequency, I think the spec does seem 
clearer, thanks.

I do have a few  additional editorial comments - all of which I think 
are likely minor comments:

* Section 5: /can send multiple ACK_Frequency frames/… could we add /for 
the same connection/ to be clear what the word multiple really means?
* Thanks for updating the text around processing of CE marks - should 
the words /CE marked/ be hyphenated?
* The last  para in section 7.2 really needs a reference to the L4S 
RFC-to-be, because, in the unlikely event that L4S does not continue to 
be used in future, the meaning of ECT(1) could potentially change. I 
can’t predict the future and including this REF appears to me to resolve 
this.
* In section 9.3: I am a big fan of wherever possible making a normative 
text sentence completely self contained. So, is it possible to replace 
/these consequences/the consequences/, or say /the consequences in 
section 9.3/?
* Is section 9.3: the recommended update once per RTT, or once per 
minimum RTT? … when there is buffering along the path, ought it to keep 
the same interval? Or increase with the increasing RTT?
* In section 9.3: there is a mention of PMTUD, It would be nice not to 
encourage PMTUD and its security/deployment issues: the quic spec uses, 
DPLPMTUD.
* DPLPMTUD does indeed benefit from the recommended approach in the ID - 
which does seem definitely worth saying here.
* Section 10: I would hope to see text that says the frames are 
protected by the normal quic security mechanisms. Potentially the method 
would allow a DOS attack on the return path of a standards compliant 
receiver by a malicious/poorly configured server, however the sender has 
control of many aspects of the receiver behaviour and I would not see 
this as a threat from a well configured sender.

* I have a comment trying to reorientate the 3rd case in section 2 - see 
separate email.

Best wishes,

Gorry