Subject: [Ips] CmdSn in login request

From: [email-masked]
Date: Mon, 6 Jun 2005 11:33:16 -0400

10.12 says:

"Login Requests are always considered as immediate."

and

10.12.8 says:

"CmdSN is either the initial command sequence number of a session (for ... 
the "leading" login), or the command sequence number in the command stream 
if the login is for a new connection in an existing session."

So what happens if the last command prior to a multi-connection login was 
lost?  In this example: 3 connections exist between the initiator and the 
target.   Initiator sends CmdSn 0x3F on a connection which fails at the 
target.  (The TCP connection fails, for whatever reason.)  After the 
appropriate timeout, the initiator attempts a recovery login using CmdSN 
0x40 -since it doesn't know what happened to the command with CmdSn 0x3F. 
The target accepts the login, which is handled as an immediate, but 
responds with ExpCmdSn of 0x3F,  since that's the current session-wide 
ExpCmdSn.

This seems to be one of those CmdSn 'holes' which gets talked about. 

Is (a) the initiator required to send a command with CmdSn of 0x3F to plug 
the hole?  OR  (b) is the target expected to recognize the hole due to 
login and use the new CmdSn (0x40) as it's new ExpCmdSn?  OR is there a 
(c)?

As a target implementer I'd like to think (a), but maybe I'm just being 
selfish.

Incidentally, the initiator may try a task reassignment giving the ITT of 
the task with CmdSn 0x3F, to which the target would reply '01 - task does 
not exist.'

thanks,

david 

David J Cuddihy, Principal Engineer 
ATTO Technology, Inc. 
http://www.attotech.com/bridge.html 
_______________________________________________
Ips mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ips

---

From: William Studenmund <[email-masked]>
Date: Mon, 6 Jun 2005 10:32:48 -0700

On Jun 6, 2005, at 8:33 AM, [email-masked] wrote:

> "CmdSN is either the initial command sequence number of a session (for 
> ... the "leading" login), or the command sequence number in the 
> command stream if the login is for a new connection in an existing 
> session."
>
> So what happens if the last command prior to a multi-connection login 
> was lost?  In this example: 3 connections exist between the initiator 
> and the target.   Initiator sends CmdSn 0x3F on a connection which 
> fails at the target.  (The TCP connection fails, for whatever reason.) 
>  After the appropriate timeout, the initiator attempts a recovery 
> login using CmdSN 0x40 -since it doesn't know what happened to the 
> command with CmdSn 0x3F.  The target accepts the login, which is 
> handled as an immediate, but responds with ExpCmdSn of 0x3F,  since 
> that's the current session-wide ExpCmdSn.
>

Yep.

> Is (a) the initiator required to send a command with CmdSn of 0x3F to 
> plug the hole?  OR  (b) is the target expected to recognize the hole 
> due to login and use the new CmdSn (0x40) as it's new ExpCmdSn?  OR is 
> there a (c)?

Yes, (a). It's the same thing as if a header digest were bad; the 
initiator has to plug the hole.

> As a target implementer I'd like to think (a), but maybe I'm just 
> being selfish.
>
> Incidentally, the initiator may try a task reassignment giving the ITT 
> of the task with CmdSn 0x3F, to which the target would reply '01 - 
> task does not exist.'

Actually you are not correct in the above. Assuming the CmdSN of 0x3f 
is still in-window for the session, 10.6.1 section (b) (page 135 of RFC 
3720) indicates that the target can consider that CmdSN received and 
completed. ExpCmdSN now moves on to the next value, and any delayed 
commands (non-immediate 0x40, non-immediate 0x41, etc.) are processed.

Take care.

Bill

---

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 07 Jun 2005 12:53:43 -0700

>> plug the hole?

As Bill said, (a) is correct - the hole should eventually be plugged due 
to initiator action (but not necessarily with a new command, an abort 
task will do just as well).

 >> of the task with CmdSn 0x3F, to which the target would reply '01 -

Yes for the task reassignment TMF (although if the initiator was told 
that the ExpCmdSN is 0x3f, it really shouldn't issue one).  I think Bill 
was assuming abort task in his response.

Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
StorageWorks Division
Hewlett-Packard MS 5668
Roseville CA 95747
cbm [at] rose.hp.com

William Studenmund wrote:
> Actually you are not correct in the above. Assuming the CmdSN of 0x3f is 
> still in-window for the session, 10.6.1 section (b) (page 135 of RFC

---

From: William Studenmund <[email-masked]>
Date: Tue, 7 Jun 2005 16:38:09 -0700

On Jun 7, 2005, at 12:53 PM, Mallikarjun C. wrote:

> that the ExpCmdSN is 0x3f, it really shouldn't issue one).  I think 
> Bill was assuming abort task in his response.

Yes, sorry about that. If it is a reassignment, then it should give the 
"task does not exist" response.

Take care,

Bill