Subject: New Version Notification for draft-hinden-6man-mtu-option

From: Bob Hinden <[email-masked]>
Date: Fri, 5 Jul 2019 11:21:48 -0700

We submitted a new version of draft-hinden-6man-mtu-option.  The changes are:

   o  Changed option format to also include the Returned MTU value and
      Return flag and made related text changes in Section 6.2 to
      describe this behaviour.
   o  ICMP Packet Too Big messages are no longer used for feedback to
      the Source host.
   o  Added to Acknowledgements Section that a similar mechanism was
      proposed for IPv4 in 1988 in [RFC1063].
   o  Editorial changes.

These changes were based on experience at the last hackathon, discussion at the last 6man session, and discussion on the list.  With the Returned MTU value and Return Flag, we think this is significantly improved from the previous drafts.

Please review and comment.

Thanks,
Bob & Gorry

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hinden-6man-mtu-option-02.txt
> Date: July 5, 2019 at 11:16:26 AM PDT
> To: "Godred Fairhurst" <[email-masked]>, "Robert Hinden" <[email-masked]>, "Robert M. Hinden" <[email-masked]>, "Gorry Fairhurst" <[email-masked]>
> 
> 
> A new version of I-D, draft-hinden-6man-mtu-option-02.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name:		draft-hinden-6man-mtu-option
> Revision:	02
> Title:		IPv6 Minimum Path MTU Hop-by-Hop Option
> Document date:	2019-07-05
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/internet-drafts/draft-hinden-6man-mtu-option-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-6man-mtu-option/
> Htmlized:       https://tools.ietf.org/html/draft-hinden-6man-mtu-option-02
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-6man-mtu-option
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-mtu-option-02
> 
> Abstract:
>   This document specifies a new Hop-by-Hop IPv6 option that is used to
>   record the minimum Path MTU along the forward path between a source
>   to a destination host.  This collects a minimum recorded MTU along
>   the path to the destination.  The value can then be communicated back
>   to the source using the return Path MTU field in the option.
> 
>   This Hop-by-Hop option is intended to be used in environments like
>   Data Centers and on paths between Data Centers, to allow them to
>   better take advantage of paths able to support a large Path MTU.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 6 Jul 2019 11:52:13 +0100

Bob, Gorry,

nits:

1. s/achieve it's potential/achieve its potential/

2. 10G ethernet is considered low speed for data centres today. To work 
around speed rate obsolescence, it might be an idea to refer to modern 
"high speed" rates or something similar rather than naming any 
particular rate. 100G is now commonplace.  In a couple of years, this 
will be outdated by 400g, at which point 100g will be considered old hat.

some initial thoughts on some other issues:

3. the document notes:

>    o  The design of this Hop-by-Hop Option makes it feasible to be
>       implemented within the fast path of a router, because the required
>       processing is simple.

I'd respectfully suggest s/makes it feasible/may make it possible/. Any 
packet rewriting mechanism comes at a cost, and in this case the 
rewriting mechanism will need to inspect the MTU of the egress interface 
in order to. In the case of NPU based forwarding, this may work.  For 
ASIC forwarding, the cost of implementation may not be worth it.

>    o  Simple-exchange protocols (i.e low data-volume applications
>       [RFC8085] that only send one or a few packets per transaction,
>       could be optimized by assuming that the Path MTU is symmetrical,
>       that is where the Path MTU is the same in both directions, or at
>       least not smaller in the return path. [...]

This is an assumption of faith.

Nick

Bob Hinden wrote on 05/07/2019 19:21:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Bob Hinden <[email-masked]>
Date: Sat, 6 Jul 2019 07:53:56 -0700

Nick,

Thanks for the comments.  Inline.

> On Jul 6, 2019, at 3:52 AM, Nick Hilliard <[email-masked]> wrote:
> 
> Bob, Gorry,
> 
> nits:
> 
> 2. 10G ethernet is considered low speed for data centres today. To work around speed rate obsolescence, it might be an idea to refer to modern "high speed" rates or something similar rather than naming any particular rate. 100G is now commonplace.  In a couple of years, this will be outdated by 400g, at which point 100g will be considered old hat.

Good point.   We will improve this text to include higher rates.  BTW, is the maximum packet size also 9000 (non-IEEE std) at 100G and 400G?

> I'd respectfully suggest s/makes it feasible/may make it possible/. Any packet rewriting mechanism comes at a cost, and in this case the rewriting mechanism will need to inspect the MTU of the egress interface in order to. In the case of NPU based forwarding, this may work.  For ASIC forwarding, the cost of implementation may not be worth it.

Noted.   “should make it” might be better for now until we have some data or feedback from ASIC designers.

> This is an assumption of faith.

Yes it is.

Thanks,
Bob