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

From: Manoj Nayak <[email-masked]>
Date: Sat, 2 Nov 2019 02:32:14 +0000

Hello Joe,

I was reading the  following comment. Even when router takes care of generating equal sized fragments, the last fragment is 
most likely to be less than rest of the fragments.

"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"

Regards
Manoj Nayak
    
    -----Original Message-----
    From: Joe Touch <[email-masked]> 
    Sent: Wednesday, October 30, 2019 12:44 AM
    To: Ron Bonica <[email-masked]>
    Cc: [email-masked]
    Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt
    
    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=[email-masked]> wrote:
    > 
    > Folks,
    > 
    > Please review and comment.
    > 
    >                        Ron
    > 
    > 
    > 
    > Juniper Business Use Only
    > 
    > -----Original Message-----
    > From: [email-masked] <[email-masked]> 
    > Sent: Tuesday, October 29, 2019 11:48 AM
    > To: Ron Bonica <[email-masked]>; Hakan Alpan <[email-masked]>; Radon Rosborough <[email-masked]>; Bradely Newton <[email-masked]>; Miles President <[email-masked]>; Manoj Nayak <[email-masked]>
    > 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!SaG54qXv3mOmFFinOp93hDtn-j4u5ZzUbomMfaHAujluBDj7pJq_RtQMALmTf6K4$ 
    > 
    > 
    > 
    > 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
    > [email-masked]
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!SaG54qXv3mOmFFinOp93hDtn-j4u5ZzUbomMfaHAujluBDj7pJq_RtQMAGjVmADJ$ 
    
    ------------------------------
    
    Message: 2
    Date: Thu, 31 Oct 2019 19:16:38 +0000
    From: Ron Bonica <[email-masked]>
    To: "[email-masked]" <[email-masked]>
    Subject: [Int-area] FW: New Version Notification for
    	draft-bonica-intarea-lossless-pmtud-01.txt
    Message-ID:
    	<[email-masked]>
    	
    Content-Type: text/plain; charset="utf-8"

    Updated draft

    Juniper Business Use Only
    
    -----Original Message-----
    From: [email-masked] <[email-masked]> 
    Sent: Thursday, October 31, 2019 3:15 PM
    To: Ron Bonica <[email-masked]>; Hakan Alpan <[email-masked]>; Radon Rosborough <[email-masked]>; Bradely Newton <[email-masked]>; Bradley Newton <[email-masked]>; Miles President <[email-masked]>; Manoj Nayak <[email-masked]>
    Subject: New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt

    A new version of I-D, draft-bonica-intarea-lossless-pmtud-01.txt
    has been successfully submitted by Ron Bonica and posted to the IETF repository.
    
    Name:		draft-bonica-intarea-lossless-pmtud
    Revision:	01
    Title:		Lossless Path MTU Discovery (PMTUD)
    Document date:	2019-10-31
    Group:		Individual Submission
    Pages:		7
    URL                     https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-01__;!8WoA6RjC81c!XLNEZ-1XcW1SCcQkdY1e72UP_43UD2slIH4JB_BJ-gO_XISUMzEDSldcRkqU5JMOvqw$ 
    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
    
    ------------------------------
    
    Message: 3
    Date: Thu, 31 Oct 2019 16:51:10 -0700
    From: Bob Hinden <[email-masked]>
    To: Ron Bonica <rbonica=[email-masked]>
    Cc: Bob Hinden <[email-masked]>, "[email-masked]"
    	<[email-masked]>
    Subject: Re: [Int-area] New Version Notification for
    	draft-bonica-intarea-lossless-pmtud-01.txt
    Message-ID: <[email-masked]>
    Content-Type: text/plain; charset="utf-8"
    
    Ron,
    
    A few comments on your draft.
    
    Naming the draft "Lossless Path MTU Discovery (PMTUD)? seems to be very aspirational, and is an oxymoron.  ICMP message can be rate limited and dropped in the network.   Hardly ?lossless?.  A different title might be better.
    
    I do like the idea of the destination sending feedback, we have worked on some other drafts with that property.
    
    The document says:
    
       This document describes alternative PMTUD procedures that do no rely
       on the network's ability to deliver ICMP Destination Unreachable
       messages to the source node.  In these procedures, the source node
       produces an initial PMTU estimate.  This initial estimate is equal to
       the MTU of the first link along the path to the destination node.  It
       can be greater than the actual PMTU.
    
    This is not really correct, your are still dependent on the networks ability to deliver ICMP messages to the source node.  Just not ICMP Destination Unreachable messages.   A new ICMP message isn?t going to be better, perhaps worse.
    
    I didn?t understand the purpose of the Code field, that can indicate reassembly error.  What is the purpose of this?   This seems to be in conflict with this message that is sent when the destination node successfully reassemblies a set of fragments.  With the code indicating reassembly error, it is saying that the fragments were not reassembled.
    
    It may be folly to try to modify IPv4 implementations at this point.   I have no objections if you wish to try pushing this big rock up hill, but I doubt you will be successful.
    
    I see you have several co-authors from Harvey Mudd College.
    
    Bob

    > On Oct 31, 2019, at 12:16 PM, Ron Bonica <rbonica=[email-masked]> wrote:
    > 
    > 
    > Updated draft
    > 
    > 
    > Juniper Business Use Only
    > 
    > -----Original Message-----
    > From: [email-masked] <[email-masked]>
    > Sent: Thursday, October 31, 2019 3:15 PM
    > To: Ron Bonica <[email-masked]>; Hakan Alpan <[email-masked]>; Radon Rosborough <[email-masked]>; Bradely Newton <[email-masked]>; Bradley Newton <[email-masked]>; Miles President <[email-masked]>; Manoj Nayak <[email-masked]>
    > Subject: New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt
    > 
    > 
    > A new version of I-D, draft-bonica-intarea-lossless-pmtud-01.txt
    > has been successfully submitted by Ron Bonica and posted to the IETF repository.
    > 
    > Name:		draft-bonica-intarea-lossless-pmtud
    > Revision:	01
    > Title:		Lossless Path MTU Discovery (PMTUD)
    > Document date:	2019-10-31
    > Group:		Individual Submission
    > Pages:		7
    > URL                     https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-01__;!8WoA6RjC81c!XLNEZ-1XcW1SCcQkdY1e72UP_43UD2slIH4JB_BJ-gO_XISUMzEDSldcRkqU5JMOvqw$ 
    > 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
    > [email-masked]
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!XLNEZ-1XcW1SCcQkdY1e72UP_43UD2slIH4JB_BJ-gO_XISUMzEDSldcRkqUNjQlVhU$ 
    
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 488 bytes
    Desc: Message signed with OpenPGP
    URL: <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/int-area/attachments/20191031/999da00d/attachment.asc__;!8WoA6RjC81c!XLNEZ-1XcW1SCcQkdY1e72UP_43UD2slIH4JB_BJ-gO_XISUMzEDSldcRkqUrBUvJx8$ >
    
    ------------------------------
    
    Subject: Digest Footer
    
    _______________________________________________
    Int-area mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!XLNEZ-1XcW1SCcQkdY1e72UP_43UD2slIH4JB_BJ-gO_XISUMzEDSldcRkqUNjQlVhU$ 

    ------------------------------
    
    End of Int-area Digest, Vol 170, Issue 14
    *****************************************

---

From: Joe Touch <[email-masked]>
Date: Fri, 1 Nov 2019 19:53:15 -0700

> On Nov 1, 2019, at 7:32 PM, Manoj Nayak <[email-masked]> wrote:
> 
> Hello Joe,
> 

See RFC 1812. Not all fragmentation algs have unequal sizes or the smallest chunk last. There are no requirements on this.