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

Tom Herbert <> Sat, 10 June 2023 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B8C6AC151B1A for <>; Sat, 10 Jun 2023 10:42:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Status: No, score=-7.096 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fLwCGXUnTQP0 for <>; Sat, 10 Jun 2023 10:41:57 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id C2ED8C151527 for <>; Sat, 10 Jun 2023 10:41:57 -0700 (PDT)
Received: by with SMTP id 98e67ed59e1d1-2564dc37c3eso1457908a91.0 for <>; Sat, 10 Jun 2023 10:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1686418917; x=1689010917; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=itoDy3ObHPbCcRNoLAiH93s5/VaSfo4UmUXwnMsyOKE=; b=UKrSd9LUZ7lSretW2Tyq8OXiCpOFm+tCbVusGa9CVIKp7Ph8JPlaInZ2L6n2ZWNrDE v2a2b5UN3iHKYBww1tpn8JRQIOX+QNx9S5btyAPKKImH4+OFsqjKtwJvu97/B57UlrA8 4tXoKKUYLjgSjaVFQwKY7CNYP7OkOFEQJKwFHMwDa90rjD2RkrlodjrwJsMvVN/cWz3i qnllZFI1gQ0QFjcaceOes0RDjekeCuKcQnutVuIZk1W3kR36+4pOXPMixkrAYAsIr/2C QDmV1MNyoPu+i7vcbXf7vmC9oiQZc3q12OTukKWqsl8FPiliz6HxhTTZ1NpVf2uDI/TG U6KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1686418917; x=1689010917; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=itoDy3ObHPbCcRNoLAiH93s5/VaSfo4UmUXwnMsyOKE=; b=dEDdRRdARHOLsAf62UWNHXhH9yG67hr6DaKHWjXrC110H3Eof+rgSCDu77UTCikbgo xcw0Uw/FqKT4v6grj8X0QyUXeTv5zKj4GHWzMRQa2hHQzJ20y98q/tbmLAjtOI/NgNIl jg2MR3evS2wdH5UxBcxsTLbXEcr5pXFQCjmqQa/xNjwtly5V8D5ZXR4LzmSNqHy5Wqr8 ydrRfHcfgU8jUQ2aQ/5OeMK6KUqkLzdYJDPjv6X/155jHNw38hRAFCd4MLexIGfDFvm6 RBMu98QlfAL6lKtk4Sdm4ZY8Sh5Ql2/laPqBoeEdTpTconjFfQyVKEt6BvkTyH/a+fo7 wXTg==
X-Gm-Message-State: AC+VfDzGMXQvOxa8VEA+9/PHOnuNRdz7DeetiLrQ15SuJlk6M3GU2Gjg nSsebnsAeDTLdJDbEQDO0gHHVMHhDY4RmjRUD79locsfJUd9W0dH8wQ=
X-Google-Smtp-Source: ACHHUZ43Wo/oCFjby/L87RMJsbZhTLpvI6biFuStIvmfj0YTJiXlypoW7mXDxQVWT8ckdYywVlnxLbSzh2GBw1hUzuA=
X-Received: by 2002:a17:90b:4d88:b0:250:69de:7157 with SMTP id oj8-20020a17090b4d8800b0025069de7157mr9772378pjb.2.1686418916862; Sat, 10 Jun 2023 10:41:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Sat, 10 Jun 2023 10:41:45 -0700
Message-ID: <>
To: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-22.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 10 Jun 2023 17:42:01 -0000

On Sat, Jun 10, 2023 at 10:10 AM
<> wrote:
> On Jun 10, 2023, at 8:40 AM, Tom Herbert <> wrote:
> On Fri, Jun 9, 2023 at 8:30 PM
> <> 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.

If different implementations are allowed to choose different protocol
parameters then that reduces interoperability; and when that happens,
the use of the protocol will degrade to the lowest common denominator
of support. This is not an aberration, it is a common trend we see
across deployed IETF dataplane protocols and is a major source of
protocol ossification on the Internet.

> "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).

You're asking the wrong question. The right question is "how did
defining unlimited options work out for out for IPv6?". Conversely,
one could ask "how did limited options work out for TCP?"

> "> 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