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

[Tom Herbert <[e-mail]>]

On Fri, Jun 9, 2023 at 8:30 PM [e-mail]
<[e-mail]> 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
replaced.

"> 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
> www.strayalpha.com
>
> On Jun 9, 2023, at 8:27 PM, [e-mail] 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:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-22
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tsvwg-udp-options-22
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
>