Subject: [tsvwg] New revision of DPLPMTU - Asking for WGLG in Sinagpore

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 11 Nov 2019 18:52:58 +0000

Hi TSVWG'ers and people who helped us get to this stage,

Could I ask ask you to look at the latest spec for DLPMTUD?
https://tools.ietf.org/pdf/draft-ietf-tsvwg-datagram-plpmtud-09.pdf

(Please excuse the errors in the table-of-contents - that was not our 
fault).

This draft has been around for some time, mainly waiting for us editors 
to get the details correct and readable (at the same time). We plan to 
ask the WG to start the WGLC process at the Singapore IETF meeting for 
draft -09, and it would be great to know that people had seen the latest 
version!

best wishes

Gorry & the editing team.

---

From: Lars Eggert <[email-masked]>
Date: Tue, 12 Nov 2019 09:35:07 +0200

Hi,

> https://tools.ietf.org/pdf/draft-ietf-tsvwg-datagram-plpmtud-09.pdf

here is a short review

Lars

INTRODUCTION, paragraph 15:
> Table of Contents

  There seem to be some editing labels in the ToC; xml2rfc issue?

Section 1.2., paragraph 2:
>    In contrast to PMTUD, Packetization Layer Path MTU Discovery
>    (PLPMTUD) [RFC4821] does not rely upon reception and validation of
>    PTB messages.  It is therefore more robust than Classical PMTUD.
>    This has become the recommended approach for implementing PMTU
>    discovery with TCP.

  Would maybe omit "with TCP" given that the point here is that it can
  be a general mechanism.

Section 6., paragraph 0:
>    6.  Probe loss recovery: It is RECOMMENDED to use probe packets that
>        do not carry any user data.  Most datagram transports permit
>        this.  If a probe packet contains user data requiring
>        retransmission in case of loss, the PL (or layers above) are
>        REQUIRED to arrange any retransmission/repair of any resulting
>        loss.  DPLPMTUD is REQUIRED to be robust in the case where probe
>        packets are lost due to other reasons (including link
>        transmission error, congestion).

  The recommendation in the first sentence seems a bit too strict, and
  is then lessened in the following text anyway. I'd say "It is
  RECOMMENDED to use probe packets that do not carry any user data that
  would require retransmission if lost." Because this mechanism can
  apply to partially-reliable protocols or protocols that can recover
  lost data by other means (e.g., FEC), where sticking such data into
  probe packets is OK.

Section 8., paragraph 0:
>    7.  Probing and congestion control: 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.  Loss of a probe packet SHOULD NOT be treated as an
>        indication of congestion and the loss SHOULD NOT directly trigger
>        a congestion control reaction [RFC4821].

  Why "SHOULD NOT" and not "MUST NOT"?

>    8.  Shared PLPMTU state: The PLPMTU value could also be stored with
>        the corresponding entry in the destination cache and used by
>        other PL instances.  The specification of PLPMTUD [RFC4821]
>        states: "If PLPMTUD updates the MTU for a particular path, all
>        Packetization Layer sessions that share the path representation
>        (as described in Section 5.2 of [RFC4821]) SHOULD be notified to
>        make use of the new MTU".  Such methods MUST be robust to the
>        wide variety of underlying network forwarding behaviors, PLPMTU
>        adjustments based on shared PLPMTU values should be incorporated
>        in the search algorithms.  Section 5.2 of [RFC8201] provides
>        guidance on the caching of PMTU information and also the relation
>        to IPv6 flow labels.

  Replace "could" with "MAY" in the first sentence, given that the rest
  of the paragraph then uses 2119 language?

Section 8., paragraph 1:
>    In addition, the following principles are stated for design of a
>    DPLPMTUD method:

  Not sure if the 2119 language in the bullets below is appropriate,
  given that no mechanisms are actually defined that it could apply to.

Section 4.1., paragraph 0:
> 4.1.  PLPMTU Probe Packets

  Section 4.1 doesn't use any 2119 language. Is this intentional? If
  not, I've identified some suggested replacements below; there are
  others that I haven't highlighted.

Section 4.1., paragraph 1:
>    The DPLPMTUD method relies upon the PL sender being able to generate
>    probe packets with a specific size.  TCP is able to generate these
>    probe packets by choosing to appropriately segment data being sent
>    [RFC4821].  In contrast, a datagram PL that needs to construct a
>    probe packet has to either request an application to send a data
>    block that is larger than that generated by an application, or to
>    utilize padding functions to extend a datagram beyond the size of the
>    application data block.  Protocols that permit exchange of control
>    messages (without an application data block) could alternatively
>    prefer to generate a probe packet by extending a control message with
>    padding data.

  "MAY" instead of "could alternatively"?

Section 4.1., paragraph 2:
>    A receiver needs to be able to distinguish an in-band data block from
>    any added padding.  This is needed to ensure that any added padding
>    is not passed on to an application at the receiver.

  "MUST" instead of "needs to"?

Section 4.1., paragraph 3:
>    This results in three possible ways that a sender can create a probe
>    packet listed in order of preference:

  It is not clear that this preference ordering is correct for
  partially-reliable transports. You would want to probe with unreliable
  application data instead of padding to increase potential goodput.

Section 4.1., paragraph 5:
>    Probing using application data and padding
>    data:  A probe packet that

  Nit: Weird line break

Section 5.1.2., paragraph 2:
>    MAX_PROBES:  The MAX_PROBES is the maximum value of the PROBE_COUNT
>                 counter (see Section 5.1.3).  MAX_PROBES represents the
>                 limit for the number of consecutive probe attempts of
>                 any size.  The default value of MAX_PROBES is 10.

  Why 10?

Section 5.1.2., paragraph 5:
>    MAX_PMTU:    The MAX_PMTU is the largest size of PLPMTU.  This has to
>                 be less than or equal to the minimum of the local MTU of
>                 the outgoing interface and the destination PMTU for
>                 receiving.  An application, or PL, MAY reduce the
>                 MAX_PMTU when there is no need to send packets larger
>                 than a specific size.

  Given path changes, is this really a constant?

Section 5.2., paragraph 2:
>    Note: Some state changes are not shown to simplify the diagram.

  But I hope they are described in the text - where?

Section 6., paragraph 1:
>    This section specifies protocol-specific details for datagram PLPMTUD
>    for IETF-specified transports.

  But it doesn't - it often *refers to* other documents where such
  details are specified, e.g., for QUIC. Suggest to make it very clear
  which subsections are intending to be normative for other protocols,
  and which are informative.

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 18 Nov 2019 06:53:11 -0800

Regarding the -10 draft:

On Mon, Nov 11, 2019 at 11:35 PM Lars Eggert wrote:
> On 2019-11-11, at 20:52, Gorry Fairhurst wrote:
...
>   Why "SHOULD NOT" and not "MUST NOT"?

The edits to address this comment have for some reason removed
the first sentence of the paragraph, which does not seem right. Was
that change intended?

Thanks

Mike Heard

---

From: G Fairhurst <[email-masked]>
Date: Wed, 20 Nov 2019 06:33:49 +0800

> the first sentence of the paragraph, which does not seem right. Was
You are quite correct!

This was unintentional, we will fix this, together with a couple of 
minor editorial mistakes and re-issue.

Gorry

---

From: G Fairhurst <[email-masked]>
Date: Mon, 25 Nov 2019 16:03:05 +0000

Thanks very much for the review. We have now revised the draft. Please 
see responses inline.

Gorry

 >   There seem to be some editing labels in the ToC; xml2rfc issue?
XML2RFC v3 format - Now resolved.

 >   Would maybe omit "with TCP" given that the point here is that it can
done.

 >   lost data by other means (e.g., FEC), where sticking such data into
Aha, we agreed.
We rewrote that as:
"It is RECOMMENDED to use probe packets that do not carry any user data 
that would require retransmission if lost."

 >   Why "SHOULD NOT" and not "MUST NOT"?
We kept "SHOULD NOT" Because although suboptimal, a use that may 
accidentally view this as a congestion signal is actually safe to treat 
the loss as a congestion indication. We did however
add an explantion at the end of the para
"because this could result in unecessary reduction of the sending rate."

 >   of the paragraph then uses 2119 language?
Indeed, done.
 > Section 3., paragraph 1:
We reviewed the text, but kept the recommendations and requirements 
language, because we think any systen implementing this would need to 
abide by these.

 >   "MAY" instead of "could alternatively"?
We checked, and updated, including this recommendation.

 >   "MUST" instead of "needs to"?
We added "A receiver is REQUIRED to be able to distinguish"...

 >   application data instead of padding to increase potential goodput.
That's a continuation of your earlier query regarding partial 
reliability, and we updated the text to align with our response.

 >>    data:  A probe packet that
Fixed.

 >>                 any size.  The default value of MAX_PROBES is 10.
There should be a default. There was a long story about how to approach 
the design, which missed the final text. The SCTP implementation chose 
3, and that number has been used before in IETF protocols to provide 
robustness against isolated loss - the most important reason for 
being>1. New proposed text:
"The default value of MAX_PROBES is 3.  This
value is greater than 1 to provide robustness to
isolated packet loss."

 >   Given path changes, is this really a constant?
It's not derived from the path, but passed from the API. This has been 
made clearer.

 >   But I hope they are described in the text - where?
The legend was updated. The (simplified) diagram indeed omits some of 
the cases, which are fully described in the text.

 >   and which are informative.
Ah - because for some protocol specs were later moved to other docs, so: 
Quite so. The text has been rewritten.

We also added that probing is limited to once/RTT (itself a result of 
this not being subject to congestion control), rather than hinting at 
RFC80865 in the security considerations section.

And also clarified the case where:
"PTB_SIZE < MIN_MTU "
- which someone asked, and although specified elsewhere, it was not 
clearly called out as a case failing validation.

These edits are now included in draft -11, along with some other review 
comments.

Thanks again,

Gorry