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

["C. M. Heard" <[e-mail]>]

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 <[e-mail]>
wrote:

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