Right, I should have said *at best* a 6x improvement. The point I'm trying to get to is: how much sense does it make to try to make the public internet safe for jumbo frames? I honestly don't know, and since I wasn't at the meeting, I don't know much much this was even a focus.
Thanks, Kyle On Mon, Dec 18, 2023, 11:58 AM Tom Herbert <tom= 40herbertland....@dmarc.ietf.org> wrote: > 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
