Re: [art] [Last-Call] Artart last call review of draft-ietf-6man-mtu-option-13

[Francesca Palombini <[e-mail]>]

Bernard: many thanks for this review. Gorry and Bob, thanks for the reply. I have balloted No Objection, with an additional suggestion to add the diagrams below to the document – it is not a strong suggestion, but I think they would improve understanding.

Thanks,
Francesca

From: last-call <[e-mail]> on behalf of Bernard Aboba <[e-mail]>
Date: Tuesday, 15 March 2022 at 07:53
To: Gorry Fairhurst <[e-mail]>
Cc: Applications and Real-Time Area Discussion <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: [Last-Call] Artart last call review of draft-ietf-6man-mtu-option-13
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?

On Sat, Mar 12, 2022 at 12:01 AM Gorry Fairhurst <[e-mail]<mailto:[e-mail]>> wrote:
On 09/03/2022 22:02, Bernard Aboba via Datatracker wrote:
> 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.
>
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