The Size of Packets

#1

Post by todsacerdoti » Fri, Apr 18, 2025, 12:59 AM UTC

The Size of Packets
potaroo.net

Re: The Size of Packets

#2

Post by posnet » Fri, Apr 18, 2025, 1:57 AM UTC

"Jumbogram", an IPv6 packet with the Jumbo Payload option set, allowing for an frame size of up to 2³²-1 bytes.

At 10Gbps it would take 3.4 seconds just to serialize the frame.

Re: The Size of Packets

#3

Post by cryptonector » Fri, Apr 18, 2025, 1:59 AM UTC

> Path MTU discovery has not been enthusiastically embraced

Ugh. I don't understand this. Especially passive PMTUD should just be rolled out everywhere. On Linux it still defaults to disabled! https://sourcegraph.com/search?q=context%3Aglobal+repo%3A%5E...

Re: The Size of Packets

#4

Post by hugmynutus » Fri, Apr 18, 2025, 2:10 AM UTC

posnet wrote: post #2

"Jumbogram", an IPv6 packet with the Jumbo Payload option set, allowing for an frame size of up to 2³²-1 bytes. At 10Gbps it would take 3.4 seconds just to serialize the frame.

Luckily 400Gb/s nics are already on the market [1]

[1] https://docs.broadcom.com/doc/957608-PB1

Re: The Size of Packets

#5

Post by Veserv » Fri, Apr 18, 2025, 4:01 AM UTC

MTU discovery would be so much easier if the default behavior was truncate and forward when encountering a oversized packet. The endpoints can then just compare the bytes received against the size encoded inside of the packet to trivially detect truncation and thus get the inbound MTU size.

This allows you to do MTU discovery as a endpoint protocol with all the authentication benefits that provides and allows you to send a single large probe packet to precisely identify the MTU size. It would also allow you to immediately and transparently identify MTU reductions due to route changes or any other such cause instead of packets just randomly blackholing or getting responses from unknown, unauthenticated endpoints.

Re: The Size of Packets

#6

Post by beeburrt » Fri, Apr 18, 2025, 4:47 AM UTC

That font size is tiny. If this is your site, maybe consider a larger font size

Re: The Size of Packets

#7

Post by nayuki » Fri, Apr 18, 2025, 4:49 AM UTC

> The speed of light in glass or fiber-optic cable is significantly slower, at approximately 194,865 kilometers per second. The speed of voltage propagation in copper is 224,844 kilometres per second.

If I understand correctly, the speed of light in an electrical cable doesn't depend on the metal that carries current, but instead depends on the dielectric materials (plastic, air, etc.) between the two conductors?

Re: The Size of Packets

#8

Post by nayuki » Fri, Apr 18, 2025, 4:52 AM UTC

beeburrt wrote: post #6

That font size is tiny. If this is your site, maybe consider a larger font size

The site specifies a base font size of 12px. The better practice is to not specify a base font size at all, just taking it from the user's web browser instead. Then, the web designer should specify every other font size and box dimension as a scaled version of the base font size, using units like em/rem/%, not px.

Re: The Size of Packets

#9

Post by mkj » Fri, Apr 18, 2025, 4:54 AM UTC

cryptonector wrote: post #3

> Path MTU discovery has not been enthusiastically embraced Ugh. I don't understand this. Especially passive PMTUD should just be rolled out everywhere. On Linux it still defaults to disabled! https://sourcegraph.com/search?q=context%3Aglobal+repo%3A%5E...

Would that help with UDP, or only TCP?

Re: The Size of Packets

#10

Post by usefulcat » Fri, Apr 18, 2025, 5:04 AM UTC

beeburrt wrote: post #6

That font size is tiny. If this is your site, maybe consider a larger font size

Given the subject of TFA, this seems appropriate in a meta sort of way.