On Thu, Sep 26, 2024 at 9:03 AM Tim Chown <Tim.Chown=40jisc.ac...@dmarc.ietf.org> wrote: > > Hi, > > > > From: Paul Vixie <paul=40redbarn....@dmarc.ietf.org> > Date: Tuesday, 24 September 2024 at 20:59 > To: Templin (US), Fred L <Fred.L.Templin=40boeing....@dmarc.ietf.org>, > Internet Area <Int-area@ietf.org>, IPv6 List <i...@ietf.org> > 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" > <Fred.L.Templin=40boeing....@dmarc.ietf.org> 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 -- int-area@ietf.org > To unsubscribe send an email to int-area-le...@ietf.org _______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
