Greetings, Late responses in-line.
On Mon, Mar 17, 2025 at 1:22 PM Daniel Migault wrote: > Hi Mike, > > I appreciate the feedback and comments provided. Kindly find my responses > included inline. > > Yours, > Daniel > On 2025-03-17 15:29, C. M. Heard wrote: > > Greetings authors, > > I have read through your draft and look forward to your presentation at > the upcoming TSVWG session. > > Here are some questions / comments: > > *Terminology*: is it correct to assume that wherever I see the acronym > *LTP*, which is not defined in the draft, it should actually be *TLP*? > > You are correct it is (Tunnel) link packet (TLP). > Thank you. > *DPLPMTUD*: I see that there is a reference to PLPMTUD (RFC 4821) but > none to its datagram counterpart DPLPMTUD (RFC 8899). The latter is an > essential underpinning to draft-spiriyath-ipsecme-dynamic-ipsec-pmtu (which > is also referenced). You may want to consider pointing to RFC 8899 also. > > I am happy to add that reference. > Thank you. *LMAP value determination*: In the draft I see: > > if IPVersion is 4: > LMAP = FragLen > elif IPVersion is 6: > LMAP = FragLen + 40 > > > As far as I am aware, there is no rule that requires that initial > fragments be as large as possible; rather, the fragmenting node has > discretion to "even out" the fragment sizes if the size of the packet to be > fragmented would result in one (or a series of) maximum-sized fragment and > one that is quite small. Indeed, I vaguely recall that this is encouraged > to avoid further downstream fragmentation. If I am correct in this belief, > then the formula above is fundamentally flawed. If you have a reference > that supports the notion that an initial fragment is required to be as > large as the outgoing MTU allows, please include a citation. > > You are highlighting an important issue. It is accurate that RFC791 seeks > to prevent the generation of small fragments and aims to standardize > fragment sizes. Although LMAP would mitigate fragmentation, it could lead > to suboptimal outcomes. I will investigate how fragmentation is executed in > practice and determine whether LMAP can be inferred or if Path MTU > Discovery (PMTUD) is necessary. > > See you at the presentation. > > Unfortunately, I failed to set my alarm clock correctly and failed to see the presentation live or offer comments. I did, however, view the recording, and I noticed that a working assumption of this spec is that the path connecting the tunnel endpoints will traverse the open Internet -- i.e., it won't be confined to a controlled environment. Based on that, I think it's fair to say that it is not safe to assume that the size of an initial IPv4 fragment will be an accurate indication of the maximum size atomic packet that the path can accommodate. The only reliable way to achieve that objective is to probe with uncompressed packets that have DF=0, preferably using the method standardized in RFC 8899 (DPLPMTUD). I would therefore strongly recommend adopting the principles of draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-01 to determine the maximum atomic tunnel packet (TLP) size, perhaps with refinements of the exact mechanisms. My conclusion from reading that draft is that the approach is sound (*). I made a point of contacting the authors of that draft when I found very little discussion in the mailing list archives, and Shibu Piriyath's response did not reveal any that fatal flaws had come up in discussion that was not in the mailing list archives. Beyond that, I'd like to say that I am in general agreement with Joe Touch's early TSVAREA early review from late October 2022 (see https://mailarchive.ietf.org/arch/browse/static/ipsec/thread/2022-10/#FcoOkEB7nG32R2OS_I-jyRgC2gI), in particular that the "Maximum Atomic Packet" message is useful to the tunnel endpoint for doing tunnel fragmentation or (in cases where the MAP is sufficiently large) to set the tunnel MTU, but is not something that can be directly sent back to the source. And as said there, the main issues here are not transport issues, but tunnel operation issues. If the tunnel operates as it should, the transport layer can and will take care of itself. Thanks and regards, Mike Heard (*) That assessment does not apply to draft-spiriyath-ipsecme-dynamic-ipsec-pmtu-00, which proposed to send probe packets over the IKEv2 control channel; that won't work.
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
