BTW, RFC5320 gives attribution for where the original "report fragmentation" concept came from (Charles Lynn; 1987).
Fred > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Templin (US), > Fred L > Sent: Friday, November 22, 2019 5:51 AM > To: Manoj Nayak <[email protected]>; [email protected] > Cc: [email protected] > Subject: Re: [Int-area] New Version Notification for > draft-bonica-intarea-lossless-pmtud-00.txt > > You forced me to go back to my old documents to see where this is discussed. > The > idea of using IPv4 fragmentation as a lossless path MTU determination > mechanism > appears in RFC5320. The SEAL header indeed includes an "R" bit telling the > receiver > when a fragmentation report response is desired. > > As an experimental, RFC5320 did not go into an implementation diversity > survey; > only linux. Listening to hearsay that MTU-sized fragments cannot normally be > expected is one of the reasons we abandoned the SEAL approach. But, if you > have done a survey and concluded that the vast majority of implementations > result in MTU-sized fragments then good for you. > > I still think though that some kind of RF bit is needed. In the same way that > ICMP "fragmentation needed" is only sent when DF is 1, ICMP "fragmentation > report" should only be sent when RF is 1. Or, maybe you want to send ICMP > "fragmentation needed" regardless of the state of the DF bit? > > I think applications that rely on fragmentation will not want to receive ICMP > fragmentation reports over links that might have long delays and/or low > data rate capacities. The application knows it is invoking fragmentation; > it does not want for the network to be sending it useless reports along > the reverse path. Hence the RF bit. > > Thanks - Fred > > > -----Original Message----- > > From: Manoj Nayak [mailto:[email protected]] > > Sent: Wednesday, November 20, 2019 8:15 PM > > To: Templin (US), Fred L <[email protected]>; [email protected] > > Cc: [email protected] > > Subject: Re: [Int-area] New Version Notification for > > draft-bonica-intarea-lossless-pmtud-00.txt > > > > Hello Fred, > > > > Yes, it is possible that the largest fragment received is *much* smaller > > than the PMTU. However, a survey of > > popular operating systems reveals that the largest fragment does reflect > > the PMTU. > > > > If we are really worried about this problem, the sender can ignore the ICMP > > message when the MTU is smaller than > > the “smallest believable value” (e.g., 1500 bytes). > > > > There was another query, if it is worth doing Lossless PMTUD for ipv4. > > IPv4 will be with us for a long time. Lossless PMTUD doesn’t take much > > effort. So why not ... > > > > Regards > > Manoj Nayak > > > > On 14/11/19, 8:15 PM, "Templin (US), Fred L" <[email protected]> > > wrote: > > > > Manoj, > > > > > As per section 4.2.2.7 from rfc 1812, > > > > > > “There are several fragmentation techniques in common use in the > > > Internet. One involves splitting the IP datagram into IP > > > fragments with the first being MTU sized, and the others being > > > approximately the same size, smaller than the MTU. “ > > > > > > In both of the above cases, idea in our draft works. > > > > No it doesn't work. The text you quoted says that some techniques can > > cause all fragments to be "smaller than the MTU". It doesn't say how > > much > > smaller, so we must assume that it could be significantly smaller such > > that > > the maximum fragment size bears no relation to the path MTU. Therefore, > > in the general sense, it just doesn't work. > > > > We have been through this before. It is in my expired drafts. > > > > Fred > > > > > -----Original Message----- > > > From: Int-area [mailto:[email protected]] On Behalf Of Manoj > > Nayak > > > Sent: Wednesday, November 13, 2019 8:35 PM > > > To: [email protected] > > > Cc: [email protected] > > > Subject: Re: [Int-area] New Version Notification for > > draft-bonica-intarea-lossless-pmtud-00.txt > > > > > > Hello Joe, > > > > > > Please find my reply. > > > > > > >>- 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) > > > > > > We use an unused field in first 8 bytes of ICMP error/reply message. > > How the idea would be > > > affected if minimum packet size is 68 bytes or 576 bytes. As per my > > understanding, > > > existing ICMP error/reply message works in v4-in-v4 tunnelling, so it > > would continue to > > > work with the idea proposed in our draft. we won’t let the ICMP > > message exceed a reasonable size. > > > in our implementation, that will be 576. > > > > > > > > > > > > >>- 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 > > > > > > > > > As per section 4.2.2.7 from rfc 1812, > > > > > > “There are several fragmentation techniques in common use in the > > > Internet. One involves splitting the IP datagram into IP > > > fragments with the first being MTU sized, and the others being > > > approximately the same size, smaller than the MTU. “ > > > > > > In both of the above cases, idea in our draft works. In our > > implementation, > > > We can assume the first fragment to be largest fragment. This first > > fragment remains > > > Largest fragment unless until one more fragment is found to be > > greater than the first fragment. > > > > > > For example: > > > > > > While assembling the fragments, > > > > > > I=0; > > > Largest Fragment = packet-I; > > > For (, I < n , ++I) > > > If ( packet-I > Largest Fragment) > > > Largest Fragment = packet-I; > > > > > > Hopefully I did not miss anything. > > > > > > Regards > > > Manoj Nayak > > > > > > ------------------------------ > > > > > > Message: 3 > > > Date: Tue, 29 Oct 2019 21:43:33 -0700 > > > From: Joe Touch <[email protected]> > > > To: Ron Bonica <[email protected]> > > > Cc: "[email protected]" <[email protected]> > > > Subject: Re: [Int-area] New Version Notification for > > > draft-bonica-intarea-lossless-pmtud-00.txt > > > Message-ID: <[email protected]> > > > Content-Type: text/plain; charset=utf-8 > > > > > > 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 > > <[email protected]> wrote: > > > > > > > > Folks, > > > > > > > > Please review and comment. > > > > > > > > Ron > > > > > > > > > > > > > > > > Juniper Business Use Only > > > > > > > > -----Original Message----- > > > > From: [email protected] <[email protected]> > > > > Sent: Tuesday, October 29, 2019 11:48 AM > > > > To: Ron Bonica <[email protected]>; Hakan Alpan > > <[email protected]>; Radon Rosborough <[email protected]>; > > Bradely > > > Newton <[email protected]>; Miles President <[email protected]>; Manoj > > Nayak <[email protected]> > > > > 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://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud- > > > > > 00__;!8WoA6RjC81c!XifH7EcqHRKXHyGSwB3ojXm6YmKn_vYWCjgM-VDTPTEzP-khJGlb9MqM8x-YTELKJ64$ > > > > > > > > > > > > > > > > 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 protected] > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int- > > > > > area__;!8WoA6RjC81c!XifH7EcqHRKXHyGSwB3ojXm6YmKn_vYWCjgM-VDTPTEzP-khJGlb9MqM8x-YOVqXLNE$ > > > > > > > > > > > > > > > _______________________________________________ > > > Int-area mailing list > > > [email protected] > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!Tp5Pvame6pgAtmlsi- > > 9_todREdZAH9ervNS0qugjDf4SKKWoRMSMvJ_yFYKUwTwaXCI$ > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
