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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sat, 12 March 2022 08:02 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDF43A0E60; Sat, 12 Mar 2022 00:02:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeUz_y7O3c2S; Sat, 12 Mar 2022 00:02:16 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5BB3A0990; Sat, 12 Mar 2022 00:02:12 -0800 (PST)
Received: from [192.168.1.64] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5270D1B001ED; Sat, 12 Mar 2022 08:01:32 +0000 (GMT)
Message-ID: <e3203cc3-b3ec-c308-37c5-c4ccfa8c8858@erg.abdn.ac.uk>
Date: Sat, 12 Mar 2022 08:01:30 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
To: Bernard Aboba <bernard.aboba@gmail.com>, art@ietf.org
Cc: draft-ietf-6man-mtu-option.all@ietf.org, ipv6@ietf.org, last-call@ietf.org
References: <164686336866.27936.1242763265861572732@ietfa.amsl.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
In-Reply-To: <164686336866.27936.1242763265861572732@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/nM5nuO8hu0NP-wP3pKskw5TsUXg>
Subject: Re: [Last-Call] Artart last call review of draft-ietf-6man-mtu-option-13
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Mar 2022 08:02:22 -0000

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