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

Gorry Fairhurst <> Sat, 03 April 2021 09:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE38F3A1573 for <>; Sat, 3 Apr 2021 02:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RlvEsEeKDlKw for <>; Sat, 3 Apr 2021 02:20:44 -0700 (PDT)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id DDFE53A156E for <>; Sat, 3 Apr 2021 02:20:43 -0700 (PDT)
Received: from GF-MBP-2.lan ( []) by (Postfix) with ESMTPSA id 67D851B001AB; Sat, 3 Apr 2021 10:20:32 +0100 (BST)
To: Paul Vixie <>
Cc: Joseph Touch <>, "" <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Sat, 3 Apr 2021 10:20:31 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [tsvwg] UDP-Options: UDP has two ???maximums???
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 03 Apr 2021 09:20:49 -0000

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: