Subject: [Ips] iscsi: More immediate data than required data

From: "Barada Mishra" <[email-masked]>
Date: Thu, 25 Jan 2007 13:08:09 -0800

Hi,

This question is from a iSCSI target point of view.

When a target receives more immediate data than the required data, what
should be the behavior?

Example :
Assume the target receives a write command for 2 blocks (1024 bytes).
But the associated immediate data it receives is 2048.

What should the target do
  1. Use only 1024 bytes, ignore the rest of data and return good status
  2. Return check condition (what should be the ASC/ASCQ)?
  3. Drop the connection and/or session
  4. Reject the PDU
Or something else?

Thanks
Barada
_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Julian Satran <[email-masked]>
Date: Fri, 26 Jan 2007 10:16:40 +0200

If you are talking about a discrepancy between the CDB indicated length in 
blocks and the total data length (including immediate) indicated by iSCSI 
(originated from SCSI) this is legal and the result will include a 
residula lenngth and an "underflow" (device needs more data than 
accomodated by SCSI buffer). The specific command set indicates how the 
blocks on the device will be filled (padded).

If you are talking about Immediate data exceeeding iSCSI total data length 
(originated from SCSI)  that is a protocol error and should be handled 
accordingly.
The command should be rejected and dropping the session depends on the 
leniency of the target.

Julo

"Barada Mishra" <[email-masked]> 
25/01/07 23:08

To
[email-masked]
cc

Subject
[Ips] iscsi: More immediate data than required data

Hi,

Example :

Thanks
Barada

---

From: Joel Buckley <[email-masked]>
Date: Fri, 26 Jan 2007 09:16:48 -0700

Barada,

The response depends on where 1024 vs. 2048 bytes are encoded...

If SCSI WRITE(10) TransferLength is set to 2 (512 Blocks) and
iSCSI SCSI Command PDU DataSegmentLength is set to 2048,
then all 2048 bytes SHALL be read by iSCSI Target and only the
first 1024 bytes SHALL be utilized by SCSI Target.

If SCSI WRITE(10) TransferLength is set to 2 (512 Blocks) and
iSCSI SCSI Command PDU DataSegmentLength is set to 1024,
then all 1024 bytes SHALL be read by iSCSI Target and all1024
bytes SHALL be utilized by SCSI Target.

In either case, the iSCSI Target SHALL expect the next iSCSI
PDU to begin immediately after the last...  So if an additional 1024
bytes of unknown data are appended to a PDU, then results are
indeterminate.  The unknown data may be evaluated as another
iSCSI PDU or may be seen as a data corruption on the connection.
If the data is seen as a data corruption, then iSCSI ERROR
RECOVERY LEVEL protocols SHALL be followed.

Cheers,
Joel.

[email-masked]
JIST Development Lead
303-272-5556, x75556
"Luck is a Planned Event."

----- Original Message -----
From: Barada Mishra <[email-masked]>
Date: Thursday, January 25, 2007 2:10 pm
Subject: [Ips] iscsi: More immediate data than required data
To: [email-masked]

> When a target receives more immediate data than the required data, 
> whatshould be the behavior?
> 
> Example :
>  1. Use only 1024 bytes, ignore the rest of data and return good 
> status  2. Return check condition (what should be the ASC/ASCQ)?

---

From: Paul Koning <[email-masked]>
Date: Fri, 26 Jan 2007 12:22:17 -0500

>>>>> "Joel" == Joel Buckley <[email-masked]> writes:

 Joel> Barada, The response depends on where 1024 vs. 2048 bytes are
 Joel> encoded...

 Joel> If SCSI WRITE(10) TransferLength is set to 2 (512 Blocks) and
 Joel> iSCSI SCSI Command PDU DataSegmentLength is set to 2048, then
 Joel> all 2048 bytes SHALL be read by iSCSI Target and only the first
 Joel> 1024 bytes SHALL be utilized by SCSI Target.

I can't imagine any reason why an initiator would do such a thing, and
I'd prefer to call it an error, but if SCSI requires this sort of
thing to be permitted, then I guess that's how it goes.

 Joel> If SCSI WRITE(10) TransferLength is set to 2 (512 Blocks) and
 Joel> iSCSI SCSI Command PDU DataSegmentLength is set to 1024, then
 Joel> all 1024 bytes SHALL be read by iSCSI Target and all1024 bytes
 Joel> SHALL be utilized by SCSI Target.

That's the normal case.

 Joel> In either case, the iSCSI Target SHALL expect the next iSCSI
 Joel> PDU to begin immediately after the last...  So if an additional
 Joel> 1024 bytes of unknown data are appended to a PDU, then results
 Joel> are indeterminate.  The unknown data may be evaluated as
 Joel> another iSCSI PDU or may be seen as a data corruption on the
 Joel> connection.  If the data is seen as a data corruption, then
 Joel> iSCSI ERROR RECOVERY LEVEL protocols SHALL be followed.

That's a third case.  What you're describing is a case where there is
junk in the middle of the iSCSI protocol data stream that isn't
described by any headers, it isn't claimed to be payload.  If so, it
obviously will be seen as another iSCSI PDU header, with whatever
consequences that implies.  Obviously, such a thing cannot ever be
valid -- but depending on the contents of the junk it may or may not
be detected.

   paul