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

Tom Herbert <> Sat, 10 June 2023 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CD27C16B1E5 for <>; Sat, 10 Jun 2023 08:41:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Status: No, score=-7.097 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_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 ZqGSjL4w9QY9 for <>; Sat, 10 Jun 2023 08:41:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1034]) (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 6D94FC151B33 for <>; Sat, 10 Jun 2023 08:41:07 -0700 (PDT)
Received: by with SMTP id 98e67ed59e1d1-2553663f71eso1216899a91.3 for <>; Sat, 10 Jun 2023 08:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1686411666; x=1689003666; 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=UuxZMkSvjNkSttTg9UHTW849kt4lx3IsCtOHpBKbUM8=; b=SkWxA+8PWlarGxjvWFYOCtujHwyKLN019mSvwMDEUy58zs7Ied2ps4sGEcL7ITaFwH TwV/fGg58NpMQFOxZtI6Rn6rtDj73VIxTiEQs08OSHqIQR6CdkTPTGT7PO4MWr7xaM+H deDecPxZNzMTj7HBva3sxJ0tjkXT9iJjmznvHGl4CORMKhmO4z/bgwbKlsdttmRlweqf kgAQImzSK4eqa5+4pMOrjhBAFIqPXbGsCjPhapgTe3cJNazK4n2zR8AlwAPchKKtw73d fn+OkRFZljR/Z0TkNOmflmJB/cg+TiJqJ295p4AD8mW8IlJhQ3TuKwJQWujlujWQgHVy tyAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1686411666; x=1689003666; 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=UuxZMkSvjNkSttTg9UHTW849kt4lx3IsCtOHpBKbUM8=; b=MT1Zop3JQ3Efi3UPLKSLgszLUlfU8/rCBB0ShmB00WQ9R9qiWKA2/BsqeXw3f8jM+a 84U5ItUDp+z7ZbRrdDELHbsM4m+FzCS4TufMKQ3pgTUOznOXDuPY6kyZC1f2t13f4YAH S2/w3imdIK9luGI1lvV/RHoAhIZehyoNSiBjO/nKNnzONPl89D5Z3WNUal9grG+L8+ba 2cJpa3s5v7jdHWy24EvnBnO4tgQRavB6Og2SLy51Icakf14E/8ia/1KShgjAkXRxhe9/ eDKKi2P2osFxNUgAd9TFAzpLkPvY0sliZUibxBbKOSZs/7/DZDwUNSrLVK0C5k3b0B0v Laqw==
X-Gm-Message-State: AC+VfDzWoJx1UdmWOwixxR60Dv2vrP9Ai56n9csF8qyEbKcos0ca1Jd7 swXZrLPdtwe+7B6YErWtQWeHzXJFO1XnPo+FDU1c+1eOVga1YdaDYlRVQw==
X-Google-Smtp-Source: ACHHUZ61i3irLGYvuc8VPVi7PNaG1rL6CZLk/mxCSaHfkPO1PbJ0YcM0lgtah4uYf02ZiyeR9LliuXLejCkCJyh+RxA=
X-Received: by 2002:a17:90a:c403:b0:259:a7df:f6f8 with SMTP id i3-20020a17090ac40300b00259a7dff6f8mr3656537pjt.24.1686411666493; Sat, 10 Jun 2023 08:41:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Sat, 10 Jun 2023 08:40:54 -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 15:41:11 -0000

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.

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

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

> Joe
> —
> Dr. Joe Touch, temporal epistemologist
> On Jun 9, 2023, at 8:27 PM, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This Internet-Draft is a work item of the Transport Area Working
> Group (TSVWG) WG of the IETF.
>   Title           : Transport Options for UDP
>   Author          : Joe Touch
>   Filename        : draft-ietf-tsvwg-udp-options-22.txt
>   Pages           : 44
>   Date            : 2023-06-09
> Abstract:
>   Transport protocols are extended through the use of transport header
>   options. This document extends UDP by indicating the location,
>   syntax, and semantics for UDP transport layer options.
> The IETF datatracker status page for this Internet-Draft is:
> There is also an htmlized version available at:
> A diff from the previous version is available at:
> Internet-Drafts are also available by rsync at