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-boun...@ietf.org] On Behalf Of Bob Hinden
> Sent: Thursday, October 31, 2019 4:51 PM
> To: Ron Bonica <rbonica=40juniper....@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....@dmarc.ietf.org> wrote:
>
> Updated draft
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: internet-dra...@ietf.org <internet-dra...@ietf.org>
> Sent: Thursday, October 31, 2019 3:15 PM
> To: Ron Bonica <rbon...@juniper.net>; Hakan Alpan <hal...@hnc.edu>; Radon
> Rosborough <rrosboro...@hmc.edu>; Bradely Newton <bnew...@hmc.edu>; Bradley
> Newton <bnew...@hmc.edu>; Miles President <mpresid...@hmc.edu>; Manoj Nayak
> <manojna...@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
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
