Re: [tcpm] Issue with multiple option code points: Re: Early assignment of IANA TCP option number for AccECN

["[e-mail]" <[e-mail]>]

> On Jul 26, 2022, at 11:44 AM, Scheffenegger, Richard <[e-mail]> wrote:
> 
> Hi Joe,
> 
> It was our understanding, that there was an agreement among participants
> in that discussion - which later focussed more on the perceived "covert
> channel" issue - to go with an easier to implement and maintain
> two-option approach.

That’s not what the email thread indicates, at least at that time.

> The suggested other variants
> * use the length field, and discard "fill bytes" for anything but
> indicate ordering - convert channel issue above)
> * use of a single bit from the first (or all) counter fields - special
> handling of the wrap around situations for 23-bit and 24-bit wide
> counters, making sure that the bit is properly masked out, potentially
> issues with offloading into simple streamlined (small) code.
> 
> While the TCP option numbers are a scarce resource, the understanding
> was this approach was still less wasteful (vs. length encoding) and more
> straightforward to implement (vs. flag bit).

It is important to optimize for TCP as a whole, not just this option.

> Although, tracking optimal
> ordering and stuffing of the TCP options (sending only required/changed
> counters rather than all counters all the time) is not that straight
> forward.
> 
> However, a sender receiving the options in the ACK can have streamlined
> logic to track this - lending to the possibility of doing this in
> offload hardware.

The onus should be on the authors to demonstrate why use of a single codepoint interferes with offloading. This sort of hand-wavy “it’ll be easier” argument doesn’t cut it for me; the default is one codepoint per option, and I still see no reason why this warrants *yet another* exception.

> The two-codepoint approach has been in the draft since -13. It was also
> discussed in the IETF 109 meeting.

But not announced to the list. This was a list discussion point. Burying changes in new versions isn’t sufficient IMO, nor is simply validating it with people who happen to attend.

Note that IMO we can skip the history of how we got here; I still think there hasn’t been a clear explanation of why a single codepoint isn’t sufficient.

Joe