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

["Templin (US), Fred L" <[e-mail]>]

One last put, then I'll shut up. What it generation of fragmentation reports were made
the default behavior (reassembler sends ICMPv4 "fragmentation needed" by default)
and a socket option is provided so that specific applications can disable the default
behavior. That way, applications that rely on IPv4 fragmentation can use it without
worrying about receiving unwanted ICMPs, and no RF bit is needed in any protocol
header.

With these inputs, and assuming the implementation survey is sound, I believe
I can withdraw my objections.

Fred

> -----Original Message-----
> From: Int-area [mailto:[e-mail]] On Behalf Of Templin (US), Fred L
> Sent: Friday, November 22, 2019 6:28 AM
> To: Manoj Nayak <[e-mail]>; [e-mail]
> Cc: [e-mail]
> Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt
> 
> And to highlight the idea so it isn't lost, why not just have the reassembler send
> back an ordinary ICMPv4 "Fragmentation Needed" instead of inventing a new
> ICMPv4 message type?
> 
> Fred
> 
> > -----Original Message-----
> > From: Int-area [mailto:[e-mail]] On Behalf Of Templin (US), Fred L
> > Sent: Friday, November 22, 2019 6:01 AM
> > To: Manoj Nayak <[e-mail]>; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt
> >
> > BTW, RFC5320 gives attribution for where the original "report fragmentation" concept
> > came from (Charles Lynn; 1987).
> >
> > Fred
> >
> > > -----Original Message-----
> > > From: Int-area [mailto:[e-mail]] On Behalf Of Templin (US), Fred L
> > > Sent: Friday, November 22, 2019 5:51 AM
> > > To: Manoj Nayak <[e-mail]>; [e-mail]
> > > Cc: [e-mail]
> > > 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:[e-mail]]
> > > > Sent: Wednesday, November 20, 2019 8:15 PM
> > > > To: Templin (US), Fred L <[e-mail]>; [e-mail]
> > > > Cc: [e-mail]
> > > > 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" <[e-mail]> 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:[e-mail]] On Behalf Of Manoj Nayak
> > > >     > Sent: Wednesday, November 13, 2019 8:35 PM
> > > >     > To: [e-mail]
> > > >     > Cc: [e-mail]
> > > >     > 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 <[e-mail]>
> > > >     >     To: Ron Bonica <rbonica=[e-mail]>
> > > >     >     Cc: "[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=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 <rbonica=[e-mail]> wrote:
> > > >     >     >
> > > >     >     > 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$
> > > >     >
> > > >     >
> > > >     >
> > > >     >
> > > >     > _______________________________________________
> > > >     > Int-area mailing list
> > > >     > [e-mail]
> > > >     > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!Tp5Pvame6pgAtmlsi-
> > > > 9_todREdZAH9ervNS0qugjDf4SKKWoRMSMvJ_yFYKUwTwaXCI$
> > > >
> > >
> > > _______________________________________________
> > > Int-area mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/int-area
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area