Warren Kumari's No Objection on draft-ietf-6man-rfc1981bis-07: (with COMMENT)

[Warren Kumari <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-6man-rfc1981bis-07: No Objection

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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)