Re: iSCSI: remove CDB from iSCSI header

[julian_satran@il.ibm.com]

It is nice and neat... and we went over it, discussed at length in the past
and rejected because commands are the most frequent outgoing message and
you want them handled in one operation at
target (initiator is easy). And 16 byte CDBs cover most of the commands.
We expect also Data Base operations with data lengths of 4-8kbytes to be
done using immediate data
and reducing the number of operations to implement them is critically
important.

On the other hand the CDB extensions and other field could go with the data
(as they are not modified by any proxy)  and we could keep header digest
strictly for the first 48 bytes.   I am not so much concerned about having
to compute a CRC on the variable header as much as by the thought that if
you keep a digest after the 48 bytes for commands with longer CDBs but no
immediate data you will have a digest after 48 bytes and another one after
the extension.

Julo

Mark Bakke <mbakke@cisco.com> on 24/01/2001 00:50:34

Please respond to Mark Bakke <mbakke@cisco.com>

To:   Matt Wakeley <matt_wakeley@agilent.com>
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI: remove CDB from iSCSI header





I agree with Matt.  Basically, then, the iSCSI header digest should cover
everything in the first 48 bytes.  All of the messages, with the exception
of the SCSI Command Request, could easily be done this way, and I think
that we should modify that to fit Matt's idea of treating the CDB (and
sense data) the same as SCSI data for digest purposes.

Here's what they would all look like:

01 - SCSI Command Request

The iSCSI header digest currently covers the 48-byte iSCSI header,
which includes the CDB.

The data digest covers everything else, which includes extended CDB,
bidi-read transfer length, and immediate data.

Since the command request is the only operation that really breaks
the notion of Matt's model, I would suggest that we start the CDB
after the 48-byte iSCSI header, and that it not be covered by the
header digest.  We can move the bidi-read length inside the iSCSI
header, and end up with:

  +----------------------------------------------------
 0| Normal iSCSI header stuff for command request
  +----------------------------------------------------
32| Bidi-read length
  +--------------------------------------------------
36/ Reserved
 +/
  +---------------------------------------------------
  | (optional header digest goes here)
  +-------------------------------------------------
48| CDB
  +--------------------------------------------------
  | Additional CDB
  +---------------------------------------------------
  | Immediate Data
  +----------------------------------------------------
  | (optional data digest goes here)
  +-----------------------------------------------------

The header digest would cover the first 48 bytes, and would exactly
match the rest of the iSCSI operations.  The data digest would include
the CDB (now contiguous with the additional CDB, as an added bonus)
and the immediate data.  Anyone concerned with having a separate
data integrity check for just the data when an additional CDB is
being used should refrain from using the immediate data feature.

While we are on the topic, is anyone really planning to make use of
bidi-read
and immediate data?


Here is my understanding of what the digests cover with the remainder
of the iSCSI operations:

81 - SCSI Response
91 - Asynchronous Event

iSCSI header digest covers 48-byte iSCSI header
iSCSI data digest covers the sense data, if present

02 - Task management command
82 - Task management response
06 - Logout command
86 - Logout response
90 - R2T

iSCSI header digest covers 48-byte header
no data, so no data digest present

05 - SCSI Data write
85 - SCSI Data read
00 - NOP-Out
80 - NOP-In

iSCSI header digest covers 48-byte header
iSCSI data digest covers the data

04 - Text command
84 - Text response
03 - Login command
83 - Login response

iSCSI header digest covers 48-byte iSCSI header
iSCSI data digest covers the text parameters

??? Should the text be padded to a 4-byte boundary before adding the data
CRC?
I think that it already says so somewhere in the spec.

--
Mark

Matt Wakeley wrote:
>
> I don't think I like this.  Header followed by digest followed by more
header.
>
> I think this is a good opportunity to think about removing the CDB from
the
> header.  This will reduce the amount of dead space used by headers that
do not
> contain a CDB.  This will be beneficial when sending multiple smaller
PDUs (in
> order to keep the CRC coverage high) by reducing the iSCSI header
overhead.
>
> Change the iSCSI command so that there is an iSCSI header (verified by
the
> header digest) followed by CDB "payload" (verified by the data digest).
No
> options for immediate data.  Keep it simple, like it is in Fibre Channel.
>
> -Matt Wakeley
> Agilent Technologies
>
> julian_satran@il.ibm.com wrote:
> >
> > yes,
> >
> > Julo
> >
> > "Barry Reinhold" <bbrtrebia@mediaone.net> on 22/01/2001 17:49:29
> >
> > Please respond to "Barry Reinhold" <bbrtrebia@mediaone.net>
> >
> > To:   mbakke@cisco.com, Julian Satran/Haifa/IBM@IBMIL
> > cc:   ips@ece.cmu.edu
> > Subject:  RE: Coverage of Data Digest when using Header Digests
> >
> > Ok,
> >      So if the bidi-read length and ADDCDB fields are not in the data
> > digest
> > then I assume we have to figure them into the header digest even though
> > they
> > are located past the header digets. Is that the expected behavior?
> >
> > -----Original Message-----
> > From: mbakke@cisco.com [mailto:mbakke@cisco.com]
> > Sent: Monday, January 22, 2001 10:22 AM
> > To: julian_satran@il.ibm.com
> > Cc: ips@ece.cmu.edu; Barry Reinhold
> > Subject: Re: Coverage of Data Digest when using Header Digests
> >
> > Barry-
> >
> > In particular, the data digest covers only the SCSI Data part of an
> > iSCSI message; the header digest covers everything else.  This means
> > that in an 8k write, the data digest will cover only the 8k, and the
> > header digest will cover everything else.
> >
> > Hope this helps,
> >
> > Mark
> >
> > julian_satran@il.ibm.com wrote:
> > >
> > > Barry,
> > >
> > > Considering that one of the reasons to have a separate header and
data
> > > digest was to enable data
> > > to carried through proxies, virtualizers etc. the current thinking is
> > that
> > > the data digest will cover only the data and the header (including
> > > extensions) will be covered by the header digest.
> > >
> > > Julo
> > >
> > > "Barry Reinhold" <bbrtrebia@mediaone.net> on 21/01/2001 21:50:04
> > >
> > > Please respond to "Barry Reinhold" <bbrtrebia@mediaone.net>
> > >
> > > To:   Julian Satran/Haifa/IBM@IBMIL
> > > cc:
> > > Subject:  Coverage of Data Digest when using Header Digests
> > >
> > > Julian,
> > >      Is the Data Digest intended to cover whatever follows the 48
byte
> > > iSCSI
> > > header? In particular in a command frame which has a CDB > 16 bytes,
uses
> > > bidi, has immediate data, and is using both header and data digests -
> > what
> > > would the data digest cover?
> > >                                                              - barry
> > > reinhold
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054

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