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

Paul Vixie <> Fri, 02 April 2021 23:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C4A83A0BD2 for <>; Fri, 2 Apr 2021 16:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CMBjtShjBzN0 for <>; Fri, 2 Apr 2021 16:12:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C8D2E3A0C3A for <>; Fri, 2 Apr 2021 16:12:01 -0700 (PDT)
Received: by (Postfix, from userid 716) id EF7AC7599B; Fri, 2 Apr 2021 23:12:00 +0000 (UTC)
Date: Fri, 2 Apr 2021 23:12:00 +0000
From: Paul Vixie <>
To: Gorry Fairhurst <>
Cc: Joseph Touch <>, "" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
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: Fri, 02 Apr 2021 23:12:05 -0000

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