Subject: Fwd: New Version Notification for draft-hinden-6man-mtu-option-01.txt

From: Bob Hinden <[email-masked]>
Date: Mon, 11 Mar 2019 13:14:49 -0700

Gorry and I did an update to the mtu-option draft.   Links below.   The changes include:

   o  Changed requested status from Standards Track to Experimental to
       allow use of experimental option type (11110) to allow for
       experimentation.  Removed request for IANA Option assignment.
   o  Added Section 2 "Motivation and Problem Solved" section to better
       describe what the purpose of this document is.
   o  Added Appendix A describing planned experiments and how the
       results will be measured.
   o  Editorial changes.

Please review and comment.

There is also work being planned for the IETF Hackathon in Prague to do some experimentation and testing of this option.

Thanks,
Bob & Gorry

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-hinden-6man-mtu-option-01.txt
> Date: March 11, 2019 at 1:09:33 PM 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-01.txt
> has been successfully submitted by Robert M. Hinden and posted to the
> IETF repository.
> 
> Name:		draft-hinden-6man-mtu-option
> Revision:	01
> Title:		IPv6 Minimum Path MTU Hop-by-Hop Option
> Document date:	2019-03-11
> Group:		Individual Submission
> Pages:		12
> URL:            https://www.ietf.org/internet-drafts/draft-hinden-6man-mtu-option-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-hinden-6man-mtu-option/
> Htmlized:       https://tools.ietf.org/html/draft-hinden-6man-mtu-option-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-6man-mtu-option
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-mtu-option-01
> 
> 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 host by an ICMPv6 Packet Too Big message.
> 
>   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: Tom Herbert <[email-masked]>
Date: Mon, 11 Mar 2019 16:32:13 -0700

One comment.

>From the draft:

"If this is the first value, or if the received value is lower, it
SHOULD record the value as the Received PMTU for the Source of the
Packet, and it SHOULD send the new value back to the Source of the
packet.  This can be done by creating an ICMPv6 Packet Too Big
message."

Alternatively to using ICMPv6 I suggest that the discovered value is
reflected back to the source in an MTU option in the reverse direction
inline of the flow. For instance, a TCP SYN could carry the MTU
option, and the SYN-ACK provides the discovered path MTU. So the MTU
option would contain two MTU values one that is set by intermdiate
nodes, and the other that is simply the reflected value. This
eliminates the dependency on ICMP (which doesn't itself have a great
track record for being reliable) and it eliminates the load of a
separate out of band packet in the network.

Tom

On Mon, Mar 11, 2019 at 1:15 PM Bob Hinden <[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 12 Mar 2019 15:58:52 +0000

Hi Bob and Gorry,

As I said a while back, this document needs a reference to RFC1063 along with
text supporting why you think your approach will be successful where RFC1063
was not.

Thanks - Fred

From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Monday, March 11, 2019 1:15 PM
To: IPv6 List <[email-masked]>
Cc: Gorry (erg) <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Fwd: New Version Notification for draft-hinden-6man-mtu-option-01.txt

Thanks,
Bob & Gorry

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-hinden-6man-mtu-option-01.txt
Date: March 11, 2019 at 1:09:33 PM PDT
To: "Godred Fairhurst" <[email-masked]<mailto:[email-masked]>>, "Robert Hinden" <[email-masked]<mailto:[email-masked]>>, "Robert M. Hinden" <[email-masked]<mailto:[email-masked]>>, "Gorry Fairhurst" <[email-masked]<mailto:[email-masked]>>

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

---

From: Erik Kline <[email-masked]>
Date: Tue, 12 Mar 2019 12:38:15 -0700

Well, 1063 being obsoleted by 1191 perhaps was a mistake?

It seems fair to me to say "because ICMP-based learning didn't really work
out, we'll go back to trying an IP-layer version of the only thing we know
does work in practice (TCP MSS)".

On Tue, 12 Mar 2019 at 09:00, Templin (US), Fred L <
[email-masked]> wrote:

> *From:* ipv6 [mailto:ipv6-bounces@ietf..org] *On Behalf Of *Bob Hinden
> *Sent:* Monday, March 11, 2019 1:15 PM
> *To:* IPv6 List <[email-masked]>
> *Cc:* Gorry (erg) <[email-masked]>; Bob Hinden <[email-masked]
> >
> *Subject:* Fwd: New Version Notification for
> draft-hinden-6man-mtu-option-01.txt
>
>
>
> There is also work being planned for the IETF Hackathon in Prague to do
> some experimentation and testing of this option.
>
>
>
> Thanks,
>
> Bob & Gorry
>
>
>
>
>
>
>
> Begin forwarded message:
>
>
>
> *From: [email-masked]
>
> *Subject: New Version Notification for draft-hinden-6man-mtu-option-01.txt*
>
> *Date: *March 11, 2019 at 1:09:33 PM PDT
>
> *To: *"Godred Fairhurst" <[email-masked]>, "Robert Hinden" <
> [email-masked]>, "Robert M. Hinden" <[email-masked]>, "Gorry
> Fairhurst" <[email-masked]>
>
>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-hinden-6man-mtu-option-01.txt
> <https://www.ietf.org/internet-drafts/draft-hinden-6man-mtu-option-01..txt>
> Status:
> https://datatracker..ietf.org/doc/draft-hinden-6man-mtu-option/
> <https://datatracker.ietf.org/doc/draft-hinden-6man-mtu-option/>
> Htmlized:
> https://tools.ietf.org/html/draft-hinden-6man-mtu-option-01
> <https://tools.ietf..org/html/draft-hinden-6man-mtu-option-01>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-hinden-6man-mtu-option
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-mtu-option-01
>
> Abstract:
>   better take advantage of paths able to support a large Path MTU..
>
>
>
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 13 Mar 2019 13:29:33 +0000

RFC1063 was obsoleted some while ago - so this is internet archaeology. 
I think the primary reasons from my side were:

(1) PMTUD at the network layer, doesn't actually solve the problem - alas.
(2) We no longer need  a full robust solution at the IP layer - PLPMTUD 
and DPLPMTUD provide the robustness needed to make this useful but do so 
at the transport layer, so we're in a different ERA where it is now much 
less important that this IP option  is sucecssfully changed by all 
routers on path.

We can add text next revision.

Gorry

On 12/03/2019, 15:58, Templin (US), Fred L wrote:
> *From:*ipv6 [mailto:[email-masked]] *On Behalf Of *Bob Hinden
> *Cc:* Gorry (erg) <[email-masked]>; Bob Hinden 
> <[email-masked]>
> There is also work being planned for the IETF Hackathon in Prague to 
> do some experimentation and testing of this option.
>
> Thanks,
>
> Bob & Gorry
>
>
>
>     Begin forwarded message:
>
>     *From: [email-masked] <mailto:[email-masked]>
>
>     *To: *"Godred Fairhurst" <[email-masked]
>     <mailto:[email-masked]>>, "Robert Hinden"
>     <[email-masked] <mailto:[email-masked]>>, "Robert M.
>     Hinden" <[email-masked] <mailto:[email-masked]>>,
>     "Gorry Fairhurst" <[email-masked] <mailto:[email-masked]>>
>
>
>     Name:draft-hinden-6man-mtu-option
>     Revision:01
>     Title:IPv6 Minimum Path MTU Hop-by-Hop Option
>     Document date:2019-03-11
>     Group:Individual Submission
>     Pages:12
>     URL:
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 13 Mar 2019 20:29:16 +0000

Hi Erik,

>> Well, 1063 being obsoleted by 1191 perhaps was a mistake?

Excellent question. I have done quite a bit of historical investigation into
the origins of PMTUD, and came to the conclusion that the working group
was under a time crunch and saw 1191 as the “easy way out”. So, they
ditched 1063 and promoted 1191, and the rest is history.

Thanks - Fred

From: Erik Kline [mailto:[email-masked]]
Sent: Tuesday, March 12, 2019 12:38 PM
To: Templin (US), Fred L <[email-masked]>
Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>; Gorry (erg) <[email-masked]>
Subject: Re: New Version Notification for draft-hinden-6man-mtu-option-01.txt

It seems fair to me to say "because ICMP-based learning didn't really work out, we'll go back to trying an IP-layer version of the only thing we know does work in practice (TCP MSS)".

On Tue, 12 Mar 2019 at 09:00, Templin (US), Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Bob and Gorry,

Thanks - Fred

From: ipv6 [mailto:ipv6-bounces@ietf.<mailto:ipv6-bounces@ietf.>.org] On Behalf Of Bob Hinden
Sent: Monday, March 11, 2019 1:15 PM
To: IPv6 List <[email-masked]<mailto:[email-masked]>>
Cc: Gorry (erg) <[email-masked]<mailto:[email-masked]>>; Bob Hinden <[email-masked]<mailto:[email-masked]>>
Subject: Fwd: New Version Notification for draft-hinden-6man-mtu-option-01.txt

Thanks,
Bob & Gorry

Begin forwarded message:

Name:                        draft-hinden-6man-mtu-option
Revision:       01
Title:              IPv6 Minimum Path MTU Hop-by-Hop Option
Document date:         2019-03-11
Group:                       Individual Submission
Pages:                        12
URL:            https://www.ietf.org/internet-drafts/draft-hinden-6man-mtu-option-01.txt<https://www.ietf.org/internet-drafts/draft-hinden-6man-mtu-option-01..txt>
Status:         https://datatracker..ietf.org/doc/draft-hinden-6man-mtu-option/<https://datatracker.ietf.org/doc/draft-hinden-6man-mtu-option/>
Htmlized:       https://tools.ietf.org/html/draft-hinden-6man-mtu-option-01<https://tools.ietf..org/html/draft-hinden-6man-mtu-option-01>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-6man-mtu-option
Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-mtu-option-01

Abstract:

The IETF Secretariat

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 13 Mar 2019 20:37:01 +0000

Hi Gorry,

As I just replied to Erik, RFCs 1063 and 1191 came to a crossroads and the pmtud
working group at that time was under a time crunch so they took the easy way out.

Who knows where we would be today if the 1063 experiment were allowed to
continue? For sure, the Internet is in a different time and place than it was 31
years ago, but I believe it bears mention in your draft and I appreciate your
offering to add it.

Thanks - Fred

> -----Original Message-----
> From: Gorry Fairhurst [mailto:[email-masked]]
> Sent: Wednesday, March 13, 2019 6:30 AM
> Cc: Bob Hinden <[email-masked]>; IPv6 List <[email-masked]>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 13 Mar 2019 21:23:42 +0000

BTW, if anyone wants to go on an archaeological dig the history can be found
in the TCP-IP archives:

http://linkupnetworks.net/tcp-ip/tcp-ip.full.txt

Some search strings to try include  "mogul", "deering", "fragmentation",
"harmful", "mtu"...

Thanks - Fred

> From: ipv6 [mailto:[email-masked]] On Behalf Of Templin (US), Fred L
> Sent: Wednesday, March 13, 2019 1:37 PM
> To: [email-masked]
> Cc: IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
> Subject: RE: New Version Notification for draft-hinden-6man-mtu-option-01.txt
> 
> Hi Gorry,
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sun, 24 Mar 2019 13:58:42 +0000

Since TCP MSS is the most robust mechanism, the learned PMTU can be used to set TCP-MSS in SYN-ACK from the client.

Unfortunately, TCP MSS cannot inform the “server” about server-to-client PMTU (because the client must send TCP MSS with its SYN).  This begs a draft allowing TCP MSS option sent with non-SYN packets.  Would anyone be interested in seeing that draft (or collaborating on that draft)?

A somewhat unrelated proposal is combining the idea of draft-hinden-6man-mtu-option (add an Hop-by-Hop option to refine PMTU estimate on the way to the destination) with the idea of draft-leddy-6man-truncate (add a “truncated” Destination Option and continue forwarding the truncated packet on the way to the destination).  If the truncated packet gets dropped before reaching the destination, no harm has been done (without “truncation”, it would had been dropped earlier).  But if the truncated packets reaches the destination, the PMTU Option has had a chance to deliver PMTU to the destination (because of the “truncated” DO, the data will not be delivered to the application).  That way, PMTU Option has a chance to work with any size packets – both smaller-then-PMTU and larger-then-PMTU packets.

  *   Igor

From: Erik Kline <[email-masked]>
Sent: Tuesday, March 12, 2019 3:38 PM
To: Templin (US), Fred L <[email-masked]>
Cc: Gorry (erg) <[email-masked]>; IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>
Subject: Re: New Version Notification for draft-hinden-6man-mtu-option-01.txt

Thanks - Fred

Thanks,
Bob & Gorry

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-hinden-6man-mtu-option-01.txt
Date: March 11, 2019 at 1:09:33 PM PDT
To: "Godred Fairhurst" <[email-masked]<mailto:[email-masked]>>, "Robert Hinden" <[email-masked]<mailto:[email-masked]>>, "Robert M. Hinden" <[email-masked]<mailto:[email-masked]>>, "Gorry Fairhurst" <[email-masked]<mailto:[email-masked]>>

Name:                        draft-hinden-6man-mtu-option
Revision:       01
Title:              IPv6 Minimum Path MTU Hop-by-Hop Option
Document date:         2019-03-11
Group:                       Individual Submission
Pages:                        12
URL:            https://www.ietf.org/internet-drafts/draft-hinden-6man-mtu-option-01.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dhinden-2D6man-2Dmtu-2Doption-2D01...txt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=p4pt8kOGB3t2wt97XqBWiNz06dcZPK3z_Z5jctKsbe8&s=j2YkFbjduYA0Ux-luGxpy_Ju1BekeOa7Vc7uoASgG14&e=>
Status:         https://datatracker..ietf.org/doc/draft-hinden-6man-mtu-option/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhinden-2D6man-2Dmtu-2Doption_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=p4pt8kOGB3t2wt97XqBWiNz06dcZPK3z_Z5jctKsbe8&s=-WdvGNDn0xEaRdxgG0YV8190xLlWyPA8E2Mt1nb-sB4&e=>
Htmlized:       https://tools..ietf.org/html/draft-hinden-6man-mtu-option-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf...org_html_draft-2Dhinden-2D6man-2Dmtu-2Doption-2D01&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=p4pt8kOGB3t2wt97XqBWiNz06dcZPK3z_Z5jctKsbe8&s=56AIqnPHsWL_BrjPleLMfOILcA5O1HChxVd2CHREu58&e=>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-hinden-6man-mtu-option<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dhinden-2D6man-2Dmtu-2Doption&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=p4pt8kOGB3t2wt97XqBWiNz06dcZPK3z_Z5jctKsbe8&s=63GIXB2kYPNuY6xvdtJ0xftec0coR0DEzKPLvCzdoR0&e=>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-hinden-6man-mtu-option-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dhinden-2D6man-2Dmtu-2Doption-2D01&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=p4pt8kOGB3t2wt97XqBWiNz06dcZPK3z_Z5jctKsbe8&s=RXwmpgy4InpFaMPLaKLRiY-J0E603mqolAZPzV1rMB0&e=>

Abstract:

  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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=p4pt8kOGB3t2wt97XqBWiNz06dcZPK3z_Z5jctKsbe8&s=6NlGXWh6hRrZf7ldB_cWH-3NnISvIV-qD2qJnI-Aym0&e=>.

The IETF Secretariat

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipv6&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=p4pt8kOGB3t2wt97XqBWiNz06dcZPK3z_Z5jctKsbe8&s=vSW4fsoRqRgUSKs-5PGS2f6LY3W2sSpKXguTvW3ClXg&e=>
--------------------------------------------------------------------

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 24 Mar 2019 15:18:16 +0100

Sent from my iPad

> On 24 Mar 2019, at 14:58, Lubashev, Igor <[email-masked]> wrote:
> 
For TCP, that is another way to feedback the result of discovering the PMTU on the forward path, I agree.

> Unfortunately, TCP MSS cannot inform the “server” about server-to-client PMTU (because the client must send TCP MSS with its SYN).  This begs a draft allowing TCP MSS option sent with non-SYN packe…
Curious: My understanding was that the MSS option worked through MSS-Clamping. So are you trying to make the IPv6 EH methods work in places where MSS-Clamping fails? (Is this a common case... if you know more tell me).

I also wonder: Do you expect all devices that currently handle MSS-Clamping to now look in other packets than SYNs to find a MSS option? 

> A somewhat unrelated proposal is combining the idea of draft-hinden-6man-mtu-option (add an Hop-by-Hop option to refine PMTU estimate on the way to the destination) with the idea of draft-leddy-6man-truncate (add a “truncated” Destination Option and continue forwarding the truncated packet on the way to the destination).  If the truncated packet gets dropped before reaching the destination, no harm has been done (without “truncation”, it would had been dropped earlier). 
Really? - It depends. If you re detecting a Smaller MTU, then yes that may be the case. If you were trying to probe to find an appropriate MTU then wouldn’t you probe to see if your largest supported local pocket size is supported by the path?

> But if the truncated packets reaches the destination, the PMTU Option has had a chance to deliver PMTU to the destination (because of the “truncated” DO, the data will not be delivered to the application).  That way, PMTU Option has a chance to work with any size packets – both smaller-then-PMTU and larger-then-PMTU packets.
By combining two approaches it would  also create multiple potential reasons why neither may not succeed. So I think it depends on whether you care more about potentially optimising in some environments, or being robust in as many cases as possible - or somewhere between. This may be worth exploring how this combined approach fairs across paths?

Gorry

> Igor
> On Tue, 12 Mar 2019 at 09:00, Templin (US), Fred L <[email-masked]> wrote:
> Hi Bob and Gorry,
>  
> From: ipv6 [mailto:ipv6-bounces@ietf..org] On Behalf Of Bob Hinden
> Status:         https://datatracker..ietf.org/doc/draft-hinden-6man-mtu-option/
> Htmlized:       https://tools..ietf.org/html/draft-hinden-6man-mtu-option-01

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sun, 24 Mar 2019 22:12:23 +0000

≫ Since TCP MSS is the most robust mechanism, the learned PMTU can be used to set TCP-MSS in SYN-ACK from the client.
> For TCP, that is another way to feedback the result of discovering the PMTU on the forward path, I agree.

≫ Unfortunately, TCP MSS cannot inform the “server” about server-to-client PMTU (because the client must send TCP MSS with its SYN).
≫ This begs a draft allowing TCP MSS option sent with non-SYN packets.  Would anyone be interested in seeing that draft (or collaborating on that draft)?
>
> Curious: My understanding was that the MSS option worked through MSS-Clamping. So are you trying to make the IPv6 EH methods work in places where MSS-Clamping fails?
> (Is this a common case... if you know more tell me).

In places where MSS-Clamping can only work for symmetric routing.  IPv6 EH would work for asymmetric routing (don’t have stats on % of such routes).  MSS-Clamping also does not work for routing changing after the initial handshake.

> I also wonder: Do you expect all devices that currently handle MSS-Clamping to now look in other packets than SYNs to find a MSS option?

There is no absolute need for that.  If the new MSS implies a lower PMTU, the PMTU would be adjusted on the sender immediately (subject to some sanity checks).  If a new MSS implies an up-adjustment of PMTU, this is an input to PMTUD to try probing for a larger PMTU.  If an MSS-Clamping device looks for MSS in non-SYNs, that would just improve the input for the PMTUD algorithm.

≫A somewhat unrelated proposal is combining the idea of draft-hinden-6man-mtu-option (add an Hop-by-Hop option to refine PMTU estimate on the way to the destination)
≫with the idea of draft-leddy-6man-truncate (add a “truncated” Destination Option and continue forwarding the truncated packet on the way to the destination).
≫If the truncated packet gets dropped before reaching the destination, no harm has been done (without “truncation”, it would had been dropped earlier).
>
> Really? - It depends. If you re detecting a Smaller MTU, then yes that may be the case. If you were trying to probe to find an appropriate MTU then wouldn’t you probe to
> see if your largest supported local pocket size is supported by the path?

Yes, that’s correct.  You can avoid black holes quickly (especially if the black hole is due to the routing change), and you start to probe for larger PMTU (with a hint of what that PMTU is likely to be).

≫But if the truncated packets reaches the destination, the PMTU Option has had a chance to deliver PMTU to the destination (because of the “truncated” DO, the data
≫will not be delivered to the application).  That way, PMTU Option has a chance to work with any size packets – both smaller-then-PMTU and larger-then-PMTU packets.
>
>By combining two approaches it would also create multiple potential reasons why neither may not succeed. So I think it depends on whether you care more about potentially optimising in some environments, or being >robust in as many cases as possible - or somewhere between. This may be worth exploring how this combined approach fairs across paths?

There are no new reasons for a failure beyond the PMTU option of draft-hinden-6man-mtu-option.  The “truncated” DO would only be added by the router, if it would have to drop the packet otherwise (and if there are CPU resources available on the router to do so – it does not have to happen in ASIC).  In fact, the router could add both PMTU Hop-By-Hop option and Truncated Destination options in leu of dropping the packet outright.

  *   Igor

From: Gorry Fairhurst <[email-masked]>
Sent: Sunday, March 24, 2019 10:18 AM
To: Lubashev, Igor <[email-masked]>
Cc: [email-masked]; Templin (US), Fred L <[email-masked]>; IPv6 List <[email-masked]>; Bob Hinden <[email-masked]>; Ron Bonica <[email-masked]>; Jen Linkova <[email-masked]>
Subject: Re: New Version Notification for draft-hinden-6man-mtu-option-01.txt

Sent from my iPad

On 24 Mar 2019, at 14:58, Lubashev, Igor <[email-masked]<mailto:[email-masked]>> wrote:
Since TCP MSS is the most robust mechanism, the learned PMTU can be used to set TCP-MSS in SYN-ACK from the client.

Gorry

  *   Igor

From: Erik Kline <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 12, 2019 3:38 PM
To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
Cc: Gorry (erg) <[email-masked]<mailto:[email-masked]>>; IPv6 List <[email-masked]<mailto:[email-masked]>>; Bob Hinden <[email-masked]<mailto:[email-masked]>>
Subject: Re: New Version Notification for draft-hinden-6man-mtu-option-01.txt

Thanks - Fred

Thanks,
Bob & Gorry

Begin forwarded message:

Abstract:

The IETF Secretariat