Subject: RE: iSCSI CRC: A CRC-checking example

From: Robert Snively <[email-masked]>
Date: Thu, 23 Aug 2001 17:54:01 -0700

I've only been following this discussion loosely, but
it seems to me that the Ethernet byte and bit ordering
is dictated by a series of hardware choices made long ago.
On the other hand, the iSCSI byte and bit ordering is
taken from (or placed in) memory in a contiguous
byte/bit stream which is basically big-endian, regardless
of how it happens to be manipulated by the attached
processor.

I would imagine that we would choose the bit and byte
ordering convenient to the DMAing of the data into and
from memory.  I believe that most of these functions will
wind up in hardware that delivers a big-endian byte stream
to a TCP processor.  

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, August 23, 2001 3:31 PM
> To: [email-masked]; [email-masked]
> Subject: RE: iSCSI CRC: A CRC-checking example
> 
> 
> From a practical standpoint, using the same implementation framework
> (for lack of a better word) as Ethernet reduces the opportunity
> to get this wrong - a designer who's done an Ethernet CRC does
> the same thing with the new CRC polynomial and the result works.
> 
> If this aspect of CRC usage "ain't broke", I would think
> that "don't fix it" is the preferred course of action ;-).
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Douglas Otis [mailto:[email-masked]]
> > Sent: Thursday, August 23, 2001 5:43 PM
> > To: Sanjay Goyal; 'CAVANNA,VICENTE V (A-Roseville,ex1)'
> > Cc: [email-masked]
> > Subject: RE: iSCSI CRC: A CRC-checking example
> > 
> > 
> > Sanjay,
> > 
> > In short, the reflected table is likely to require fewer 
> instructions to
> > implement a lookup than a non-reflected table.  Secondly, 
> if the processor
> > is Little Endian, then the result is already in network 
> order without byte
> > swapping.  Obviously this last point only helps if you are 
> using a Little
> > Endian processor but this happens only once per packet 
> whereas the lookup
> > may happen every byte.  Third, the inverted store improves 
> the sensitivity
> > to the packet length.  All these Ethernet techniques seems 
> to be good
> > things.  One difference however is the polynomial.
> > 
> > Doug
> > 
> > > The last line says
> > >  "but I suppose it is advantageous to do things the ethernet way."
> > > May I know in what ways it would be advantageous.
> > >
> > > Regards
> > > Sanjay Goyal
> > >
>

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 23 Aug 2001 18:59:09 -0700

Bob,

If there is a hardware implementation at the memory bus level, then the
gates assembled to provide a workable solution will not be greatly affected
by the bit order except of course to accommodate whatever bit order was
defined.  In hardware, the polynomial will play a greater role than the bit
order as this becomes a parallel conversion.  It may mean tightening the
straps on the thinking cap when assigning terms.

Doug

---

From: "Joe Gervais" <[email-masked]>
Date: Thu, 23 Aug 2001 19:21:21 -0700

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: [email-masked] [mailto:[email-masked]]On Behalf Of
Robert Snively

... snip ...

Bob

---

From: Mark Bakke <[email-masked]>
Date: Fri, 24 Aug 2001 08:49:15 -0500

I agree with Joe.  Whether to reflect, complement, or
whatever makes no important difference for either a table-
driven software implementation, nor for a hardware
implementation; at least not important enough to tell our
grandkids about someday.

The important thing is that we have finally specified
the algorithm, and have clear examples that everyone's
implementation matches, so this will actually interoperate.

The rest just doesn't matter.

Let's please move on.

--
Mark

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054