Re: Warren Kumari's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS and COMMENT)

Bob Hinden <bob.hinden@gmail.com> Sat, 13 May 2017 19:43 UTC

Return-Path: <bob.hinden@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 67430129AFC; Sat, 13 May 2017 12:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ecLt8nbGyEXs; Sat, 13 May 2017 12:43:24 -0700 (PDT)
Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 1720412EA8C; Sat, 13 May 2017 12:40:14 -0700 (PDT)
Received: by mail-wm0-x242.google.com with SMTP id u65so19668179wmu.3; Sat, 13 May 2017 12:40:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Xsukos6GYfPj29uexEgqLSVqkJzzuxAuzh/VU/+X7jQ=; b=t83k+ElXizBTCnEpMX1/pgqtbgpoNucIy93FJrtJuANWCraBWkEZBWbu4Qy9NybGPX 8uI5Xk5o4RnA0mGop/W5u8o27oSJGpo8nvZ1drxkeHcg8ZPNpSFyIRlHAN9+QwQmLCZq 6jZngCpYw9fV6nfl14u3aq0upszedDGMrVP7Nujsa3+Ne2wz42379xkYVggD/Ok79UN9 0q0KiolpLM/ICIbUW69bPnSvBpIxWlDl4B3nkICgq7pfbH6RnSmDljvGLaCqggF0EeMp SJ6PeWLfv/xUDsNjOjhR7DN8SNQbbQM7SjCbzaUXKvz2aHbcrJeONgoXM0DQMblss16C 8wlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Xsukos6GYfPj29uexEgqLSVqkJzzuxAuzh/VU/+X7jQ=; b=RjZwhit/zAOUlp7AUlNqLimCqEam0RHxe1x5v+qj5ztFBuONORZKOCKJUn9GEh3C/V VOeRXMIDh9FQ5f7O6UK1DcBjdtRBALxFZLeUvd0lYs0onLokzQ+24vz+NF2CbXeZh+SX GaqmjTaNOhuQ6qL9YHCq5n7/HCo6Af1XdoGq+sLHBtUr5P9Flytec/XLJiYKqkUBo3Vr j7T40si0MtbEM4DW4UuYSUXgTJ+fm76d18JXl7HHTMj2hrZ+k2ujWL8dQOzRmTUtE3Im UAGVItEPDrKtIFfN33ySvR9xRUHnX/D6BBtMpnCCr3BhxefAAUG2fXwPLkYKyJy/EVWQ H0Lg==
X-Gm-Message-State: AODbwcB4kS3e05Kt7Gwytjjy5Z0P2MTCGwb+VpPh4zLKoH4pekI2I69Z MYdw2UuRDFBlQA==
X-Received: by 10.28.45.18 with SMTP id t18mr1732053wmt.6.1494704412445; Sat, 13 May 2017 12:40:12 -0700 (PDT)
Received: from ?IPv6:2601:647:4d01:db10:1d51:b039:45a8:3797? ([2601:647:4d01:db10:1d51:b039:45a8:3797]) by smtp.gmail.com with ESMTPSA id o20sm5487688wro.61.2017.05.13.12.40.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 May 2017 12:40:11 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <2D89FFFE-1EC7-41FF-A6F0-FEDFFEAFBBE9@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_7E6C9D8C-ADFD-4BCE-9C6B-24646FF26272"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: Warren Kumari's Discuss on draft-ietf-6man-rfc1981bis-06: (with DISCUSS and COMMENT)
Date: Sat, 13 May 2017 12:40:03 -0700
In-Reply-To: <149443158586.30086.10156582311718173877.idtracker@ietfa.amsl.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, IESG <iesg@ietf.org>, draft-ietf-6man-rfc1981bis@ietf.org, Ole Trøan <otroan@employees.org>, 6man-chairs@ietf.org, IPv6 List <ipv6@ietf.org>
To: Warren Kumari <warren@kumari.net>
References: <149443158586.30086.10156582311718173877.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MHCydWN1w7WJm7QT4M4LTPSgo3A>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 13 May 2017 19:43:26 -0000

Hi Warren,

> On May 10, 2017, at 8:53 AM, Warren Kumari <warren@kumari.net> wrote:
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-6man-rfc1981bis-06: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6man-rfc1981bis/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> The OpsDir review
> (https://datatracker.ietf.org/doc/review-ietf-6man-rfc1981bis-04-opsdir-lc-hares-2017-03-04/
> ) raises an interesting point, which I had not occurred to me. If the MTU
> for a path is 1440 bytes, and ND/RA suddenly says that the interface MTU
> is only 1400 bytes, what should implementations do?
> I'd expect something like decrease the path MTU (for all paths) to min
> (new link MTU, current path MTU), but it isn't (AFAICT) specified.
> 
> It's entirely possible that this is a: already covered and / or b:
> covered at a different layer / different protocol, happy to be hit with a
> clue bat…

I am not sure this is a PMTU question as this is about the first hop link MTU size not somewhere along the path.  Neighbor Discovery RFC4861 (Section 6.3.4) says to use the new value.  Based on this, the node would change it’s MTU to the new value and start sending smaller packets, or fragments.  The transport layer would pick up the new MTU and act accordingly.

ND also has rules to bound a received MTU.  From Section 6.3.4 of ND:

   If the MTU option is present, hosts SHOULD copy the option's value
   into LinkMTU so long as the value is greater than or equal to the
   minimum link MTU [IPv6] and does not exceed the maximum LinkMTU value
   specified in the link-type-specific document (e.g., [IPv6-ETHER]).

Hope this answers your question.

Thanks,
Bob




> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Please also see the OpsDir review....
> 
> 
> I sent email about this to the authors on Feb 23rd - I seem to still have
> have many of the same questions...
> 
> Comments:
> 1: Sec 1: "Path MTU Discovery relies on such messages to determine the
> MTU of the path."
> -- it is unclear which "such" refers to. Perhaps s/such/ICMPv6/ (or
> PTB).
> 
> 2: Sec 3: "Upon receipt of such a message, the
>   source node reduces its assumed PMTU for the path based on the MTU
> of
>   the constricting hop as reported in the Packet Too Big message" --
> this says that it reduces it *for the path*. But (as somewhat alluded to
> later in the draft) the nodes doesn't know what the path *is* -- it can
> decrease for the destination, or flow, or even interface, but (unless it
> is strict source routing) it doesn't control or really know the path (see
> also #4)
> 
> 3: Sec 4: "The recommended setting for this timer is twice its minimum
> value (10 minutes)." - as above. This was from 1996 - were these metrics
> discussed at all during the -bis? I suspect that the average flow is much
> shorter these days (more web traffic, fatter pipes, etc) and so a flow of
> 10 minutes seems really long (to me at least).
> 
> 4: Sec 5.2: "The packetization layers must be notified about decreases in
> the
>   PMTU.  Any packetization layer instance (for example, a TCP
>   connection) that is actively using the path must be notified if the
>   PMTU estimate is decreased.
>      Note: even if the Packet Too Big message contains an Original
>      Packet Header that refers to a UDP packet, the TCP layer must be
>      notified if any of its connections use the given path."
> - this is related to #2 -- I don't know *which* path my packets take -
> once I launch them into the void, they may be routed purely based upon
> destination IP address, or they may be hashed based upon some set of
> header fields to a particular ECMP link or LSP. Once packets hit a load
> balancer, it is probably even *likely* that the UDP and TCP packets end
> up on different things. So, if I get a PTB from a router somewhere, I can
> probably guess that other packets to the same destination address will
> also follow that path, but I cannot know that for sure. I'm fine to
> decrease MTU towards that destination IP, but is that what this is
> suggesting? If so, please say that. If not, please let me know what I
> should do. The above is even more tricky / fun when I'm using flow id as
> the flow identifier -- if I get a PTB for flow 0x1234, what do I do?
> 
> 5: Sec 5.3: "Once a minute, a timer-driven procedure runs through all
> cached PMTU values, and for each PMTU whose timestamp is not "reserved"
> and is older than the timeout interval ...". Please consider providing
> clarifications here. The wording implies that I should set a timer to
> fire on the minute, and trigger the behavior. If all of the (NTP synced!)
> machines in my datacenter do this, and all try send bigger packets (on
> 1/10th of long flows) their first hop router will get many, many
> over-sized packets and it will severely rate-limit the PTBs.
> 
> 
> Nits (Some of these are purely academic.)
> I understand that you are trying to limit the changes, so feel free to
> ignore these:
> 
> 1: "A node sending packets much smaller than the Path
> MTU allows is wasting network resources and probably getting
> suboptimal throughput." - the "much" confuses me. If I'm using anything
> less than the MTU I'm wasting network resources and getting suboptimal
> throughput - I might not care, but if (used MTU) < (path MTU) I'm wasting
> resources.
> 
> 2: "Nodes implementing Path MTU Discovery and sending packets larger
> than
> the IPv6 minimum link MTU are susceptible to problematic connectivity
> if ICMPv6 [ICMPv6] messages are blocked or not transmitted." The
> "implementing Path MTU Discovery and" seems redundant. ALL nodes sending
> packets larger than minimum MTU are "susceptible to problematic
> connectivity if ICMPv6 [ICMPv6] messages are blocked or not
> transmitted.". I get what you are trying to say, but my OCD tendencies
> would not allow me to ignore this...
> 
> 3: "In the case of multipath routing (e.g., Equal Cost Multipath Routing,
> ECMP),"- this is vague / confusing -- (Equal Cost Multipath Routing,
> ECMP) makes it sound like either ECMP is an acronym for Equal Cost
> Multipath Routing, or that ECMP is something different to Equal Cost
> Multipath Routing.
> I'd suggest just dropping the "ECMP" (or, "Equal Cost Multipath (ECMP)
> routing", but that seems clumsy)
> 
>