[tsvwg] Robert Wilton's No Objection on draft-ietf-tsvwg-datagram-plpmtud-19: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-tsvwg-datagram-plpmtud-19: 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/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:
----------------------------------------------------------------------

Firstly I would like to say thank you for writing this document.

I have a general concern, not specifically with this document, but with the
overall complexity of the solution.  I.e. the algorithm that is described has
to contend with a lot of unreliable information (e.g. are packets dropped
because of congestion or some other routing failure, hard to know whether PTB
messages can be relied upon etc), there are also several different ways that
the probes can be sent etc.

Not the subject of this document, but it feels like life could be significantly
simpler if somehow there was a mechanism to getting a set of agree a set of
defined minimum PLPMTU that network may support.  E.g. perhaps 1280, 2000,
4000, 8000, 16000 octets.   My assumption here is that the underlying core link
MTUs would be higher to cope with header overheads.

A few comments on specific sections of the document:

1) I would include PTB in the terminology section.

3. Features Required to Provide Datagram PLPMTUD

Most of the the requirements in this section use RFC 2119 language, but a few
don't:

   7.   Probing and congestion control: The decision about when to send
        a probe packet does not need to be limited by the congestion
        controller.  When not controlled by the congestion controller,
        the interval between probe packets MUST be at least one RTT.  If
        transmission of probe packets is limited by the congestion
        controller, this could result in transmission of probe packets
        being delayed or suspended during congestion.

Rather than "does not need to be limited", would this be better stated as 
"SHOULD NOT be limited" or "MAY not be limited"?

   11.  Probing and flow control: Flow control at the PL concerns the
        end-to-end flow of data using the PL service.  This does not
        apply to DPLPMTU when probe packets use a design that does not
        carry user data to the remote application.

The second sentence could be stated something like:

"Flow control MUST NOT apply to DPLPMTU when probe packets use a design that
does not carry user data to the remote application"

5.1.2.  Constants

   MIN_PLPMTU:  The MIN_PLPMTU is the smallest allowed probe packet
      size.  For IPv6, this value is 1280 bytes, as specified in
      [RFC8200].  For IPv4, the minimum value is 68 bytes.

Does it really make sense to probe for a path MTU of 68 bytes.  Would it make
sense for applications to be able to control the MIN_PLPMTU that they find
acceptable?  E.g. if IPv6 has this at 1280 and QUIC has uses 1280, perhaps many
applications/implementations would like to use 1280 as a reasonable lower bound
rather than 68 bytes?