Re: Warren Kumari's No Record on draft-ietf-6man-rfc1981bis-06: (with COMMENT)

[Suresh Krishnan <[e-mail]>]

Hi Warren,
  Thanks for your comments. Please see responses inline.

On Mon, May 8, 2017 at 4:01 PM, Warren Kumari <[e-mail]> wrote:
> Warren Kumari has entered the following ballot position for
> draft-ietf-6man-rfc1981bis-06: No Record
>
> 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:
> ----------------------------------------------------------------------
>
> [ Reminder to myself - I'm leaving this as No Record while looking
> more... ]
>
> 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).

This was new text added in the -bis document. In the context of the
sentence (regarding ICMPv6 filtering leading to black hole connection)
I think ICMPv6 works better than singling out 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)

Right. This is explored further in Section 5.2

"  However, in most cases a node will not have enough
   information to completely and accurately identify such a path.
   Rather, a node must associate a PMTU value with some local
   representation of a path.  It is left to the implementation to select
   the local representation of a path."

Would you like some additional text in this section?

>
> 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).

AFAIK, there was no discussion regarding this number. I have a hard
time seeing how this number relates to the (shortened) length of the
flow, though.

>
> 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?

Yes. You are right. Any out of band mechanism for probing the MTU will
likely end up having the same problem if the probe packets are treated
differently from the payload packets by the load balancers and other
middleboxes.

>
>  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.

I am not sure why the first hop router will send PTBs. At timer
expiry, the PMTU estimate will only be set to the MTU of the first-hop
link and hence the first hop router should be able to handle this, no?

>
>
> Nits (Some of these are purely academic.)
> I understand that you are trying to limit the changes, so feel free to
> ignore these:

I will let the editor chime in on these.

Thanks
Suresh