Re: [tsvwg] UDP-Options: UDP has two ???maximums???

[Paul Vixie <[e-mail]>]

On Fri, Apr 02, 2021 at 12:29:55PM +0100, Gorry Fairhurst wrote:
> ... Whereas a sender could anticipate a common fragment size - e.g.
> 1200B, or use dplpmtud to discover this, there is no real way of
> determining the largest datagram that would be the option. ...

i think some form of discovery/negotiation ought to be required here.
the internet has lived with ethernet-sized packets since the mid-1980's
even while underlying link speeds have grown O(4^10). we're now seeing
host interfaces with their own CPU's and operating systems just to cope
with the extraordinary packet rates it takes at that MTU to fill those
pipes. we won't get to the 22nd century without larger MTUs, and it's
nothing like too soon to begin laying the ground work for that. many of
us are using MTU ~9000 in our campuses, and i'm aware of transit networks
using an MTU ~4100 in their cores (and thus available at their edges.)

anticipating "a common fragment size - e.g., 1200B" is how we got here,
but it doesn't have to be how we move on from here. FDDI used MTU ~4000
to avoid having PPS take the full cost of the 10X bit rate improvement
over ethernet. in a non-bridged ethernet market, where each new speed did
not have to be L2-reachable by hosts operating at the previous speed(s),
we would likely have been at MTU ~32K by the gigabit era, and MTU ~64K by
the tenGig era. it's worth recalling the lesson of ATM: that 53b was
considered too small for an OC3C link, and that this was one of the
reasons ATM stopped attracting new customers after a while.

-- 
Paul Vixie