Change:
Address ; Clarify what RFC8201 specifies; Consistently using "network segment"; Moved the IP cache discussion to end of section and adds .
Some networks support 1500-byte packets, but can only do so by fragmenting at a lower layer before traversing a smaller MTU segment,” change segment to “network segment” or “link” - just to avoid the unfortunate combination of the word“segment” often associated with TCP. I like the way the new PMTU text is heading, but have various small suggestions: This did not make sense: “For QUIC endpoints using DPLPMTUD it is recommended for the path to drop a packet larger than the supported size. A QUIC probe packet is used to discover the PMTU. If lost, this does not impact the flow of QUIC data.” the word endpoint appears in the wrong place, is this better: “For networks supporting QUIC it is recommended that a path drops any packet larger than the supported size. When a QUIC endpoint uses DPLPMTUD, it will use a QUIC probe packet is used to discover the PMTU. If this probe is lost, it will not impact the flow of QUIC data.” Not always (there are many exceptions such as rate control): “Since a network cannot know in advance which discovery method a QUIC endpoint is using, it should always send a PTB message in addition to dropping the oversized packet. “ Is this more correct as: “A network cannot know in advance which discovery method is used by a QUIC endpoint, so it should send a PTB message in addition to dropping an oversized packet. “ “This will likely provide the right signal for the endpoint to keep the packet size small and thereby avoid network fragmentation for that flow entirely.” Could be better as: “This will likely provide a useful signal to the endpoint to prevent the packet size from growing too large and thereby entirely avoid network segment fragmentation for that flow.”
Lots of points in there! Taking them one at a time: I agree that the word "segment" could be confusing, but not sure whether "link" or "network segment" is a better choice. Agree it's not particularly ideal to have "endpoint" at the beginning of the sentence. Your replacement is more readable, although we just need to remove the repetition of the verb "use". Your "A network cannot know" version looks better to me, but since the aim here is to encourage a complete implementation I would prefer to keep the word "always" in there. Without it, it seems too easy for an implementer to think "PTB is optional, so I'll skip that". Not so convinced about this one. I tend to think it is the right signal, not just one of a bag of useful signals.
Thanks, see below: Link is the correct term, wrt IP. Although "network segment" would be OK and I suspect easier to read, the word segment on its own was confusing. OK, indeed the spurious "used" needs deleted. The word "always" is a problem. Even if a node were to send a PTB message for each packet, ICMP is often rate-limited and can be filtered, and assumes a symetric forwarding path. The "should" is OK, but the always isn't a strict requirement. I think we differ on optimisim that PMTUD is still workable. However, would it be OK just to remove /useful/ and leave it as a signal. I'd be OK to also remove "likely", if that seems stronger.
Some responses on the latter two: I think Mirja had an opinion on this phrasing when we were discussing so it would be good to hear her thoughts. I agree PMTUD is on its way to obsolescence. But my reading of DPLPMTUD/RFC8899 is that it is still generally expected that PTBs are sent, hence the inclusion of section 4.6 on what to do when PTBs are received, and why totally ignoring PTBs is described as one extreme of the implementation spectrum. In that light, I suggest the best form of words is to remove both "likely" and "useful". The resulting sentence is then: “This will provide a signal to the endpoint to prevent the packet size from growing too large and thereby entirely avoid network segment fragmentation for that flow.”
Thanks NAME and NAME I will review the PR!
So Section 4.10 in manageability-11 "Guiding Path MTU" discusses dropping QUIC packets above a configured limits that are less than the normal PMTU and also sending an ICMP PTB message back when doing this. I think the text in this section would benefit from an additional clarification that implementing this can impact all IP traffic to and from the involved endpoint pairs. The reasons for this is that RFC 8201 recommend that endpoints that receive IPv6 ICMPv6 PTBs cache these messages in relation to a implementation specific representation of the path. Thus, any IPv6 packets sent from the endpoint towards a destination which the implementation considers being the same path will have a PMTU applied according to the value in the PTB. For example if you have an endpoint in an access network and a datacenter front-end that fronts both HTTP/3 servers and a DNS service that the endpoint uses, then the DNS message size would be fragmented to the lower value than the absolute PMTU. I don't see any major issue with this, but I think the document should be clear on the potential implications of applying this method to QUIC flows.
Yes if a node updates it's IP cache (which is a valid approach), this impacts other flows sharing the same "path" where the notion of path needs thought (RFC8201, s5.2). I'm noting that RFC8899 explicity says: "The PMTU value calculated from the PLPMTU MAY also be stored with the corresponding entry associated with the destination in the IP layer cache and used by other PL instances." This was a MAY because of the potential impact on other flows. When the IPv6 RFC was updated, we added some caution about ECMP, etc. which is a hint at the same problem.
I can review this.

Discussion:
4.10. <del> Some networks support 1500-byte packets, but can only do so by fragmenting at a lower layer before traversing a smaller MTU segment, and then reassembling.  This is permissible even when the IP layer is IPv6 or IPv4 with the DF bit set, because it occurs below the IP layer.  However, this process can add to compute and memory costs, leading to a bottleneck that limits network capacity.  In such networks this generates a desire to influence a majority of senders to use smaller packets, so that the limited reassembly capacity is not exceeded. </del> <ins> Some network segments support 1500-byte packets, but can only do so by fragmenting at a lower layer before traversing a network segment with a smaller MTU, and then reassembling within the network segment. This is permissible even when the IP layer is IPv6 or IPv4 with the DF bit set, because fragmention occurs below the IP layer.  However, this process can add to compute and memory costs, leading to a bottleneck that limits network capacity.  In such networks this generates a desire to influence a majority of senders to use smaller packets, to avoid exceeding limited reassembly capacity. </ins> For TCP, MSS clamping (Section 3.2 of RFC4459) is often used to <del> change the sender's maximum TCP segment size, but QUIC requires a </del> <ins> change the sender's TCP maximum segment size, but QUIC requires a </ins> different approach.  Section 14 of QUIC-TRANSPORT advises senders to probe larger sizes using Datagram Packetization Layer PMTU Discovery (DPLPMTUD) or Path Maximum Transmission Unit Discovery (PMTUD: <del> RFC1191 and RFC8201).  This mechanism will encourage senders to approach the maximum size, which could cause fragmentation with a network segment that they may not be aware of. </del> <ins> RFC1191 and RFC8201).  This mechanism encourages senders to approach the maximum packet size, which could then cause fragmentation within a network segment of which they may not be aware. </ins> <del> If path performance is limited when sending larger packets, an on- </del> <ins> If path performance is limited when forwarding larger packets, an on- </ins> path device should support a maximum packet size for a specific transport flow and then consistently drop all packets that exceed the configured size when the inner IPv4 packet has DF set, or IPv6 is <del> used.  Endpoints can cache PMTU information between IP flows, in the IP-layer cache, so short-term consistency between the PMTU for flows can help avoid an endpoint using a PMTU that is inefficient. </del> <ins> used. </ins> Networks with configurations that would lead to fragmentation of <del> large packets should drop such packets rather than fragmenting them. Network operators who plan to implement a more selective policy may start by focusing on QUIC.  QUIC flows cannot always be easily distinguished from other UDP traffic, but we assume at least some portion of QUIC traffic can be identified (see sec-identifying).  For QUIC endpoints using DPLPMTUD it is recommended for the path to drop a packet larger than the supported size.  A QUIC probe packet is used to discover the PMTU.  If lost, this does not impact the flow of QUIC data. </del> <ins> large packets within a network segment should drop such packets rather than fragmenting them.  Network operators who plan to implement a more selective policy may start by focusing on QUIC. QUIC flows cannot always be easily distinguished from other UDP traffic, but we assume at least some portion of QUIC traffic can be identified (see sec-identifying).  For networks supporting QUIC, it is recommended that a path drops any packet larger than the fragmentation size.  When a QUIC endpoint uses DPLPMTUD, it will use a QUIC probe packet to discover the PMTU.  If this probe is lost, it will not impact the flow of QUIC data. </ins> IPv4 routers generate an ICMP message when a packet is dropped because the link MTU was exceeded.  RFC8504 specifies how an IPv6

whereas DPLPMTUD does not reply upon these messages, but still can optionally use these to improve performance Section 4.6 of DPLPMTUD. <del> Since a network cannot know in advance which discovery method a QUIC endpoint is using, it should always send a PTB message in addition to dropping the oversized packet.  A generated PTB message should be </del> <ins> A network cannot know in advance which discovery method is used by a QUIC endpoint, so it should send a PTB message in addition to dropping an oversized packet.  A generated PTB message should be </ins> compliant with the validation requirements of Section 14.2.1 of QUIC- <del> TRANSPORT, otherwise it will be ignored by DPLPMTUD.  This will likely provide the right signal for the endpoint to keep the packet size small and thereby avoid network fragmentation for that flow entirely. </del> <ins> TRANSPORT, otherwise it will be ignored for PMTU discovery.  This provides a signal to the endpoint to prevent the packet size from growing too large, which can entirely avoid network segment fragmentation for that flow. Endpoints can cache PMTU information, in the IP-layer cache.  This short-term consistency between the PMTU for flows can help avoid an endpoint using a PMTU that is inefficient.  The IP cache can also influence the PMTU value of other IP flows that use the same path RFC8899, including IP packets carrying protocols other than QUIC. The representation of an IP path is implementation-specific RFC8201. </ins> 5.