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

[Lars Eggert <[e-mail]>]

Hi,

On 2019-11-11, at 20:52, Gorry Fairhurst <[e-mail]> wrote:
> 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

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.