Original text:
9.3. <del> QUIC, TLS, and HTTP/2 all contain messages that have legitimate uses in some contexts, but that can be abused to cause a peer to expend processing resources without having any observable impact on the state of the connection.  If processing is disproportionately large in comparison to the observable effects on bandwidth or state, then this could allow a malicious peer to exhaust processing capacity without consequence. While there are legitimate uses for some redundant packets, implementations SHOULD track redundant packets and treat excessive volumes of any non-productive packets as indicative of an attack. 9.4. </del> Header protection relies on the packet protection AEAD being a pseudorandom function (PRF), which is not a property that AEAD algorithms guarantee.  Therefore, no strong assurances about the payloads and packet numbers MUST be free from side-channels that would reveal the packet number or its encoded size. <del> 9.5. </del>  In using TLS, the central key schedule of TLS is used.  As a result of the TLS handshake messages being integrated into the calculation 21.7.  An on-path attacker could manipulate the value of ECN codepoints in the IP header to influence the sender's rate.  RFC3168 discusses manipulations and their effects in more detail. an IP packet unless at least one QUIC packet in that IP packet is successfully processed; see ecn. <del> 21.8. </del>  Stateless resets create a possible denial of service attack analogous to a TCP reset injection.  This attack is possible if an attacker is for connections to time out.  However, this is acceptable only if the routing cannot be influenced by an attacker. <del> 21.9. </del>  This document defines QUIC Version Negotiation packets version- negotiation, which can be used to negotiate the QUIC version used packets MUST define a mechanism that is robust against version downgrade attacks. <del> 21.10. </del>  Deployments should limit the ability of an attacker to target a new connection to a particular server instance.  This means that client-

Reviewer comments:
Issue observes that this text mentions HTTP/2, which isn't necessary. In reviewing it, I noticed that this talks about messages that do nothing, but not really about messages that do little (or that can be reversed to have net zero effect). So I expanded the text a little.
Thanks for improving the section's clarity. As a follow up question, when implementations decide that excessive packets is an attack, is there a recommended actionable (eg. sending reset, dropping the connection, do nothing) or would that be up for implementer's discretion?
Maybe this needs to be stated explicitly, but there is no point in continuing discussion with an attacker. So while it might be considered polite to send a connection error, it is also acceptable to just drop any further incoming packets. I'll add that here.
Under the section Peer Denial of Service of TLS draft, a referenced was made to HTTP/2. URL I was wonder if this is in fact referring to HTTP/3 or HTTP/2. Also curious why the section is labelled
That mention of h2 was a mistake. I've made a few changes after reviewing this. (The thing is a joke.)

Revised text:
9.3.  Header protection relies on the packet protection AEAD being a pseudorandom function (PRF), which is not a property that AEAD algorithms guarantee.  Therefore, no strong assurances about the payloads and packet numbers MUST be free from side-channels that would reveal the packet number or its encoded size.  <ins> 9.4. </ins> In using TLS, the central key schedule of TLS is used.  As a result of the TLS handshake messages being integrated into the calculation 21.7. <ins> QUIC and TLS both contain messages that have legitimate uses in some contexts, but that can be abused to cause a peer to expend processing resources without having any observable impact on the state of the connection. Messages can also be used to change and revert state in small or inconsequential ways, such as by sending small increments to flow control limits. If processing costs are disproportionately large in comparison to bandwidth consumption or effect on state, then this could allow a malicious peer to exhaust processing capacity. While there are legitimate uses for all messages, implementations SHOULD track cost of processing relative to progress and treat excessive quantities of any non-productive packets as indicative of an attack.  Endpoints MAY respond to this condition with a connection error, or by dropping packets. 21.8. </ins> An on-path attacker could manipulate the value of ECN codepoints in the IP header to influence the sender's rate.  RFC3168 discusses manipulations and their effects in more detail. an IP packet unless at least one QUIC packet in that IP packet is successfully processed; see ecn.  <ins> 21.9. </ins> Stateless resets create a possible denial of service attack analogous to a TCP reset injection.  This attack is possible if an attacker is for connections to time out.  However, this is acceptable only if the routing cannot be influenced by an attacker.  <ins> 21.10. </ins> This document defines QUIC Version Negotiation packets version- negotiation, which can be used to negotiate the QUIC version used packets MUST define a mechanism that is robust against version downgrade attacks.  <ins> 21.11. </ins> Deployments should limit the ability of an attacker to target a new connection to a particular server instance.  This means that client-