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

From: [email-masked]
Date: Mon, 20 Jan 2020 06:25:09 -0800

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/

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 20 Jan 2020 14:33:08 +0000

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.

---

From: Maksim Proshin <[email-masked]>
Date: Wed, 29 Jan 2020 10:53:45 +0000

Hi Gorry,

I've checked your updates related to my comments. I still have one thing I want you to clarify: 

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.
[Maxim] I can't find the new text. Can you please point the exact place where it has been added? Anyway, I'm fine with your proposal above. 

I also noticed a couple of new nits:
1. I assume the following sentence from Abstract should also include RFC 4960: "When published, this specification updates RFC 4821 and RFC 8085."
2. Section 4.4: The dot is missed in the last sentence. 

BR, Maxim

-----Original Message-----
From: tsvwg [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
Sent: Monday, January 20, 2020 17:33
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-datagram-plpmtud-13.txt

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:

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:
          This does not apply to DPLPMTU when probe packets use a design that

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.
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.

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.

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.

=======

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.

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

- 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.

——

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.

11.

12.

13.

14.

15.

16.

18.

19.

20.

21.

22.

23.

24.

26.

27.

28.

29.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 29 Jan 2020 14:46:19 +0000

> [Maxim] I can't find the new text. Can you please point the exact place where it has been added? Anyway, I'm fine with your proposal above.
Section 5 now states:

    DPLPMTUD SHOULD NOT be used by an upper PL or application if it is
    already used in a lower layer, DPLPMTUD SHOULD only be performed once
    between a pair of endpoints.  A PL MUST adjust the MPS indicated by
    DPLPMTUD to account for any additional overhead introduced by the PL.

Does that address the point?

> 1. I assume the following sentence from Abstract should also include RFC 4960: "When published, this specification updates RFC 4821 and RFC 8085."
Indeed, will be corrected.
> 2. Section 4.4: The dot is missed in the last sentence.
Yes, we will correct
Gorry

---

From: Maksim Proshin <[email-masked]>
Date: Thu, 30 Jan 2020 08:47:11 +0000

Hi Gorry,

Yes, it’s fine with me. No more comments.

BR, Maxim
From: Gorry Fairhurst [mailto:[email-masked]]
Sent: Wednesday, January 29, 2020 17:46
To: Maksim Proshin <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-datagram-plpmtud-13.txt

Hi Gorry,

17.

BR, Maxim
Gorry

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

best wishes,

Gorry

(as one of the editors)

Magnus: 2.

Formally update RFC4960.

NEW text in Abstract:

GF: DONE

GF: NEW text on MPS.

6.

9.

17.

25.

Martin Duke:

     > 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.

        Loss of a probe

Martin Duke:

NEW:

Martin Duke:

        path.  >>

NEW:

<https://tools.ietf.org/html/rfc4821><https://tools.ietf.org/html/rfc4821>] also apply to the use of the technique with a datagram PL. >>

NEW:

       PLPMTUD.</t>

NEW:

Martin Duke:

NEW:

Martin Duke:

Magnus:

1.

NEW:

        with UDP datagrams.</t>

And

NEW:

Processing PTB messages

NEW:

       A PTB message

            to test for a larger

Magnus: 4. Section 4.3:

TJ/GF: DONE

NEW:

               the required size.</t>

               <t>MIN_PMTU: 1280 bytes.

               the affected path.</t>

=======

GF: DONE

GF: DONE

Section 2:

Section 3:

NEW:

section:

NEW:

GF/TJ: DONE. Added text.

NEW:

GF/TJ: DONE

NEW:

NEW:

           (PLPMTU = MAX_PMTU).</t>

——

OLD starting:

——

Major comments:

2.

4.

  GF: DONE

NEW:

           search algorithm.

7.

GF: DONE - cite RFC8085.

8.

10.

or rephrase it.

11.

MUST?

GF: DONE

NEW:

12.

GF: DONE, added

NEW:

13.

HG:

14.

GF: DONE

15.

16.

GF: RFC-Ed can resolve!

18.

to consider it.

GF: DONE - changed to

NEW:

and at least

19.

GF: DONE rephrased.

20.

GF: DONE

21.

smaller PLPMTU value.

GF: DONE.

22.

23.

24.

GF: DONE - reworded.

26.

GF: DONE

NEW:

27.

to the probed size.

28.

GF: DONE

NEW:

does not

29.

GF: DONE.

On 20/01/2020 14:25, [email-masked]<mailto:[email-masked]> wrote:

                           Tom Jones

                           Michael Tuexen

                           Irene Ruengeler

                           Timo Voelker

   Pages           : 45

   Date            : 2020-01-20

Abstract:

    datagram transports.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 30 Jan 2020 08:56:30 +0000

OK,

Thanks,

Gorry

On 30/01/2020 08:47, Maksim Proshin wrote:
> *From:*Gorry Fairhurst [mailto:[email-masked]]
> *Sent:* Wednesday, January 29, 2020 17:46
> *To:* Maksim Proshin <[email-masked]>; [email-masked]; 
> [email-masked]; [email-masked]
> *Subject:* Re: [tsvwg] I-D Action: 
> draft-ietf-tsvwg-datagram-plpmtud-13.txt
>
>     To:[email-masked]  <mailto:[email-masked]>;[email-masked]  <mailto:[email-masked]>;[email-masked]  <mailto:[email-masked]>
>
>     <https://tools.ietf.org/html/rfc4821>  <https://tools.ietf.org/html/rfc4821>] also apply to the use of the technique with a datagram PL. >>
>
>     On 20/01/2020 14:25,[email-masked]  <mailto:[email-masked]>  wrote:
>