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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 30 January 2020 08:56 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46187120119 for <tsvwg@ietfa.amsl.com>; Thu, 30 Jan 2020 00:56:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqQ_neADe1gO for <tsvwg@ietfa.amsl.com>; Thu, 30 Jan 2020 00:56:38 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id D034B12010F for <tsvwg@ietf.org>; Thu, 30 Jan 2020 00:56:37 -0800 (PST)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 605E51B00119; Thu, 30 Jan 2020 08:56:32 +0000 (GMT)
To: Maksim Proshin <maksim.proshin@mera.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <157953030955.1507.9882967315489009757@ietfa.amsl.com> <66cb2beb-4e7d-9ee9-4227-620fcffb6e86@erg.abdn.ac.uk> <3c8b5e5d745341a5b89d00b7455648c2@mera.com> <188a33e7-9938-5536-6aae-9fd02e1bac18@erg.abdn.ac.uk> <1600e80828b44122908b8af5c443f30e@mera.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <02917593-4a91-2679-7601-87b2f2464225@erg.abdn.ac.uk>
Date: Thu, 30 Jan 2020 08:56:30 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <1600e80828b44122908b8af5c443f30e@mera.com>
Content-Type: multipart/alternative; boundary="------------513A25A519CE14C06F1F9A36"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/IXEAgCGVpXmR0MYrkoMcwa8Tl9Q>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-datagram-plpmtud-13.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2020 08:56:44 -0000

OK,

Thanks,

Gorry

On 30/01/2020 08:47, Maksim Proshin wrote:
>
> Hi Gorry,
>
> Yes, it’s fine with me. No more comments.
>
> BR, Maxim
>
> *From:*Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
> *Sent:* Wednesday, January 29, 2020 17:46
> *To:* Maksim Proshin <maksim.proshin@mera.com>om>; tsvwg@ietf.org; 
> internet-drafts@ietf.org; i-d-announce@ietf.org
> *Subject:* Re: [tsvwg] I-D Action: 
> draft-ietf-tsvwg-datagram-plpmtud-13.txt
>
> On 29/01/2020 10:53, Maksim Proshin wrote:
>
>     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.
>
> 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?
>
>       
>
>       
>
>     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."
>
> Indeed, will be corrected.
>
>       
>
>     2. Section 4.4: The dot is missed in the last sentence.
>
> Yes, we will correct
>
>       
>
>     BR, Maxim
>
> Gorry
>
>       
>
>       
>
>     -----Original Message-----
>
>     From: tsvwg [mailto:tsvwg-bounces@ietf.org] On Behalf Of Gorry Fairhurst
>
>     Sent: Monday, January 20, 2020 17:33
>
>     To:tsvwg@ietf.org  <mailto:tsvwg@ietf.org>;internet-drafts@ietf.org  <mailto:internet-drafts@ietf.org>;i-d-announce@ietf.org  <mailto:i-d-announce@ietf.org>
>
>     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:
>
>     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>  <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,internet-drafts@ietf.org  <mailto:internet-drafts@ietf.org>  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/
>
>       
>
>       
>