(PL)PMTU text

[gorryfair]

These comments relate only to the PMTU text in -24, relative to the current DPLPMTUD text as that now progresses to WGLC.

/This can also be used to construct PMTU probes (see
Section 14.3.1). /

• Is this necessary? Or can padding frames be used to make (PL)PMTU probes?.
• My confusion here may be linked to not understanding the intent of 14.3.1

/Further validation can also be provided:

o An IPv4 endpoint could set the Don't Fragment (DF) bit on a small
proportion of packets, so that most invalid ICMP messages arrive
when there are no DF packets outstanding, and can therefore be
identified as spurious.

o An endpoint could store additional information from the IP or UDP
headers to use for validation (for example, the IP ID or UDP
checksum)./

• I suggest the above text is spurious, since the checks advocated in DPLPMTUD and the QUIC fields provide a way to detect this. While it is possible too toggle the DF field, I do no think the IETF should endorse this, because it can have other side effects and this is not the place to propose that method.

/An endpoint MUST NOT increase PMTU based on ICMP messages. /

• DPLPMTUD already specifies. This has always been the case, so please either delete or cite DPLPMTUD or the two core IP specs.

Section 14.3.1
I didn’t understand section 14.3.1. Maybe that isn’t good since I do understand PMTUD and PLPMTUD. Perhaps this section requires some reworking to explain the goal.

[mnot]

Tentatively marking this as editoral; if something design-y pops up when processing please ping.

[martinthomson]

Let me see if I can break this down a little. cc @martinduke for his opinion of these.

14.3.1: The first and last comment relates to the section on using coalescing to help the routing of ICMP messages. I had no difficulty reading this section, though I might suggest one tweak:

Endpoints that rely on the destination connection ID for routing incoming QUIC packets are likely to require that the connection ID be included in PMTU probe packets to route any resulting ICMP messages (Section 14.2) back to the correct endpoint.

The "further validation" text: DF is currently mandated, but this text pre-dates that requirement. We should drop that clause. And the other clause is a little lame. I'd be happy dropping all of the quoted text.

Citing DPLPMTUDTD is sensible and we should do that.