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

[Manoj Nayak <[e-mail]>]

Hello Bob,

Please find my reply.

   
>>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 think that when we say lossless , we refer to a PMTU without blackhole. In our approach, black holing is 
prevented as sender gets an ack for it’s sent packet even when ICMP messages are dropped.
 
A PMTU black hole is where the ICMP message doesn't reach the sending host to inform it that it needs to adjust
 its MTU. This can be down to the router not sending the ICMP message or the ICMP message being blocked 
on the way back to the sender, In this scenario the sender is waiting for an acknowledgment for its sent packet. 
The destination is still waiting for its packet, and the whole session falls down.
 

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

 
Yes, we are dependent on networks ability to deliver ICMP messages to source node
to get actual MTU size at source node. But without actual MTU size at source node,
source node continue to operate normal way by sending further packets to destination
and intermediate node continues to fragment packets.
 
 
>>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.
 

When destination node successfully reassemblies a set of fragments for a bunch of packets,
the destination node sends ack to sender. However our idea does not compare the ack with a ICMP message
with reassembly error. Because ack is sent for one packet or multiple packets and ICMP message
with reassembly error is sent for each packet. So we can not co-relate these two.

With the code indicating reassembly error,  fragment size mentioned in ICMP message is not
considered by source for PMTU.

Hope it clarifies.


Regards
Manoj Nayak
 


------------------------------
    
    Message: 3
    Date: Thu, 31 Oct 2019 16:51:10 -0700
    From: Bob Hinden <[e-mail]>
    To: Ron Bonica <rbonica=[e-mail]>
    Cc: Bob Hinden <[e-mail]>, "[e-mail]"
    	<[e-mail]>
    Subject: Re: [Int-area] New Version Notification for
    	draft-bonica-intarea-lossless-pmtud-01.txt
    Message-ID: <[e-mail]>
    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=[e-mail]> wrote:
    > 
    > 
    > Updated draft
    > 
    > 
    > Juniper Business Use Only
    > 
    > -----Original Message-----
    > From: [e-mail] <[e-mail]>
    > Sent: Thursday, October 31, 2019 3:15 PM
    > To: Ron Bonica <[e-mail]>; Hakan Alpan <[e-mail]>; Radon Rosborough <[e-mail]>; Bradely Newton <[e-mail]>; Bradley Newton <[e-mail]>; Miles President <[e-mail]>; Manoj Nayak <[e-mail]>
    > 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
    > [e-mail]
    > 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
    [e-mail]
    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
    *****************************************