Subject: [Int-area] FW: New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

From: Ron Bonica <[email-masked]>
Date: Tue, 29 Oct 2019 16:53:11 +0000

Folks,

Please review and comment.

                        Ron

Juniper Business Use Only

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Tuesday, October 29, 2019 11:48 AM
To: Ron Bonica <[email-masked]>; Hakan Alpan <[email-masked]>; Radon Rosborough <[email-masked]>; Bradely Newton <[email-masked]>; Miles President <[email-masked]>; Manoj Nayak <[email-masked]>
Subject: New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

A new version of I-D, draft-bonica-intarea-lossless-pmtud-00.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:		draft-bonica-intarea-lossless-pmtud
Revision:	00
Title:		Lossless Path MTU Discovery (PMTUD)
Document date:	2019-10-29
Group:		Individual Submission
Pages:		8
URL:            https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-00

Abstract:
   This document describes alternative IPv4 PMTUD procedures that do not
   prevent IP fragmentation and do no rely on the network's ability to
   deliver ICMP Destination Unreachable messages to the source node.
   This document also defines a new ICMP message.  IPv4 nodes emit this
   new message when they reassemble a fragmented packet.

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: Fred Baker <[email-masked]>
Date: Tue, 29 Oct 2019 10:30:55 -0700

A few thoughts.

I take it that this imposes an expectation on the receiving node, per session, that it will keep a record of whether one or more fragments have been received, and if so what the largest of them is. Not clear to me, at least on a quick reading - is this sent the first time that size fragment is received (and therefore subject to issues with loss of the ICMP response), the first N times such a fragment is received, or every time such a fragment is received? I'd expect it's the first N times, for some value of N.

The big issue with PLMTUD at the moment is the fact that people filter out ICMP, or manage to do so accidentally. If people (or NATs) are filtering ICMP, won't they equally filter this one? If so, I don't see how this fixes it.

It also presumes a change to existing IPv4 code, this time twice - in the sender and in the receiver. What I'd really like to see is PLPLMTUD (RFC 4821 or some approximation thereto), which is a change to - only - the sender. I tend to see developers as choosing between implementing PLPMTUD and this logic; since neither helps the other and this logic requires two changes, I think the net effect (pun intended) is that neither works, just like PMTUD fails to work now.

Did I miss something?

---

From: Ron Bonica <[email-masked]>
Date: Tue, 29 Oct 2019 19:25:53 +0000

Hi Fred,

Thanks for the review. Responses inline.....

-----Original Message-----
From: Fred Baker <[email-masked]> 
Sent: Tuesday, October 29, 2019 12:31 PM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

A few thoughts.

[RB] Feedback is provided on a per packet basis, not on a per session basis. Whenever a receiver reassembles a packet, it sends an ICMP message to the sender indicating the size largest fragment belonging to the packet. This is assumed to be the PMTU. As always, ICMP messages are rate limited. 

[RB] Clearly, the ICMP message does no good unless it is delivered to the sender. However, in lossless PMTUD, ICMP filtering does not cause black holing. Subsequent packets will be fragmented and reassembled.

[RB] Lossless PMTUD isn't a competitor to PLPMTUD. It's really a niche solution for legacy IPv4 applications allow downstream fragmentation.

                                                                   Ron

Did I miss something?

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 29 Oct 2019 19:41:18 +0000

Ron, I proposed something like this a long time ago and called it "Report Fragmentation (RF)".
I think that concept and name were also proposed an even longer time ago in the days of
the pmtud wg back when RFCs 1063 and 1191 were under development in the late 1980's.

The thing is, applications that want to use steady-state fragmentation will not want to
receive RF ICMP messages. And so, there should be some way for the sender to indicate
to the receiver that an RF ICMP is desired. I think the way I proposed doing that was for
the sender to set the evil bit in the IPv4 header and re-purpose that bit as the "RF bit".
But, another way could be to include an indication at connection setup time at a layer
above IPv4 (e.g., a TCP option).

In any event, this idea has been kicked down the road before by myself and the earlier
pmtud researchers.  There are a number of details to concern yourself with including
assumptions of the receiver's reassembly buffer size. I have quite a large stack of
expired drafts on pmtud that you are welcome to examine to see what ground has
already been covered.

Fred

> From: Int-area [mailto:[email-masked]] On Behalf Of Ron Bonica
> Sent: Tuesday, October 29, 2019 9:53 AM
> To: [email-masked]
> Subject: [Int-area] FW: New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt
> 
> Folks,
> 
> To: Ron Bonica <[email-masked]>; Hakan Alpan <[email-masked]>; Radon Rosborough <[email-masked]>; Bradely
> Newton <[email-masked]>; Miles President <[email-masked]>; Manoj Nayak <[email-masked]>
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Joe Touch <[email-masked]>
Date: Tue, 29 Oct 2019 21:43:33 -0700

Hi, Ron,

A few things come to mind. The first one, IMO, renders the rest somewhat less important.

Joe

-------------

- this approach applies only to IPv4; not sure it’s worth trying to optimize for only that case
	(it requires on-path fragmentation permitted)

- this approach relies on ICMPs, so it’s as robust (or, more to the point, not) as PMTUD
	if ICMPs can find the reverse path from the dest, why wouldn’t the routers?
	i.e., isn’t the problem with ICMPs not just routers not sending them but firewalls BLOCKING them?
	(i.e., if ICMPs would work here, PMTU would have worked, rendering this unnecessary)

- why does this doc assume the max ICMP is 576?
	we’re still talking IPv4 here; it’s still 68 (that’s why only 64 bits of the orig payload are guaranteed)
	(yes, your note in the end of sec 1 is relevant, but given v4-in-v4 tunneling, it’s possible that paths might be smaller than the 576 assumption)

- why would this approach find the largest fragment through a system?
	rfc1812 talks about various strategies, one of which is “equal sized”, which might never find the max the way you propose 

> On Oct 29, 2019, at 9:53 AM, Ron Bonica <rbonica=[email-masked]> wrote:
> 
> Folks,
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 31 Oct 2019 19:07:27 +0000

Joe,

You have a point that this solution may never be widely deployed. So, I have cranked the intended status back to EXPERIMENTAL and removed the IANA request. (We can work with experimental code points.)

We will do the experiment and report on results.

                                                 Ron

-----Original Message-----
From: Joe Touch <[email-masked]> 
Sent: Wednesday, October 30, 2019 12:44 AM
To: Ron Bonica <[email-masked]>
Cc: [email-masked]
Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

Hi, Ron,

Joe

-------------

> URL:            https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-00__;!8WoA6RjC81c!SaG54qXv3mOmFFinOp93hDtn-j4u5ZzUbomMfaHAujluBDj7pJq_RtQMALmTf6K4$ 
> 
> 
> 
> Abstract:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!SaG54qXv3mOmFFinOp93hDtn-j4u5ZzUbomMfaHAujluBDj7pJq_RtQMAGjVmADJ$