> 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:int-area-boun...@ietf.org] On Behalf Of Bob Hinden > Sent: Thursday, October 31, 2019 4:51 PM > To: Ron Bonica <rbonica=40juniper....@dmarc.ietf.org> > Cc: int-area@ietf.org > 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=40juniper....@dmarc.ietf.org> wrote: > > > > > > Updated draft > > > > > > Juniper Business Use Only > > > > -----Original Message----- > > From: internet-dra...@ietf.org <internet-dra...@ietf.org> > > Sent: Thursday, October 31, 2019 3:15 PM > > To: Ron Bonica <rbon...@juniper.net>; Hakan Alpan <hal...@hnc.edu>; Radon > > Rosborough <rrosboro...@hmc.edu>; Bradely > Newton <bnew...@hmc.edu>; Bradley Newton <bnew...@hmc.edu>; Miles President > <mpresid...@hmc.edu>; Manoj Nayak > <manojna...@juniper.net> > > 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 > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
