Re: Target Behavior Clarifications (with corrections)

On Apr 18, 2006, at 11:15 AM, <[email protected]> wrote:

> 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 all tasks allegiant  
> on that connection 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) since  
> when the session is reestablished there wont be any tasks.
Actually 06/29/00 is wrong. If the initiator gets another connection  
in within Time2Wait + Time2Retain, then you really should be doing an  
06/29/07. The advantage of that is that you could also do the  
06/47/7e after the nexus loss.

To be honest, I think all of this is governed by the standard  
connection recovery procedures. :-)
> - 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.

I'd say go with what the RFC 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!!!
I think (a) is enough. Actually, I think it's not (a) or (b), but (a)  
or (a) and (b); I think you really need to do the processing in (a).  
Even if you slam the session down, there are internal processing  
consequences of (a). :-)

Take care,

Bill

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