iperf3 is a real Internet application in the same way that ping, traceroute, tcpdump, etc. are real applications. It is a well-known tool that network engineers use on a daily basis and demonstrates that UDP performance is highly correlated with UDP datagram size (i.e., even for sizes that exceed the PMTU).
> -----Original Message----- > From: Fred Baker [mailto:[email protected]] > Sent: Thursday, November 29, 2018 12:53 PM > To: Templin (US), Fred L <[email protected]> > Cc: Ron Bonica <[email protected]>; Joe Touch <[email protected]>; > Stewart Bryant <[email protected]>; int-area > <[email protected]> > Subject: Re: [Int-area] draft-ietf-intarea-frag-fragile-03 > > > > > 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... _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
