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

[Gorry Fairhurst <[e-mail]>]

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:
> 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
>
>
> On 3/25/2017 7:37 PM, C. M. Heard wrote:
>> On Sat, Mar 25, 2017 at 3:06 PM, Joe Touch<[e-mail]>  wrote:
>>> On 3/25/2017 6:26 AM, C. M. Heard wrote:
>>>> On Wed, Mar 22, 2017 at 10:43 PM, Joe Touch<[e-mail]>  wrote:
>>>>>> In section 5.4, was a decision made as to what the CRC16 is? Details
>>>>>> 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?
>>>> 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 that case should we go with CRC-16-CDMA2000?
>>>
>>> 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