RE: 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 <mailto:[email protected]>  
To: Eddy Quicksall <mailto:[email protected]>  ;
[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 <mailto:[email protected]>  
	To: Eddy Quicksall
<mailto:[email protected]>  
	Cc: [email protected] ; Amit Kumar <mailto:[email protected]>  
	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