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

From: "Templin (US), Fred L" <[email-masked]>
Date: Fri, 1 Nov 2019 16:04:36 +0000

> A different title might be better.

Call it "Report Fragmentation". Have the receiver check the RF bit to see if the sender
wants fragmentation reported. If so, send the report; else, just reassemble as normal.

Fred

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: Thursday, October 31, 2019 4:51 PM
> To: Ron Bonica <rbonica=[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt
> 
> Ron,
> 
> A few comments on your draft.
> 
> Naming the draft "Lossless Path MTU Discovery (PMTUD)” seems to be very aspirational, and is an oxymoron.  ICMP message can be
> rate limited and dropped in the network.   Hardly “lossless”.  A different title might be better.
> 
> I do like the idea of the destination sending feedback, we have worked on some other drafts with that property.
> 
> The document says:
> 
>    This document describes alternative PMTUD procedures that do no rely
>    on the network's ability to deliver ICMP Destination Unreachable
>    messages to the source node.  In these procedures, the source node
>    produces an initial PMTU estimate.  This initial estimate is equal to
>    the MTU of the first link along the path to the destination node.  It
>    can be greater than the actual PMTU.
> 
> This is not really correct, your are still dependent on the networks ability to deliver ICMP messages to the source node.  Just not ICMP
> Destination Unreachable messages.   A new ICMP message isn’t going to be better, perhaps worse.
> 
> I didn’t understand the purpose of the Code field, that can indicate reassembly error.  What is the purpose of this?   This seems to be
> in conflict with this message that is sent when the destination node successfully reassemblies a set of fragments.  With the code
> indicating reassembly error, it is saying that the fragments were not reassembled.
> 
> It may be folly to try to modify IPv4 implementations at this point.   I have no objections if you wish to try pushing this big rock up hill,
> but I doubt you will be successful.
> 
> I see you have several co-authors from Harvey Mudd College.
> 
> Bob
> 
> 
> > On Oct 31, 2019, at 12:16 PM, Ron Bonica <rbonica=[email-masked]> wrote:
> >
> >
> > Updated draft
> >
> >
> > Juniper Business Use Only
> >
> > -----Original Message-----
> > From: [email-masked] <[email-masked]>
> > Sent: Thursday, October 31, 2019 3:15 PM
> > To: Ron Bonica <[email-masked]>; Hakan Alpan <[email-masked]>; Radon Rosborough <[email-masked]>; Bradely
> Newton <[email-masked]>; Bradley Newton <[email-masked]>; Miles President <[email-masked]>; Manoj Nayak
> <[email-masked]>
> > Subject: New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt
> >
> >
> > A new version of I-D, draft-bonica-intarea-lossless-pmtud-01.txt
> > has been successfully submitted by Ron Bonica and posted to the IETF repository.
> >
> > Name:		draft-bonica-intarea-lossless-pmtud
> > Revision:	01
> > Title:		Lossless Path MTU Discovery (PMTUD)
> > Document date:	2019-10-31
> > Group:		Individual Submission
> > Pages:		7
> > URL                     https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-01
> > 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
> > _______________________________________________
> > Int-area mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/int-area

---

From: Fred Baker <[email-masked]>
Date: Fri, 1 Nov 2019 12:44:21 -0400

On Nov 1, 2019, at 12:39 AM, Joe Touch <[email-masked]> wrote:
> On Oct 31, 2019, at 5:07 PM, Erik Kline <[email-masked]> wrote:
>> 
>> It may be folly to try to modify IPv4 implementations at this point.   I have no objections if you wish to try pushing this big rock up hill, but I doubt you will be successful.
>> 
>> BTW, what *actually* prevents a middlebox from doing IPv6 fragmentation? 
> 
> Expecting it to work. That middlebox has no idea what packets are going through other middleboxes from the same endpoint. There’s no way it can pick IDs to avoid collision, the way the origin can. That’s why both IPv4 and IPv6 rely on the origin creating those IDs.
> 
> The result would either be significantly increased reassembly errors, sort of like accidental poisoning of the receiver’s cache, or potentially resulting in incorrect packets (the latter could be more likely in some cases, e.g., when the fragment happens to have a zero IP checksum).

I don't especially disagree with you, BUT...

Thinking about middlebox fragmentation. OK, suppose I am a company with N middleboxen. Suppose I configured the middleboxes to generate N disjoint ranges of IDs. If I have a datagram arriving at a middle box and being fragmented into two or more, and the ID generated is within the range assigned to the middle box, I don't think the results you predict actually transpire.

Note that I'm not writing a draft about that. I'm not sure I want anyone thinking it's a great idea and needs to be implemented.

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Nov 2019 13:52:56 -0700

On 2019-11-01 09:44, Fred Baker wrote:

> On Nov 1, 2019, at 12:39 AM, Joe Touch <[email-masked]> wrote: On Oct 31, 2019, at 5:07 PM, Erik Kline <[email-masked]> wrote: 
> Expecting it to work. That middlebox has no idea what packets are going through other middleboxes from the same endpoint. There's no way it can pick IDs to avoid collision, the way the origin can. That's why both IPv4 and IPv6 rely on the origin creating those IDs.
> 
> The result would either be significantly increased reassembly errors, sort of like accidental poisoning of the receiver's cache, or potentially resulting in incorrect packets (the latter could be more likely in some cases, e.g., when the fragment happens to have a zero IP checksum).

Thinking about middlebox fragmentation. OK, suppose I am a company with
N middleboxen. Suppose I configured the middleboxes to generate N
disjoint ranges of IDs. If I have a datagram arriving at a middle box
and being fragmented into two or more, and the ID generated is within
the range assigned to the middle box, I don't think the results you
predict actually transpire. 

Yes - but that's exactly the point. You can't know you are the only such
middlebox. 

I.e., my general rule about middleboxes is that they work ONLY when ALL
the middleboxes on a path from A to B can act as a single proxy for
either A or B. That works at the edge of an enterprise (firewalls setup
around an enterprise perimeter) but nearly nowhere else. 

> Note that I'm not writing a draft about that. I'm not sure I want anyone thinking it's a great idea and needs to be implemented.

Glad to hear that, though. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 01 Nov 2019 13:56:32 -0700

FWIW, it could also be "Receiver PMTUD" (vs Packetization Layer, etc.). 

Again, though, the trouble is it doesn't overcome the issue with PMTUD
of ICMP black-holing. It is easier to deploy for experimental purposes
(runs only at the receiver rather than on all intermediate hops), but
that's the only benefit. 

Joe

On 2019-11-01 09:04, Templin (US), Fred L wrote:

> Naming the draft "Lossless Path MTU Discovery (PMTUD)" seems to be very aspirational, and is an oxymoron.  ICMP message can be
> rate limited and dropped in the network.   Hardly "lossless".  A different title might be better.
> 
> Destination Unreachable messages.   A new ICMP message isn't going to be better, perhaps worse.
> 
> I didn't understand the purpose of the Code field, that can indicate reassembly error.  What is the purpose of this?   This seems to be
> To: Ron Bonica <[email-masked]>; Hakan Alpan <[email-masked]>; Radon Rosborough <[email-masked]>; Bradely Newton <[email-masked]>; Bradley Newton <[email-masked]>; Miles President <[email-masked]>; Manoj Nayak
> <[email-masked]> Subject: New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt
> 
> 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