> On Sep 7, 2019, at 2:09 AM, Ole Troan <[email protected]> wrote: > >>>>>>> 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. > > Sorry, I still don't understand how PLPMTUD detects if fragmentation works > reliably or not. > > The paragraph we are disccusing is: > "Protocols and applications that rely on IP > fragmentation will work less reliably on the Internet unless they > also include mechanisms to detect that IP fragmentation isn't working > reliably." > > My view is that unless we can point to a reference or specification for how > to do this, then it amounts of hand waving.
It’s a homework assignment in a 1st yr net class. *Any* two-way protocol gets feedback as to whether it works. If you send large packets and they work, you’re done. If not, you have to backoff and fragment at the app layer - which is less efficient, but will still get through. — ANY protocol that can adjust to an MTU based on feedback CAN try larger MTUs than the first hop link reports and see if they work. > And possibly sending application developers out on a wild goose chase. > And given that applications would have to work in the cases where > fragmentation was found to not work reliably… They have to do this anyway, but this way they don’t have to be stuck with app-layer fragmentation when the network can to it instead. > >>>> 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. > > It does not work. > Host A -- ipsec tunnel -- SGW -- Host B > > 1) If host A sends fragments inside of the tunnel to host B, the fragments > are equally fragile between the security gateway and host B. It’s not equally fragile. Fragments inside UDP overcome NATs and ECMP that (incorrectly) refuse to support packets without transport headers. …. > >>> ...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? > > Firstly, a fundamental architectural change of how we would recommend > application transport to work is not appropriate for this document. There is no architectural change in using UDP for tunnels. There’s a section in RFC 8085 on this if you want a citation. > ... >> Frag and reassembly outside of an app can be, in some cases, more efficient >> - even with additional layers of headers. > > Yes, in _some_ cases. Try to introduce 1% of packet drop and that number of > cases likely drop to 0. (speaking of hand waving…) > The large scale deployments of this kind of thing is for example TSO/GSO. Oh, now we’re off into implementation mechanisms (not standards) that don’t follow existing standards either in many cases. > As a way to bypass bottlenecks in packet processing in the kernel. > But there segmentation is done at the transport layer, which will not suffer > from the issues of a single packet drop in a 40 fragment chain. > (64K packet / 1500). Fragmentation is fragmentation. If you send 64K messages and lose one fragment - at any layer of a protocol - you lose the message. Unless you send those fragments over a reliable channel that retransmits (e.g., TCP) anyway. > >>> 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. > > The whole purpose of this document is to limit use of network layer > fragmentation. NO IT IS NOT. It is to reduce the impact of the FAILURE of network layer fragmentation - which IMO is best done through a *variety* of approaches that app and protocol designers can choose. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
