Subject: [tsvwg] WGLC for DPLPMTUD

From: Wesley Eddy <[email-masked]>
Date: Thu, 5 Dec 2019 10:36:14 -0500

This email starts a Working Group Last Call for the Datagram Path MTU 
Discovery draft:

https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/

This is targeted for Proposed Standard.

Please in the next couple of weeks send any further inputs you have to 
the TSVWG list.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 09 Dec 2019 19:43:34 +1100

Have the authors considered putting their real names on the document?  RFC 7997 should be in full production now.

On Mon, Dec 9, 2019, at 18:47, Lars Eggert wrote:
> This document is of interest to the QUIC WG; please send your comments to TSVWG.
> 
> Lars
> 
> > Begin forwarded message:
> > 
> > *From: *Wesley Eddy <[email-masked]>
> > *Subject: **[tsvwg] WGLC for DPLPMTUD*
> > *Date: *December 5, 2019 at 17:36:14 GMT+2
> > *To: *"[email-masked]" <[email-masked]>
> > 
> > This email starts a Working Group Last Call for the Datagram Path MTU Discovery draft:
> > 
> > Please in the next couple of weeks send any further inputs you have to the TSVWG list.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Dec 2019 09:48:19 +0000

Hi,

I have reviewed this document to get a head start on the AD review. There are a few issues that needs to be addressed. When these have been addressed it is from my perspective ready for publication. 

Several issues have to do with the relation to QUIC and it specification. Therefore I do CC the QUIC WG to see if we can agree how to handle where to describe the QUIC protocol's implementation of DPLPMTUD. See issue 5 and forward. 

Reviewed HTML version as this is an v3 document and like to see how the SVG etc looks. https://www.ietf.org/id/draft-ietf-tsvwg-datagram-plpmtud-12.html
	
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. 	

2. Section 1.3: 
	
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? 
	
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.
	
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. 
	
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? 

5. Section 6.3:
Inconsistency between 6.3 and draft-ietf-quic-transport24. 
	
It recommends the use of PADDING frames to build the probe packet. Pure probe-only packets are constructed with PADDING frames and PING frames to create a padding only packet that will elicit an acknowledgement.
	
This is now stated in 14.3. I also note that draft-quic-transport wrongly references 6.4 when it is 6.3. 
	
As this is a question of coordination between these two specifications, I do wonder if it would not be best to move the whole 6.3 into draft-ietf-quic-transport section 14.3 so that the QUIC adaptation is contained in the QUIC specification. It will requires some changes to this text to correctly point in to the DPLPMTUD specification but likely minimizes these inconsistencies. Clearly this needs to be handshaken with the QUIC WG. 
	
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.
	
Draft-ietf-quic-transport-24 states: 
	
  When implementing the algorithm in Section 5.3 of [DPLPMTUD], the
  initial value of BASE_PMTU SHOULD be consistent with the minimum QUIC
  packet size (1232 bytes for IPv6 and 1252 bytes for IPv4).
	
7. Section 6.3.4: 
QUIC operates over the UDP transport, and the guidelines on ICMP validation as specified in Section 5.2 of [RFC8085] therefore apply. In addition to UDP Port validation QUIC can validate an ICMP message by looking for valid Connection IDs in the quoted packet.
	
Section 14.2 of draft-ietf-quic-transport-24 includes much more on ICMP validation. Also the issue discussed in 14.3.1 is relevant here. 

Cheers

Magnus Westerlund

---

From: Timo Völker <[email-masked]>
Date: Tue, 17 Dec 2019 14:00:50 +0000

Hello Martin,

we considered it, but decided to use ascii characters only to have equal content in the ascii and html (or PDF) version.

Timo

> On 9. Dec 2019, at 09:43, Martin Thomson <[email-masked]> wrote:
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 18 Dec 2019 07:28:44 +1100

On Wed, Dec 18, 2019, at 01:00, Timo Völker wrote:
> we considered it, but decided to use ascii characters only to have 
> equal content in the ascii and html (or PDF) version.

The content would be the same no matter the output format.  It's worth trying.

---

From: Maksim Proshin <[email-masked]>
Date: Fri, 20 Dec 2019 11:38:16 +0000

Hi,

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:

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?

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?

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

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?

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?

Minor comments:

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?
7.
Im: Sec 1.2: “This has become the recommended approach for implementing PMTU discovery.” – recommended by IETF? can it be referenced/clarified?
8.
Mi: Sec 1.2: “see Section 4.5<https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-12#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.
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 relelvant to refer to RFC4960.
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.
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?
The local PL endpoint => The destination PL endpoint?
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.
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.
14.
Mi: Sec 4.2: “These PLs need to either rely on an application protocol to detect this loss.” – “either” should be removed.
15.
Mi: Sec 4.3: “There are two alternative mechanism:” –> “mechanisms”
16.
Mi: Something wrong with references to RFCs when 2 or more of them are used. E.g. [RFC1191<https://tools.ietf.org/html/rfc1191>][RFC8201]
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.
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.
19.
Im: Sec 5.1.2: “expected to work for most paths” – it’s better to say “all paths” due to “expected”.

20.

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

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

23.

Mi: Sec 5.2: “Note: Not all changes are not shown to simplify the diagram.” – the second “not” should be removed.

24.

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

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.

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.

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.

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.

29.

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

BR, Maxim

From: Wesley Eddy <[email-masked]<mailto:[email-masked]>>
Date: 5 December 2019 at 15:36:34 GMT
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [tsvwg] WGLC for DPLPMTUD
This email starts a Working Group Last Call for the Datagram Path MTU Discovery draft:

---

From: G Fairhurst <[email-masked]>
Date: Fri, 20 Dec 2019 15:18:52 +0000

Maxim: I’ve reviewed this draft and below you can find my response to 
your comments, marked as GF. If you see anything more I should do, 
please say.

Best wishes,

Gorry

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.
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 - all 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: Is this correct:
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).

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: 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: G Fairhurst <[email-masked]>
Date: Fri, 20 Dec 2019 15:20:54 +0000

Maxim, thanks again for all your comments. These comments below will 
require more help to resolve. Please help us discuss on the list, or 
help by offering some initial text proposals.

Best wishes,

Gorry

Major comments:

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: QUERY - I am unsure I understand the question - but maybe this 
relates to always probing a new PLPMTU before it is used - in which 
case, this is covered.

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: QUERY What does the WG think?

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?

Minor comments:

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?
GF : Which parameters do you mean?

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 relelvant to refer 
to RFC4960.
GF : Should this document 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.

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?

26.
GF: Is this correct below:

---

From: Maksim Proshin <[email-masked]>
Date: Mon, 23 Dec 2019 08:19:38 +0000

Hi Gorry,

I'm fine with your answers to these comments but I'd like to check that my understanding of the following response is correct:

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.
[Maxim] So the basic idea of DPLMTUD is to switch to the BASE state and start from BASE_PMTU if PTB_SIZE < PLPMTU. Also the PLPMTU value is changed to BASE_PMTU in that case. Is my understanding correct? 

Would it better to replace "can" by MAY in the added sentence?

BR, Maxim

-----Original Message-----
From: G Fairhurst <[email-masked]> 
Sent: Friday, December 20, 2019 6:19 PM
To: Maksim Proshin <[email-masked]>
Cc: [email-masked]
Subject: Re: [tsvwg] WGLC for DPLPMTUD - Response to WGLC comments (presumed resolved)

Maxim: I’ve reviewed this draft and below you can find my response to your comments, marked as GF. If you see anything more I should do, please say.

Best wishes,

Gorry

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.

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

15.

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.

19.

20.

21.

22.

23.

24.

26.

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

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 23 Dec 2019 10:22:51 +0000

Great, see below,

Sent from my iPad

> On 23 Dec 2019, at 08:19, Maksim Proshin <[email-masked]> wrote:
> 
> Hi Gorry,
> 
To be sure: The way I would see this is...
1) you can implement and ignore PTB messages ... this is at least robust, in which case the PLPMTU needs to return to a safe value (base) and probe higher. This takes several RTTs to find a new PLPMTU that is larger than base.

2) you can (and would be encouraged to) implement and use Validated PTB messages. In this case, the usual next step after receiving an ICMP message, is to probe with the PTB size indicated in the PTB ICMP message, and see if that works - which it usually will within one RTT, resulting in an appropriate choice of the PLPMTU.
2a) If that probe did not work, then the sender will revert to the safe PMTU (base) and grow from there.

> Would it better to replace "can" by MAY in the added sentence?
In this case, I thought this described that improvements can happen, rather than permitting the protocol to take an action. Perhaps we ought to change it to “is expected to improve...” or usually improves?

Gorry

---

From: Maksim Proshin <[email-masked]>
Date: Mon, 23 Dec 2019 10:42:53 +0000

Hi Gorry,

Thanks! I think we're aligned now. 
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.

BR, Maxim

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: Monday, December 23, 2019 13:23
To: Maksim Proshin <[email-masked]>
Cc: [email-masked]
Subject: Re: [tsvwg] WGLC for DPLPMTUD - Response to WGLC comments (presumed resolved)

Great, see below,

Sent from my iPad

Gorry

---

From: Maksim Proshin <[email-masked]>
Date: Mon, 23 Dec 2019 11:02:24 +0000

Hi Gorry,

Please see below my follow-up.

BR, Maxim

-----Original Message-----
From: G Fairhurst <[email-masked]> 
Sent: Friday, December 20, 2019 6:21 PM
To: Maksim Proshin <[email-masked]>
Cc: [email-masked]
Subject: Re: [tsvwg] WGLC for DPLPMTUD - WGLC comments, still to be resolved.

Maxim, thanks again for all your comments. These comments below will require more help to resolve. Please help us discuss on the list, or help by offering some initial text proposals.

Best wishes,

Gorry

Major comments:

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: QUERY - I am unsure I understand the question - but 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).   

3.

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.   

Minor comments:

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?
GF : Which parameters do you mean?
[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.

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

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)? 

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

26.

[Maxim] It's fine with me.