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

[Tom Herbert <[e-mail]>]

On Sat, Jun 10, 2023 at 10:10 AM [e-mail]
<[e-mail]> wrote:
>
>
> On Jun 10, 2023, at 8:40 AM, Tom Herbert <[e-mail]> wrote:
>
> 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.
>
>
> 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
>