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 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
