Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-02

From: "C. M. Heard" <[email-masked]>
Date: Thu, 24 May 2018 11:09:15 -0700

On Fri, May 11, 2018 at 3:07 AM, Tom Jones <[email-masked]> wrote:
> On Sun, May 06, 2018 at 10:23:54AM -0700, C. M. Heard wrote:
>> Section 5.5, LITE option: the following instruction
>>
>>    3. Swap all four bytes of the LITE option with the first 4 bytes of
>>       the LITE data area (Figure 11).
>>
>>
>> works only if the LITE data area is at least four bytes long. However, the
>> option will work just fine with 0, 1, 2, or 3 bytes of LITE data if one
>> simply moves the option to the start of the LITE data area and moves the
>> displaced LITE bytes just past the end of the relocated LITE option. This
>> operation is then reversed on the receive side. In effect, one is swapping
>> the locations of the LITE option and the initial segment of the LITE data
>> area of length min(4, LITE offset).
>
> A UDP Lite region greater than 0 must be a minimum of 8 octets.
>
>         A Checksum Coverage of zero indicates that the entire UDP-Lite
>         packet is covered by the checksum.  This means that the value of
>         the Checksum Coverage field MUST be either 0 or at least 8.
>
> So only the 0 coverage case must be considered by this document.

This is a misreading of RFC 3828. In UDP-Lite, if the value of the Checksum
Coverage field is non-zero, then the number of UDP payload bytes covered by
the checksum is 8 less than that value. So UDP-Lite allows for any number of
payload bytes from 0 to (MAXIMUM_UDP_DATAGRAM_SIZE - 8) to be covered by the
UDP checksum. The same range is allowed for the number of payload bytes that
are **not** covered by the UDP checksum. The objective for udp-options should
IMHO be to provide the exact same flexibility (modulo reduction of the upper
bound by the length of the UDP options trailer).

In UDP (protocol 17), even when augmented by UDP options, the minimum value
of UDP Length is 8, full stop; a value from 0 through 7 is simply an error
(see page 6 of the draft). The special meaning of the value 0 defined in RFC
3828 does not apply. But other than that, the meaning of UDP Length field
in the udp-options draft and the Checksum Coverage field in RFC 3828 are
(essentially) the same.

So we do need to deal with LIE data lengths from 0 through 3.

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 May 2018 11:33:34 -0700

On 2018-05-24 11:09, C. M. Heard wrote:

> ...

Agreed, but I don't think it needs to change what's in the existing doc
all that much. 

For 4 or more, do what's in the doc. 

For 0-3, then "slide" the LITE option before the LITE data, e.g.: 

the lite header = [L I T E] 
lite data = caps, e.g., U V W X Y Z or a subset thereof 
other options = a b c d e ... 

before transmitting: 
        lite data len:    lite area and options: 
       ------------------------------------------ 
              0 bytes     [L I T E] a b c d e ... 
              1 byte      U [L I T E] a b c d e ... 

              2 bytes     U V [L I T E] a b c d e ... 

              3 bytes     U V W [L I T E] a b c d e ... 

              4 bytes     U V W X [L I T E] a b c d e ...  
              5 bytes     U V W X Y [L I T E] a b c d e ...  
              6 bytes     U V W X Y Z [L I T E] a b c d e ... 

after transmitting 
              0 bytes     [L I T E] a b c d e ... 

              1 byte      [L I T E] U a b c d e ... 

              2 bytes     [L I T E] U V a b c d e ... 

              3 bytes     [L I T E] U V W a b c d e ... 

              4 bytes     [L I T E] U V W X a b c d e ...
              5 bytes     [L I T E] Y U V W X a b c d e ...  
                                    ^ 
              6 bytes     [L I T E] Y Z U V W X a b c d e ... 
                                    ^ ^ 

The issue is highlighted with the carets (^).  

For 3 bytes or less, "SLIDE" 
For 4 bytes, SLIDE is the same as SWAP 
For more than 4 bytes, SWAP is more efficient than SLIDE (avoids a long
copy of the data) 

I don't think it's bad to have a special case for 3 or fewer bytes. 

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 25 May 2018 07:36:30 -0700

> I don't think it's bad to have a special case for 3 or fewer bytes.

Agreed.

--cmh