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

[Ron Bonica <[e-mail]>]

Hi Fred,

Thanks for the review. Responses inline.....


Juniper Business Use Only

-----Original Message-----
From: Fred Baker <[e-mail]> 
Sent: Tuesday, October 29, 2019 12:31 PM
To: Ron Bonica <[e-mail]>
Cc: [e-mail]
Subject: Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

A few thoughts.

I take it that this imposes an expectation on the receiving node, per session, that it will keep a record of whether one or more fragments have been received, and if so what the largest of them is. Not clear to me, at least on a quick reading - is this sent the first time that size fragment is received (and therefore subject to issues with loss of the ICMP response), the first N times such a fragment is received, or every time such a fragment is received? I'd expect it's the first N times, for some value of N.

[RB] Feedback is provided on a per packet basis, not on a per session basis. Whenever a receiver reassembles a packet, it sends an ICMP message to the sender indicating the size largest fragment belonging to the packet. This is assumed to be the PMTU. As always, ICMP messages are rate limited. 


The big issue with PLMTUD at the moment is the fact that people filter out ICMP, or manage to do so accidentally. If people (or NATs) are filtering ICMP, won't they equally filter this one? If so, I don't see how this fixes it.

[RB] Clearly, the ICMP message does no good unless it is delivered to the sender. However, in lossless PMTUD, ICMP filtering does not cause black holing. Subsequent packets will be fragmented and reassembled.


It also presumes a change to existing IPv4 code, this time twice - in the sender and in the receiver. What I'd really like to see is PLPLMTUD (RFC 4821 or some approximation thereto), which is a change to - only - the sender. I tend to see developers as choosing between implementing PLPMTUD and this logic; since neither helps the other and this logic requires two changes, I think the net effect (pun intended) is that neither works, just like PMTUD fails to work now.

[RB] Lossless PMTUD isn't a competitor to PLPMTUD. It's really a niche solution for legacy IPv4 applications allow downstream fragmentation.

                                                                   Ron


Did I miss something?