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 |