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

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

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