Re: iSCSI error recovery

[Mark Bakke <mbakke@cisco.com>]

Quite right.  Not only that, but the other reason for separating
the header and data CRCs is to make at least the data CRC end-to-end
when an iSCSI proxy or gateway is in the middle.

--
Mark

Matt Wakeley wrote:
> 
> Black_David@emc.com wrote:
> 
> > - Given some of the CRC discussion, I think the conclusion
> >         in Orlando to have separate header and data CRCs is
> >         NOT the rough consensus of the WG.  We need to go
> >         back to a requirements discussion on this rather than
> >         debating exactly where to put the CRCs.  Would those
> >         envisioning middleboxes/gateways/etc. that would
> >         benefit from this sort of CRC separation please post
> >         short use cases/descriptions indicating the basic
> >         functionality of the box and which fields it needs
> >         to change (let's do this with reference to the header
> >         layout in -03 rather than subsequent changes)?  As
> >         part of the use case/description, please explain
> >         how/why Fibre Channel's single CRC covering both
> >         the frame header and data causes problems/difficulties.
> 
> David,
> 
> The use of a separate header/data CRC is required in order to perform
> efficient data steering.  If the iSCSI header and data are both protected by
> the same CRC (which for efficiencies in transmission would be after the data),
> then an iSCSI adapter would have to buffer up an entire iSCSI PDU before it
> could begin DMAing the PDU payload to host memory (because it could not
> guarantee that the information in the iSCSI header was correct to begin DMAing
> it earlier).  Since Julian insists that PDUs could be in lengths requiring 32
> bit length fields, this is a lot of unnecessary storage.
> 
> -Matt Wakeley
> Agilent Technologies

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054