On Mon, Dec 18, 2023, 5:31 PM Robinson, Herbie <Herbie.Robinson= 40stratus....@dmarc.ietf.org> wrote:
> If we are going much beyond 9K, the hardware has to change, because a 32 > bit CRC doesn’t cut it for really large packets. > > > > If the hardware has to change, we can push MTU negotiation into the > hardware. And completely bypass the momentum involved with getting every > existing implementation on the planet to actually implement PTB. > > > Maybe a larger MTU with that sort of negotiation would make sense for Ultra Ethernet (not sure where they are on that) Tom *From:* Int-area <int-area-boun...@ietf.org> *On Behalf Of *Paul Vixie > *Sent:* Monday, December 18, 2023 8:12 PM > *To:* Tom Herbert <tom=40herbertland....@dmarc.ietf.org>; Christian > Huitema <huit...@huitema.net> > *Cc:* Gorry (erg) <go...@erg.abdn.ac.uk>; int-area <int-area@ietf.org> > *Subject:* [EXTERNAL] Re: [Int-area] Jumbo frame side meeting at IETF118 > - notes > > > > *[**EXTERNAL SENDER**: This email originated from outside of Stratus > Technologies. Do not click links or open attachments unless you recognize > the sender and know the content is safe.]* > > > ------------------------------ > > We've got to teach the system how to negotiate and/or discover this. 9000 > was about right for fast Ethernet but it's small at gigabit Ethernet and > above. > > > > Petabit is probably coming within our lifetimes. > > > > 9000 would be a great starting point and 64k after that but like the ibmpc > 640k memory threshold the lesson is that hard limits don't last. > > > > I've been happy with 9000 in my various campus networks. But more would be > better. > > > > Max speed changing by no more than 6x isn't the issue. Complexity of work > arounds, power utilization, cost, and future proofing are the drivers here. > > > > p vixie > > > > On Dec 18, 2023 12:52, Tom Herbert <tom=40herbertland....@dmarc.ietf.org> > wrote: > > On Mon, Dec 18, 2023 at 11:24 AM Christian Huitema <huit...@huitema.net> > wrote: > > > > On 12/18/2023 9:15 AM, Kyle Rose wrote: > > > 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. > > > > It is certainly less that 6x, especially for encrypted transports. There > > is a fixed cost per packet, but is corresponds more or less to the > > encryption of a per packet header and checksum, so maybe 32 to 64 bytes. > > After that, the cost of encryption is linear with the size of the > message. > > > > That does not mean that we should not do it. How many of us remember > > mocking ATM and its 48 byte packet size? The max speed of ATM circuits > > then was maybe 150Mbps, and 48 bytes meant 2.6us. Guess what, at 10Gbps, > > 1500 bytes means 1.2us... > > Christian, > > Right, and at 1Tbps 1500 bytes means 12ns! With respect to Internet > protocols there's no reason to artificially limit MTUs to 1500 bytes, > or for that matter even 9000 bytes or 64K bytes with IPv6. > > Tom > > > > > -- Christian Huitema > > _______________________________________________ > 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
