Subject: RE: [Ips] Target Behavior Clarifications

From: <[email-masked]>
Date: Tue, 18 Apr 2006 13:10:46 -0500

Based on the responses from Bill and Julian this is what I have:

1) What should the behavior of a target be if it receives a PDU on a
connection, larger than what it declared with MaxRecvDataSegmentLength:

- If the PDU is part of a SCSI command? 

<JC> I will drop the connection and terminate the task and generate a UA
with ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY ISCSI
PROTOCOL EVENT". If this is only connection in the session then I
generate a UA (06/29/00).

- If the PDU is part of a login?

<JC> I will drop the connection. Agreed that the default value of 8K
should be supported since login is not complete.

2) What should the target behavior be if the initiator sends it more
data than MaxBurstLength?

3) What should the target behavior be if the initiator sends more data
than FirstBurstLength?

<JC> I have two options here: 

a)    As per the spec: The target reports the "Incorrect amount of data"
condition if during data output the total data length to output is
greater than FirstBurstLength and the initiator sent unsolicited
non-immediate data but the total amount of unsolicited data is different
than FirstBurstLength. The target reports the same error when the amount
of data sent as a reply to an R2T does not match the amount requested.
(0B/0C/0D - Write Error, Incorrect Amount of Data). This should work.

The only issue here is that the definition of the sense code does not
match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR - NOT
ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says.

b)    Treat this as a really bad error and assume that I have an
initiator that does not play well and drop the session and kill the
command.

I am leaning towards (b). Help!!! Suggestions/Comments/Discussion.

Thanks, 
  
Jacob Cherian 
Dell Inc. 
Ph: (512) 723 3247 

________________________________

From: William Studenmund [mailto:[email-masked]] 
Sent: Tuesday, April 18, 2006 12:33 PM
To: Cherian, Jacob
Cc: [email-masked]
Subject: Re: [Ips] Target Behavior Clarifications

On Apr 17, 2006, at 2:48 PM, <[email-masked]>
<[email-masked]> wrote:

A couple of quick questions?

1) What should the behavior of a target be if it receives a PDU on a
connection, larger than what it declared with MaxRecvDataSegmentLength:

- If the PDU is part of a SCSI command? 

- If the PDU is part of a login?

Drop the connection. Note, the session may still stick around as part of
recovery processing.

Also, during login (before FFP), the MaxRecvDataSegmentLength in force
is 8k, regardless of announced values.

2) What should the target behaviour be if the initiator sends it more
data than MaxBurstLength?

3) What should the target behavior be if the initiator sends more data
than FirstBurstLength?

There are specific sense and ASC/Q values for these errors.

These are treated as SCSI errors 1) because you have to give some
explanation for why you killed the SCSI task, and 2) because it is not
obvious which PDU in the burst was "too much." While you might want to
say it was the last one, that isn't necessarily true.

Note also that to trigger these errors, all the data placement had to
stay within the TTT bounds and you have to be in DataPDUInOrder=No.
That's the only way you can really write the same area twice. Most other
errors involved in sending too much data in a burst would trigger an
iSCSI protocol error by placing data outside the bounds of the TTT.

Take care,

Bill

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

---

From: Julian Satran <[email-masked]>
Date: Tue, 18 Apr 2006 22:28:45 +0300

<[email-masked]> wrote on 18/04/2006 21:10:46:

> <JC> I will drop the connection and terminate the task and generate 
> a UA with ASC/ASCQ value of 47h/7Fh - "SOME COMMANDS CLEARED BY 
> ISCSI PROTOCOL EVENT". If this is only connection in the session 
> then I generate a UA (06/29/00).
> 2) What should the target behavior be if the initiator sends it moredata 
than
> MaxBurstLength?
than 
> FirstBurstLength?
> a)    As per the spec: The target reports the "Incorrect amount of 
> data" condition if during data output the total data length to 
> output is greater than FirstBurstLength and the initiator sent 
> unsolicited non-immediate data but the total amount of unsolicited 
> data is different than FirstBurstLength. The target reports the same
> error when the amount of data sent as a reply to an R2T does not 
> match the amount requested. (0B/0C/0D ? Write Error, Incorrect 
> Amount of Data). This should work.
> 
> The only issue here is that the definition of the sense code does 
> not match the definition in SPC-3 which says 0Ch 0Dh - WRITE ERROR -
> NOT ENOUGH UNSOLICITED DATA), which is not quite what the iSCSI says.
> 
> 
command.
That's what I would do too 
> On Apr 17, 2006, at 2:48 PM, <[email-masked]> 
<[email-masked]
> > wrote:

> Drop the connection. Note, the session may still stick around as 
> part of recovery processing.
> 
> Also, during login (before FFP), the MaxRecvDataSegmentLength in 
> force is 8k, regardless of announced values.
> 

> 2) What should the target behaviour be if the initiator sends it 
> more data than MaxBurstLength?
than 
> FirstBurstLength?
> explanation for why you killed the SCSI task, and 2) because it is 
> not obvious which PDU in the burst was "too much." While you might 
> want to say it was the last one, that isn't necessarily true.
> 
> Note also that to trigger these errors, all the data placement had 
> to stay within the TTT bounds and you have to be in 
> DataPDUInOrder=No. That's the only way you can really write the same
> area twice. Most other errors involved in sending too much data in a
> burst would trigger an iSCSI protocol error by placing data outside 
> the bounds of the TTT.
> 
> Take care,
> 
> Bill_______________________________________________
> Ips mailing list
> [email-masked]