Herbie, an alternative to trying to force advanced integrity checks into hardware is for the source to include a higher fidelity integrity check along with the jumbo, then the destination gets to verify the integrity after the jumbo has traversed the path. That way, there is still good integrity coverage even if all links in the path are still only using CRC32.
Fred From: Int-area <int-area-boun...@ietf.org> On Behalf Of Robinson, Herbie Sent: Monday, December 18, 2023 5:31 PM To: Paul Vixie <paul=40redbarn....@dmarc.ietf.org>; 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: Re: [Int-area] [EXTERNAL] Re: Jumbo frame side meeting at IETF118 - notes 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. From: Int-area <int-area-boun...@ietf.org<mailto: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<mailto:tom=40herbertland....@dmarc.ietf.org>>; Christian Huitema <huit...@huitema.net<mailto:huit...@huitema.net>> Cc: Gorry (erg) <go...@erg.abdn.ac.uk<mailto:go...@erg.abdn.ac.uk>>; int-area <int-area@ietf.org<mailto: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<mailto:tom=40herbertland....@dmarc.ietf.org>> wrote: On Mon, Dec 18, 2023 at 11:24 AM Christian Huitema <huit...@huitema.net<mailto: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<mailto: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
