Subject: Artart last call review of draft-ietf-6man-mtu-option-13

From: Bernard Aboba via Datatracker <[email-masked]>
Date: Wed, 09 Mar 2022 14:02:48 -0800

Reviewer: Bernard Aboba
Review result: Ready with Issues

Document: draft-ietf-6man-mtu-option-13
Reviewer: Bernard Aboba
Result: Ready with Issues

This document proposes an experimental mechanism to add a new Path MTU
Hop-by-Hop option to IPv6.

As noted in Section 2, the IPv6 PMTU discovery mechanisms defined in RFC 8201
is known to fail when nodes in the network do not send ICMP Packet Too Big
(PTB) messages, or where ICMP messages are rate limited, or where there is no
return path to the source host. As noted in Section 2, the proposed mechanism
does not replace PLPPMTUD (RFC 4821) or Datagram PLPMTUD (RFC 8899), both of
which do not rely on ICMP messages, but do require a return path to the source
host.

The proposed mechanism does not rely on reception of ICMPv6 PTB messages and as
noted in Section 6.3.5, it has advantages over PLPPMTUD and DPLPMTUD in
detecting path changes, since the option consumes less capacity than a
full-sized probe packet.

However, the proposed mechanism does rely on widespread implementation of the
Hop-by-Hop option.  Where the Hop-by-Hop option is implemented sporadically,
the proposed mechanism could return a misleading result. This represents a
major weakness of the proposed approach. As noted in RFC 5218 Section 2.1.2,
one of the characteristics of successful protocols is incremental
deployability, where early adopters can gain some benefit even though the rest
of the Internet does not support the protocol. In this case, the incremental
benefits are limited (or even negative, due to the potential for misleading
results), which could limit the motivation for it to be widely deployed.
Section 10 mentions two implementations, but does not indicate adoption by
router vendors.

Past history is also sobering. A similar approach was proposed in 1988 (RFC
1063), but was never widely implemented, and was therefore obsoleted by RF 1191
in 1990.

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 12 Mar 2022 08:01:30 +0000

> 1063), but was never widely implemented, and was therefore obsoleted by RF 1191
Thank you for this review.

The reality was that the work in 6man was not based on RFC1063, but 
after completing the work we did see similarities with the old proposal. 
The latest revision added a para about the history, trying to explain 
that things have changed from the position with an IPv4 option with 
PMTUD to that of an IPv6 HBH option with (D)PLPMTUD:

                 A similar mechanism was proposed in 1998 for IPv4 in 
[RFC1063] by
                 Jeff Mogul, C.  Kent, Craig Partridge, and Keith 
McCloghire.  It was
                 later obsoleted in 1990 by [RFC1191], the current 
deployed approach
                 to Path MTU Discovery.  In contrast, the method 
described in this
                 document uses the HBH option of IPv6.  It does not 
replace PMTUD
                 [RFC8201], PLPPMTUD [RFC4821] or Datagram PLPMTUD 
[RFC8899], but
                 rather is designed to compliment these methods.

We also made a set of diagrams that help illustrate the way this option 
can be used over paths where the (D)PLPMTUD search would otherwise take 
many rounds of probes to complete - such as on pathes where equipment 
might be configured to support jumboframes (see 4).

This also shows that there is often only one additional probe cycle when 
the HBH option is not processed by legacy routers, which I think might 
reflect the incremental deployment case (5).

This set of diagrams was not added to the draft, but could help 
understanding:

---

Consider a set of packet sizes a<b<c<d<e and one on-path router,
that has an actual PMTU of d' where d<=d'<=e.

a= Minimum PMTU set by application.

There are several PMTU discovery methods:

1. Working PMTUD
With with one router returning ICMP.

---- Packets of data sized (e) ---X
<--------------ICMP PTB (d')------|
---- Packets of data sized d' --------------------------->
The chosen PMTU was d', with one RTT to detect using ICMP.

2. Failing PMTUD, relying on black-hole detection.
With with one router not successfuly returning ICMP.

---- Packets of data sized (e)---X
          X----ICMP PTB (d')------|
---- Packets of data sized (e)---X
.... Timeout after black holing data packets.
---- Packets of data sized (a) -------------------------->

The chosen PMTU was a

This uses the minimum PMTU configured for blackhole detection (a).

3. Working (D)PLPMTUD
Showing 3 successful probes and ICMP PTB message.

----Packets of data sized (a) --------------------------->
<------------------------------------ ACK ----------------
----Packets of data sized (a) --------------------------->
----Probe size (b) -------------------------------------->
<------------------------------------ ACK of probe -------
----Packets of data sized (b) --------------------------->
----Probe size (c) -------------------------------------->
<------------------------------------ ACK of probe -------
----Packets of data sized (c) --------------------------->
----Probe size (d) -------------------------------------->
<------------------------------------ ACK of probe -------
----Packets of data sized (d) --------------------------->
... Probes sent above actual PMTU
----Probe size (e)------------X
          X----ICMP PTB (d')---|
----Packets of data sized (d') -------------------------->
...
... etc, until MaxProbes are unsuccessful and search phase completes.
----Packets of data sized (d') -------------------------->

The chosen PMTU was  d<=d', after successive DPLPMTUD probes.
The number of probe rounds depends on number of steps needed by algorithm.

3. Working (D)PLPMTUD with ICMP
Showing 3 successful probes and one failed probe repeated 3 times.

----Packets of data sized (a) ---------------------------->
<------------------------------------ ACK -----------------
----Packets of data sized (a) ---------------------------->
----Probe size (b) --------------------------------------->
<------------------------------------ ACK of probe --------
----Packets of data sized (b) ---------------------------->
----Probe size (c) --------------------------------------->
<------------------------------------ ACK of probe --------
----Packets of data sized (c) ---------------------------->
----Probe size (d) --------------------------------------->
<------------------------------------ ACK of probe --------
----Packets of data sized (d) ---------------------------->
... Probes sent above actual PMTU
----Probe size (e)-----------X
<----------ICMP PTB (d')-----|
----Probe size (d') using target set by PTB size --------->
<------------------------------------ ACK of probe --------
----Packets of data sized (d) ---------------------------->
----Probe size (e)----------X
...
... etc, until MaxProbes are unsuccessful and search phase completes.
----Packets of data sized a+c ----------------------------->

The chosen PMTU was d' after successive probes, matching actual PMTU.
The number of probe rounds depends on number of steps needed by algorithm.

4. (D)PLPMTUD + MinMTU
Showing 3 successful probes to size d.

----Packets of data sized (a) ---------------------------->
----Probe size (a)+ IPv6 MinMTU (e)-+
                                     |-MinMTU Probe (d') -->
<--- IPv6 MinMTU with Rtn-PMTU (a+c) ----------------------
<------------------------------------ ACK -----------------
----Packets of data sized (a) ---------------------------->
----Probe size (d') using target set by Rtn-PMTU --------->
<------------------------------------ ACK of probe --------
----Packets of data sized (d') --------------------------->
... More probes to check for larger PMTU
----Probe size (e) ---------X
----Packets of data sized (d') --------------------------->
... etc, until MaxProbes are unsuccessful and search phase completes.
----Packets of data sized (d') --------------------------->

The chosen PMTU was d' after one RTT to probe using Rtn-PMTU
(Rtn-PMTU shortcuts probing algorithm)

5. (D)PLPMTUD + MinMTU
IPv6 MinMTU sent end to end, but not processed at bottleneck.
Showing a failed target probe (set by the Rtn-MTU) that was to large,
followed by successful probes to size d.

----Packets of data sized (a) ---------------------------->
----Probe size (a) +MinMTU Probe (e) --------------------->
<--- Rtn-PMTU = (e) ---------------------------------------
<------------------------------------ ACK -----------------
----Packets of data sized (a) ---------------------------->
----Probe size (e) using target of Rtn-PMTU- X
----Packets of data sized (a) ---------------------------->
----Probe size (b) --------------------------------------->
<------------------------------------ ACK of probe -------
----Packets of data sized (b) ---------------------------->
----Probe size (c) --------------------------------------->
<------------------------------------ ACK of probe --------
----Packets of data sized (c) ---------------------------->
----Probe size (d) --------------------------------------->
<------------------------------------ ACK of probe --------
----Packets of data sized (d) ---------------------------->
----Probe size (e)----------X
...
... etc, until MaxProbes are unsucessful and search phase completes.
----Packets of data sized (d) ---------------------------->

The chosen PMTU was  d, where d<= d', using probes to increase PMTU.
The number of probe rounds depends on number of steps needed by algorithm.

6. (D)PLPMTUD + MinMTU
IPv6 MinMTU not sent end to end.
Showing 3 successful probes and one failed probe repeated 3 times,

----Packets of data sized (a) ---------------------------->
----Probe size (a) +MinMTU Probe (e)---------X
<------------------------------------ ACK -----------------
----Packets of data sized (a) ---------------------------->
... Target failed, restart algorithm to search for PMTU
----Probe size (b) --------------------------------------->
<------------------------------------ ACK of probe -------
----Packets of data sized (b) ---------------------------->
----Probe size (c) --------------------------------------->
<------------------------------------ ACK of probe --------
----Packets of data sized (c) ---------------------------->
----Probe size (d) --------------------------------------->
<------------------------------------ ACK of probe --------
----Packets of data sized (d) ---------------------------->
... Probes sent above actual PMTU
----Probe size (e)-----------X
<----------ICMP PTB (d')-----|
----Probe size (d') using target set by PTB size --------->
<------------------------------------ ACK of probe --------
----Packets of data sized (d) ---------------------------->
----Probe size (e)----------X
...
... etc, until MaxProbes are unsuccessful and search phase completes.
----Packets of data sized a+c ---------------------------->

The chosen PMTU was  d, using probes to increase PMTU.
The number of probe rounds depends on number of steps needed by algorithm.

----

I hope this helps add a little more context.

Best wishes,

Gorry and Bob

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 14 Mar 2022 23:51:31 -0700

Thanks, Gorry.

The diagrams do help in understanding how the HBH option can add value even
when there are legacy routers that do not support the option. However, I do
wonder whether there will be a tendency for legacy routers to be connected
to low-MTU links (e.g. legacy routers for legacy links).  Are there plans
to evaluate this as part of the experiment?