Subject: RE: iSCSI Data Integrity - Digests

From: "Douglas Otis" <[email-masked]>
Date: Thu, 1 Feb 2001 11:25:55 -0800

David,

Once dealing with 32-bit wide memory accesses, adding and subtracting are
hardly difficult operations nor more difficult than that needed for CRC.
Adler32 does not involve division in most implementations and requires few
gates between states so minor pipe-lining easily handles any perceived
difficulty.  You will notice that s2 does not feed into s1.

Here is the repetitive operation of adler32:

     s1 += *buf++;
     if (s1 >= BASE)
         s1 -= BASE;
     s2 += s1;
     if (s2 >= BASE)
         s2 -= BASE;

Doug

> > I am not sure I understand the difficulty imposed by adler32
> with respect
> to
> > hardware. Optimal assembly code looks different with about three
> > instructions per byte.
>
> I believe the concern is about how fast a hot-rodded ASIC can go.
> The arithmetic involved in CRCs doesn't have to cope with carry/borrow
> propagation in contrast to the arithmetic involved in the Adler-32
> modulus.
>
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> [email-masked]       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>
>

---

From: "Y P Cheng" <[email-masked]>
Date: Tue, 6 Feb 2001 13:05:07 -0800

> With my TC Hat on:
> YP and others,
> It does not matter if you are technically right.  We have been over and
> over this. Please let it lay.  If you are sending something that is
> technically TCP/IP but has some extra (legal) trick.  That is of course
> fine, if you are talking to your own adapter.  We here in the IETF would
> not like to talk about your tricks to your adapter.  We need to have
> knowledge that works with other vendors HW and SW Targets.  That means we
> have to define how to use the tricks, and exploit them.  As you know we
> have been told Over and Over that the IETF as a whole will NOT accept this
> kind of thing in our draft standard, so we should not waste our time and
> reflector bandwidth talking about it.
>
> If you folks just have to talk about it, please take it off the reflector.

I apologize for giving you the impression of wanting to talk about something
not appropriate on this reflector.  As you know, I wrote in responding to
comments on non-Standard TCP implementation.  The real question is that each
time a new TCP option is added, does the old TCP remains as Standard or the
new TCP becomes a new Standard. I stated that this WG was prohibited from
discussing this topic.  But, many people in this WG does not seem to realize
that iSCSI chips will have new TCP features and options whether we like it
or not.  While this reflector doesn't wish to talk about TCP, it certainly
could not demand that all new TCP implementations for iSCSI are prohibited.
Peace!