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

[Bernard Aboba <[e-mail]>]

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]>
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
>
>
>
>
>