Subject: iSCSI: SNACK and resend with current values of ExpCmdSn and MaxCmdSN

From: "John Hufferd" <[email-masked]>
Date: Sun, 30 Dec 2001 14:38:47 -0800

Julian,
in the SNACK Request PDU (section 3.16), there is the statements that
current values of ExpStatSN and ExpDataSN should be used on the resent
PDUs, but no mention of sending the current values of ExpCmdSN or MaxCmdSN.
I have thought that those also should be included in the fields that must
be current when resent.

Is there any reason to exempt those fields?

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136, Cell: (408) 499-9702
Internet address: [email-masked]

---

From: "Julian Satran" <[email-masked]>
Date: Mon, 31 Dec 2001 08:17:21 +0200

John,

The current text reads:

The numbered-response, or R2T, requested by a SNACK have to be deliv-ered 
as exact replicas of the ones the initiator missed including all its flags 
except for the ExpCmdSN, MaxCmdSN and ExpDataSN fields that MUST carry the 
current values.

The numbered Data-In PDUs, individually requested by a SNACK, have to be 
delivered as exact replicas of the ones the initiator missed including all 
its flags except for the ExpCmdSN and MaxCmdSN fields that MUST carry they 
current values.  Data-In PDUs requested with RunLength 0 (meaning all PDUs 
after this number) may be different from the ones originally sent in order 
to reflect changes in MaxRecvPDULength. 

Regards,
Julo

John Hufferd/San Jose/IBM@IBMUS
Sent by: [email-masked]
31-12-01 00:38

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     [email-masked]
        Subject:        iSCSI: SNACK and resend with current values of ExpCmdSn and MaxCmdSN

Julian,
in the SNACK Request PDU (section 3.16), there is the statements that
current values of ExpStatSN and ExpDataSN should be used on the resent
PDUs, but no mention of sending the current values of ExpCmdSN or 
MaxCmdSN.
I have thought that those also should be included in the fields that must
be current when resent.

.
.
.
John L. Hufferd

---

From: "John Hufferd" <[email-masked]>
Date: Sun, 30 Dec 2001 23:47:52 -0800

Good change, I have included minor edits in-line below.

.
.
.
John L. Hufferd

Julian Satran@IBMIL
12/30/2001 10:06 PM

To:    John Hufferd/San Jose/IBM@IBMUS
cc:    [email-masked], [email-masked]
From:  Julian Satran/Haifa/IBM@IBMIL
Subject:    Re: iSCSI: SNACK and resend with current values of ExpCmdSn and
       MaxCmdSN  (Document link: John Hufferd)

John,

The current text reads:

       The numbered-response, or R2T, requested by a SNACK
       have to be deliv-ered as exact replicas of the ones
       the initiator missed including all its flags except
       for the ExpCmdSN, MaxCmdSN and ExpDataSN fields that
       MUST carry the current values.

       The numbered Data-In PDUs, individually requested by
                                  ^^^^^^^^^^^^ Delete this
       a SNACK, have to be delivered as exact replicas of
       the ones the initiator missed including all its flags
       except for the ExpCmdSN and MaxCmdSN fields that MUST
       carry they current values.  Data-In PDUs requested
                ^ Should delete the y
       with RunLength 0 (meaning all PDUs after this number)
       may be different from the ones originally sent in
                                         add comma   ^
       order to reflect changes in MaxRecvPDULength.

 Regards,
 Julo

                      John Hufferd/San                                                       
                      Jose/IBM@IBMUS           To:       Julian Satran/Haifa/IBM@IBMIL       
                      Sent by:                 cc:       [email-masked]                     
                      [email-masked]        Subject:  iSCSI: SNACK and resend with        
                      .edu                      current values of ExpCmdSn and MaxCmdSN      

                      31-12-01 00:38                                                         

Julian,

.
.
.
John L. Hufferd