RE: Re-sending a command

Ken,

You are right. Sorry - The reset command should have carried CmdSN 27in 
order to convey unequivocally to what commands it applies.

Thanks,
Julo



"Sandars, Ken" <[email protected]> 
26/09/06 14:02

To
Julian Satran/Haifa/IBM@IBMIL
cc

Subject
RE: [Ips] Re-sending a command






Hey Julo,
 
Shouldn't that be 27?
 
Cheers
Ken ;-)

From: Julian Satran [mailto:[email protected]] 
Sent: Tuesday, 26 September 2006 20:48
To: Ashish Shah (ashishs)
Cc: [email protected]; Amit Kumar; Eddy Quicksall; Arpakorn Boonkongchuen 
(aboonkon)
Subject: RE: [Ips] Re-sending a command


The target behavior is correct. The initiator "misbehaves" in two ways: 
1.             (mild) the rest CmdSN should have been 26 
2.              (hard) it should advance CmdSN to a value inside the 
window after receiving the TM response

Julo 


"Ashish Shah \(ashishs\)" <[email protected]> 
26/09/06 12:11 


To
"Eddy Quicksall" <[email protected]>, Julian 
Satran/Haifa/IBM@IBMIL 
cc
<[email protected]>, "Amit Kumar" <[email protected]>, "Arpakorn 
Boonkongchuen \(aboonkon\)" <[email protected]> 
Subject
RE: [Ips] Re-sending a command








  
I have a question that is a slight variation to this example. 
  
I->T: CmdSN=25 ITT=1 SCSI1 
I->T: CmdSN=26 ITT=2 SCSI1 
<time out period> 
I->T: CmdSN=25 (immediate) ITT=3 TMF - LU Reset 
T->I: ITT=3 ExpCmdSN=27 TMF Response - Function Complete 
I->T: CmdSN=25 ITT=4 SCSI1 
    The target drops the command as it falls outside its expected window. 
  
Note that two commands time out and the initiator is issuing TMF 
(immediate) using the 1st command's Cmd SN. The target is responding with 
ExpCmdSN as 27 (thus acknowledging the completion of both the commands SN 
25 and 26). The initiator still comes back with CmdSN as 25. 
  
Question: Is the target behavior correct ? If it is, according to RFC 3720 
section "3.2.2.1.  Command Numbering and Acknowledging", the initiator 
should update its ExpCmdSN based on the target response. So, is this also 
(same) initiator bug ? The initiator is MS iSCSI initiator. 
  
Appreciate your answers. 
Thanks 
Ashish 

From: Eddy Quicksall [mailto:[email protected]] 
Sent: Thursday, August 10, 2006 3:57 AM
To: Julian Satran
Cc: [email protected]; Amit Kumar
Subject: Re: [Ips] Re-sending a command

Thanks. I have pasted an example from Ken Sanders that is exactly the case 
I have seen when using the Microsoft initiator. The initiator then goes 
into a loop because every time it tries to reset, it sends the command 
again with the old CmdSN which itself causes a timeout and another reset. 
  
Eddy 
 
 
----- Original Message ----- 
From: Sandars, Ken 
To: Eddy Quicksall ; [email protected] 
Sent: Wednesday, August 09, 2006 7:42 PM 
Subject: RE: [Ips] Re-sending a command 

Hi Eddy, 
  
There's some reading between the lines needed, but if this is scenario you 
are describing: 
  
I->T: CmdSN=25 ITT=1 SCSI1 
<time out period> 
I->T: CmdSN=26 (immediate) ITT=2 TMF - LU Reset 
T->I: ITT=2 ExpCmdSN=26 TMF Response - Function Complete 
I->T: CmdSN=25 ITT=1 SCSI1 
  
In this case, the target actions for the TMF - LU Reset will ensure that 
no responses will be sent for the affected commands (including CmdSN=25) 
after the TMF response is sent. 
  
The initiator is in effect (re)sending a command outside the CmdSN window, 
and a working target will discard it. 
  
HTH 
Ken 
----- Original Message ----- 
From: Julian Satran 
To: Eddy Quicksall 
Cc: [email protected] ; Amit Kumar 
Sent: Thursday, August 10, 2006 2:22 AM 
Subject: Re: [Ips] Re-sending a command 


Eddy, 

The LU reset "plugs the holes" in command sequence and the old CmdSN 
should not be used (it is definitely an initiator bug). If you have seen 
it Mallikarjun may want to mention that dropping the command is the 
expected behavior of the target after all the task management commands 
that "plug the holes" in the implementation guide. 

Julo 

"Eddy Quicksall" <[email protected]> 
10/08/06 01:34 


To
<[email protected]> 
cc
Amit Kumar <[email protected]> 
Subject
[Ips] Re-sending a command










It was brought to my attention that one initiator being tested will 
re-issue a "timed out" command using the same CmdSN after it has issued a 
LU Reset. When this happens the command is dropped. Note that this is on a 
single connection session. 
 
I'm wondering if this could be an initiator bug or if there is a case 
where it is actually valid (in the report I have I don't know if the 
initiator also reissued the command with a valid CmdSN or not). 
 
Does anyone know? 
 
Eddy_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips

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

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