Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-22.txt

"touch@strayalpha.com" <touch@strayalpha.com> Sat, 10 June 2023 17:10 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA94C152F15 for <tsvwg@ietfa.amsl.com>; Sat, 10 Jun 2023 10:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.316
X-Spam-Level:
X-Spam-Status: No, score=-1.316 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-Nxlj9zjK1f for <tsvwg@ietfa.amsl.com>; Sat, 10 Jun 2023 10:10:00 -0700 (PDT)
Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24A8C152F0E for <tsvwg@ietf.org>; Sat, 10 Jun 2023 10:10:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VDPQ6Omvt2Dsi79KQ2MF0M7r+BzGEM4Rr3ntBkLyaxg=; b=LkINM4e1RcYF2O2Lh/ZcTxko3W +rj+KQ8LbCzRXn1mc4LP89o4ILD0nhqdEjgA81ZqLyENsOqbZQK8vu00EcruQhkggeNAjZ8y7he5A 2X7c9lLY7a4NEtgzSNjOLNo26s86UDH4+i/j+gqJzJ3ECZN+66H6Myb3msHvPvJAMjJHtGO2MdgSY BhzLXVvTkDO+CVFzEom6u8siXf3pIv2YwpoDSzHov/6mMlItopEVkftJilnVLimkVpJok7t/1JXcv fR46IoGuJdnuOAsehlzQBcvs8v8wrK0qY7xDnkGxEOItxcAfGCI89z7fXTYeoaegKgKivgFhN8eZL tTxTBjJQ==;
Received: from [172.58.209.100] (port=1671 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <touch@strayalpha.com>) id 1q8266-003Eyh-84; Sat, 10 Jun 2023 13:09:58 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_3716F878-80F8-4CB0-BF09-328F4B373752"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <CALx6S35UE2TApueBPacjCou_GJqpU7=JCrtryu7YVPbeukg2Qw@mail.gmail.com>
Date: Sat, 10 Jun 2023 10:09:42 -0700
Cc: tsvwg@ietf.org
Message-Id: <9D908FAE-27EC-4CBC-8C56-C757374434F2@strayalpha.com>
References: <168636765932.60931.17876556014123415544@ietfa.amsl.com> <2DFC6427-542D-4226-B11F-19D7F55BCD8C@strayalpha.com> <CALx6S35UE2TApueBPacjCou_GJqpU7=JCrtryu7YVPbeukg2Qw@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3731.600.7)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/0IhPa3u9Q3uIzy24vEvmqWWQmbA>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-22.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Jun 2023 17:10:04 -0000

> On Jun 10, 2023, at 8:40 AM, Tom Herbert <tom@herbertland.com> wrote:
> 
> On Fri, Jun 9, 2023 at 8:30 PM touch@strayalpha.com
> <touch@strayalpha.com> wrote:
>> 
>> Hi, all,
>> 
>> This version attempts to address the recent exchange.
>> 
>> Note that it updates previous advice to support at least 8 options per packet, learning from (IMO) the errors of RFC8502, and instead specifying the number in terms of the individual implementation. This still easily caps the number expected by any receiver, but while avoiding “baking” a fixed limit of 8 into deployed systems.
>> 
> RFC8504 is a BCP, those limits can change if necessary (given
> historical data and state of deployment, those aren't going to need to
> change anytime soon).
> 
> "E.g., if a system supports 10 different option types that could
> concurrently be used, it is expected to allow up to around 13-14
> different options in the same packet."
> 
> In the current draft only seven options are defined. So by the above
> logic, the default limit would be seven plus a few for expected
> growth. So for all practical purposes, the default could be specified
> as 10. IMO, it's much better to be explicit here, even as a BCP, if
> you leave this up to individual implementations you might not be happy
> with what they choose.

This isn’t a BCP. And no, it’s not better - putting a specific number sets that as an expectation until that doc is updated, which effectively locks it in forever. Nobody does more than is expected.

By expecting implementations that do more to allow more, the current wording both avoids that lock-in and allows more modest implementations - e.g., that don’t have resources to enable 100 options - to not need to support packets with 100 options.

> 
> "but should also consider
> being adaptive and based on the implementation, to avoid locking in
> that limit globally."
> 
> IMO, it's unlikely that anyone will invest the time and resources to
> make adaptive algorithms

Adapted to the implementation. It does not talk about adaptive algorithms.

As above, this just indicates that lesser implementations can allow less, but full-featured ones need to accommodate more.

> for a new protocol that hasn't yet seen any
> deployment. So much simpler to just set a limit. So we can assume the
> default limit will be locked in globally, and once systems are
> deployed changing those limits takes years as legacy systems are
> replaced.

How’s that working out for IPv6? (It doesn’t - once you set the bar low, that’s it).

> "> Receivers supporting UDP options MUST silently drop the UDP user
>   data of the reassembled datagram if any fragment or the entire
>   datagram includes an UNSAFE option whose UKind is not supported or
>   if an UNSAFE option appears outside the context of a fragment or
>   reassembled fragments. Note that this still results in the receipt"
> 
> This needed to be split into two requirements, one for fragments and
> one for non-fragments.

AOK - yes, that would be more clear. Will do.

> Unless it's a fragment, processing UDP Options
> should NEVER cause the packet to be discarded or the UDP datagram to
> be modified in any way. To do so otherwise could systematically break
> pre-existing uses, inadvertent or not, of the UDP surplus space.

Agreed.

Joe