Re: Artart last call review of draft-ietf-6man-mtu-option-13
Bernard Aboba <bernard.aboba@gmail.com> Tue, 15 March 2022 06:51 UTC
Return-Path: <bernard.aboba@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8168F3A1942; Mon, 14 Mar 2022 23:51:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pJkVVYaHJJGS; Mon, 14 Mar 2022 23:51:42 -0700 (PDT)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C57C3A1940; Mon, 14 Mar 2022 23:51:42 -0700 (PDT)
Received: by mail-ua1-x92e.google.com with SMTP id x19so971027uaf.1; Mon, 14 Mar 2022 23:51:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KFwvJDJsk5f/wjHq3b0f5wYu+1Fo1Yyb2lqbp6DKHKM=; b=QqciuWZElNBMKVOw5UYtEIVlmk90i2Zj/dzF3r80X97NcsUWJP7i+YwNjgM45HMRzp rFtnSP9QZCS29wnHu1n/zApYSk8eXv36kT4TwH+OBlnfj6NQNMOZECQNLv/TtmAwvsng e+S4pt3JEZ7ffwUtvk2aRmIUki+m12a8WiKvE9RahZgiGSCGXmNWXRhRWREjh63Fk5B1 q3m6NgkJOZWrCnGIlkQq0y6SwC/FuS41Gx4CELFxGAlLAp/6B9EmB9tCnMrcduAVjvgr wWTYqK4DvA29GShZMVj9zl19LRrc6ENlKvlaYFcTM2SxFZi/oVMpfYAUvB0mk5l2EWGd 1yqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KFwvJDJsk5f/wjHq3b0f5wYu+1Fo1Yyb2lqbp6DKHKM=; b=EHR5ew1mo8oZBZIom6Ei9QlaPUiNm36FmDvAiRflIk/2oM5Edx6Qon2k7rqzd72ahH uQUBItpFEJn+LejtVkxw55wX9Qc4B0yakA0wD3c9MDSwoZKIKPQE0x0RtIcY3uR9Ka+A HzI4r5dSyRT25BlaVlE7kdXop1SwmJ3y1pz3CKhPRBqI36aR4Wvq2Zxeu1GDo3NtVMR/ mLkKWl5kHQ7TDymxkvOo0n760N0oev8TC32uOLCOhW88u1mKRFOMNllZPvPcnevy7n4G iswzkVSN5XdoYiZj+nUy/YkGF009j3wD0NGXSX2fEuC46idTA6z7eYWdNAVFUYAyE9l0 iKUg==
X-Gm-Message-State: AOAM5319i9Mp967wYJkpJAEWtyb9QgCLsMnrN+x1BZutiirVCukeNYr1 31pYizrH2uSc5mcS7+msFY46w7LEBbeLj0ZKbu2p7XUm
X-Google-Smtp-Source: ABdhPJzl5Xmutw7F0/P9IT58reQMNEJiihX9k6UWUoUYevVbG3FDdmBBlwPjq3wd5w4SwC/qhPl5Inv1j0DFBz/XdZE=
X-Received: by 2002:ab0:2603:0:b0:34b:ca85:bc2f with SMTP id c3-20020ab02603000000b0034bca85bc2fmr10171395uao.30.1647327101008; Mon, 14 Mar 2022 23:51:41 -0700 (PDT)
MIME-Version: 1.0
References: <164686336866.27936.1242763265861572732@ietfa.amsl.com> <e3203cc3-b3ec-c308-37c5-c4ccfa8c8858@erg.abdn.ac.uk>
In-Reply-To: <e3203cc3-b3ec-c308-37c5-c4ccfa8c8858@erg.abdn.ac.uk>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 14 Mar 2022 23:51:31 -0700
Message-ID: <CAOW+2dvuyw+cwemLOQLbHknLV-a-A3w8EVu26rOMGHy+8cmphQ@mail.gmail.com>
Subject: Re: Artart last call review of draft-ietf-6man-mtu-option-13
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Applications and Real-Time Area Discussion <art@ietf.org>, draft-ietf-6man-mtu-option.all@ietf.org, ipv6@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="000000000000af3f1705da3c3ad7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/LcE-BvK83ECir1hdb015Qvbxp0g>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2022 06:51:48 -0000
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 <gorry@erg.abdn.ac.uk> 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 > > > > >
- Artart last call review of draft-ietf-6man-mtu-op… Bernard Aboba via Datatracker
- Re: Artart last call review of draft-ietf-6man-mt… Gorry Fairhurst
- Re: Artart last call review of draft-ietf-6man-mt… Bernard Aboba
- Re: [Last-Call] Artart last call review of draft-… Francesca Palombini