Subject: RE: [Tsvwg] [SCTP checksum problems]

From: "CAVANNA,VICENTE V (A-Roseville,ex1)" <[email-masked]>
Date: Wed, 18 Apr 2001 13:09:08 -0400

Hi Jim,
I don't think iSCSI can be completely relieved of performing some data
integrity checking as long as there exists the possibility of "middle boxes"
opening up the transport protocol's packet and thus potentially invalidating
any reliability guarantees the transport protocol makes.
Vince

|-----Original Message-----
|From: WENDT,JIM (HP-Roseville,ex1) [mailto:[email-masked]]
|Sent: Tuesday, April 17, 2001 11:44 AM
|To: [email-masked]'
|Cc: [email-masked]; [email-masked]; 'Craig Partridge'; Jonathan Wood;
[email-masked]; Jonathan Stone; Randall Stewart; WENDT,JIM
|(HP-Roseville,ex1)
|Subject: Re: [Tsvwg] [SCTP checksum problems]
|
|
|Julian,
|The SCTP folks are right now discussing changing the SCTP 
|checksum to be a
|CRC-32 (or other). This is a very good thing and really what 
|needs to happen
|with SCTP for it to support iSCSI and other data-critical applications
|effectively (and also relieve iSCSI from having to implement 
|data integrity
|checking and transport-like functionality over SCTP).
|
|They are looking for inputs as to which CRC-32 or checksum to 
|use. The iSCSI
|WG's CRC investigation work and conclusion would be a valuable 
|input into
|their decision. The sooner that you can provide the iSCSI 
|recommended CRC
|and reasoning behind it to them, the better, even before the 
|forthcoming I-D
|is distributed.
|
|Jim Wendt
|Networked Storage Architecture
|Hewlett-Packard Company
[email-masked] 916-785-5198
|
|---------------------------------------------------------------
|-------------
|-
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]]
|> Sent: Sunday, April 15, 2001 7:58 AM
|> To: [email-masked]
|> Subject: CRCs
|> 
|> 
|> 
|> 
|> Dear colleagues,
|> 
|> We will probably not be able to finish the CRC/checksum 
|> document in time
|> for Nashua but we hope it will be out very soon after that.   
|> However I
|> would like to inform you that while in Orlando and 
|> Minneapolis we where
|> still talking about different CRCs we (Dafna Sheinwald, Pat 
|> Thaler, Matt
|> Wakeley, Vince Cavanna and myself) have agreed on a CRC and 
|> the forthcoming
|> ID will give all the reasons and why we recomend it.
|> 
|> Regards,
|> Julo
|> 
|
|---------------------------------------------------------------
|-------------
|-
|
|-----Original Message-----
|From: Randall Stewart [mailto:[email-masked]]
|Sent: Tuesday, April 17, 2001 4:31 AM
|To: Jonathan Wood
|Cc: [email-masked]; [email-masked]; Jim Wendt; Jonathan Stone; Craig
|Partridge
|Subject: Re: [Tsvwg] [SCTP checksum problems]
|
|
|Jonathan:
|
|I will make sure everyone at the bakeoff is aware of the upcoming
|"checksum" change... Now one of the big questions yet is
|what checksum should we use?
|
|I kinda lean towards crc-32 myself (but of course I have no technical
|basis for this and need to keep silent on which one to use anyway :->),
|but do we have other candidates besides fletcher-32 and possibly
|modified 
|Adler-32 (i.e. 16 bit adds instead of 8)??
|
|I will take the above 3 and do a bit of performance work this
|week and post some numbers... thats about all I can do i.e.  tell
|how much time the options I know of take... 
|
|If you have some other candidates let me know and I can possibly get
|some performance numbers on these as well...
|
|As far as which is the best... I encourage all of you check-sum
|experts out there to please join the thread :)
|
|Oh, I know Jonathan Stone's paper will NOT be ready until sometime
|in May.. so we may want to proceed slowly so that Craig Partridge and
|he can have some cycles to add to this dicussion :)
|
|R
|
|Jonathan Wood wrote:
|> 
|> As an SCTP implementor and someone who will want to get the 
|hardware folks
|to
|> help with checksumming, I wholeheartedly agree with Randy. 
|Remember that
|SCTP is
|> just a proposed standard, and is as such not all that far along the
|> standardization process. We should still be able to make 
|changes like this
|if
|> necessary.
|> 
|> Jon
|> 
|> >
|> >Q:
|> >
|> >The only problem with an additional "CRC chunk" is that
|> >it makes hardware assistance to error correction much
|> >more difficult. It is better (I think) to just realize
|> >we made a mistake. Get the opinions of the experts as to
|> >what checksum to use... i.e.:
|> >
|> >- CRC-32
|> >- Modified Adler-32 (16 bit word sums)
|> >- Fletcher-32
|> >- ???
|> >
|> >And then go with this as a replacement... Admit we were wrong
|> >and fix the problem..
|> >
|> >This way you have ONE and only ONE checksum algorithm making
|> >hardware designers life much easier...
|> >
|> >R
|> >
|> >Qiaobing Xie wrote:
|> >>
|> >> Another solution could be (I think I mentioned this to 
|Randy and a few
|> >> others at last IETF):
|> >>
|> >> - Define a CRC-32 (or other strong checksum) control 
|chunk and when the
|> >> sender wishes to use a stronger checksum protection, in 
|addition to the
|> >> Adler-32 in the common SCTP header it includes this 
|CRC-32 chuck in the
|> >> outbound packet. When the packet arrives, the receiver will do the
|> >> Adler-32 first, and then if the receiver supports the 
|CRC-32 and sees
|> >> the presence of the CRC-32 chunk in the packet it will 
|further verify
|> >> the CRC-32.
|> >>
|> >> We could also use a bit pattern in the chunk type of the 
|CRC-32 chunk
|so
|> >> that if the receiver doesn't understand the CRC-32 chunk 
|it would drop
|> >> it with a report back to the sender.
|> >>
|> >> -Qiaobing
|> >>
|> >> _______________________________________________
|> >> tsvwg mailing list
|> >> [email-masked]
|> >> http://www1.ietf.org/mailman/listinfo/tsvwg
|> >
|> >--
|> >Randall R. Stewart
|> >Systems & Solutions Engineering
|> >Cisco Systems Inc.
|> >[email-masked] 815-342-5222 or 815-477-2127
|> >
|> >_______________________________________________
|> >tsvwg mailing list
|> >[email-masked]
|> >http://www1.ietf.org/mailman/listinfo/tsvwg
|
|-- 
|Randall R. Stewart
|Systems & Solutions Engineering
|Cisco Systems Inc.
[email-masked] 815-342-5222 or 815-477-2127
|
|> 
|

---

From: Stephen Bailey <[email-masked]>
Date: Wed, 18 Apr 2001 18:09:02 -0400

Vince,

> any reliability guarantees the transport protocol makes.

Any protection provided against this failure mode will only be
transient, so we must temper the desire to introduce such a
requirement with reality.

Middleboxes can just as easily open up to the iSCSI layer and tinker
with the payload, as they do with other ULPs running on TCP (e.g HTTP)
today.  Short of securing the connection, there is ALWAYS a
possibility of a middlebox terminating and reoriginating an integrity
check.  In case you think this is a farfetched scenario, I do get the
impression that there is a high level of interest in `actively
middling' iSCSI once the specs crystalize.  Who shaves the barber?

An integrity check is not necessary as long as some lower layer
provides adequate integrity guarantees.

Adding an integrity check above the transport layer is based upon
documentation of the presence of a lot of crappy network hardware and
software and analyses of the transport integrity check (TCP checksum)
which suggests it might not be adequately strong against some such
observed errors.

I claim that the high incidence of `broken' (corruption introducing)
components is a result of a variety of factors which have shaped the
development of network components thus far.  The fact that integrity
checks are assumed to be performed in a network context substantially
lowers the bar for implementation correctness.

In a storage (or CPU) context, these types of implementation errors
are a) more easily detectable (more fatal) b) more carefully avoided
during implementation (because of the cost of a potential fatal
error).  If network components magically reached the same `quality
level' as storage and CPU components, there might be no justification
for additional integrity checks above the transport.  Similarly if the
transport (or whatever lower layer) integrity checks are very strong
(e.g. IPSec), there is, again, no need for a higher level integrity
check.

I am not disagreeing that we need an additional integrity check over
TCP in the present target environment, but I do disagree that iSCSI
will always need such a check, independently of what is running
beneath it.

Steph

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 19 Apr 2001 12:29:27 +0100 (BST)

> provides adequate integrity guarantees.

That is the complete antithesis of the end-to-end argument. And you
earlier discussed middleboxes, where the information needed for such
guarantees can be faked...

Reality check, please.

L.

iSCSI. iNSANE.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 19 Apr 2001 05:49:57 -0700

Lloyd,

I am aware of efforts to compare CRC with Alder-32.  CRC that is primarily
aimed at providing burst error detection but if while trying various
techniques, this modification may be interesting.

  #define BASE 65521
  unsigned s1 = 0x5555;
  unsigned s2 = 0;
  unsigned short dat_buf*

  while (length -= 2)
    {
    s1 += ntoh(*dat_buf++);  /* 16 bit summing */
    s2 += s1;
    if (s2 >= BASE)          /* Adler modulo for s2 only  */
      s2 -= BASE;
    }
  return (s2 << 16) | (s1 & 0xffff);

This would exercise more bits for small packets, improve burst error
sensitivity and trade a modulo function for a network to host swap in some
cases.  It seems to become a comparison against burst errors vs. missing
segment and stuck bit sensitivity.

The alternative code for CRC would look something like this.

Here is an example using a 256 entry (512 byte) table.

  unsigned char* dat_buf;
  unsigned long crc_syn = 0xffffffff;

  while(length--)
    crc_syn = (crc_syn >> 8) ^ crc32_table[(crc_syn & 0xff) ^ *dat_buf++];

  return (crc_syn ^ 0xffffffff);

Doug

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 19 Apr 2001 11:47:31 -0700

All,

A few corrections to this post.

   #define BASE 65521
   unsigned short s1 = 0x5555;
   unsigned s2 = 0;
   unsigned short dat_buf*

   while (length -= 2)
     {
   return (s2 << 16) s1 );

The 32 bit CRC table for an 8 bit lookup would be 1k byte in size and not
512 bytes.

---

From: Stephen Bailey <[email-masked]>
Date: Mon, 23 Apr 2001 09:15:30 -0400

Lloyd,

Thanks for your input.

> Reality check, please.

Is your point that no protocol should ever assume that there's an
end-to-end integrity check operating at some layer below it?

The point of the iSCSI integrity check is not that to assume that
underlying layers (the transport and/or security & integrity) have
abdicated responsibility for end-to-end integrity.  It is a trust, but
verify model.  In a suitably trustworthy [or suitably devious]
environment you're wasting your time verifying.

Steph

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 23 Apr 2001 15:43:21 +0100 (BST)

> end-to-end integrity check operating at some layer below it?

No. (How can an *end-to-end* integrity check operate at a lower
layer?)

> abdicated responsibility for end-to-end integrity. 

I've spent several minutes trying to parse your sentence and its
opposed negatives. I don't think that sentence means whatever you
think it means.

> It is a trust, but verify model.  In a suitably trustworthy [or
> suitably devious] environment you're wasting your time verifying.

In a *perfectly* trustworthy or *perfectly* devious environment that
might be the case. But environments are not perfect - and they change,
too.

So, always verify.

L.