Subject: [Bier] Comments on PMTUD for BIER draft (draft-ietf-bier-path-mtu-discovery)

From: Eric Gray <[email-masked]>
Date: Wed, 20 Jul 2016 09:05:23 +0000

Authors,

Comments/questions on PMTUD for BIER draft (NITs sent via separate mail):

Introduction:

For IPv6, fragmentation is not possible at hops along the route; even for IPv4, fragmentation may or may not occur (returning a "too big" ICMP error is an option, even when the "don't fragment" bit is not set).

The second sentence is difficult to parse, incorrect for IPv6 (where discard is the only option), whether or not your intended statement applies to "most cases" is largely dependent on usage (for real time and interactive applications, this efficiency may be an irrelevant consideration), and where performance degradation occurs is largely a matter of implementation; I suggest replacing the sentence with one that reads along the lines of:

"In many cases it is more efficient to use the largest size packets that are less than or equal to the least MTU for any forwarding device along the routed path to the IP destination for these packets."

You could, if you want, add another sentence after this to the effect that this "least MTU" is known as Path MTU (PMTU).

Because fragmentation is not guaranteed to occur, the fourth sentence should read "Fragmentation may occur ..."

Also, possibly because of the wording chosen, the next to last sentence in the first paragraph is incorrect. What an IP packet source needs to know is the least MTU value that will be encountered along the current path (route) a set of packets will follow or, in some cases, the least MTU for all such paths.

As a related observation (which I would understand if you don't want to include in this text), the same is true for each successive hop along a routed path.

I think it might be useful to add a short paragraph at the end of the introduction section that points out that PMTU is of particular importance in multicast usages, such as for BIER.

Terminology:

I believe the BIER-related terminology was previously defined in the BIER architecture draft.  If that is true, you could simply omit these definitions (you've already provided the reference and I believe you've also provided an expansion with at least the first use of each in the draft), or you could list them in a single sentence, indicating that they are used as defined in the BIER architecture draft or you could group them as terms defined in that draft.  Listing them as is currently done seems to imply that they may not be used in this document as they were defined previously.

Problem Statement:

In the second paragraph -

1)      I suggest inserting "possibly" before "through [a] series of ..." and replacing "decreasing and increasing size ..." with "varying the size..." The most direct approach is to start with the MTU of the local interface and decrease if needed (in a common case, defined in RFC 1191, in a single step);

2)      it is - in the general case and for current mechanisms - more correct to use "packet source" instead of "ingress node" and "packet destination" instead of "egress."  Also a response from the egress is not guaranteed in all cases for existing PMTU discovery mechanisms.  So you should insert "may."

Note: I realize that the wording used is probably correct for the BIER case, but in this text you are talking about current mechanisms.

Has the case where the multicast tree is constructed using unicast shortest paths been considered (i.e. - where the tree MTU can be determined as the least MTU for the unicast paths from the root to each leaf)?

Assuming that TCP is used (guaranteeing an Ack for each message), is the intent to exclude PMTU discovery specifically as defined in RFC 1191 in all subsequent statements about what is possible using current PMTU discovery? The assumption of Ping use seems to be implied (which makes sense for the target application "BIER").

In section 3 (PMTUD Mechanism for BIER), is "multicast distribution path" really the correct phrase?

In the first bullet on page 5, should "links" be "paths" - and, if not, how is "egress BIER links" meant to be interpreted?

At the top of page 6, it is not clear what is meant by "BFIR MUST continue sending probes using BMS until the bit string is clear or the discovery is declared unsuccessful."  AFAICT, we are not specifying anything about the retransmission feature (presumably including at least frequency, backoff, or number of tries) - hence it seems to me that "BFIR sends probes using BMS and its own (locally determined) retransmission procedures until either the bit string is clear (contains no set bits), or until the BFIR retransmission procedure terminates and PMTU discovery is declared unsuccessful."  Since it is possible that a compliant locally determined retransmission procedure could terminate after a single transmission (I saw nothing to indicate a minimum number of retransmissions if no response is received for a first one - though possibly I missed it), the use of "MUST" seems extraordinary.

In subsequent bullets, it seems to me that we might want to include "a BFIR MUST have a locally defined retransmission procedure;" as one of the bullets.

As usual, the draft is otherwise well-written and extremely useful work.

--

Eric

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 25 Jul 2016 17:35:53 +0000

Hi Eric,
greatly appreciate your thorough review and the most helpful and detailed comments.
Please find responses and notes in-lined and tagged GIM>>.
I've attached the version with the proposed changes and its diff to the previous version.

                Regards,
                                Greg

From: BIER [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Wednesday, July 20, 2016 11:05 AM
To: [email-masked]; [email-masked]
Subject: [Bier] Comments on PMTUD for BIER draft (draft-ietf-bier-path-mtu-discovery)
Importance: High

Authors,

Introduction:

GIM>> Absolutely agree. And fragmentation is not supported not only for IPv6 but for MPLS and Ethernet that may be carried over a BIER domain. Accepted as suggested.

GIM>> Perhaps more complete list "Fragmentation or packet drop, silent or not, may occur ..." work?

GIM>> Agree with minor note. To exercise all paths from the ingress border router to the given set of destinations operator should run number of PMTUD tests while changing the value of the Entropy field in the BIER header. I think that discovering and exercising multipath in the BIER domain is outside of the scope of this document. Hence the updated sentence:

        To avoid any of the listed above behaviors, the packet source must find

        the value of the least MTU, i.e. PMTU, that will be encountered along the route that

        a set of packets will follow to reach the given set of destinations.

GIM>> But that would be the case only if a BFR may act as BFIR. But if that is the case, then an operator may request another PMTUD or configure the PMTU to the value previously discovered for the downstream BFR.

Terminology:

GIM>>  I understand your point but on number occasions was suggested to explicitly list all acronyms used in the document regardless whether they first introduced in the document or defined elsewhere.

Problem Statement:

GIM>> Accepted.

GIM>> Accepted.

GIM>> AFAIK, there's no restriction on how the multicast tree in the particular BIER domain constructed. Ensuring the particular PMTU may be the constrain used to calculate the tree.

GIM>> I recall several attempts to make multicast TCP work but I cannot recall any one that was successful. Thus we had chosen UDP-like.

GIM>> Agreed and changed to "tree".

GIM>> "BIER link" is logical link between two BFRs. Would the following text be acceptable:

MTU SHOULD be set to the minimal MTU value among all egress BIER links,

logical links between this and downstream BFRs,

that could be used to reach B's downstream BFERs;

GIM>> Agreed and accepted.

GIM>> Accepted.

--

Eric