On Thu, Jul 26, 2018 at 12:01 AM, Mikael Abrahamsson <swm...@swm.pp.se> wrote: > On Tue, 24 Jul 2018, Templin (US), Fred L wrote: > >> Try it - by default, iperf3 sets an 8KB UDP packet size and allows packets >> to fragment across paths that support only smaller MTUs. I have seen iperf3 >> exercise IP reassembly at line rates on high-speed links, i.e., it shows >> that reassembly at high rates is feasible. >> >> We know from RFC4963 that there are dangers for reassembly at high rates, >> but there are applications such as iperf3 that ignore the "SHOULD NOT" and >> leverage IP fragmentation anyway. So, should the "SHOULD NOT" have an >> asterisk? > > > The iperf3 usage of fragments for UDP testing seems to be platform specific, > at least that's what I've seen. Behaviour has been different on MacOS > compared to Linux. > Mikael,
I don't understand what would be platform specific. Can you elaborate? iperf3 is sending UDP packets that are exceeding MTU and packets are being fragmented. For IPv4, this means that DF is not set and packets are being fragmented somewhere in the network, for IPv6 they are being fragmented at the source. I don't believe path MTU discovery is in use by iperf3, so if packets do exceed MTU then the only way they can can be delivered is if fragmented. > Anyhow, I believe we should keep the "SHOULD NOT". This allows applications > that feel they have a good reason to do fragmentation to do so, but doesn't > disallow it. > The text is "Application developers SHOULD NOT develop applications that rely on IPv6 fragmentation.". As Brian said, this requirement does not describe the algorithm, nor is it obvious what it even means for an application developer to knowingly develop an application that relies on IPv6 fragmentation. Besides that, RFC8085, which is referenced in section 5.2, already provides the recommendations that applications should avoid fragmentation by limiting packer size or doing PMTU discovery. I don't see how 7.1 of this draft adds anything to that or is clarifying those recommendations. Tom > -- > Mikael Abrahamsson email: swm...@swm.pp.se > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
