Draft: draft-ietf-quic-manageability

Commentary: 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  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 can not 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 can not 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 : agree that the word " segment " could be confusing , but not sure whether " link " or " network segment " is a better choice . 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 " . " A network can not 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 " . 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 : 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 . , indeed the spurious " used " needs deleted . 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 is n't a strict requirement . 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 : think  had an opinion on this phrasing when we were discussing so it would be good to hear her thoughts . 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 and 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 do n'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 some caution about ECMP , etc . which is a hint at the same problem . 
 I can review this .
Paragraph (version A):
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.
Paragraph (version A):
For TCP, MSS clamping (Section 3.2 of RFC4459) is often used to
change the sender's maximum TCP segment size, but QUIC requires a
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:
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.
Paragraph (version A):
If path performance is limited when sending larger packets, an on-
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
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.
Paragraph (version A):
Networks with configurations that would lead to fragmentation of
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.
Paragraph (version B):
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.
Paragraph (version B):
For TCP, MSS clamping (Section 3.2 of RFC4459) is often used to
change the sender's TCP maximum segment size, but QUIC requires a
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:
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.
Paragraph (version B):
If path performance is limited when forwarding larger packets, an on-
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
used.
Paragraph (version B):
Networks with configurations that would lead to fragmentation of
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.
Paragraph (version B):
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.
Paragraph (version A):
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
compliant with the validation requirements of Section 14.2.1 of QUIC-
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.
Paragraph (version B):
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
compliant with the validation requirements of Section 14.2.1 of QUIC-
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.
Paragraph (version B):
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.