Subject: RE: Coverage of Data Digest when using Header Digests

From: [email-masked]
Date: Mon, 22 Jan 2001 17:59:55 +0200

yes,

Julo

"Barry Reinhold" <[email-masked]> on 22/01/2001 17:49:29

Please respond to "Barry Reinhold" <[email-masked]>

To:   [email-masked], Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 22, 2001 10:22 AM
To: [email-masked]
Cc: [email-masked]; 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

[email-masked] 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" <[email-masked]> on 21/01/2001 21:50:04
>
> Please respond to "Barry Reinhold" <[email-masked]>
>
> 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
[email-masked]
763.398.1054

---

From: Matt Wakeley <[email-masked]>
Date: Tue, 23 Jan 2001 13:16:17 -0800

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

---

From: Mark Bakke <[email-masked]>
Date: Tue, 23 Jan 2001 16:50:34 -0600

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

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

---

From: "Douglas Otis" <[email-masked]>
Date: Tue, 23 Jan 2001 17:00:19 -0800

Mark,

By removing the CDB from the header, perhaps FCIP, iFCP and iSCSI could
converge on a common header structure after all for a common encapsulation.
The SCSI portion could be defined to contain the same information as FCP.

Doug

---

From: "Venkat Rangan" <[email-masked]>
Date: Wed, 24 Jan 2001 08:18:29 -0800

We agree with the proposed changes as well.

On the "optional" open issue, we would like to have two bits in the flags
portion of the header which indicates whether digests are present or not.

The digests should be "mandatory" for implementation and "optional" for
deployment with "ON" as the default.

Venkat Rangan
Rhapsody Networks Inc.
http://www.rhapsodynetworks.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mark Bakke
Sent: Tuesday, January 23, 2001 2:51 PM
To: Matt Wakeley
Cc: [email-masked]
Subject: Re: iSCSI: remove CDB from iSCSI header

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

81 - SCSI Response
91 - Asynchronous Event

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

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

??? 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

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