> On Sep 6, 2019, at 9:03 AM, Ole Troan <[email protected]> wrote: > > Joe, > > edited to focus on the two added "recommendation sentences". > >>>>> 1) It introduces something new and undescribed in paragraph 2. >>>>> "unless they also include mechanisms to detect that IP fragmentation >>>>> isn't working >>>>> reliably." >>>>> That seems like hand-waving to me. Suggest deleting. >>>> >>>> Fragmentation success or failure is directly testable. Any feedback >>>> mechanism will work and specific ones are mentioned elsewhere (PLPMTUD). >>>> >>>> This differs from ICMP black-holing in path MTU detection. >>> >>> Can you please point me to where in the PLPMTUD document testing for IP >>> fragmentation is described? >> >> Any feedback mechanism will detect when fragmentation - or anything else - >> prevents delivery. > > Any pointer to such a mechanism in any IETF protocol? > Would be interesting to get transport/application perspective on this. > But unless there is a reference I would claim this is hand-waving.
As I said, PLPMTUD. It doesn’t have to detect if there’s a layer of fragmentation it can’t detect; it figures out for itself that a given MTU doesn’t succeed and sends a smaller MTU. > > [...] > >> If you fragment and put the result inside GRE or UDP, the impact of the >> fragment (interfering with flow-based multi path routing, nat traversal, >> etc) is overcome. > > Sure, but that only applies to tunnels that go end to end. It applies to tunnels that traverse wherever fragmentation is both needed and doesn’t work other ways. Speaking of deployed mechanisms, it’s also how IPsec tunnels over UDP already work and are widely deployed. > ...This document should not recommend IP in UDP in IP encapsulation to > achieve end to end IP fragmentation for new applications. Why not exactly not? Frag and reassembly outside of an app can be, in some cases, more efficient - even with additional layers of headers. > If this paragraph has to be there it would be more accepting to have it in > the "Legacy protocols" parapgraph above. It’s unnecessarily limiting to mention it only there. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
