Re: [Int-area] Int-area Digest, Vol 170, Issue 13

[Manoj Nayak <[e-mail]>]

Hello Fred,


Please find my thought on the following comment. Current implementation uses certain assembly buffer size at receiver side  and our proposed Idea 
in the draft is not going to increase the assembly buffer size.


"There are a number of details to concern yourself with including  assumptions of the receiver's reassembly buffer size."

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$ 
        
        
        
        ------------------------------
        
        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$ 
        
        
        
        ------------------------------
        
        Message: 4
        Date: Wed, 30 Oct 2019 14:50:40 +0000
        From: Dave Thaler <[e-mail]>
        To: S Moonesamy <[e-mail]>
        Cc: Ian Farrer <[e-mail]>, "[e-mail]"
        	<[e-mail]>, Suresh Krishnan <[e-mail]>,
        	Suresh Krishnan <[e-mail]>, "[e-mail]"
        	<[e-mail]>
        Subject: Re: [Int-area] Last Call: <draft-thaler-iftype-reg-05.txt>
        	(Guidelines and Registration Procedures for Interface Types and Tunnel
        	Types) to Proposed Standard
        Message-ID:
        	<[e-mail]>
        	
        Content-Type: text/plain; charset="us-ascii"
        
        S. Moonesamy wrote:
        > RFC 2863 is a Draft Standard which states that it specifies a protocol. 
        > draft-thaler-iftype-reg is about guidance for registration requests.  The write-up
        > does not explain why the intended status of the document is "Proposed Standard".
        > That is an usual (intended) status when a document is about procedures (e.g. Section 6.1).
        
        Oops, that was not intentional, thanks for catching!  The intent was to follow the same
        precedent as similar RFCs like RFC 7595, which is BCP and which I co-authored.  Hence
        changed to BCP in the pending update.
        
        > Section 6.3.1 states that "A link to some document is required".  The requirement is phrased
        > in such a way that it leaves a lot of room for interpretation.  Does the person reviewing those
        > (future) requests wish to deal with that?
        
        It was already that way before.  https://urldefense.com/v3/__https://www.iana.org/form/iftype__;!8WoA6RjC81c!XifH7EcqHRKXHyGSwB3ojXm6YmKn_vYWCjgM-VDTPTEzP-khJGlb9MqM8x-YMGWpzQs$  says simply:
        > Reference, Internet-Draft, or Specification (required - provide link):
        
        The policy is unchanged from Expert Review, which is weaker than Specification Required
        (which requires a permanent, public document), as elaborated on in RFC 5226.
        
        Currently the draft is written to specifically address known issues that have actually occurred,
        so it really is documenting best current practice.  So far, we have not run into problems yet 
        with the flexibility as phrased.
        
        Thanks for the review,
        Dave
        
        
        
        ------------------------------
        
        Subject: Digest Footer
        
        _______________________________________________
        Int-area mailing list
        [e-mail]
        https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!XifH7EcqHRKXHyGSwB3ojXm6YmKn_vYWCjgM-VDTPTEzP-khJGlb9MqM8x-YOVqXLNE$ 
        
        
        ------------------------------
        
        End of Int-area Digest, Vol 170, Issue 13
        *****************************************