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

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

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