Re: [tsvwg] I-D Action: draft-ietf-tsvwg-datagram-plpmtud-13.txt

[Gorry Fairhurst <[e-mail]>]

We've just uploaded a revised version of the dplpmtud spec. The authors 
expect this addresses all the comments that we observed from the mailing 
list during WGLC. Please check and tell us if we have missed anything.

If you previously sent a review on a topic and would like to understand 
our update in response, there is a brief summary of the main comments in 
the list below.

best wishes,

Gorry

(as one of the editors)

Magnus: 2.
Section 6 specifies the method for a set of transports, and provides 
information to enable the implementation of PLPMTUD with other datagram 
transports and applications that use datagram transports.
Shouldn't the transports this document actually defines be explicitly 
listed here?
GF: This may be resolved in the new text?

1. RFC 4821 states that “an implementation SHOULD implement some form of 
MTU verification” and I don’t see how that aspect is addressed in 
DPLMTUD. Did I miss it or was it intentionally skipped?
GF: Maybe this relates to always probing a new PLPMTU before it is used 
- in which case, this is covered.
[Maxim] I refer to Section 7.8 of RFC 4821. My understanding of that 
section is that in some cases PLPMTUD might fail to find a correct 
PLPMTU value when e.g. a flow traverses multiple paths. In that case it 
might lead to packet losses. RFC 4821 recommends to check the loss rate 
and if it rises, to switch back to the previous value of eff_pmtu. I 
think that "always probing a new PLPMTU before it is used" is not enough.
First of all I wanted to understand if DPLPMTUD recommends any other 
mechanism of the verification or refers to RFC 4821 for that or 
intentionally skips it (then why). If DPLMTUD relies on RFC 4821 (which 
I'm fine with), I would clearly state that. If you want to cover it in 
DPLMTUD, it will probably require a new state and a timer (or re-use 
SEARCH_COMPLETE).
GF: DONE - The new spec no longer relies on RFC4821.
Formally update RFC4960.
NEW text in Abstract:
        Section 7.3 of RFC4960 recommends an endpoint
        apply the techniques in RFC4821 on a per-destination-address basis.
        RFC4960 is updated to replace this with a recommendation to use the
        method specified in this document.
- Amended introduction to SCTP to match this change.

3. Some PLs like SCTP can’t re-fragment data during retransmission which 
might lead to a problem if PMTU was decreased in run-time or the PLPMTU 
value was discovered wrongly. In some case the data would never be 
retransmitted. This aspect is not covered in the draft. I think it would 
be good at least to recommend to not set DF-bit for retransmitted data 
and to not fragment user data to pieces larger than BASE_PMTU (or even 
MIN_PMTU?).
GF: DONE
GF: NEW text on MPS.
  GF: NEW text based on SCTP method based on RFC4960:
    Section 6.9 of <xref target="RFC4960"></xref> describes fragmentation
     and reassembly by the PL when using SCTP.
     This describes the retransmission of messages when the MPS has been 
reduced by DPLPMTUD,
     and the use of IP fragmentation for this case.

5. Sec 3: “A method is REQUIRED to signal an appropriate MPS to the 
higher layer using the PL. ” – In general I don’t see how the draft 
addresses it. Is it up to the PL implementation or the PL specification? 
I assume it requires SCTP Socket API update. If so, is it out of scope 
of this doc?
GF: Should we specify this?
[Maxim] Now when I thought more about this, I'd like to understand the 
idea of this "REQUIRED". Do you want each PL regardless of whether it 
supports fragmentation or not to signal the MPS value every time the 
PLPMTU value is changed? If so I would probably replace it by "SHOULD" 
if fragmentation is supported.
Anyway, I personally think the signal should be specified if "REQUIRED" 
is used because implementers are forced to implement it and will need to 
care about the signal. If not specified, it will be many different 
implementations. If some PL already has such signal specified in another 
doc, it could be good to refer to it. In the SCTP case there is a way 
for the user to retrieve the current PMTU value but it is not a signal.
GF: DONE Updated to recommended and amended text to discuss this (see 3).

6.
Im: The default value is specified for some parameters but not for all 
and without clear explanation of why such values are used as default. 
The same is for recommended values. Shouldn’t it be consistent?
[Maxim] I meant mainly section 5.1.2. E.g. MAX_PROBES has the default 
value and BASE_PMTU has the recommended value. Other constants don't 
have any of them. For me it would be better to align it and e.g. put 
recommended values for all of them. Perhaps Section 5.1.1 could also be 
improved.
This is really a minor comment so you can skip it if there are no 
recommendations for other constants.
GF: Please check new text.

9.
Mi: Sec 1.3. why don’t you refer to SCTP specification RFC4960 instead 
of or additionally to RFC4821. Section 7.3 of RFC4960 has a statement 
“An endpoint SHOULD apply these techniques, and SHOULD do so on a 
per-destination-address basis.” so for me it’s more relevant to refer to 
RFC4960.
GF : Should this document update RFC4960?
[Maxim] Good question. I personally think it should update it. Let's see 
what Michael and Randall say.
GF: DONE  - amended to update RFC4960.

17.
Im/Q: Sec 4.4: “MUST suspend” – I assume it’s valid in general even when 
PL is using the other PL like QUIC uses UDP. If so, it would be good to 
clarify.
GF: I did not understand what text to add.
[Maxim] Let's agree on the issue first. If a PL uses another PL (like 
QUIC over UDP), does the draft assume that DPLPMTUD should only be 
enabled in the highest level (in QUIC)?
GF: DONE - text added that only one PL should do `DPLPMTUD and that MPS 
needs to be adjusted when a PL uses DPLPMUD in a pL below.

25.
Im: Sec 6.2 (maybe general for Sec 6): It would be good to recommend to 
enable fragmentation (do not set DF bit) for all packets except for 
probes or at least for retransmitted packets.
GF:  i understand and know this is done. in some SCTP implementations. 
What specific text is required?
[Maxim] I think the following text should work:
"In IPv4, it is NOT RECOMMENDED to set the DF bit for any packet which 
is not a probe."
If you think it's too strong then probably the following text is a 
better choice:
"When retransmitting any packet which is not a probe, SCTP SHOULD NOT 
set the DF bit."
GF: DONE - by (3) above and added a pointer in the SCTP method to the 
SCTP spec.

Martin Thomson: Have the authors considered putting their real names on 
the document?
Timo - DONE: The authors do not wish to use a different name.

Martin Duke:
Section 5 is that I should increment
     > PROBE_COUNT for each loss of a probe regardless of the overall loss
     > context. 4821 recommends simply ignoring the probe loss (not
     > incrementing PROBE_COUNT) if there are other losses. I would like
     > something of this nature explicitly discussed in Sec 5.
GF: DONE - New text added see below, and later:
        Loss of a probe
       packet SHOULD NOT be treated as an indication of congestion.  The
       loss of a probe packet SHOULD NOT directly trigger a congestion
       control reaction <xref target="RFC4821"></xref> because this could
       result in unnecessary reduction of the sending rate.

Martin Duke:
1) Are Probe packets counted against flightsize?
GF: DONE -  I agree they need not be (QUIC differs from other PLs but is 
now covered).
NEW:
  The decision about when to send a probe packets 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.

Martin Duke:
The sender needs to still realise that attempts to raise the PMTU
are likely to fail, so you shouldn't count loss of a probe as 
congestion, which is what
section 3, requirement 7 was about.
GF: DONE. New text was added elsewhere.

Martin Duke: Under what circumstances do probe losses indicate that the 
packet is too big?
GF: DONE - PLPMTU is reduced only when PROBE_COUNT>MAX_PROBES,
so never for an isolated loss.  In this text:
<<The DPLPMTUD sender treats
        isolated loss of a probe packet (with or without a corresponding
        PTB message) as a potential indication of a PMTU limit for the
        path.  >>
the word "potential" here was expected to read, "not yet confirmed, so 
try again to check...:"
- I see that isn't really clear, and we will rewrite the sentence.
NEW:
          The PROBE_COUNT is a count of the number of successive
           unsuccessful probe packets that have been sent. Each time a 
probe
           packet is acknowledged, the value is set to zero. (Some probe 
loss is
           expected while searching, therefore loss of a single probe is 
not
           an indication a PMTU problem.)

Martin Duke: 6.2.  DPLPMTUD for SCTP
<< All of the requirements in [RFC4821 
<https://tools.ietf.org/html/rfc4821>] also apply to the use of the
technique with a datagram PL. >>
GF: DONE: I also now have a note that this could finally prove 
problematic, and this para has been overtaken
by the more specific requirements that follow it.
NEW:
       <t>TCP PLPMTUD has been defined using standard TCP protocol 
mechanisms.
       The principles expressed in <xref target="RFC4821"></xref> also 
apply to
       the use of the technique with other PLs. Unlike TCP, datagram
       PLs require additional mechanisms and considerations to implement
       PLPMTUD.</t>

There only additional required concerned CC’s that work in packets, and 
we now have added:
NEW:
       <t> An update to the PLPMTU or MPS MUST NOT modify the congestion
           window measured in bytes <xref target="RFC4821"></xref>.
           Therefore, an increase in the packet size
           does not cause an increase the data rate in bytes per 
second.</t>

Martin Duke:
Maybe we should replace "without interfering with congestion control"
by "without interfering with congestion control and flow control"
GF: DONE  - We adapted text as below.
NEW:
         <t>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.</t>

Martin Duke:
  I am not fond of the way that important considerations relating to the 
loss of non-probe packets are buried in a reference to RFC 4821 in Sec 
4.1. Good PROBE_COUNT incrementing logic is quite subtle (see "Probe 
Inconclusive" in Sec 7.6.4 of RFC 4821). I suspect implementers will 
spend most of their time in Section 5, and I would like more discussion 
of these important issues in that section, probably directly under the 
definition of PROBE_COUNT.
Personally, I find the 4821 language to be quite vague and I would like 
an example safe algorithm (for example, off the top of my head, " 
decrement PROBE_COUNT for each non-probe packet lost between when the 
probe packet is sent and it is declared lost").
TJ/GF:DONE Follow-up discussion shows this not as an issue, but 
requiring clearer statement and now trying not saying that RFC 4821 
requirements apply. See other proposed text updates.

Magnus:
1.
Should this document beyond updating 4821, actually update RFC8085 also? 
That would require a small section basically saying that for 
applications that consider using RFC 4821 style should directly look 
into this document. Given the UDP context of RFC 8085 directly reading 
this document is much more useful.
GF/TJ: DONE, we agree - added:
NEW:
        The document updates RFC 4821 to specify the method for datagram 
PLs,
        and updates RFC 8085 as the method to use in place of RFC 4821
        with UDP datagrams.</t>
And
NEW:
     This document updates the message size guidelines in section 3.2 <xref
     target="RFC8085"></xref> to specify this method in place of PLPMTUD.

Magnus: 3. Section 3. Bullet 4:
Processing PTB messages
A PTB message MUST NOT be used to increase the PLPMTU [RFC8201].
I assume the requirement here is to not directly raise PLPMTU to the 
given PTB_SIZE. However, using it to indicate that probing may be worth 
performing around the given PTB_SIZE can be done? The issue from my 
perspective with the sentence is that "used" may include so many 
actions, not only the direct update of the PLPMTU estimate with PTB_SIZE.
GF/TJ: DONE - Wording issue… we propose:
NEW:
       A PTB message
       MUST NOT be used to increase the PLPMTU <xref
       target="RFC8201"></xref>, but could trigger a probe
            to test for a larger
            PLPMTU. A PTB_SIZE greater than the current
       PROBE_SIZE must be ignored. </t>

Magnus: 4. Section 4.3:
This can be triggered when a validated PTB message is received, or by 
another event that indicates the network path no longer sustains the 
current packet size, such as a loss report from the PL, or repeated lack 
of response to probe packets sent to confirm the PLPMTU.
Maxim: Regarding can/MAY, I think "usually improves" is the best 
phrasing here. It seems I misread it initially so my proposal with MAY 
wasn't appropriate.
GF: DONE - Text rewritten to match the remainder of the document. Please 
check new text.

Magnus: 6. Section 6.3.2:
The current specification of QUIC sets the following:
  ○ BASE_PMTU: 1200. A QUIC sender needs to pad initial packets to 1200 
bytes to confirm the path can support packets of a useful size.
  ○ MIN_PMTU: 1200 bytes. A QUIC sender that determines the PMTU has 
fallen below 1200 bytes MUST immediately stop sending on the affected path.
TJ/GF: DONE
NEW:
               <t>BASE_PMTU: 1280. A QUIC sender pads initial packets
               to confirm the path can support packets of
               the required size.</t>
               <t>MIN_PMTU: 1280 bytes.
                A QUIC sender that determines the PLPMTU
               has fallen below 1280 bytes MUST immediately stop sending on
               the affected path.</t>

TJ: Also added a figure to make clear the relationship between MPS and 
PLPMTU.

=======

Editorial issues and nits:

Would not "loss reports from the PL" be better than "a loss report from 
the PL"? It is not like the Black hole detection will trigger on a 
single loss or?
GF: DONE - the comment is related to the earlier comments on not 
assuming the reader needs to know RFC 4821.

Abstract: s/functionally/functionality/
GF: DONE

Section 1.1: In the first paragraph the clause that begins "and a 
method" should probably be reworded and become its own sentence.
GF: DONE

Section 2:
- I am unclear of the difference between "Packet Black Hole" and "ICMP 
Black Hole". By a literal reading of the definition, I think ICMP black 
holes are a superset of packet black holes? In any case, these subtypes 
appear only once in the draft (Sec 1.2), so perhaps simply eliminating 
this distinction is easiest. I don't know that Packet Black Holes are a 
useful concept for this draft.
GF: DONE. This text was added to address earlier comments, but does not 
need to define these as terms, the definitions have been replaced by 
bullets.

- Reading the definition for PL a few times, I was unclear if for 
SCTP/QUIC over UDP, UDP was the PL or the upper protocol. >From later 
context I *think* I inferred it to be the latter. I recognize that 
defining the upper protocol is difficult but I would like another pass 
to this. I'm happy to discuss further in a separate thread.
GF: DONE Added examples, did this resolve this?

Section 3:
- Item 1. I am unclear who the DPLPMTUD sender is to provide the 
information to. Is this to the peer, like a TCP MSS option, or is this 
an internal interface? Please clarify. If internal, please rephrase to 
"A DPLPMTUD sender is RECOMMENDED to consider local link limitations…”
GF: DONE - should have been /utilise/
NEW:
           A DPLPMTUD sender is RECOMMENDED to utlise
           information about the maximum size of packet that can be 
transmitted
           by the sender on the local link

- Can we order this section with REQUIRED up front and MAYs down below?
GF: DONE - We tried this - please see diff.

- The blanket adoption of RFC 4821 requirements is not well written. If 
the intention is to have all the 4821 requirements PLUS the 8 listed 
here, then #7 is listed twice. If that is not the intent that this is 
worded incorrectly.
GF: DONE. No longer relies on RFC4821 requirements - see the diff.

Section 4.2: "When supported, this mechanism [reporting specific 
datagrams] SHOULD also be used by DPLPMTUD to acknowledge reception of a 
probe packet." I think this sits somewhat uneasily with QUIC. The 
closest analogue to SCTP HEARTBEAT/HEARTBEAT_ACK (IRRC) is QUIC 
PATH_CHALLENGE/PATH_RESPONSE. We would certainly use PING instead of 
this. In practice, QUIC's total unambiguity with ACKs and packet numbers 
renders this irrelevant, but I don't love how this is worded.
GF: DONE - This is captured by other minor changes. Specifically in this 
section:
NEW:
mechanism MAY also be used by DPLPMTUD to acknowledge reception of a

Sec 4.5.1. Do we want to say anything about how NATs can complicate PTB 
validation, or are most NATs smart enough to handle this?
GF/TJ: DONE. Added text.
NEW:
         <t> A Network Addres Translation (NAT) device that translates a
             packet header, ought to also translate ICMP messages and 
update
             the ICMP quoted packet <xref target="RFC5508"></xref> in
             that message. If this is not correctly translated
             then the sender may not be able to associate the message
             with the PL that originated the packet, and hence this
             ICMP message cannot be validated.</t>

Sec 6.2.3.4 I think it is too strong to say that DTLS makes SCTP Common 
Header validation "not possible". There are certainly somewhat expensive 
options like storing the beginning of each encrypted packet or 
re-encrypting a stored copy of the plaintext packet to compare.
GF/TJ: DONE
NEW:
<xref target="RFC4960"></xref> does not specify a way to
         validate SCTP/DTLS ICMP message payload. This can prevent
         processing of PTB messages at the PL.

Timo: Updated diagram to follow the Black hole definition
NEW:
           <t> The state is exited to enter SEARCH_COMPLETE when the
           PROBE_COUNT reaches MAX_PROBES, a validated PTB is received that
           corresponds to the last successfully probed size
           (PTB_SIZE = PLPMTU), or a probe of size MAX_PMTU is acknowledged
           (PLPMTU = MAX_PMTU).</t>

——

GF: I think this text suffered rot, and was inconsistent with the 
principles and therefore fundamentally wrong:
DONE - please check new text.
OLD starting:
         <t>A PL sender needs to reduce the PLPMTU when it discovers the 
actual
         PMTU supported by a network path is less than the PLPMTU. This 
can be
         triggered when a validated PTB message is received, or by another
         event that indicates the network path no longer sustains the 
current
         packet size, such as loss reports from the PL, or repeated lack of
         response to probe packets sent to confirm the PLPMTU. Detection is
         followed by a reduction of the PLPMTU.</t>

——


Maxim: I’ve reviewed this draft and below you can find my comments. I 
think the document is in a good shape and I have only a couple of 
comments to discuss while the rest are minor or suggestions.
I can also add that we support PLPMTUD in our SCTP implementation but 
it’s not exactly the same as in this draft. There are some minor 
deviations but I don’t consider them severe.

Major comments:


2.
Sec 5.1.1: “This value MUST NOT be smaller than 1 second, and SHOULD be 
larger than 15 seconds.” and “PROBE_TIMER can be derived from the PL RTT 
estimate.” – I assume it means that if the RTT estimate is used, it 
still must not be less than 1 second. Is it true? If so, I think it 
would be good to understand where 1 second is taken from. Is it due to 
RTO.Min recommendations? If so, can it be better to say that the value 
must not be less than RTO.Min of that particular PL?
  GF:DONE -  Removed this. To meet the CC rules, the requirements are in 
terms of 1/sec.

4.
Sec 4.5.1: “PTB messages that have been validated MAY be utilized by the 
DPLPMTUD algorithm, but MUST NOT be used directly to set the PLPMTU.” – 
what is a purpose if this MUST NOT here? What is a risk to apply it 
after the validation? If it’s not applied immediately, it might cause 
data loss. Or did you mean something different here?
  GF: DONE
NEW:
     PTB messages that have been validated MAY be utilized by the
           DPLPMTUD algorithm, but MUST NOT be used directly to set the 
PLPMTU.
           A method that utilizes these PTB messages can improve the 
speed at
           the which the algorithm detects an appropriate PLPMTU by 
triggering
           an immediate probe for the PTB_SIZE, compared to
           one that relies solely on probing using a timer-based
           search algorithm.

7.
Im: Sec 1.2: “This has become the recommended approach for implementing 
PMTU discovery.” – recommended by IETF? can it be referenced/clarified?
GF: DONE - cite RFC8085.

8.
Mi: Sec 1.2: “see Section 4.5” - my understanding was that the section 
is reference here because it provides more details about “all PTB 
processing can be disabled and PLPMTUD can completely replace Classical 
PMTUD” but I failed to find it in that section. Either the reference is 
wrong or I misunderstood the purpose of having it there.
GF: DONE - removed citation.

10.
Im/Q: Sec 3: “A DPLPMTUD sender is RECOMMENDED to provide information 
about the maximum size of packet” – provide to whom? Propose to clarify 
or rephrase it.
GF: DONE - Corrected by Magnus /provide/utilise/

11.
Im/Q: Sec 3: “The mechanism needs to be robust to the possibility that 
packets could be significantly delayed along a network path.” - Isn’t it 
MUST?
GF: DONE
NEW:
mechanism is REQUIRED to be robust

The local PL endpoint => The destination PL endpoint?
GF: DONE Actually it’s covered by the first requirement, removed.

12.
Im: Sec 3, Req 6: I think it would be also good to mention that if data 
is used in a probe the sender must be able to retransmit it in a smaller 
packet(s) because otherwise it would be lost again and again.
GF: DONE, added
NEW:
possibly using a smaller PLPMTU.

13.
Im: Sec 3, Req 7: Can it be improved saying MUST NOT when data is not 
used in a probe? And SHOULD when “isolated” data probe is lost.
HG:
GF: DONE - addressed in an update for Magnus. The method still works, 
even if with unfortunate side effects so MUST ius
rather harsh - instead we explain why this is important./

14.
Mi: Sec 4.2: “These PLs need to either rely on an application protocol 
to detect this loss.” – “either” should be removed.
GF: DONE

15.
Mi: Sec 4.3: “There are two alternative mechanism:” –> “mechanisms”
GF:  DONE (removed the sentence)

16.
Mi: Something wrong with references to RFCs when 2 or more of them are 
used. E.g. [RFC1191][RFC8201]
GF: RFC-Ed can resolve!

18.
Mi/Q: Sec 4.5.2: “larger than minimum size accepted” – I assume “larger 
than or equal to”. If so, all further formulas should also be corrected 
to consider it.
GF: DONE - changed to
NEW:
and at least

19.
Im: Sec 5.1.2: “expected to work for most paths” – it’s better to say 
“all paths” due to “expected”.
GF: DONE rephrased.

20.
Im/Q: Sec 5.1.3: “PROBED_SIZE” – I wonder why it’s not called “PROBE_SIZE”.
GF: DONE

21.
Im: Sec 5.1.4: I assume that Base phase confirms the connectivity for 
BASE_PMTU and not in general as the connectivity can be achieved by a 
smaller PLPMTU value.
GF: DONE.

22.
Im/Q: Sec 5.1.4: Is it assumed that Base is the first phase? If so, it 
would be good to clearly state it.
GF: DONE - No longer in latest rev.

23.
Mi: Sec 5.2: “Note: Not all changes are not shown to simplify the 
diagram.” – the second “not” should be removed.
GF: DONE - Text no longer in latest rev.

24.
Im: There are “may”, “should”, etc in a couple of places. They either 
should be capital or rephrased.
GF: DONE - reworded.

26.
Im/Q: Sec 6.2: Should or should not probe packets influence assoc and 
path error counters? I think it’s “SHOULD” when a probe is acknowledged 
and “SHOULD NOT” when it’s lost. In other words probes should only clear 
the error counters in my view.
GF: DONE
NEW:
  A successful probe updates the association and path
             counters, but an unsuccessful probe is discounted (assumed
             to be a result of choosing too large a PLPMTU).
[Maxim] It's fine with me.

27.
Im/Q: Sec 6.2.1.2: “The HEARTBEAT chunk carries a Heartbeat Information 
parameter which should include, besides the information suggested in 
[RFC4960], the probe size ...” – Why is it required? If the sender of HB 
is able to uniquely associate the HB with the HB ACK, it only needs to 
remember the current PROBED_SIZE value.
GF: DONE Text no longer in latest rev. This was intending to be padding 
to the probed size.

28.
Im: Sec 9: “A node supporting DPLPMTUD MUST therefore appropriately 
validate the payload of PTB messages” – in addition it must not be used 
to directly set PTB value as prescribed in section 4.5.1. I would add it.
GF: DONE
NEW:
       The successful processing of this message can trigger a probe and 
does not
       directly update the PLPMTU for the path.</t>

29.
Im: Sec 9: A potential attack when PTB increases PLPMTU is not described 
here. It would be good to add it.
GF: DONE.


On 20/01/2020 14:25, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the IETF.
>
>          Title           : Packetization Layer Path MTU Discovery for Datagram Transports
>          Authors         : Godred Fairhurst
>                            Tom Jones
>                            Michael Tuexen
>                            Irene Ruengeler
>                            Timo Voelker
> 	Filename        : draft-ietf-tsvwg-datagram-plpmtud-13.txt
> 	Pages           : 45
> 	Date            : 2020-01-20
>
> Abstract:
>     This document describes a robust method for Path MTU Discovery
>     (PMTUD) for datagram Packetization Layers (PLs).  It describes an
>     extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path
>     MTU Discovery for IPv4 and IPv6.  The method allows a PL, or a
>     datagram application that uses a PL, to discover whether a network
>     path can support the current size of datagram.  This can be used to
>     detect and reduce the message size when a sender encounters a packet
>     black hole (where packets are discarded).  The method can probe a
>     network path with progressively larger packets to discover whether
>     the maximum packet size can be increased.  This allows a sender to
>     determine an appropriate packet size, providing functionality for
>     datagram transports that is equivalent to the Packetization Layer
>     PMTUD specification for TCP, specified in RFC 4821.
>
>     The document updates RFC 4821 to specify the method for datagram PLs,
>     and updates RFC 8085 as the method to use in place of RFC 4821 with
>     UDP datagrams.  Section 7.3 of RFC4960 recommends an endpoint apply
>     the techniques in RFC4821 on a per-destination-address basis.
>     RFC4960 is updated to recommend that SCTP uses the method specified
>     in this document instead of the method in RFC4821.
>
>     The document also provides implementation notes for incorporating
>     Datagram PMTUD into IETF datagram transports or applications that use
>     datagram transports.
>
>     When published, this specification updates RFC 4821 and RFC 8085.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-13
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-datagram-plpmtud-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-datagram-plpmtud-13
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/