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

[Joe Touch <[e-mail]>]

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

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.
>
>>> 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.
>> 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?
> You are of course correct on this point, and I withdraw the comment.
>
> Mike Heard