Subject: Re: [tsvwg] New Version Notification for draft-touch-tsvwg-udp-options-05.txt

From: Joe Touch <[email-masked]>
Date: Fri, 17 Mar 2017 18:03:45 -0700

Hi, all,

The queue has closed, but I have a new version of UDP options 06 that
will post as soon as it opens (why do we still do this?)

Here's a pointer in the meantime:

http://www.isi.edu/touch/pubs/draft-touch-tsvwg-udp-options-06.txt

It includes Mike's nice observation about combining FRAG and LITE,
clarifies some nits about what happens in each order, etc.

I tried to keep things simple, so LITE comes first when it's used, FRAG
stops processing until reassembly, and things pick up after reassembly
with options included after the last fragment. I think that's clean...

Thanks all - Gorry will be presenting this (I hope it's not gotten too
complex),

Feedback welcome, of course,

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 22 Mar 2017 18:52:20 -0700

> with options included after the last fragment. I think that's clean...

Agreed, I like the way you have done this, with the final fragment being
indicated by including a checksum. That said, the following text:

>> A host SHOULD indicate FRAG support by transmitting an
   unfragmented datagram using the Fragmentation option (e.g., with
   Offset and M both zero), except when encoded as LITE.

needs to be adjusted owing to elimination of the M bit in favor of a
whole-datagram checksum.

Regarding the whole-datagram checksum: it would IMHO be appropriate to
be very specific as to what it is. I would propose the standard Internet
checksum without a pseudo-header, with the value 0x0000 indicating the
absence of a checksum.

Other comments:

In section 5.4, was a decision made as to what the CRC16 is? Details
will be needed in order to ensure interoperability.

In Section 9, third paragraph, you may want to make the following change:

OLD:
   This feature is also inconsistent with the UDP application interface
   [RFC768] [RFC1122].
NEW:
   This feature is also inconsistent with the UDP application interface
   [RFC1122].

in view of the following text in RFC 768:

IP Interface
-------------

The UDP module  must be able to determine  the  source  and  destination
internet addresses and the protocol field from the internet header.  One
possible  UDP/IP  interface  would return  the whole  internet  datagram
including all of the internet header in response to a receive operation.
Such an interface  would  also allow  the UDP to pass  a  full  internet
datagram  complete  with header  to the IP to send.  The IP would verify
certain fields for consistency and compute the internet header checksum.

Thanks and regards,

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Wed, 22 Mar 2017 22:43:20 -0700

Hi, Mike,

> needs to be adjusted owing to elimination of the M bit in favor of a
Thanks for the catch. I'll fix that in -06.

> checksum without a pseudo-header, with the value 0x0000 indicating the

It does say "IP checksum over the reassembled payload", which could be
"optional Internet checksum over the reassembled UDP payload (i.e.,
excluding the IP pseudoheader, UDP header, and UDP options), where a
value of 0x0000 indicates no checksum."

And a warning that "This reassembly checksum SHOULD be used unless a
stronger application layer integrity protection is used." (or something
close to that).
> will be needed in order to ensure interoperability.

That's on my to-do list (I was a bit distracted by these other issues).
There are three obvious possibilities:

CRC-16-CCITT            used by Bluetooth, X.25, HDLC (4 terms - 0x1021)
CRC-16-IBM               used by USB (4 terms -- 0x8005)
CRC-16-CDMA2000    used by CDMA  mobile nets (8 terms - 0xC867)

There are other analyses that point to other polynomials:
https://users.ece.cmu.edu/~koopman/crc/

Any suggestions?
> in view of the following text in RFC 768:

I read that section as defining the interface below UDP, not above UDP.
I.e., it's the IP API that UDP expects, not the interface UDP expects
users to utilize.

Can you double-check?

Thanks again,

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 23 Mar 2017 08:34:05 +0000

On 23/03/2017, 05:43, Joe Touch wrote:
>> On Fri, Mar 17, 2017 at 6:03 PM, Joe Touch<[email-masked]>  wrote:
I suggest using CRC-16-CCITT, it's common (and fairly strong) and there 
is lookup-based code published.
> I.e., it's the IP API that UDP expects, not the interface UDP expects
Gorry

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 25 Mar 2017 06:26:16 -0700

> https://users.ece.cmu.edu/~koopman/crc/

Both the CRC-16-CCITT and CRC-16-IBM polynomials factor into the product
of x+1 times a primitive polynomial of degree 15 (*op in Koopman's notation)
and are in a sense optimal for random error patterns. They detect all triple
errors (and all error patterns of odd weight) for data lengths of 4093 bytes
or less. The CRC-16-CDMA2000 has a single factor, which is a primitive
degree 16 polynomial (*p in Koopman's notation), and it will detect all
double errors for data lengths of 8189 bytes or less. By data length I
mean of course the length of the data protected by the CRC (not
including the CRC itself).

There are generic fast table lookup algorithms for all CRC-16 polynomials,
including automated methods for generating the lookup tables, so that is
not really a factor in choosing a polynomial.

> I.e., it's the IP API that UDP expects, not the interface UDP expects

You are of course correct on this point, and I withdraw the comment.

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Sat, 25 Mar 2017 15:06:58 -0700

I that case should we go with CRC-16-CDMA2000?

Or is there a better/stronger one from the table that's more useful?

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 25 Mar 2017 19:37:04 -0700

> Or is there a better/stronger one from the table that's more useful?

Actually, CRC-16-CCITT or CRC-16-IBM (which are theoretically equivalent)
are ***stronger** than CRC-16-CDMA2000  for datagram payloads up to 32751
bits (i.e., CRC + data length = 32767 bits), when errors are random. For
datagrams of that exact length It can be proven (again for random errors)
that the undetected error rate is no worse than 1/65536, and for lesser
lengths simulations bear this out (see, for example,
http://doc.utwente.nl/64267/1/schiphorst.pdf). The only reason I can see
to choose CRC-16-CDMA2000 would be to provide protection for datagrams
longer than 4K bytes, in which case a better choice would be a 32-bit CRC.
The standard Autodin/Ethernet/ADCCP/HDLC CRC-32 polynomial is

x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+1

Although it is a primitive polynomial (without a factor of x+1) it will
protect against all triple error patters for datagram lengths of 11450
bytes, according to simulations that I ran about 14 years ago, and
its undetected error rate (for random errors) can be expected to be
under 2^-32. So that's what I would be inclined to recommend.

Regards,

Mike Heard

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Mar 2017 08:37:33 -0700

So do we want to recommend a 16-bit value or jump to the 32-bit one?

IMO, for UDP, anything reasonably stronger than the Internet checksum
should be fine. I was hoping for a 16-bit selection to leave the result
32-bit aligned...

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 27 Mar 2017 11:02:18 -0500

I'd think CRC-16 is likely to be a good proposal. 32b alignment is 
always good.

Gorry

On 27/03/2017, 10:37, Joe Touch wrote:
>> On Sat, Mar 25, 2017 at 3:06 PM, Joe Touch<[email-masked]>  wrote:
>>>> On Wed, Mar 22, 2017 at 10:43 PM, Joe Touch<[email-masked]>  wrote:

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 27 Mar 2017 10:41:34 -0700

I have no objections to that. As for the selection of the specific
polynomial:

   - If you think protection of long payloads ~8K bytes is of overriding
   importance, choose CRC-16-CDMA2000
   - If you think protection of shorter payloads (less than 4K bytes) is
   more important, choose CRC-16-CCITT or CRC-16-IBM

My sense is that CRC-16-CCITT is more widely used than CRC-16-IBM and may
be preferable for that reason.

Mike Heard

On Mon, Mar 27, 2017 at 9:02 AM, Gorry Fairhurst <[email-masked]>
wrote:

> I'd think CRC-16 is likely to be a good proposal. 32b alignment is always
> good.
>
> Gorry
>
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 27 Mar 2017 10:53:03 -0700

Hi, Mike,

I don't know if we have a sense of what the future will evolve into, but
the likely more immediate use is packets too large for the path MTU but
not all that big overall - which suggests we ought to use CRC-16-CCITT.

I'll roll that in and issue the update shortly.

Joe

On 3/27/2017 10:41 AM, C. M. Heard wrote:
>   * If you think protection of long payloads ~8K bytes is of
>     overriding importance, choose CRC-16-CDMA2000
>   * If you think protection of shorter payloads (less than 4K bytes)
>     is more important, choose CRC-16-CCITT or CRC-16-IBM
>
> My sense is that CRC-16-CCITT is more widely used than CRC-16-IBM and
> may be preferable for that reason.
>
> Mike Heard
>
> On Mon, Mar 27, 2017 at 9:02 AM, Gorry Fairhurst <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>             On Sat, Mar 25, 2017 at 3:06 PM, Joe Touch<[email-masked]
>             <mailto:[email-masked]>>  wrote:
>
>                     On Wed, Mar 22, 2017 at 10:43 PM, Joe
>                     Touch<[email-masked] <mailto:[email-masked]>>  wrote:
>
>                         <https://users.ece.cmu.edu/%7Ekoopman/crc/>
>
>                         Any suggestions?
>
>             http://doc.utwente.nl/64267/1/schiphorst.pdf
>             <http://doc.utwente.nl/64267/1/schiphorst.pdf>). The only
>             reason I can see