Comments on draft-ietf-6man-mtu-option-05

Jen Linkova <furry13@gmail.com> Wed, 28 July 2021 04:30 UTC

Return-Path: <furry13@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 4C1983A1B7C for <ipv6@ietfa.amsl.com>; Tue, 27 Jul 2021 21:30:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 sEYPxX_yEyOG for <ipv6@ietfa.amsl.com>; Tue, 27 Jul 2021 21:30:39 -0700 (PDT)
Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 549FA3A1B7B for <ipv6@ietf.org>; Tue, 27 Jul 2021 21:30:39 -0700 (PDT)
Received: by mail-ej1-x62e.google.com with SMTP id e19so2367260ejs.9 for <ipv6@ietf.org>; Tue, 27 Jul 2021 21:30:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JC51kx52n/8tYyMb3ThYYKH08kxWC3xE0nofqfFO61Q=; b=DT73FqdVsPXH1B2NwopBq2hARMQKr5O00e9VYa5RYDqTzbgw5jzu3H/ytpHElsC1UW GKfaJO0SgRj+8tz7tgLtCpWSBREfvqIJIaTId1SrtI1EpJA9hanvZ/sKm5s8e3wWR/eS ma4PpaQhAx3JuL24REXgUJovqIzof0hNBVehr152e21yXCFZrnoPW1DoNselNLdXrshr HJcLp8JASf4QhITUzEFyV+YPGdg3FiTLQ2MzptE+ub0Ft/hHv1a1i2fvFGlSlCKt1dtK VAXPyw3Hjq6KrYdKdc/Ah9GSEWnC2AnJMaHhPk+U2NBkahzkX/6Rpia4MxPSTrTutHEP YRiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JC51kx52n/8tYyMb3ThYYKH08kxWC3xE0nofqfFO61Q=; b=fMxCaUccct9rB7TWGs9rPFjJ1OFFywWrYXa2KkMkcBlgrcE3deQ/ytHNMq1BpPyLoL RsjDGobC3oi6fQsX1ePdslm6jcCpYr+qJZcEJf/iuHyAX2aiKqcKgyNh9AZiCHyIBaep lEFIpr9Y2pdTwqUnbeJ76M+LVLdkqPtzprDll8cBciX8l3ncPhvxQ2bv86W3m2FOKuYI j2ZpoWB0V5gR7rbWz/8KGd+GQR3U897pX9BnRtGdx1rHBJ5oQh8+qPFhQWqteBciHfoa bIixVYN4HhLyUEYaQ9Qe2Y1BVQPBQT1ZrTdEUwwqTIU+G/FfEGJLp0dsuwDkuLrURvBC adjg==
X-Gm-Message-State: AOAM530wO0f/huyagQB0kkLRJtWAXFIv1kDhf9YVvt7Kvh7ZvUngKgu9 UNctvS0Rm+NJnGMx905R7KeIZHENtbIxpA16tEZ9rh1P02U=
X-Google-Smtp-Source: ABdhPJx9Qjn7XeUvfcVrMYpYWMaWfAOWlXdOTTzSdTNVZnzvPzj5FcWu0qUMt6X7u47cgdvQxK7VZFdJYjlRpRsxKdc=
X-Received: by 2002:a17:906:ae8f:: with SMTP id md15mr17570549ejb.198.1627446636819; Tue, 27 Jul 2021 21:30:36 -0700 (PDT)
MIME-Version: 1.0
From: Jen Linkova <furry13@gmail.com>
Date: Wed, 28 Jul 2021 14:30:25 +1000
Message-ID: <CAFU7BASY=reS_2zN7Ug_wbDOoFMOsLr_0t-U58zAp5dHDAuGeQ@mail.gmail.com>
Subject: Comments on draft-ietf-6man-mtu-option-05
To: 6man <ipv6@ietf.org>, G Fairhurst <gorry@erg.abdn.ac.uk>, Bob Hinden <bob.hinden@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BOeaLQJw_X5_J4OISD43LTDdGx8>
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: Wed, 28 Jul 2021 04:30:42 -0000

Bob, Gorry,

A few comments on the draft:

1)Section 4. Applicability Statements
"This Hop-by-Hop Option header is intended to be used in environments
such as Data Centers and on paths between Data Centers".

It might be just me but I find it a bit confusing. Are, for example,
enterprise networks, like Data Centers? I read it as 'networks under
single/coordinated administrative control' but I'm not sure.

2) Section 6.2.  Host Behavior
"When requested to send an IPv6 packet with the Minimum Path MTU
option, the source host includes the option in an outgoing packet.
   The source host SHOULD fill the Min-PMTU field with the MTU
   configured for the link over which it will send the packet on the
   next hop towards the destination host.  If this value is not updated,
   the field MUST be set to zero."

What are the cases when the host might not set Min-PMTU? "If the value
is not updated' sounds a bit confusing to me, to be honest. Also, it
creates a bit of an issue: the routers are requested to update the
Min-PMTU field only if the outgoing link MTU is less than the Min-PMTU
value. So, sending a packet with Min-PMTU = 0 would do nothing as no
router would ever update the field.
The destination host would get the zero value as well (and, as I can
see, the draft does not describe any special treatment for the '0' on
the receiver side).

Am I missing anything here? It looks like we shall either ensure that
the field is always initialized with the link MTU, or the router
behaviour shall be modified. The receiver shall ignore zero MTU as
well.


3)Packet Loss

-  IMHO it would be beneficial to discuss the packet loss scenarios a
bit more and provide more guidance when to set the option. As I've
mentioned earlier, setting it for TCP SYN might drastically increase
the chances for Happy Eyeballs fallback. I'm not sure what's the best
course of action - maybe setting it for the first packet after the
handshake?

- Another crazy idea: what about some kind of "happy eyeballs" for the
option and when the packet with the option is sent for the first time
- sending another one, w/o an option soon after? Or, if the packet was
a TCP one and wasn't ACKed - the stack MUST send the retransmit w/o
the option?

- The draft says 'this option is intended to be used in environments
such as Data Centers'. Do we want to discuss how we can achieve that
it's only used for some destinations and not for the others? So hosts
inside a DC can send the option towards destinations in another DC but
not towards Google, for example?

- The draft recommends suspending the option usage if an ICMPv6 error
message is received. Shall the host keep some state/do a kind of
exponential backoff based on the data about blackholed packets with
the option?

-- 
SY, Jen Linkova aka Furry