Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Joe Touch <[e-mail]>]

Trying to get back on topic, with explicit clarification and context: 

Where we are on UDP options: 

- this thread is currently discussing only OCS 

- we need to pickup the previous thread on variants of LITE and FRAG,
but for now we're assuming the existing definitions of those 

- options will consume ALL the surplus space when present (which means
we might end up removing EOL) 

Where we currently are on OCS: 

- 16-bit, as per current UDP-options draft TEXT (figs and tables need to
be updated) 

- zeroes-out with the checksummed data, to enable transit of widespread
implementation bugs in middleboxes 

- the OCS field is now manditory (not signalled with a KIND field or
optional as a field) 

- OCS *SHOULD be computed, but MAY be set to zero (e.g., when UDP CS=0,
at user discretion and peril) 

- with LITE, OCS might be transmit-side computed and receive-side
ignored to allow for the intended NON-ROBUST capability (at least when
NOT transiting buggy middbleboxes; see below) of LITE 

(if LITE data doesn't change, that will transit middleboxes; if the LITE
data does change, there's no way to help it transit middleboxes anyway) 

------------ 

So we need to decide: 

- where OCS is (head or tail of the surplus space) 

- whether OCS is aligned, and if so is that 16-bit or 32-bit 

I propose that OCS can come first with no padding or alignment. 

Here's why and questions to guide the discussion (please address the
questions below or indicate why they're not sufficient):

*Given* that we *are* different from UDP and TCP in that we do NOT have
the luxury of a fixed-offset FROM THE BEGINNING OF THE TRANSPORT HEADER
for this checksum: 

- why does the offset distance matter, i.e., front vs. end? 
  NOTE that arguments based on existing implementations that limit 
  the "offset FROM TRANSPORT START" to 255 are not viable, 
  because we're already in a surplus area that's likely to be 
  500+ bytes from that location 

- how *MUCH* does the offset alignment matter, keeping in mind: 
    - ALL offloading requires dealing with the last byte not being
aligned (even when treated as zero-fill)
    - no offset might require 1 byte-swap at some point, but consumes
the least space
    - half-word alignment wastes 4 bits on avg.
    - full-word alignment wastes 12 bits (1.5 bytes) on avg

In comms, the typical figure of merit is 1 opcode per bit. So, IMO:

- if we can save 4 bits with 4 or fewer opcodes, it's a win
- if we can save 12 bits with 12 or fewer opcodes, it's a win

My assumption is that offload engines or the core processor need to do
"non-halfword length" cleanup regardless.

That cleanup should be at most 5 opcodes:
    load
    mask the addend
    add w/carry
    mask the sum (for the 1's compl wrap)
    add w/carry (for the 1's compl wrap)
    swap (if not half-word aligned)

That suggests we're either very close to no real penalty for "no offset"
or that we win by using at least half-word offset.

Note: the alignment overhead will also NEED to be zero-fill - and
checked that it's zero-fill, which are additional opcodes needed that
are not too far from the cleanup ones above.

i.e., given the similarity of the zero-check and the cleanup, why is it
useful to waste these bytes?

Joe