[Int-area] Re: IP Parcels and Advanced Jumbos (AJs)
"Templin \(US\), Fred L" <[email protected]> Fri, 27 Sep 2024 16:00:03 +0000
| Newsgroups | gmane.ietf.int,gmane.ietf.ipv6 |
|---|---|
| Message-ID | <BN0P110MB1420A9EF5C46A2A16F96BD46A36BA@BN0P110MB1420.NAMP110.PROD.OUTLOOK.COM> |
Forgot to also mention the ATM days of the 1990s, which I was not directly involved in but had colleagues at DEC who were. AAL5 set an MTU of 9180 for IP over ATM. > -----Original Message----- > From: Templin (US), Fred L <[email protected]> > Sent: Friday, September 27, 2024 8:31 AM > To: Brian E Carpenter <[email protected]>; Tom Herbert <[email protected]>; Tim Chown <[email protected]> > Cc: Internet Area <[email protected]>; IPv6 List <[email protected]> > Subject: [Int-area] Re: IP Parcels and Advanced Jumbos (AJs) > > Rolling back a bit to an earlier message: > > > RFC2675 jumbograms are single datagrams. They were originally intended for use over HIPPI, i.e. > > internally to data centres as they existed 25 years ago > > Yes, I worked in one of those data centers (NASA Ames Research) 1996/1997 timeframe so actually a > bit more than 25 years ago. Before that, I was involved with the DEC FDDI program in the late 1980s. > So, I am not new to the subject of larger packet sizes, and the subject of larger packet sizes is not > new to the industry in general. > > Thank you - Fred > > > -----Original Message----- > > From: Brian E Carpenter <[email protected]> > > Sent: Thursday, September 26, 2024 1:22 PM > > To: Templin (US), Fred L <[email protected]>; Tom Herbert <[email protected]>; Tim Chown <[email protected]> > > Cc: Internet Area <[email protected]>; IPv6 List <[email protected]> > > Subject: [EXTERNAL] Re: [Int-area] Re: IP Parcels and Advanced Jumbos (AJs) > > > > EXT email: be mindful of links/attachments. > > > > > > > > On 27-Sep-24 05:56, Templin (US), Fred L wrote: > > > Hi Tom, > > > > > > I would like to gently suggest a new terminology. Rather than calling them "the multi-segment buffers managed by GSO and GRO", can > we > > begin calling them "parcel buffers" or simply "parcels"? Not suggesting this in a self-serving manner - I just think it is a more concise yet > > more descriptive terminology. > > > > But that isn't the same thing. RFC2675 jumbograms are single datagrams. They were originally intended for use over HIPPI, i.e. internally > to > > data centres as they existed 25 years ago, so the usage that Tom reported seems close to what they were designed for. > > > > Tom, is there a full description of this usage? > > > > Regards > > Brian > > > > > > > > Thank you - Fred > > > > > >> -----Original Message----- > > >> From: Tom Herbert <[email protected]> > > >> Sent: Thursday, September 26, 2024 10:15 AM > > >> To: Tim Chown <[email protected]> > > >> Cc: Paul Vixie <[email protected]>; Templin (US), Fred L <[email protected]>; Internet Area <[email protected]>; IPv6 List > > >> <[email protected]> > > >> Subject: Re: [Int-area] Re: IP Parcels and Advanced Jumbos (AJs) > > >> > > >> On Thu, Sep 26, 2024 at 9:03 AM Tim Chown > > >> <[email protected]> wrote: > > >>> > > >>> Hi, > > >>> > > >>> > > >>> > > >>> From: Paul Vixie <[email protected]> > > >>> Date: Tuesday, 24 September 2024 at 20:59 > > >>> To: Templin (US), Fred L <[email protected]>, Internet Area <[email protected]>, IPv6 List > <[email protected]> > > >>> Subject: [Int-area] Re: IP Parcels and Advanced Jumbos (AJs) > > >>> > > >>> Something like this is long needed and will become badly needed. Every 10X of speed increase since 10mbit/sec has gone straight to > > PPS, > > >> whereas the speed increase from 3mbit/sec to 10mbit/sec was shared between PPS and MTU. > > >>> > > >>> > > >>> > > >>> If every 10X has been shared between PPS and MTU, say sqrt(10) for each, our MTU would be well over 64K by now and our PPS > > wouldn't > > >> require dedicated NPU hardware to source, sink, and ferry those packets at link saturation levels. > > >>> > > >>> > > >>> > > >>> Every attempt at PMTUD so far has failed but that's not an excuse to stop trying. > > >>> > > >>> > > >>> > > >>> I think that depends on the deployment scenario and environment. In R&E networking the adoption of 9000 MTU for large scale wide > > >> area data transfers has grown, in particular by dozens of sites worldwide that take part in the CERN experiments. CERN did a site > survey > > >> recently, for which I could dig out the results. > > >>> > > >>> > > >>> > > >>> The sites running 9000 MTU are interoperating with the sites still at 1500, which is an indication that PMTUD is working well enough. > > The > > >> large majority of CERN traffic is IPv6, so for that there’s no fragmentation on path. > > >> > > >> Tim, > > >> > > >> That's also happening in some datacenters. I believe Google is using a > > >> 9K MTU internally as it makes zero copy on hosts feasible (two 4K > > >> pages per packet). Interestingly, there's also increasing use of > > >> RFC2675 jumbograms, they're not sent on the wire but used internally > > >> for GSO and GRO for greater than 64K packets. > > >> > > >> Tom > > >>> > > >>> > > >>> > > >>> The use case is somewhat constrained in that it’s only the parts of the campus with the storage, the campus paths to the edge, and > the > > >> intervening R&E backbones that need to be configured. But with correct ICMPv6 filtering, it seems robust. > > >>> > > >>> > > >>> > > >>> Best wishes, > > >>> > > >>> Tim > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> Thanks for driving this Fred. > > >>> > > >>> > > >>> > > >>> p vixie > > >>> > > >>> > > >>> > > >>> On Sep 24, 2024 14:39, "Templin (US), Fred L" <[email protected]> wrote: > > >>> > > >>> It has been a while since I have posted about this, and there are some updates to highlight. > > >>> > > >>> See below for the IPv6 and IPv4 versions of “IP Parcels and Advanced Jumbos (AJs)”: > > >>> > > >>> > > >>> > > >>> https://datatracker.ietf.org/doc/draft-templin-6man-parcels2/ > > >>> > > >>> https://datatracker.ietf.org/doc/draft-templin-intarea-parcels2/ > > >>> > > >>> > > >>> > > >>> The documents acknowledge that parcels are analogous to Generic Segment/Receive Offload > > >>> > > >>> (GSO/GRO) but taken to the ultimate aspiration of encapsulating multi-segment buffers in > > >>> > > >>> {TCP/UDP}/IP headers for transmission over parcel-capable network paths. They further give > > >>> > > >>> a name to the multi-segment buffers used by GSO/GRO, suggesting that they be called > > >>> > > >>> “parcel buffers” or simply “parcels”. > > >>> > > >>> > > >>> > > >>> AJs are simply single-segment parcels that can range in size from very small to very large. > > >>> > > >>> They differ from ordinary jumbograms in several important ways, most notably in terms > > >>> > > >>> of integrity verification and error correction. They also suggest a new link service model > > >>> > > >>> that defers integrity checks to the end systems where bad data can be discarded while > > >>> > > >>> good data can be accepted as an end-to-end function, reducing retransmissions. > > >>> > > >>> > > >>> > > >>> Together, these documents cover all possible packet sizes and configurations that may > > >>> > > >>> be necessary both in the near term and for the foreseeable future for Internetworking > > >>> > > >>> performance maximization . Comments on the list(s) are welcome. > > >>> > > >>> > > >>> > > >>> Fred Templin > > >>> > > >>> _______________________________________________ > > >>> Int-area mailing list -- [email protected] > > >>> To unsubscribe send an email to [email protected] > > > > > > _______________________________________________ > > > Int-area mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > _______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]