[bmwg] Martin Duke's No Objection on draft-ietf-bmwg-ngfw-performance-13: (with COMMENT)

[Martin Duke via Datatracker <[e-mail]>]

Martin Duke has entered the following ballot position for
draft-ietf-bmwg-ngfw-performance-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bmwg-ngfw-performance/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(4.3.1.3) RFC8446 is not the reference for HTTP/2.

(4.3.1.1), (4.3.2.1) Is there a reason that delayed ack limits are defined only
in terms of number of bytes, instead of time? What if an HTTP request (for
example) ends, and the delayed ack is very long? Note also that the
specification for delayed acks limits it to every two packets, although in the
real world many endpoints use much higher thresholds. [It's OK to keep it at
10*MSS if you prefer].

(4.3.3.1) What is a "TCP persistence stack"?