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

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:manojnayak@juniper.net]
> Sent: Wednesday, November 13, 2019 9:02 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: int-area@ietf.org
> 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" <Fred.L.Templin@boeing.com>
>     To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>,
>     	"int-area@ietf.org" <int-area@ietf.org>
>     Subject: Re: [Int-area] New Version Notification for
>     	draft-bonica-intarea-lossless-pmtud-00.txt
>     Message-ID: <f3de4d2744234239acf2e4bfa4626e8c@boeing.com>
>     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:int-area-bounces@ietf.org] On Behalf Of Ron Bonica
>     > Sent: Tuesday, October 29, 2019 9:53 AM
>     > To: int-area@ietf.org
>     > 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: internet-drafts@ietf.org <internet-drafts@ietf.org>
>     > Sent: Tuesday, October 29, 2019 11:48 AM
>     > To: Ron Bonica <rbonica@juniper.net>; Hakan Alpan <halpan@hnc.edu>; Radon Rosborough <rrosborough@hmc.edu>; Bradely
>     > Newton <bnewton@hmc.edu>; Miles President <mpresident@hmc.edu>; Manoj Nayak <manojnayak@juniper.net>
>     > 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
>     > Int-area@ietf.org
>     > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-
> area__;!8WoA6RjC81c!XifH7EcqHRKXHyGSwB3ojXm6YmKn_vYWCjgM-VDTPTEzP-khJGlb9MqM8x-YOVqXLNE$
> 
> 
> 