RE: iSCSI CRC: A CRC-checking example

["THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>]

Joe and Bob,

I doubt that any implementation today will be doing CRC computation in a bit
serial circuit. The computation is generally done either byte parallel or,
increasingly, multi-byte parallel. The order in which the bits of a byte are
assigned to polynomial coefficients makes no difference to byte parallel CRC
implementation complexity. The only time complexity would be effected by bit
order is when one was doing a serial shift register implementation of the
CRC generator as some of the earliest Ethernet implementations did. The
technical reasons which applied to Ethernet in chosing the CRC bit checking
order, burst protection and serial implementation complexity, don't apply to
iSCSI.

The only reason for choosing one bit order over another for iSCSI CRC
checking is the limits of human comprehension. Which bit order is most
likely to be gotten right by the humans implementing the standard?

 Ethernet 
          + many people are already accustomed to its bit order
          - most significant byte first, least significant bit first can
cause confusion
 Most significant everything first 
          + more internally consistent than Ethernet
          - different from Ethernet

The most important thing is that we specify whichever one we chose as
clearly as possible.

Regards,
Pat 
             

-----Original Message-----
From: Joe Gervais [mailto:joeg@alacritech.com]
Sent: Thursday, August 23, 2001 7:21 PM
To: Robert Snively; Black_David@emc.com; sanjay_goyal@ivivity.com;
ips@ece.cmu.edu
Subject: RE: iSCSI CRC: A CRC-checking example


Bob,

If the data was going on token ring or some other media, sure, who cares
about an Ethernet approach, but the data is generally being sent and
received over Ethernet, and there is advantage at least in some
implementations to be in Ethernet bit/byte order.

Additionally, as David said earlier today, if it isn't broke, let's not fix
it. Can we get consensus and move on?

Joe
-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Robert Snively

... snip ...
So I would have expected that we would avoid any choice that
makes that less convenient.  The Ethernet approach to those
bytes would strike me as being the second-least convenient
approach.  Clearly, throwing hardware at this could correct
for that inconvenience, but it seems to me that any
optimizations we make should focus on what we want to do, not
what Ethernet did.

Bob