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

[Joe Touch <[e-mail]>]

Hi, Mike, 

On 2018-05-06 10:23, C. M. Heard wrote:

> Greetings, 
> 
> Some issues came to my attention during a recent off-list discussion with someone from the DNS community. 
> 
> Section 5.4, Alternate Checksum (ACS): since the option area is not included in the ACS, the following text seems out of place: 
> 
> When ACS is computed, its checksum (CRC) area is zeroed. No other
> options are zeroed before computing ACS.
> 
> All that is needed is to stuff the remainder of the standard polynomial long division in the ACS checksum area.

Agreed. I need to check on that text throughout. 

> There are also some issues that need to nailed down for clarity. the usual way that the specified polynomial is used is to invert the first 16 bits of data and transmit the complement of the resulting polynomial division. If that is not done here, it would probably be good to say so. Also, it is necessary to specify whether the data polynomial is constructed as if the bytes are transmitted most significant bit first or least significant bit first. Finally, the polynomial is x^16 + x^12 + x^5 + 1 (which would be 0x11021, but that fact is not needed, and I recommend omitting it).

Agreed. 

> 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).

Agreed - I needed a whiteboard to see what you're doing here, but yes -
SLIDE if Len < 4 and SWAP otherwise. Thanks - I'll add that. 

> Note that being able to use the LITE option with a length of zero is important for option negotiation.

Agreed and worth pointing out when adding the text for the exception
case. 

> Section 5,8, FRAG option: it appears to me that the length of the the terminal FRAG option is 10 bytes, not 12. This isn't stated, but the inference I make is that the the checksum is the standard UDP checksum, computed as if the datagram were sent unfragmented, but not including the pseudo-header (to avoid issues created by NAT). If this isn't what was intended, then the intent needs to be clearly spelled out. I note that if the alternate checksum as defined in Section 5.4 does not admit the use of the value zero to indicate that it is not present.

I'll check but the intent is exactly as you inferred - and I need to
double check the size as well. 

> Section 5.8.1, Coupling FRAG with LITE: if the comments above about the checksum field in the terminal FRAG option are correct, some text should be added here that the final checksum in the reconstituted UDP header is not taken directly from the terminal fragment, but is adjusted to include the UDP pseudo-header.

Agreed. 

> Section 8, UDP options vs. UDP-Lite: Is the following paragraph left over from a previous incarnation of the draft? 
> 
> UDP options support a similar service to UDP-Lite by terminating the
> UDP options with an EOL option. The additional data not covered by
> the UDP checksum follows that EOL option, and is passed to the user
> separately. The difference is that UDP-Lite provides the un-
> checksummed user data to the application by default, whereas UDP
> options can provide the same capability only for endpoints that are
> negotiated in advance (i.e., by default, UDP options would silently
> discard this non-checksummed data). Additionally, in UDP-Lite the
> checksummed and non-checksummed payload components are adjacent,
> whereas in UDP options they are separated by the option area -
> which, minimally, must consist of at least one EOL option.
> 
> It seems to me that this should be rewritten, because the service in question is now provided by the LITE option.

This text is exactly explaining the difference between our LITE and
"UDP-Lite". I can clarify this, e.g.,: 

    The UDP option LITE option supports a similar service to
UDP-Lite.... 

Is there some part of this explanation of the differences that isn't
accurate? 

> I'm hoping that there is still enough interest in this draft to push it to completion.

As am I... 

Joe 

> Thanks and regards, 
> 
> Mike Heard