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

[Manoj Nayak <[e-mail]>]

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" <[e-mail]>
    To: Ron Bonica <rbonica=[e-mail]>,
    	"[e-mail]" <[e-mail]>
    Subject: Re: [Int-area] New Version Notification for
    	draft-bonica-intarea-lossless-pmtud-00.txt
    Message-ID: <[e-mail]>
    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:[e-mail]] On Behalf Of Ron Bonica
    > Sent: Tuesday, October 29, 2019 9:53 AM
    > To: [e-mail]
    > 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: [e-mail] <[e-mail]>
    > Sent: Tuesday, October 29, 2019 11:48 AM
    > To: Ron Bonica <[e-mail]>; Hakan Alpan <[e-mail]>; Radon Rosborough <[e-mail]>; Bradely
    > Newton <[e-mail]>; Miles President <[e-mail]>; Manoj Nayak <[e-mail]>
    > 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
    > [e-mail]
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!XifH7EcqHRKXHyGSwB3ojXm6YmKn_vYWCjgM-VDTPTEzP-khJGlb9MqM8x-YOVqXLNE$