Manoj, on some links any number of unwanted messages greater than 0 is too many. Last week, I had the opportunity to do networking over a 35Kbps link. On links like that, there is a dire need to reduce the number of non-essential packets, and useless ICMPs are a good example of a non-essential packet.
But extending to consider all manners of links, useless packets are simply clutter that would be better off suppressed even if there is ample link capacity. If the sender doesn't want to receive fragmentation reports, the receiver should have some way of knowing that and suppress them. Fred > -----Original Message----- > From: Manoj Nayak [mailto:[email protected]] > Sent: Wednesday, November 13, 2019 9:02 PM > To: Templin (US), Fred L <[email protected]> > Cc: [email protected] > Subject: Re: [Int-area] New Version Notification for > draft-bonica-intarea-lossless-pmtud-00.txt > > Hello Fred, > > Please find my reply. > > >>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).” > > > > If an application does not want to receive the ICMP reply then it can drop > the message. > All ICMP message replies are unconditional and sender does not set any > condition > to receive them. Sender Application of the packet either drop ICMP reply or > rate-limit them. > > Setting RF bit in IPV4 header is a complex task and needs changes at sender > end. > So far none of the ICMP reply/error message sets a bit in the packet while > sending a packet > to indicate receivers to send ICMP reply. > > Hopefully I was able to explain... > > Regards > Manoj Nayak > > > > Message: 2 > Date: Tue, 29 Oct 2019 19:41:18 +0000 > From: "Templin (US), Fred L" <[email protected]> > To: Ron Bonica <[email protected]>, > "[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="us-ascii" > > 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 > > > -----Original Message----- > > From: Int-area [mailto:[email protected]] On Behalf Of Ron > Bonica > > Sent: Tuesday, October 29, 2019 9:53 AM > > To: [email protected] > > Subject: [Int-area] FW: New Version Notification for > draft-bonica-intarea-lossless-pmtud-00.txt > > > > 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://www.ietf.org/mailman/listinfo/int-area
