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
