RE: [IPS - iSCSI] Command retry

[pat_thaler@agilent.com]

The target nver received the command with CmdSN 2. Therefore ExpCmdSN is 2 (assuming that it doesn't have any earlier holes).

 

The initiator retransmits (either because of a time out or because it sees ExpCmdSN is still 2). That isn't a protocol violation. 3.2.2.1 says "For non-immediate commands, the CmdSN field can take any value from ExpCmdSN to MaxCmdSN inclusive. The target MUST silently ignore any no-immediate commands outside of this range or any non-immediate duplicates within the range."

 

CmdSN 2 is inside the range and it is not a duplicate since the original transmission of that command was dropped. Therefore, it is a valid command which can be acted upon. It doesn't matter that it arrived on the connection before the command with CmdSN 3.

 

Regards,

Pat

-----Original Message-----
From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org]On Behalf Of Lakshmi Ramasubramanian
Sent: Thursday, 09 September, 2004 3:47 PM
To: ips@ietf.org
Cc: Chris Robinson
Subject: [IPS - iSCSI] Command retry

Assume there are 2 connections in a session - A and B, and ERL is 2.

 

- Initiator sends a command with CmdSN 2 over A and a command with CmdSN 3 over B.

 

- Target detects Header Digest upon receiving the command over A and it wants that connection to be closed.

 

- Initiator reassigns the command with CmdSN 2 to connection B now. Target is going to reject this Task Reassign command  

  since it never really saw CmdSN 2. But it sees a command with lower CmdSN (2) on B when it has already received

  CmdSN 3 on B. It results in protocol violation.

 

How should the intiator reassign the CmdSN 2 command in the above scenario? What is the right behavior in this case?

 

thanks,

 -lakshmi

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips