> On Nov 29, 2018, at 11:02 AM, Templin (US), Fred L > <[email protected]> wrote: > > If you are referring to iperf3, that is exactly what it does (uses > fragmentation > to generate a high data rate), but I would not call it "artificial" - > fragmentation > is a real Internet service.
But iperf3 is a test/diagnostic tool, not a "real" internet application. The reason for bringing up NFS is that it was, at least at one time, a real service that was widely used in real networks, and breaking it would have been a real operational problem. Even for that, since fragmentation would likely occur at the originating host (as in IPv6), apart from tunnels or links that reduced the PMTU, the issue would have been between the endpoints and any middleware en route, and since NFS didn't cross network boundaries, it would be unusual to find firewalls in the path. For NFSv4, RFC 5661 requires the use of TCP, SCTP, or "whatever is recommended at the time", which could perhaps refer to QUIC today, and discourages the use of UDP. It also refers to RDMA etc. I frankly don't see what "observing the demonstrable and measurable fact that there are issues with Internet Fragmentation and Reassembly" hurts. The paper doesn't recommend that the service be deprecated or removed. It does, however, suggest that applications and transports not depend on Internet fragmentation and reassembly; applications above the IP layer that need packets smaller than the relevant PMTU should find a way (such as by using TCP) to avoid it. I don't see how iperf3, or for that matter any application, is harmed by that. I think that what we really need to understand is what measurable harm this comment and recommendation causes. Maybe you could start your reply with that issue? -------------------------------------------------------------------------------- The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
