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

[Gorry Fairhurst <[e-mail]>]

On 03/04/2021 00:12, Paul Vixie wrote:
> 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.
>
I think I agree, is this something like you were suggesting:

https://tools.ietf.org/html/draft-fairhurst-tsvwg-udp-options-dplpmtud-04

Gorry