[tsvwg] Martin Duke's Yes on draft-ietf-tsvwg-datagram-plpmtud-17: (with COMMENT)

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

Martin Duke has entered the following ballot position for
draft-ietf-tsvwg-datagram-plpmtud-17: Yes

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/



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

I'm excited for this to go to RFC once the QUIC reference clears.

Normative issue:

Sec 3, item #9 "An update to the PLPMTU (or MPS) MUST NOT modify the congestion
window". Would it not be OK to round down the congestion window to remain a
multiple of the MPS? Probably not a big issue in practice, but I would hate to
constrain an implementer in this way. I would suggest "MUST NOT increase".

Nits:

Sec 2. In the definition for EMTU_R, put "the largest datagram size that can be
reassembled" in quotes, and delete "by EMTU_R (Effective MTU to receive)"

Sec 4.1. delete word in brackets:  "A PL that uses a probe packet carrying [an]
application data..."

Sec 4.6.2 I think this list of inequalities would be easier to read if it was
ranked in order of increasing PL_PTB_SIZE.

5.1.1. s/up to data/up to date