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
- Comments on draft-ietf-6man-mtu-option-05 Jen Linkova
- Re: Comments on draft-ietf-6man-mtu-option-05 Gorry Fairhurst