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

From: "C. M. Heard" <[email-masked]>
Date: Sun, 6 May 2018 10:23:54 -0700

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.

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

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

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

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.

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.

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.

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

Thanks and regards,

Mike Heard

---

From: Tom Jones <[email-masked]>
Date: Fri, 11 May 2018 11:07:32 +0100

Hi Mike,

inline

>    options are zeroed before computing ACS.

I need some clarification on this too.

> 0x11021, but that fact is not needed, and I recommend omitting it).

The currect text on the OCS says the checksum is not inverted, this
should be added here as well.

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

> important for option negotiation.

- [tj]

---

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

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

> 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? 
> 
> 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

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 25 May 2018 09:01:14 -0700

Hi Joe,

Regarding this:

On Thu, May 24, 2018 at 11:39 AM, Joe Touch <[email-masked]> wrote:

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

The trouble with the above explanation (a) that is starts with an
inaccurate description of how the LITE option works -- the unchecksummed
data does NOT follow EOL in the surplus area -- and (b) it says that the
checksummed and unchecksummed payload components are separated by the
options -- which is not the case; the order, after processing the LITE
option (slide/swap), is:

UDP Header | checksummed payload data | unchecksummed payload data |
options |  trailing data following EOL

I've highlighted the specific sentences that I think have issues, and I
propose the following replacement paragraph:

   UDP options, via the LITE option, support a service similar to
   UDP-Lite.  The main difference is that UDP-Lite supports carriage
   of non-checksummed user data between the endpoints by default,
   whereas UDP options can safely provide that service only between
   endpoints that negotiate that capability in advance -- an endpoint

   that does not implement UDP options will silently discard the

   non-checksummed user data, along with the UDP options themselves.

Hope this helps.

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 May 2018 09:25:23 -0700

On 2018-05-25 09:01, C. M. Heard wrote:

> This text is exactly explaining the difference between our LITE and "UDP-Lite". I can clarify this, e.g.,: 
> Is there some part of this explanation of the differences that isn't accurate?

  The trouble with the above explanation (a) that is starts with an
inaccurate description of how the LITE option works -- the unchecksummed
data does NOT follow EOL in the surplus area 

Yes, that was from previous text and needs to be fixed.  

> -- and (b) it says that the checksummed and unchecksummed payload components are separated by the options -- which is not the case; the order, after processing the LITE option (slide/swap), is:
> 
> UDP Header | checksummed payload data | unchecksummed payload data | options |  trailing data following EOL

Agreed - I do also need to check the how FRAG and LITE interact to make
sure this describes the details correctly, but yes - thanks. I didn't
see what you had issue with. 

> I've highlighted the specific sentences that I think have issues, and I propose the following replacement paragraph:
> 

Yes, thanks, 

Joe