On Mon, Dec 18, 2023 at 8:38 AM Kyle Rose <krose=40krose....@dmarc.ietf.org> wrote: > > Apologies for not being able to make the meeting. Had I been able to attend, > the question I was going to ask was: with respect to overhead, there's a > constant factor 6x improvement when moving from 1500->9000 octets. How > quickly do hardware performance improvements typically reach 6x > packet-per-second throughput at ~the same cost (capex, power, etc.)?
Kyle, It's not really constant. A larger MTU is opportunistic optimization, it's only useful when the host is sending large amounts of data and path MTU allows a larger MSS (for instance, we'll still see forty byte pure ACKs being sent). There should be a reduction in packets but probably much less than 6x I would think. Tom > > Kyle > > On Mon, Dec 18, 2023 at 11:15 AM Tim Chown > <Tim.Chown=40jisc.ac...@dmarc.ietf.org> wrote: >> >> Hi, >> >> Apologies for the delay in posting these notes. Gorry and I held a side >> meeting in Prague on the topic of (lack of) use of jumbo frames, and what >> topics might lie within the IETF’s remit to help promote greater use. >> >> After talking to an AD it was suggested we raise the topic on the int-area >> list to gauge interest, rather than set up a new list at this stage. >> >> So, all thoughts and comments welcome... >> >> -- >> >> Jumbo frame side meeting, IETF118, 2-3pm Thu 9 November >> >> Convened by Tim Chown (Jisc) and Gorry Fairhurst (Univ Aberdeen) >> >> The meeting had no set agenda. The aim was to gather those interested in >> more widespread use of jumbo frames to gather and discuss what actions might >> be taken in or by the IETF and its WGs towards that goal. >> >> Comments: >> • There is no standard for Ethernet for frame sizes above 1500 bytes >> • Would it be useful to work towards a “certified jumbo” >> interoperability test? >> • NICs at 1Gbit/s+ should all use phase-locked loop (PLL). >> • What tools should we use to identify issues or errors in transmission >> at various MTU sizes? >> • Tim noted that Jisc’s 100G perfSONAR node at London showed no errors >> on its 9000 MTU interface – stats can be seen under the interface details >> section at https://ps-london-bw.perf.ja.net/toolkit/ >> • We should consider the relevance of MTU in respective IETF areas – >> INT, TSV and OPS >> • Jen Linkova has talked about networks with multiple sizes of MTU >> • There are providers who offer 9000 MTU networks, end-to-end, such as >> Hurrican Electric >> • Tim reported that many PBs of data are moved by the CERN experiments >> and a proportion of that is using 9000 MTU. Single stream TCP performance >> can be 2-3x better, depending on RTT and other factors. >> • What issues might there be in specific technologies, e.g. ND, BGP, >> ECMP, multipath TCP, …? >> • There is a perception that IXPs find 9000 MTU problematic >> • There are previous IETF I-Ds on MTU use, e.g. in IXPs – we should look >> at old drafts or any RFCs >> • There may be relevant presentations from *NOG and RIR member meetings >> • Improvements to host stacks can make the performance gains of jumbo >> frames less important, e.g. various offloading technologiesCan we get >> current measurements and data, e.g., via MAPRG? >> • We should look at hyperscalers; there is support there for 9000 MTU >> • IPsec, and any encapsulation that benefits from avoiding >> fragmentation, can work better with jumbo frames >> • We could look a Globus transfer logs to detect MD5 errors for evidence >> of issues in the application data not picked up at lower layers >> • There are other non-Ethernet technologies used in DCs with large frames >> • Does QUIC break offload due to its encryption? In practice QUIC uses >> a Max Datagram Packet size less than 1500. Might larger MTUs be useful for >> QUIC >> • Post-quantum scenarios were mentioned. >> • What about MTU discovery? There is anecdotal evidence of issues; Tim >> has seen this at a UK university where ICMPv6 PTB was being dropped. >> • PLPMTUD is specified by QUIC; useful when there’s no path back to a >> sender for receipt of an ICMP PTB message. >> >> Agreed actions: >> • Tim will ask Eric Vyncke (INT area AD) for support to create a >> “jumbo-discuss” IETF mail list >> • We will seek to collectively document the status of jumbo frames, >> focusing on what works (success stories), opportunities, gaps (potential >> work items in the IETF and elsewhere) and other open issues. >> • Tim will ask Eric Vyncke for a side meeting at a future IETF. >> • We will seek to present relevant parts of the above documented status >> in the INT, TSV and OPS area open meetings at the next IETF meeting. >> • Tim will email the 118attendees list with the meeting notes >> >> — >> >> Tim >> _______________________________________________ >> 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 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
