Tim and Gorry, thank you for this meeting report-out. I have a draft out right 
now that I
think addresses most if not all of the points regarding larger packet sizes. 
The draft was
aligned with intarea for a long time but was recently re-aligned with 6man and 
refactored
to focus on IPv6. I did leave behind an intarea-aligned draft on IPv4 
dependencies also
though.

The draft is called: "IPv6 Parcels and Advanced Jumbos" and brings a 
comprehensive
portfolio of techniques necessary to deal with these larger sizes in both the 
Internet
and other generalized Internetworking scenarios. It is worth a look if you 
haven't
already seen it, and worth another look if you already have.

Thank you - Fred

> -----Original Message-----
> From: Int-area <int-area-boun...@ietf.org> On Behalf Of Tim Chown
> Sent: Monday, December 18, 2023 8:15 AM
> To: int-area@ietf.org
> Cc: Gorry (erg) <go...@erg.abdn.ac.uk>
> Subject: [Int-area] Jumbo frame side meeting at IETF118 - notes
> 
> 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

Reply via email to