Skip to main content

Packetization Layer Path MTU Discovery for Datagram Transports
draft-ietf-tsvwg-datagram-plpmtud-22

Revision differences

Document history

Date Rev. By Action
2020-09-10
22 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-08-20
22 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-06-23
22 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-06-10
22 (System) IANA Action state changed to No IANA Actions from In Progress
2020-06-10
22 (System) RFC Editor state changed to EDIT
2020-06-10
22 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-06-10
22 (System) Announcement was received by RFC Editor
2020-06-10
22 (System) IANA Action state changed to In Progress
2020-06-10
22 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-06-10
22 Amy Vezza IESG has approved the document
2020-06-10
22 Amy Vezza Closed "Approve" ballot
2020-06-10
22 Amy Vezza Ballot approval text was generated
2020-06-10
22 Magnus Westerlund Document is now to be approved. Moved normative QUIC procedures to the QUIC transport document (draft-ietf-quic-transport).
2020-06-10
22 Magnus Westerlund IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2020-06-10
22 Magnus Westerlund Ballot approval text was generated
2020-06-10
22 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-22.txt
2020-06-10
22 (System) New version approved
2020-06-10
22 (System) Request for posting confirmation emailed to previous authors: Michael Tuexen , Tom Jones , Timo Voelker , Gorry Fairhurst , Irene Ruengeler
2020-06-10
22 Tom Jones Uploaded new revision
2020-05-12
21 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-21.txt
2020-05-12
21 (System) New version approved
2020-05-12
21 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst , Timo Voelker
2020-05-12
21 Tom Jones Uploaded new revision
2020-05-07
20 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-20.txt
2020-05-07
20 (System) New version approved
2020-05-07
20 (System) Request for posting confirmation emailed to previous authors: Timo Voelker , Irene Ruengeler , Tom Jones , Michael Tuexen , Gorry Fairhurst
2020-05-07
20 Tom Jones Uploaded new revision
2020-04-24
19 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from Approved-announcement to be sent::Point Raised - writeup needed
2020-04-09
19 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
2020-04-09
19 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. The document is clear, easy to read and quite useful (perhaps mixing too many …
[Ballot comment]
Thank you for the work put into this document. The document is clear, easy to read and quite useful (perhaps mixing too many PL protocols though).

Please find below nee non-blocking NIT.

I hope that this helps to improve the document,

Nice to read about the outcomes of the NEAT project

Regards,

-éric

==NIT ==

-- Section 2 --
Looking for details in " A Packet is the IP header plus the IP payload." is it worth mentioning the IPv6 extension headers or using "IP headers" (plural form) ?
2020-04-09
19 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-04-09
19 Robert Wilton
[Ballot comment]
Firstly I would like to say thank you for writing this document.

I have a general concern, not specifically with this document, but …
[Ballot comment]
Firstly I would like to say thank you for writing this document.

I have a general concern, not specifically with this document, but with the overall complexity of the solution.  I.e. the algorithm that is described has to contend with a lot of unreliable information (e.g. are packets dropped because of congestion or some other routing failure, hard to know whether PTB messages can be relied upon etc), there are also several different ways that the probes can be sent etc.

Not the subject of this document, but it feels like life could be significantly simpler if somehow there was a mechanism to getting a set of agree a set of defined minimum PLPMTU that network may support.  E.g. perhaps 1280, 2000, 4000, 8000, 16000 octets.  My assumption here is that the underlying core link MTUs would be higher to cope with header overheads.

A few comments on specific sections of the document:

1) I would include PTB in the terminology section.

3. Features Required to Provide Datagram PLPMTUD

Most of the the requirements in this section use RFC 2119 language, but a few don't:

  7.  Probing and congestion control: The decision about when to send
        a probe packet 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 or suspended during congestion.

Rather than "does not need to be limited", would this be better stated as  "SHOULD NOT be limited" or "MAY not be limited"?


  11.  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.
       
The second sentence could be stated something like:

"Flow control MUST NOT apply to DPLPMTU when probe packets use a design that does not carry user data to the remote application"


5.1.2.  Constants

  MIN_PLPMTU:  The MIN_PLPMTU is the smallest allowed probe packet
      size.  For IPv6, this value is 1280 bytes, as specified in
      [RFC8200].  For IPv4, the minimum value is 68 bytes.

Does it really make sense to probe for a path MTU of 68 bytes.  Would it make sense for applications to be able to control the MIN_PLPMTU that they find acceptable?  E.g. if IPv6 has this at 1280 and QUIC has uses 1280, perhaps many applications/implementations would like to use 1280 as a reasonable lower bound rather than 68 bytes?
2020-04-09
19 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-04-08
19 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-04-08
19 Benjamin Kaduk
[Ballot comment]
[I'm reviewing the native HTML, so line breaks in quoted text are
locally generated]

We could perhaps benefit from more clarity in several …
[Ballot comment]
[I'm reviewing the native HTML, so line breaks in quoted text are
locally generated]

We could perhaps benefit from more clarity in several places about
whether a given size is measured at the IP layer or the PL (some
locations mentioned in the per-section comments).

Should RFC 8085 be cited as BCP 145?

It would be nice to have a bit more detail about how to effectuate
things like robustness to inconsistent paths, but I don't think the lack
of such concrete guidance should hold up publication of this document.

I mention in the per-section comments a few instances of apparent
internal inconsistency; they don't quite rise to DISCUSS-level, but
please take a look.

Abstract

    This 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. [...]

nit(?): the wording here is a bit odd; I think we want to say that it
"updates RFC 8085 to refer to the method specified in this document
instead of the method in RFC 4821 for use with UDP datagrams".

Section 1.1

    Classical PMTUD is subject to protocol failures. One failure arises when
    traffic using a packet size larger than the actual PMTU is black-holed
    (all datagrams sent with this size, or larger, are discarded).

nit: if "this size" is "the actual PMTU", shouldn't this just be
"strictly larger than this size", since packets of exactly that size
will pass?

    When the router issuing the ICMP message drops a tunneled packet, the
    resulting ICMP message will be directed to the tunnel ingress. This
    tunnel endpoint is responsible for forwarding the ICMP message and also
    processing the quoted packet within the payload field to remove the
    effect of the tunnel, and return a correctly formatted ICMP message to
    the sender [I-D.ietf-intarea-tunnels]. Failure to do this prevents the
    PTB message reaching the original sender.

Is it supposed to be implie that this is a little bit complicated and
many existing tunnels don't do it properly?

    In this case, when a packet sent by the server encounters a problem
    after the ECMP router, then any resulting ICMP message also needs to be
    directed by the ECMP router towards the original sender.

Similarly, is it implicit that it's complicated for the ECMP router to
do this, it's not currently implemented well, etc.?

    When an ICMP message is generated by a router in a network segment that
    has inserted a header into a packet, the quoted packet could contain
    additional protocol header information that was not included in the
    original sent packet, and which the PL sender does not process or may
    not know how to process. This could disrupt the ability of the sender to
    validate this PTB message.

Should/can the entity that added the extra header be inspecting ICMP to
remove the header from the quoted packet in the reverse direction?  (We
could perhaps try to normalize the language between this point and the
following on on NAT behavior.)

    Section 10.2 of [RFC4821] recommended a PLPMTUD probing method for
    the Stream Control Transport Protocol (SCTP). SCTP utilizes probe
    packets consisting of a minimal sized HEARTBEAT chunk bundled with a
    PAD chunk as defined in [RFC4820]. However, RFC 4821 did not provide
    a complete specification. The present document replaces this by
    providing a complete specification.

nit(?): s/replaces this/replaces that description/?

Section 2

    Packetization Layer (PL):
    The PL is a layer of the network stack that places data into packets
    and performs transport protocol functions. Examples of a PL include:
    TCP, SCTP, SCTP over DTLS or QUIC.

nit: Serial comma, please!

    PTB_SIZE:
    The PTB_SIZE is a value reported in a validated PTB message that
    indicates next hop link MTU of a router along the path

nit: missing article ("the next hop link MTU"?)

Section 3

    A PTB message MUST NOT be used to increase the PLPMTU [RFC8201], but
    could trigger a probe to test for a larger PLPMTU. A PL_PTB_SIZE
    that is greater than that currently probed MUST be ignored. A valid
    PTB_SIZE is converted to a PL_PTB_SIZE before it is to be used in
    the DPLPMTUD state machine.

Perhaps these last two sentences should be swapped, so we talk about how
the PL_PTB_SIZE is computed before we talk about ignoring invalid
values?

    The decision about when to send a probe packet does not need to be
    limited by the congestion controller.

Does the congestion controller need to account for the size/bandwidth of
the probe packets in its pacing mechanism, though?

    Path validation: It is RECOMMENDED that methods are robust to path
    changes that could have occurred since the path characteristics were
    last confirmed, and to the possibility of inconsistent path
    information being received.

What would such robustness look like?  (Why is it not REQUIRED?)

Section 4.1

    A PL that uses a probe packet carrying application data and needs
    protection from the loss of this probe packet could perform
    transport-layer retransmission/repair of the data block (e.g., by
    retransmission after loss is detected or by duplicating the data
    block in a datagram without the padding data). This retransmitted
    data block might possibly need to be sent using a smaller PLPMTU,
    which could need the PL to to use a smaller packet size to traverse
    the end-to-end path. (This could utilize endpoint network-layer or a
    PL that can re-segment the data block into multiple datagrams).

nit: check the grammar around "utilize endpoint network-layer"?

Section 4.2

    Transport protocols can include end-to-end methods that detect and
    report reception of specific datagrams that they send (e.g., DCCP
    and SCTP provide keep-alive/heartbeat features).

Does a packet-level ACK mechanism (e.g., like QUIC but not TCP) suffice?

Section 4.3

    When the method detects the current PLPMTU is not supported,
    DPLPMTUD sets a lower PLPMTU, and sets a lower MPS. The PL then
    confirms that the new PLPMTU can be successfully used across the
    path. A probe packet could need to have a size less than the size of
    the data block generated by the application.

Why is "less than half the size" noteworthy?

Section 4.4

    Operational experience reveals that IP fragmentation can reduce the
    reliability of Internet communication
    [I-D.ietf-intarea-frag-fragile], which may reduce the success of
    retransmission.

nit: if "success" is a binary yes/no, then this could be "reduce the
probability of success of the retransmission".  (I add "the" in "the
retransmission" as well, since we refer to the specific retransmission
after the initial loss and MPS change, not retransmission in general.)

Section 4.6.1

    A PL that receives a PTB message from a router or middlebox performs
    ICMP validation as specified in Section 5.2 of [RFC8085][RFC8201].

If we're going to have a section number, we need only one RFC reference!

    PTB messages that have been validated MAY be utilized by the
    DPLPMTUD algorithm, but MUST NOT be used directly to set the PLPMTU.
    The PL_PTB_SIZE is smaller than the PTB_SIZE because it is reduced
    by headers below the PL including any IP options or extensions added
    to the PL packet.

nit: this transition is pretty abrupt.

Section 4.6.2

    Before using the size reported in the PTB message it must first be
    converted to a PL_PTB_SIZE. A set of checks are intended to provide
    protection from a router that reports an unexpected PTB_SIZE. The PL
    also needs to check that the indicated PL_PTB_SIZE is less than the
    size used by probe packets and at least the minimum size accepted.

How do these "checks" relate to the "validation" that was discussed in
the previous section?

Section 5

    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.

This seems to imply an expectation of a communications channel between
PLs on the same endpoint.  I don't see anything in this document
discussing such a channel; is there anything (more) that's useful that
we can say?

Section 5.1.1

    DPLPMTUD MAY inhibit sending probe packets when no application data
    has been sent since the previous probe packet. A PL preferring to
    use an up-to-date PMTU once user data is sent again, can choose to
    continue PMTU discovery for each path. However, this could result in
    sending additional packets.

How is this "could" and not "will"/"would"?  (Twice)

    The various timers could be implemented using a single timer

Is this an incomplete thought?  (There's no full stop, and it doesn't
give much clarity for me.)

Section 5.1.2

    MIN_PLPMTU:
    The MIN_PLPMTU is the smallest allowed probe packet size. For IPv6,
    this value is 1280 bytes, as specified in [RFC8200]. For IPv4, the
    minimum value is 68 bytes.

This feels like slightly curious naming, as the "PL" infix suggests that
it is the size usable at the packetization layer, but the quoted
constants include the IP headers.

    BASE_PLPMTU:
    The BASE_PLPMTU is a configured size expected to work for most
    paths. The size is equal to or larger than the MIN_PLPMTU and
    smaller than the MAX_PLPMTU. In the case of IPv6, this value is
    derived from the IPv6 minimum link MTU of 1280 bytes

"Derived from" but using what derivation mechanism and/or arriving at
what value?

Section 5.1.3

    PROBED_SIZE:
    The PROBED_SIZE is the size of the current probe packet. This is a
    tentative value for the PLPMTU, which is awaiting confirmation by an
    acknowledgment.

Size at which layer?

Section 5.1.4

    The Base Phase confirms connectivity to the remote peer using
    packets of the BASE_PLPMTU. This phase is implicit for a
    connection-oriented PL (where it can be performed in a PL connection
    handshake).

This seems slightly internally inconsistent, in that it seems to say
that BASE_PLPMTU size packets are always used, but the implicit
connection-handshake method seems unlikely to actually do so.
(Also, if we always did so, then the following paragraph about
confirming BASE_PLPMTU support would be redundant.)

    Search Complete:
    The Search Complete Phase is entered when the PLPMTU is supported
    across the network path

It seems like this would be trivially true for (e.g.) the initial PLPMTU
set to BASE_PLPMTU on the Base->Search transition, yet I don't expect we
terminate Search immediately in that case!  Presumably this is intended
to say also that the PLPMTU corresponds to the actual PMTU as well?

Section 5.2

nit(?): the diagram shows PTB: PLPTB_SIZE < BASE_PLPMTU as cause for a
transition from BASE to ERROR, though of course this would only occur
after the PTB is validated.  Perhaps that doesn't need to be in the
figure, though.

Section 5.3.1

    The PROBE_COUNT is initialized to zero when the first probe with a
    size greater than or equal to PLPMTUD is sent. A timer is used to
    trigger the sending of probe packets of size PROBED_SIZE, larger
    than the PLPMTU.

This seems inconsistent about whether we use PROBE_COUNT when probing
with the current PLPMTU size -- we initialize the count to zero when we
first send one, but the timer only triggers sending of larger packets.

Section 5.3.2

I confess I was expecting a more detailed specification of how to pick
probe sizes, here.

Section 6.1

    To use common method for managing the PLPMTU has benefits, both in
    the ability to share state between different processes and
    opportunities to coordinate probing.

Nit: singular/plural mismatch "common"/"method"

Section 6.2

    Section 10.2 of [RFC4821] specified a recommended PLPMTUD probing
    method for SCTP and Section 7.3 of [RFC4960] and recommended an
    endpoint apply the techniques in RFC4821 on a
    per-destination-address basis.

nit: spurious "and" after "[RFC4960]".

    Section 6.9 of [RFC4960] describes dividing the user messages into
    data chunks sent by the PL when using SCTP. This notes that once an
    SCTP message has been sent, it cannot be re-segmented. [RFC4960]
    describes the method to retransmit data chunks when the MPS has
    reduced, and the use of IP fragmentation for this case.

Should we say something about "such behavior is unchanged by this
document"?

Section 6.2.1.2

    The HEARTBEAT chunk carries a Heartbeat Information parameter which
    includes, besides the information suggested in [RFC4960], the probe
    size, which is the size of the complete datagram.

IIUC the Heartbeat Information layout is entirely at the sender's
discretion, so the implementation will have to pick a way to convey the
probe size in it; should we be more explicit about this?

    Probing starts directly after the PL handshake, before data is sent.
    Assuming this behavior (i.e., the PMTU is smaller than or equal to
    the interface MTU), this process will take several round trip time
    periods, dependent on the number of DPLPMTUD probes sent. The
    Heartbeat timer can be used to implement the PROBE_TIMER.

(But sending data doesn't have to wait for DPLPMTUD to complete, right?)

Section 6.2.2.2

    Packet probing can be performed as specified in Section 6.2.1.2. The
    maximum payload is reduced by 8 bytes, which has to be considered
    when filling the PAD chunk.

(8 bytes of UDP header?)

Section 6.2.3.2

(Interesting that we don't have a note about payload reduction to be
considered when filling the PAD chunk, as we did in Section 6.2.2.2.)

Section 6.2.3.4

    [RFC4960] does not specify a way to validate SCTP/DTLS ICMP message
    payload.

("and neither does this document"?)

Section 6.3.2

    QUIC provides an acknowledged PL, a sender can therefore enter the
    BASE state as soon as connectivity has been confirmed.

[This seems entirely redundant with the content of Section 6.3.1.]

Section 9

    An on-path attacker able to create a PTB message could forge PTB
    messages that include a valid quoted IP packet. Such an attack could
    be used to drive down the PLPMTU.

Are there cases where such an on-path attacker would not also be able to
actually drop traffic larger than the forged PTB PMTU value?

    It is possible that the information about a path is not stable. This
    could be a result of forwarding across more than one path that has a
    different actual PMTU or a single path presents a varying PMTU. The
    design of a PLPMTUD implementation SHOULD consider how to mitigate
    the effects of varying path information. One possible mitigation is
    to provide robustness (see Section 5.4) in the method that avoids
    oscillation in the MPS.

This document specifies some PLPMTUD mechanics; should we say what we do
(and don't) say about this topic for those protocols we do cover?

    A node performing DPLPMTUD could experience conflicting information
    about the size of supported probe packets. This could occur when
    multiple paths are concurrently in use and these exhibit a different
    PMTU. If not considered, this could result in packets not being
    delivered (black holed) when the PLPMTU results in a packet larger
    than the smallest actual PMTU.

It feels like this content has high overlap with the previous paragraph;
is it reasonable to try consolidating them?
2020-04-08
19 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-04-08
19 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-04-08
19 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-04-08
19 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-04-08
19 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-04-07
19 Roman Danyliw
[Ballot comment]
Thank you for your updates in response to the SECDIR review by Stephen Farrell (and thanks for the review Stephen!)

** As previously …
[Ballot comment]
Thank you for your updates in response to the SECDIR review by Stephen Farrell (and thanks for the review Stephen!)

** As previously mentioned, please consider the stability of the [I-D.ietf-quic-transport] when advancing this document

** Section 1.  Per “ICMP messages can be filtered by middleboxes (including firewalls) [RFC4890].  A stateful firewall could be configured …”, couldn’t all firewalls (stateless and stateful) also do this?

** Editorial Nits:
Section 4.1.  Typo. s/retransmited/retransmitted/

Section 4.1. s/… which could need the PL to to use a smaller packet size…/…which could force the PL to use a smaller packet size …/

Section 5.1.2.  Typo. s/valugreater/value greater/
2020-04-07
19 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-04-07
19 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-04-07
19 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-04-04
19 Erik Kline
[Ballot comment]
{Yes}

[nits]

S1.1

* It's not clear to me that "stateful" in the phrase "stateful firewall"
  matters here. I imagine a "stateless" …
[Ballot comment]
{Yes}

[nits]

S1.1

* It's not clear to me that "stateful" in the phrase "stateful firewall"
  matters here. I imagine a "stateless" firewall could just as easily block
  incoming ICMP messages.

S4.5

* The "[RFC8201]" didn't render as a clickable link. Source XML weirdness?
  Same in S4.6.1.

S5.

* First sentence of second paragraph seems like two sentences, one sentence
  with a parenthetical comment, or a run-on sentence.  Also, I think "only be
  performed once" here means "only performed at one layer" rather than "only
  performed at one point in time"?

S5.1.1

* The "section 3.1.1" link seems to be internal to the draft rather than linked
  into RFC 8085, as I would expect from the text. (this happens twice in this
  section)

S5.3.3

* Is there any additional detail worth including here?  It asserts that a PL
  sender is able to detect inconsistencies, but I wonder whether more guidance
  (or an example) might be helpful to implementors.

S6.2.2

* s/is to be added//

S6.2.3.4

* Maybe check the XML for the "[RFC4960]" reference, since it doesn't seem to
  have been converted into a link.
2020-04-04
19 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2020-04-04
19 Stephen Farrell Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Stephen Farrell. Sent review to list.
2020-04-03
19 Tero Kivinen Request for Telechat review by SECDIR is assigned to Stephen Farrell
2020-04-03
19 Tero Kivinen Request for Telechat review by SECDIR is assigned to Stephen Farrell
2020-04-03
19 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-04-03
19 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-19.txt
2020-04-03
19 (System) New version approved
2020-04-03
19 (System) Request for posting confirmation emailed to previous authors: Michael Tuexen , Irene Ruengeler , Timo Voelker , Tom Jones , Gorry Fairhurst
2020-04-03
19 Tom Jones Uploaded new revision
2020-04-02
18 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-04-02
18 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-18.txt
2020-04-02
18 (System) New version approved
2020-04-02
18 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Gorry Fairhurst , Timo Voelker , Irene Ruengeler , Michael Tuexen
2020-04-02
18 Tom Jones Uploaded new revision
2020-03-31
17 Murray Kucherawy
[Ballot comment]
Kudos on a very approachable document.  The thin air up in the ART layers had me fearing something that said "TSVWG" on it. …
[Ballot comment]
Kudos on a very approachable document.  The thin air up in the ART layers had me fearing something that said "TSVWG" on it.

Section 2:
* The definition for EMTU_R appears to double up on itself.

Section 3:
* In bullet 2, "On request, a DPLPMTUD sender is REQUIRED to be able to transmit a packet  ..." -- I read this as "If I ask you to do X, you MUST be able to do X", versus "you MUST do X".  Was that the intent?
* In bullet 3, there's reference to a "feedback method" that is REQUIRED, but this method is unspecified.  Is that defined elsewhere, or is out of scope here?

Section 4.1:
Nits:
* "... uses a probe packet carrying an application data ..." -- s/an//
* "... this probe packet, could perform ..." -- s/,//
* "This retransmited data block ..." --  typo: "retransmitted"

Section 4.3:
* PROBE_COUNT and MAX_PROBES are first used here, though they are not defined until later in the document in the DPLPMTUD section.
Nit:
* "... data is sent again, MAY choose ..." -- s/,//

Section 4.4:
Nit:
* "... over clearing the DF-bit in the IPv4 header ..." -- s/-/ /

Section 4.6.1:
* "For example, by checking the value ..." -- Suggest: "For example, it could check the value..."
Nit:
* "... from a router or middlebox, performs ..." -- s/,//

Section 5:
Nit:
* "... in a lower layer, DPLPMTUD SHOULD only ..." -- s/,/./

Section 5.1.1:
Nit:
* "... use an up-to-data PMTU once ..." -- I think you mean "up-to-date"

Section 5.1.2:
Nit:
* "... from a MAX_PROBES valugreater than 1 because ..." -- s/valugreater/value greater/

Section 5.3.3:
Nit:
* "... inconsistent, when, for example, ..." -- remove the first comma

Section 6.1.1:
Nit:
* "... from off-path insertion of data [RFC8085], suitable methods include ..." -- s/, s/. S/

Section 6.3.2:
Nit:
* "... packets of the required size, this sets the ..." -- either s/, t/. T/, or s/this/which/

Section 9:
"Parallel forwarding paths SHOULD be considered."  What is the specific action being recommended here?
Nits:
* "This protection if provided ..." -- s/if/is/
* "... design (see Section 1.1), this method therefore ..."  -- I think "this" should begin a new sentence.
* "An on-path attacker, able to create ..." -- remove comma
* "This could occur when there are multiple paths are concurrently in use." -- s/there are//
2020-03-31
17 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from No Record
2020-03-31
17 Tim Chown Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tim Chown. Sent review to list.
2020-03-30
17 Murray Kucherawy
[Ballot comment]
[ballot position under construction]

Section 2:
* The definition for EMTU_R appears to double up on itself.

Section 3:
* In bullet 2, …
[Ballot comment]
[ballot position under construction]

Section 2:
* The definition for EMTU_R appears to double up on itself.

Section 3:
* In bullet 2, "On request, a DPLPMTUD sender is REQUIRED to be able to transmit a packet  ..." -- I read this as "If I ask you to do X, you MUST be able to do X", versus "you MUST do X".  Was that the intent?
* In bullet 3, there's reference to a "feedback method" that is REQUIRED, but this method is unspecified.  Is that defined elsewhere, or is out of scope here?

Section 4.1:
Nits:
* "... uses a probe packet carrying an application data ..." -- s/an//
* "... this probe packet, could perform ..." -- s/,//
* "This retransmited data block ..." --  typo: "retransmitted"

Section 4.3:
* PROBE_COUNT and MAX_PROBES are first used here, though they are not defined until later in the document.
Nit:
* "... data is sent again, MAY choose ..." -- s/,//

Section 4.4:
Nit:
* "... over clearing the DF-bit in the IPv4 header ..." -- s/-/ /

Section 4.6.1:
* "For example, by checking the value ..." -- Suggest: "For example, it could check the value..."
Nit:
* "... from a router or middlebox, performs ..." -- s/,//

Section 5:
Nit:
* "... in a lower layer, DPLPMTUD SHOULD only ..." -- s/,/./

Section 5.1.1:
Nit:
* "... use an up-to-data PMTU once ..." -- I think you mean "up-to-date"

Section 5.1.2:
Nit:
* "... from a MAX_PROBES valugreater than 1 because ..." -- s/valugreater/value greater/

Section 9:
"Parallel forwarding paths SHOULD be considered."  What is the specific action being recommended here?

Nits:
* "This protection if provided ..." -- s/if/is/
* "... design (see Section 1.1), this method therefore ..."  -- I think "this" should begin a new sentence.
* "An on-path attacker, able to create ..." -- remove comma
* "This could occur when there are multiple paths are concurrently in use." -- s/there are//
2020-03-30
17 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2020-03-30
17 Murray Kucherawy
[Ballot comment]
[ballot position under construction]

Section 2:
* The definition for EMTU_R appears to double up on itself.

Section 3:
* In bullet 2, …
[Ballot comment]
[ballot position under construction]

Section 2:
* The definition for EMTU_R appears to double up on itself.

Section 3:
* In bullet 2, "On request, a DPLPMTUD sender is REQUIRED to be able to transmit a packet  ..." -- I read this as "If I ask you to do X, you MUST be able to do X", versus "you MUST do X".  Was that the intent?
* In bullet 3, there's reference to a "feedback method" that is REQUIRED, but this method is unspecified.  Is that defined elsewhere, or is out of scope here?

Section 4.1:
Nits:
* "... uses a probe packet carrying an application data ..." -- s/an//
* "... this probe packet, could perform ..." -- s/,//
* "This retransmited data block ..." --  typo: "retransmitted"

Section 4.3:
* PROBE_COUNT and MAX_PROBES are first used here, though they are not defined until later in the document.
Nit:
* "... data is sent again, MAY choose ..." -- s/,//

Section 4.4:
Nit:
* "... over clearing the DF-bit in the IPv4 header ..." -- s/-/ /

Section 4.6.1:
* "For example, by checking the value ..." -- Suggest: "For example, it could check the value..."
Nit:
* "... from a router or middlebox, performs ..." -- s/,//

Section 9:
"Parallel forwarding paths SHOULD be considered."  What is the specific action being recommended here?

Nits:
* "This protection if provided ..." -- s/if/is/
* "... design (see Section 1.1), this method therefore ..."  -- I think "this" should begin a new sentence.
* "An on-path attacker, able to create ..." -- remove comma
* "This could occur when there are multiple paths are concurrently in use." -- s/there are//
2020-03-30
17 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2020-03-30
17 Martin Duke
[Ballot comment]
I'm excited for this to go to RFC once the QUIC reference clears.

Normative issue:

Sec 3, item #9 "An update to the …
[Ballot comment]
I'm excited for this to go to RFC once the QUIC reference clears.

Normative issue:

Sec 3, item #9 "An update to the PLPMTU (or MPS) MUST NOT modify the congestion window". Would it not be OK to round down the congestion window to remain a multiple of the MPS? Probably not a big issue in practice, but I would hate to constrain an implementer in this way. I would suggest "MUST NOT increase".

Nits:

Sec 2. In the definition for EMTU_R, put "the largest datagram size that can be reassembled" in quotes, and delete "by EMTU_R (Effective MTU to receive)"

Sec 4.1. delete word in brackets:  "A PL that uses a probe packet carrying [an] application data..."

Sec 4.6.2 I think this list of inequalities would be easier to read if it was ranked in order of increasing PL_PTB_SIZE.

5.1.1. s/up to data/up to date
2020-03-30
17 Martin Duke Ballot comment text updated for Martin Duke
2020-03-30
17 Martin Duke
[Ballot comment]
I'm excited for this to go to RFC once the QUIC reference clears.

Normative issue:
Sec 3, item #9 "An update to the …
[Ballot comment]
I'm excited for this to go to RFC once the QUIC reference clears.

Normative issue:
Sec 3, item #9 "An update to the PLPMTU (or MPS) MUST NOT modify the congestion window". Would it not be OK to round down the congestion window to remain a multiple of the MPS? Probably not a big issue in practice, but I would hate to constrain an implementer in this way. I would suggest "MUST NOT increase".

Nits:
Sec 2. In the definition for EMTU_R, put "the largest datagram size that can be reassembled" in quotes, and delete "by EMTU_R (Effective MTU to receive)"
Sec 4.1. delete word in brackets:  "A PL that uses a probe packet carrying [an] application data..."
Sec 4.6.2 I think this list of inequalities would be easier to read if it was ranked in order of increasing PL_PTB_SIZE.
5.1.1. s/up to data/up to date
2020-03-30
17 Martin Duke [Ballot Position Update] New position, Yes, has been recorded for Martin Duke
2020-03-30
17 Murray Kucherawy
[Ballot comment]
[ballot position under construction]

Section 2:
* The definition for EMTU_R appears to double up on itself.

Section 3:
* In bullet 2, …
[Ballot comment]
[ballot position under construction]

Section 2:
* The definition for EMTU_R appears to double up on itself.

Section 3:
* In bullet 2, "On request, a DPLPMTUD sender is REQUIRED to be able to transmit a packet  ..." -- I read this as "If I ask you to do X, you MUST be able to do X", versus "you MUST do X".  Was that the intent?
* In bullet 3, there's reference to a "feedback method" that is REQUIRED, but this method is unspecified.  Is that defined elsewhere, or is out of scope here?

Section 9:
"Parallel forwarding paths SHOULD be considered."  What is the specific action being recommended here?

Nits:
* "This protection if provided ..." -- s/if/is/
* "... design (see Section 1.1), this method therefore ..."  -- I think "this" should begin a new sentence.
* "An on-path attacker, able to create ..." -- remove comma
* "This could occur when there are multiple paths are concurrently in use." -- s/there are//
2020-03-30
17 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2020-03-30
17 Murray Kucherawy
[Ballot comment]
[ballot position under construction]

Section 2:
* The definition for EMTU_R appears to double up on itself.

Section 9:
"Parallel forwarding paths SHOULD …
[Ballot comment]
[ballot position under construction]

Section 2:
* The definition for EMTU_R appears to double up on itself.

Section 9:
"Parallel forwarding paths SHOULD be considered."  What is the specific action being recommended here?

Nits:
* "This protection if provided ..." -- s/if/is/
* "... design (see Section 1.1), this method therefore ..."  -- I think "this" should begin a new sentence.
* "An on-path attacker, able to create ..." -- remove comma
* "This could occur when there are multiple paths are concurrently in use." -- s/there are//
2020-03-30
17 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2020-03-29
17 Murray Kucherawy
[Ballot comment]
[ballot position under construction]

Section 9:
"Parallel forwarding paths SHOULD be considered."  What is the specific action being recommended here?

Nits:
* "This …
[Ballot comment]
[ballot position under construction]

Section 9:
"Parallel forwarding paths SHOULD be considered."  What is the specific action being recommended here?

Nits:
* "This protection if provided ..." -- s/if/is/
* "... design (see Section 1.1), this method therefore ..."  -- I think "this" should begin a new sentence.
* "An on-path attacker, able to create ..." -- remove comma
* "This could occur when there are multiple paths are concurrently in use." -- s/there are//
2020-03-29
17 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2020-03-27
17 Cindy Morgan Placed on agenda for telechat - 2020-04-09
2020-03-27
17 Magnus Westerlund IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2020-03-27
17 Magnus Westerlund Ballot has been issued
2020-03-27
17 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund
2020-03-27
17 Magnus Westerlund Created "Approve" ballot
2020-03-23
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-03-23
17 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-17.txt
2020-03-23
17 (System) New version approved
2020-03-23
17 (System) Request for posting confirmation emailed to previous authors: Irene Ruengeler , Timo Voelker , Gorry Fairhurst , Tom Jones , Michael Tuexen
2020-03-23
17 Tom Jones Uploaded new revision
2020-03-11
16 Francis Dupont Request for Last Call review by GENART Completed: Ready. Reviewer: Francis Dupont. Sent review to list.
2020-03-10
16 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2020-03-09
16 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2020-03-09
16 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-tsvwg-datagram-plpmtud-15, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-tsvwg-datagram-plpmtud-15, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2020-03-09
16 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-16.txt
2020-03-09
16 (System) New version approved
2020-03-09
16 (System) Request for posting confirmation emailed to previous authors: Timo Voelker , Gorry Fairhurst , Irene Ruengeler , Michael Tuexen , Tom Jones
2020-03-09
16 Tom Jones Uploaded new revision
2020-03-03
15 Stephen Farrell Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Stephen Farrell. Sent review to list.
2020-03-03
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2020-03-03
15 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Chown
2020-02-27
15 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2020-02-27
15 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2020-02-26
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stephen Farrell
2020-02-26
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Stephen Farrell
2020-02-25
15 Cindy Morgan IANA Review state changed to IANA - Review Needed
2020-02-25
15 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-03-10):

From: The IESG
To: IETF-Announce
CC: magnus.westerlund@ericsson.com, tsvwg-chairs@ietf.org, draft-ietf-tsvwg-datagram-plpmtud@ietf.org, Wesley Eddy , …
The following Last Call announcement was sent out (ends 2020-03-10):

From: The IESG
To: IETF-Announce
CC: magnus.westerlund@ericsson.com, tsvwg-chairs@ietf.org, draft-ietf-tsvwg-datagram-plpmtud@ietf.org, Wesley Eddy , wes@mti-systems.com, tsvwg@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Packetization Layer Path MTU Discovery for Datagram Transports) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document: - 'Packetization Layer Path MTU
Discovery for Datagram Transports'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-03-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 RFC 4821 on a per-destination-address basis.  RFC
  4960
, RFC 6951 and RFC 8261 are updated to recommend that SCTP, SCTP
  encapsulated in UDP and SCTP encapsulated in DTLS use the method
  specified in this document instead of the method in RFC 4821.

  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 4960, RFC 4821, RFC
  8085
and RFC 8261.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ballot/


No IPR declarations have been submitted directly on this I-D.




2020-02-25
15 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-02-25
15 Magnus Westerlund Last call was requested
2020-02-25
15 Magnus Westerlund Ballot approval text was generated
2020-02-25
15 Magnus Westerlund IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-02-25
15 Magnus Westerlund Last call announcement was changed
2020-02-24
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-02-24
15 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-15.txt
2020-02-24
15 (System) New version approved
2020-02-24
15 (System) Request for posting confirmation emailed to previous authors: Irene Ruengeler , Timo Voelker , Michael Tuexen , Tom Jones , Gorry Fairhurst
2020-02-24
15 Tom Jones Uploaded new revision
2020-02-17
14 Magnus Westerlund Sent AD eval comments to WG mailing list and authors.
2020-02-17
14 Magnus Westerlund IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2020-02-17
14 Magnus Westerlund IESG state changed to AD Evaluation from Publication Requested
2020-02-17
14 Magnus Westerlund Ballot writeup was changed
2020-02-12
14 Wesley Eddy
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.  This is the right target due to the scope, content, and intent of the work.  It is properly indicated in the header.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  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, RFC 4960 and RFC 8085.

Working Group Summary:

There were no major controversies or points of questionable consensus in the process of working on this document.  The document is somewhat related to work in other working groups (such as QUIC), since it lays out the framework for path MTU discovery that can be used in any datagram-based protocol.

Document Quality:

There have been a number of separate implementations at different stages of the document's maturity. An implementation for SCTP targets the FreeBSD kernel, and is starting the review process to be included.
This code also is the basis for a userland stack currently used in browsers for WebRTC data channels.
Another implementation with UDP options was done for the FreeBSD kernel, though has not tracked the draft since 2018.  Three early implementations were also done as part of the EU MAMI project, to test possible algorithms and check if the specification could be implemented, but these did not enter production code.  Two of these implementations were with UDP application protocols, for testing, and the third was for a QUIC implementation.

Personnel:

Wesley Eddy is the document shepherd.  Magnus Westerlund is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have done a full review of the document, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No additional special reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Good consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No possible appeals mentioned.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are a few erroneous idnits warnings about the Updates header based on the abstract.  I think this is because the header was truncated, and should be fixed by the RFC Editor if needed.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There is a normative reference to the QUIC specification, which is still an I-D (not yet published as an RFC).  This is fine, because it should block this document in the RFC Editor queue waiting for that reference to be resolved.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downrefs.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No RFCs are obsoleted, and the three that are updated are noted in the header, explained in the abstract, and discussed properly in the document.  The 4960 update is discussed in the later section specific to SCTP (which is appropriate) and not in the introduction, but the other two documents updated are discussed clearly in the introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There are no IANA requests.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.
2020-02-12
14 Wesley Eddy IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2020-02-12
14 Wesley Eddy IESG state changed to Publication Requested from I-D Exists
2020-02-12
14 Wesley Eddy IESG process started in state Publication Requested
2020-02-12
14 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-14.txt
2020-02-12
14 (System) New version approved
2020-02-12
14 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Timo Voelker , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2020-02-12
14 Tom Jones Uploaded new revision
2020-02-07
13 Wesley Eddy
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.  This is the right target due to the scope, content, and intent of the work.  It is properly indicated in the header.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  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, RFC 4960 and RFC 8085.

Working Group Summary:

There were no major controversies or points of questionable consensus in the process of working on this document.  The document is somewhat related to work in other working groups (such as QUIC), since it lays out the framework for path MTU discovery that can be used in any datagram-based protocol.

Document Quality:

There have been a number of separate implementations at different stages of the document's maturity. An implementation for SCTP targets the FreeBSD kernel, and is starting the review process to be included.
This code also is the basis for a userland stack currently used in browsers for WebRTC data channels.
Another implementation with UDP options was done for the FreeBSD kernel, though has not tracked the draft since 2018.  Three early implementations were also done as part of the EU MAMI project, to test possible algorithms and check if the specification could be implemented, but these did not enter production code.  Two of these implementations were with UDP application protocols, for testing, and the third was for a QUIC implementation.

Personnel:

Wesley Eddy is the document shepherd.  Magnus Westerlund is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have done a full review of the document, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No additional special reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Good consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No possible appeals mentioned.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are a few erroneous idnits warnings about the Updates header based on the abstract.  I think this is because the header was truncated, and should be fixed by the RFC Editor if needed.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There is a normative reference to the QUIC specification, which is still an I-D (not yet published as an RFC).  This is fine, because it should block this document in the RFC Editor queue waiting for that reference to be resolved.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downrefs.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No RFCs are obsoleted, and the three that are updated are noted in the header, explained in the abstract, and discussed properly in the document.  The 4960 update is discussed in the later section specific to SCTP (which is appropriate) and not in the introduction, but the other two documents updated are discussed clearly in the introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There are no IANA requests.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.
2020-01-24
13 Wesley Eddy
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Proposed Standard.  This is the right target due to the scope, content, and intent of the work.  It is properly indicated in the header.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  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, RFC 4960 and RFC 8085.

Working Group Summary:

There were no major controversies or points of questionable consensus in the process of working on this document.  The document is somewhat related to work in other working groups (such as QUIC), since it lays out the framework for path MTU discovery that can be used in any datagram-based protocol.

Document Quality:

TBD - implementation report requested from authors

Personnel:

Wesley Eddy is the document shepherd.  Magnus Westerlund is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have done a full review of the document, and believe it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No additional special reviews are needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Confirmed.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Good consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No possible appeals mentioned.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are a few erroneous idnits warnings about the Updates header based on the abstract.  I think this is because the header was truncated, and should be fixed by the RFC Editor if needed.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

There is a normative reference to the QUIC specification, which is still an I-D (not yet published as an RFC).  This is fine, because it should block this document in the RFC Editor queue waiting for that reference to be resolved.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No downrefs.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No RFCs are obsoleted, and the three that are updated are noted in the header, explained in the abstract, and discussed properly in the document.  The 4960 update is discussed in the later section specific to SCTP (which is appropriate) and not in the introduction, but the other two documents updated are discussed clearly in the introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

There are no IANA requests.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A.
2020-01-24
13 Wesley Eddy IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2020-01-20
13 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-13.txt
2020-01-20
13 (System) New version approved
2020-01-20
13 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Timo Voelker , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2020-01-20
13 Tom Jones Uploaded new revision
2019-12-06
12 Magnus Westerlund Shepherding AD changed to Magnus Westerlund
2019-12-05
12 Wesley Eddy IETF WG state changed to In WG Last Call from WG Document
2019-12-05
12 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-12.txt
2019-12-05
12 (System) New version approved
2019-12-05
12 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Timo Voelker , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2019-12-05
12 Tom Jones Uploaded new revision
2019-11-20
11 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-11.txt
2019-11-20
11 (System) New version approved
2019-11-20
11 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Timo Voelker , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2019-11-20
11 Tom Jones Uploaded new revision
2019-11-18
10 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-10.txt
2019-11-18
10 (System) New version approved
2019-11-18
10 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Timo Voelker , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2019-11-18
10 Tom Jones Uploaded new revision
2019-11-04
09 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-09.txt
2019-11-04
09 (System) Forced post of submission
2019-11-04
09 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Timo Voelker , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2019-11-04
09 Tom Jones Uploaded new revision
2019-06-05
08 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-08.txt
2019-06-05
08 (System) New version approved
2019-06-05
08 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Timo Voelker , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2019-06-05
08 Tom Jones Uploaded new revision
2019-02-18
07 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-07.txt
2019-02-18
07 (System) New version approved
2019-02-18
07 (System) Request for posting confirmation emailed to previous authors: Tom Jones , tsvwg-chairs@ietf.org, Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2019-02-18
07 Tom Jones Uploaded new revision
2018-11-20
06 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-06.txt
2018-11-20
06 (System) New version approved
2018-11-20
06 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2018-11-20
06 Tom Jones Uploaded new revision
2018-10-02
05 Gorry Fairhurst New version available: draft-ietf-tsvwg-datagram-plpmtud-05.txt
2018-10-02
05 (System) New version approved
2018-10-02
05 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2018-10-02
05 Gorry Fairhurst Uploaded new revision
2018-09-05
04 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-04.txt
2018-09-05
04 (System) New version approved
2018-09-05
04 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2018-09-05
04 Tom Jones Uploaded new revision
2018-07-19
03 David Black Added to session: IETF-102: tsvwg  Thu-1550
2018-07-02
03 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-03.txt
2018-07-02
03 (System) New version approved
2018-07-02
03 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2018-07-02
03 Tom Jones Uploaded new revision
2018-06-07
02 Gorry Fairhurst New version available: draft-ietf-tsvwg-datagram-plpmtud-02.txt
2018-06-07
02 (System) New version approved
2018-06-07
02 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2018-06-07
02 Gorry Fairhurst Uploaded new revision
2018-03-18
01 Gorry Fairhurst Changed consensus to Yes from Unknown
2018-03-18
01 Gorry Fairhurst Intended Status changed to Proposed Standard from None
2018-03-15
01 Gorry Fairhurst Added to session: IETF-101: tsvwg  Thu-1550
2018-03-05
01 Tom Jones New version available: draft-ietf-tsvwg-datagram-plpmtud-01.txt
2018-03-05
01 (System) New version approved
2018-03-05
01 (System) Request for posting confirmation emailed to previous authors: Tom Jones , Michael Tuexen , Irene Ruengeler , Gorry Fairhurst
2018-03-05
01 Tom Jones Uploaded new revision
2018-01-22
00 David Black Notification list changed to Wesley Eddy <wes@mti-systems.com>
2018-01-22
00 David Black Document shepherd changed to Wesley Eddy
2018-01-22
00 David Black This document now replaces draft-fairhurst-tsvwg-datagram-plpmtud instead of None
2018-01-22
00 Gorry Fairhurst New version available: draft-ietf-tsvwg-datagram-plpmtud-00.txt
2018-01-22
00 (System) WG -00 approved
2018-01-22
00 Gorry Fairhurst Set submitter to "Godred Fairhurst ", replaces to (none) and sent approval email to group chairs: tsvwg-chairs@ietf.org
2018-01-22
00 Gorry Fairhurst Uploaded new revision