Subject: [Ips] Re-sending a command

From: "Eddy Quicksall" <[email-masked]>
Date: Wed, 9 Aug 2006 18:34:15 -0400

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-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: Julian Satran <[email-masked]>
Date: Thu, 10 Aug 2006 09:22:13 +0300

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-masked]> 
10/08/06 01:34

To
<[email-masked]>
cc
Amit Kumar <[email-masked]>
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-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 10 Aug 2006 06:57:19 -0400

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-masked] 
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-masked] ; 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-masked]> 
        10/08/06 01:34 
       To <[email-masked]>  
              cc Amit Kumar <[email-masked]>  
              Subject [Ips] Re-sending a command 

    
    
  Does anyone know? 

------------------------------------------------------------------------------

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 16 Aug 2006 22:39:06 -0700 (PDT)

Sorry, I am catching up late on this thread.

LU reset actually does not by itself plug the holes
since it is not a target-scoped request like warm &
cold resets.  

OTOH, as Ken illustrated in his example, whenever a
TMF Response with an ExpCmdSN larger than the
timed-out command is sent by the target, the timed-out
command is implicitly acknowledged and the left edge
of the CmdSN window has advanced beyond that of
timed-out command.  RFC 3720 is sufficiently explicit
on that point.

Mallikarjun

--- Julian Satran <[email-masked]> wrote:

> "Eddy Quicksall"
> <[email-masked]> 
> 10/08/06 01:34
> 
> To
> <[email-masked]>
> cc

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Julian Satran <[email-masked]>
Date: Thu, 17 Aug 2006 09:12:07 +0300

The effect of ExpCmdSN is the same as plugging in the holes.
I have a hard time understanding how an LU reset can be executed in the 
presence of hole - as the target has no way knowing if the commands in the 
"holes" refer to the LU being reset or to some other LU. So IMHO from the 
POV of the LU in question no command preceding the LU reset can be resent 
- i.e., the effect is like the holes are plugged for the unit on which an 
LU reset was sent and the initiator should not send any after the LU 
reset.

Julo

"Mallikarjun C." <[email-masked]> 
17/08/06 08:39

To
[email-masked]
cc

Subject
Re: [Ips] Re-sending a command

Mallikarjun

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 17 Aug 2006 15:29:23 -0700 (PDT)

Julian, you're right that LU reset cannot be executed
in the presence of holes, and that's consistent with
what I was pointing out.  I was clarifying that an LU
reset automatically does not plug holes as either
flavor of target reset does (the target must wait for
all commands to arrive with LU reset).  So I guess we
are saying the same thing.

Mallikarjun

--- Julian Satran <[email-masked]> wrote:

> > it Mallikarjun may want to mention that dropping
> the
> > command is the 
> > 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