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

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

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

---

From: Bob Hinden <[email-masked]>
Date: Thu, 31 Oct 2019 16:51:10 -0700

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
> 
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Erik Kline <[email-masked]>
Date: Thu, 31 Oct 2019 17:07:11 -0700

>
> 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?
In other words, if some box "decided to be helpful" and do IPv6
fragmentation in the middle, would anything really break (*other* than the
obvious existing problem with fragment extension headers not being
forwarded to their destination)?

I'm wondering about whether this work might be applicable to v6 as well,
even if just for parity.

---

From: Joe Touch <[email-masked]>
Date: Thu, 31 Oct 2019 21:39:17 -0700

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

Joe