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

FWIW, it could also be "Receiver PMTUD" (vs Packetization Layer, etc.). 

Again, though, the trouble is it doesn't overcome the issue with PMTUD
of ICMP black-holing. It is easier to deploy for experimental purposes
(runs only at the receiver rather than on all intermediate hops), but
that's the only benefit. 

Joe

On 2019-11-01 09:04, Templin (US), Fred L wrote:

>> A different title might be better.
> 
> Call it "Report Fragmentation". Have the receiver check the RF bit to see if the sender
> wants fragmentation reported. If so, send the report; else, just reassemble as normal.
> 
> Fred
> 
> -----Original Message-----
> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Bob Hinden
> Sent: Thursday, October 31, 2019 4:51 PM
> To: Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt
> 
> 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=40juniper.net@dmarc.ietf.org> wrote:
> 
> Updated draft
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: internet-drafts@ietf.org <internet-drafts@ietf.org>
> Sent: Thursday, October 31, 2019 3:15 PM
> To: Ron Bonica <rbonica@juniper.net>; Hakan Alpan <halpan@hnc.edu>; Radon Rosborough <rrosborough@hmc.edu>; Bradely Newton <bnewton@hmc.edu>; Bradley Newton <bnewton@hmc.edu>; Miles President <mpresident@hmc.edu>; Manoj Nayak
> <manojnayak@juniper.net> 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://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-01
> 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
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area