Subject: Re: iSCSI Draft 11 Comments and MaxCmdSN rule

From: "Julian Satran" <[email-masked]>
Date: Wed, 6 Mar 2002 09:09:16 +0200

Hasebe-San,

I am looking at the text and I am sorry - I am using Framemaker and the 
paragraph you quoted as appearing twice
does not appear on my text. 

I looked again at the published chapter 2 - and some how the whole chapter 
contains both the INSERTED and DELETED text from versions 10 and 11 
(evidence on page 33 chapter7 and chapter 8).

I will correct the pdf at my site.

As for the second comment - I will fix it in the next text.

Thanks for catching this.
Julo

[email-masked]
Sent by: [email-masked]
06-03-02 08:12
Please respond to y-hasebe

        To:     [email-masked]
        cc: 
        Subject:        iSCSI Draft 11 Comments and MaxCmdSN rule

Julian & All,

I have two comments on the draft 11 file.
(http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-11.pdf)

(1) Editional Comment
  On page 31, This sentence appers twice in this page.
  (Line 3 and Line 20)
 
   "The target MUST NOT transmit a MaxCmdSN that is less than the last
   ExpCmdSN. For non-immediate commands, the CmdSN field can take any
   value from ExpCmdSN to MaxCmdSN. The target MUST silently ignore any
   non-immediate command outside of this range or non-immediate duplicates
   within the range."

(2)MaxCmdSN rule
  I think that this sentence should change as Ayman says.
  This sentence is a confusing expression.

  On Page 31, Line 3
   "The target MUST NOT transmit a MaxCmdSN that is less than the last
   ExpCmdSN. "

                         change to

   "The target MUST NOT transmit a MaxCmdSN that is less than the last
   ExpCmdSN-1. "

-------------------
Yoshihiro Hasebe
NEC Corporation
-------------------

-------------------- Attached Mail -------------------------------

Please consider also carefully the Serial Arithmetic rules with regard to
"lower/higher" and the bounds on the ExpComdSN and MaxCmdSN difference.

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 08-02-02 02:26 -----
  
                    "Ayman Ghanem"  
                    <aghanem@cisco       To:     <[email-masked]>    
                    .com>                cc:  
                    Sent by:             Subject:     RE: iSCSI: MaxCmdSN 
rule 
                    owner-ips@ece.  
                    cmu.edu  

                    08-02-02 00:53  

This sentence should be changed to:

"The target MUST NOT transmit a MaxCmdSN that is less than the last
ExpCmdSN-1"

The paragraph above this states:

"If the PDU MaxCmdSN is less than the PDU ExpCmdSN-1 (in Serial Arithmetic
Sense), they are both ignored."

which allows MaxCmdSN = ExpCmdSN-1,valid, for the case when the target's
command window is closed.

-Ayman

 -----Original Message-----
 From: [email-masked] [mailto:[email-masked]]On Behalf Of
 Buck Landry
 Sent: Thursday, February 07, 2002 2:40 PM
 To: [email-masked]
 Subject: iSCSI: MaxCmdSN rule

 Hi all, I'm struggling over how to interpret this rule in section 1.2.2 
of
 draft v10:

 >>> The target MUST NOT transmit a MaxCmdSN that is less than
         the last ExpCmdSN.
 <<<

 This confuses me because it says to me (in some cases) that a target must
 be able to handle an unlimited number of commands.  For example, let's 
say
 the target has just about reached the limit of the commands it can 
handle:

 T=>(Nop-In) (MaxCmdSN = 1, ExpCmdSN = 1)

 I=>(Scsi Read Cmd) (CmdSN = 1)

 T=>(Data-in) (MaxCmdSN = 1, ExpCmdSN = 2 /* acknowledging scsi read cmd
 */)

 Now the target may have many more data-ins to transmit.  But according to
 the rule, since the last ExpCmdSN the target transmitted was 2, the 
target
 is now forced to send a MaxCmdSN of 2:

 T=>(Data-in) (MaxCmdSN = 2, ExpCmdSN = 2)

 But this allows the initiator to send another command, even though the
 target can't handle it!

 Obviously something is wrong with my reasoning here (perhaps my
 interpretation of 'last ExpCmdSN', or when I"m supposed to acknowledge 
the
 scsi cmd); can anybody clarify?

 --buck

----- Forwarded by Julian Satran/Haifa/IBM on 08-02-02 02:26 -----
  
                    "Buck Landry"  
                    <blandry@cross       To:     <[email-masked]>    
                    roads.com>           cc:  
                    Sent by:             Subject:     iSCSI: MaxCmdSN rule 
 
                    owner-ips@ece.  
                    cmu.edu  

                    07-02-02 22:40  

Hi all, I'm struggling over how to interpret this rule in section 1.2.2 of
draft v10:

>>> The target MUST NOT transmit a MaxCmdSN that is less than
        the last ExpCmdSN.
<<<

This confuses me because it says to me (in some cases) that a target must
be able to handle an unlimited number of commands.  For example, let's say
the target has just about reached the limit of the commands it can handle:

T=>(Nop-In) (MaxCmdSN = 1, ExpCmdSN = 1)

I=>(Scsi Read Cmd) (CmdSN = 1)

T=>(Data-in) (MaxCmdSN = 1, ExpCmdSN = 2 /* acknowledging scsi read cmd 
*/)

Now the target may have many more data-ins to transmit.  But according to
the rule, since the last ExpCmdSN the target transmitted was 2, the target
is now forced to send a MaxCmdSN of 2:

T=>(Data-in) (MaxCmdSN = 2, ExpCmdSN = 2)

But this allows the initiator to send another command, even though the
target can't handle it!

Obviously something is wrong with my reasoning here (perhaps my
interpretation of 'last ExpCmdSN', or when I"m supposed to acknowledge the
scsi cmd); can anybody clarify?

--buck

---

From: "Robert D. Russell" <[email-masked]>
Date: Wed, 6 Mar 2002 04:36:12 -0500 (EST)

Julian:

3 small editorial corrections that I believe should be made to draft 11.

1)  In section 2.2.4, the fourth paragraph from the end, on page 36,
    should be removed:

    The value "?" with any key has the meaning of enquiry and should be
    answered with the current value or "NotUnderstood". The value "?" MUST
    be used ONLY in Full Feature Phase.  Whenever the responder has 2 two
    values for a key - one for the offering-to-responding-party direction
    and a second one for the responding-to-offering-party direction it
    will answer with the two values separated by a comma starting with the
    requesting-to-offering-party direction.

2)  In section 11.4, on page 186, the word "must" should be "MUST":

    The initiator of the TCP connection MUST provide this key to the
                                        ^^^^
    remote endpoint in the first login request if the initiator is not

3)  In section 11.5, on page 187, the word "must" should be "MUST":

    The initiator of the TCP connection MUST provide this key to the
                                        ^^^^
    remote endpoint at the first Login of the login phase for every con-
    nection. The Initiator key enables the initiator to identify itself to
    the remote endpoint.

Thanks,

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774