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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8C503A1554 for <>; Sat, 3 Apr 2021 02:17:44 -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 CXK_-oL18Z-C for <>; Sat, 3 Apr 2021 02:17:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 834A43A1552 for <>; Sat, 3 Apr 2021 02:17:40 -0700 (PDT)
Received: from GF-MBP-2.lan ( []) by (Postfix) with ESMTPSA id 069FB1B001AB; Sat, 3 Apr 2021 10:17:35 +0100 (BST)
To: Joseph Touch <>
Cc: "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Sat, 3 Apr 2021 10:17:34 +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: 8bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [tsvwg] =?utf-8?q?UDP-Options=3A_UDP_has_two_=E2=80=9Dmaximums?= =?utf-8?b?4oCd?=
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:17:45 -0000

On 02/04/2021 18:59, Joseph Touch wrote:
> Hi, Gorry (et al.),
>> On Apr 2, 2021, at 4:29 AM, Gorry Fairhurst <> wrote:
>> In the last IETF TSVWG meeting you asked for throughts about what MSS should mean?
>> I have now thought - the key unknown here is how large a datagram segment the remote receiver is willing to accept - i.e., what is the largest fragmented datagram I can send that would be reassembled. This might be any number, depending on the way in which the receiver is designed or configured. 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 you suggested this as: Max reassembly size, a hard upper bound, similar to MSS_R.
>> Does this help?
> I had assumed that would be at useful.
> The question that remains is whether it is useful to also have an MSS option in the same spirit as TCP. That would argue for two different MSS values:
> 	UDP path MSS
> Are both actually useful? Is the TCP one useful? (esp. given it really isn’t path info)?
> Joe
Hi Joe,

I'll argue also that the maximum size a remote transport receiver can 
process, isn't so helpful, because the transport endpoint often does not 
know the set of encaps/tunnel/link-MTU along the path. That's why I 
argue we should have a "default" (as in "For IPv4, EMTU_S is the smaller 
of 576 bytes and the first-hop MTU [RFC1122]. For IPv6, EMTU_S is 1280 
bytes [RFC2460]"), that could be used - and might be expected to usually 
work, *or* a "probe" to find out what the path actually supports: 
knowing the remote receiver can process X bytes does not really help 
that much, and actually could be unhelpful when information if it is not 
correct. So I'll argue against sharing this from the receiver.

I'll also follow-up on Paul's email in a moment...