Thank you for this follow up - much appreciated. Fred
From: Juan Carlos Zuniga (juzuniga) <juzuniga=40cisco....@dmarc.ietf.org> Sent: Wednesday, November 22, 2023 8:15 AM To: Templin (US), Fred L <fred.l.temp...@boeing.com>; int-area@ietf.org Subject: [EXTERNAL] Re: IETF 118 IntArea minutes EXT email: be mindful of links/attachments. Thanks for the notes Fred. The minutes have been amended accordingly. Best, Jc & W From: Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org<mailto:Fred.L.Templin=40boeing....@dmarc.ietf.org>> Date: Monday, November 13, 2023 at 17:00 To: Juan Carlos Zuniga (juzuniga) <juzun...@cisco.com<mailto:juzun...@cisco.com>>, int-area@ietf.org<mailto:int-area@ietf.org> <int-area@ietf.org<mailto:int-area@ietf.org>> Subject: RE: IETF 118 IntArea minutes Hi, thank you for this but the minutes that tried to capture what was said in my talk have some distortions that need to be clarified: "Fred Templin presented graphs showing that on a 100GB/s point-to-point Ethernet link between two machines connected back-to-back, Licklider Transmission Protocol (LTP) (which runs over UDP and has no congestion control) sends data faster than TCP (which does use congestion control to avoid exceeding the network capacity)." That is not what I said. The graphs show that the fastest service is iperf3 using the TCP transport - iperf3 TCP is faster than iperf3 UDP under the same transport layer segment sizes. Congestion control is not a factor in the iperf3 performance metrics. What I did say was that HDTN's LTP/UDP shows significant performance increases when segment sizes that exceed the path MTU and invoke IP fragmentation are used in comparison with using segment sizes no larger than the path MTU. For a 1500 byte path MTU for example, a 16000 byte segment using fragmentation gave a factor 2 performance increase over a 1400 byte segment size not using fragmentation. "Sending an unrestrained flood of bare UDP packets achieved an even higher packet sending rate." I do not recognize this statement - not something I said. "However, the system call overhead of sending UDP packets individually, with a system call per packet, still limited the maximum sending rate even of the unrestrained UDP flood. Sending oversized UDP packets larger than the IP MTU, and letting the kernel break them into IP fragments, reduced the software overhead by generating multiple IP packets per system call." That is not the conclusion I represented, and the system call overhead was shown to not be the limiting performance bottleneck in this study. The overarching factor in performance is the transport layer segment size. Using larger segment sizes allows the transport to deal with fewer segments which results in a significant performance increase. This is true whether or not the segment size exceeds the path MTU. "(Possibly the software overhead could also have been reduced by using newer APIs that allow batch sending of multiple UDP packets with single system call.)" I made the statement in the talk that GSO/GRO (batch sending of multiple UDP packets with single system call) did not produce significant performance gains in this study - the most significant factor in performance increase came from increasing the transport layer segment size whether/not GSO/GRO were used. "However, as pointed out in RFC 8900 (Fragmentation Considered Fragile), on real networks intentionally fragmenting IP packets actually harms performance and reliability." RFC8900 says that "IP Fragmentation Considered Fragile"; not "IP Fragmentation Harms Performance". I agree with the former but do not agree with the latter since performance benchmarks show better performance. In agreeing with the former, the stated goal of "Identification Extension for the Internet Protocol" is to make IP fragmentation robust (within limited domains) and therefore to update RFC8900. "Therefore a new mechanism is proposed, called Deep Packet Fragmentation, to extend the use of fragmentation in the Internet by using a larger packet identifier field to allow more liberal use of IP fragmentation in the Internet. (Possibly using a more efficient UDP API on the sender could enable the same increase in sending rate without having to change the way the rest of the Internet works.)" I have no problem with the above statements. Thank you - Fred From: Int-area <int-area-boun...@ietf.org<mailto:int-area-boun...@ietf.org>> On Behalf Of Juan Carlos Zuniga (juzuniga) Sent: Monday, November 13, 2023 11:19 AM To: int-area@ietf.org<mailto:int-area@ietf.org> Subject: [EXTERNAL] [Int-area] IETF 118 IntArea minutes EXT email: be mindful of links/attachments. Hi all, Thanks a lot to Stuart Cheshire for helping with the notes! The minutes are now posted: https://datatracker.ietf.org/doc/minutes-118-intarea-202311091400/ Best, Juan-Carlos & Wassim (IntArea WG chairs)
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
