Subject: iSCSI - ExpDataSN

From: "Julian Satran" <[email-masked]>
Date: Fri, 16 Aug 2002 14:02:21 +0300

Mallikarjun has expressed a lingering concern that we should allow the 
value 0
for the field ExpDataSN in a TASK REASSIGN TM function to say "give me all 
unacked data" (as we do for SNACK).
Please observe that we already allow the target to do this on its own and 
this change does not affect
any recovery mechanism. To do it I am suggesting the following rephrasing 
of 9.5.6

For recovery purposes the iSCSI target and initiator maintain a data 
acknowledgement reference number - the first input DataSN number 
unacknowledged by the initiator. When issuing a new command this num-ber 
is set to 0. If the function is TASK REASSIGN, which establishes a new 
connection allegiance for a previously issued Read or Bidirec-tional 
command ExpDataSN will contain either a new data acknowldge-ment reference 
number or the value 0 indicating that the data acknowledgement reference 
number is unchanged. The initiator MUST discard any data PDUs from the 
previous execution that it did not acknowledge and the target MUST 
transmit all Data-in PDUs (if any) starting with the data acknowledgement 
reference number.  The number of retransmitted PDUs, may or may not be the 
same as the original transmission depending on if there was a change in 
MaxRecvDataSeg-mentLength in the reassignment. The target MAY also  send 
no more Data-In PDUs if it sent all its data in PDUs with DataSN less than 
ExpDataSN.

The value of ExpDataSN  MUST be either 0 or higher than the DataSN of the 
last acknowledged Data-In PDU but not larger than DataSN+1 of the last 
Data-IN PDU sent by the target. Any other value MUST be ignored by the 
target. 

For other functions this field is reserved.

Please let me know what you think.

Julo

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Fri, 16 Aug 2002 15:01:26 -0400

If I understand correctly, this change will align the TASK REASSIGN task
management function behavior with the SNACK request behavior wrt
understanding that the value 0 means "send me all unacked data" - that makes
sense to me.  
 
In the 3rd sentence, it's not clear to me what you mean by "a new data
acknowledgement ref. number" - shouldn't this be the requestor's ExpDataSN
or 0?  The use of the word "new" leave the impression that the requestor is
somehow resetting this number and offering a new one? 
 
Editorial comments: the 3rd sentence in the first paragraph seems to be
missing a comma after "Bidirectional command"?  And the word
"acknowledgement" is mis-spelled in the hyphenated spot.  I've corrected the
text below:

For recovery purposes the iSCSI target and initiator maintain a data
acknowledgement reference number - the first input DataSN number
unacknowledged by the initiator. When issuing a new command this num-ber is
set to 0. If the function is TASK REASSIGN, which establishes a new
connection allegiance for a previously issued Read or Bidirec-tional
command, ExpDataSN will contain either a new data acknowledge-ment reference
number or the value 0 indicating that the data acknowledgement reference
number is unchanged. The initiator MUST discard any data PDUs from the
previous execution that it did not acknowledge and the target MUST transmit
all Data-in PDUs (if any) starting with the data acknowledgement reference
number.  The number of retransmitted PDUs, may or may not be the same as the
original transmission depending on if there was a change in
MaxRecvDataSeg-mentLength in the reassignment. The target MAY also  send no
more Data-In ! PDUs if it sent all its data in PDUs with DataSN less than
ExpDataSN.

---

From: [email-masked]
Date: Fri, 16 Aug 2002 17:17:58 -0600

Julian,
 
Looks good.
 
For completeness, "The target MAY also  send no more Data-In ! PDUs if it sent all its data in PDUs with DataSN 
   ^ not sure what that character was suppose to be
less than ExpDataSN." should be
"The target MAY also send no more Data-In PDUs if all data has been acknowledged."
because ExpDataSN might be 0 and all the data was already acknowledged. If all the PDUs had DataSN less than ExpDataSN, then all the data was also acknowledged so this change covers both cases.
 
Pat

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, August 16, 2002 4:02 AM
To: [email-masked]
Subject: iSCSI - ExpDataSN

Mallikarjun has expressed a lingering concern that we should allow the value 0 
for the field ExpDataSN in a TASK REASSIGN TM function to say "give me all unacked data" (as we do for SNACK). 
Please observe that we already allow the target to do this on its own and this change does not affect 
any recovery mechanism. To do it I am suggesting the following rephrasing of 9.5.6 

For recovery purposes the iSCSI target and initiator maintain a data acknowledgement reference number - the first input DataSN number unacknowledged by the initiator. When issuing a new command this num-ber is set to 0. If the function is TASK REASSIGN, which establishes a new connection allegiance for a previously issued Read or Bidirec-tional command ExpDataSN will contain either a new data acknowldge-ment reference number or the value 0 indicating that the data acknowledgement reference number is unchanged. The initiator MUST discard any data PDUs from the previous execution that it did not acknowledge and the target MUST transmit all Data-in PDUs (if any) starting with the data acknowledgement reference number.  The number of retransmitted PDUs, may or may not be the same as the original transmission depending on if there was a change in MaxRecvDataSeg-mentLength in the reassignment. The target MAY also  send no more Data-In ! PDUs if it sent all its data in PDUs with Dat
 aSN less than ExpDataSN. 

The value of ExpDataSN  MUST be either 0 or higher than the DataSN of the last acknowledged Data-In PDU but not larger than DataSN+1 of the last Data-IN PDU sent by the target. Any other value MUST be ignored by the target. 

Julo

---

From: "Julian Satran" <[email-masked]>
Date: Sat, 17 Aug 2002 17:03:22 +0300

Thanks - to all - Julo
----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Sent by: [email-masked]
08/16/2002 10:01 PM

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc: 
        Subject:        RE: iSCSI - ExpDataSN

If I understand correctly, this change will align the TASK REASSIGN task 
management function behavior with the SNACK request behavior wrt 
understanding that the value 0 means "send me all unacked data" - that 
makes sense to me. 
 
In the 3rd sentence, it's not clear to me what you mean by "a new data 
acknowledgement ref. number" - shouldn't this be the requestor's ExpDataSN 
or 0?  The use of the word "new" leave the impression that the requestor 
is somehow resetting this number and offering a new one? 
 
Editorial comments: the 3rd sentence in the first paragraph seems to be 
missing a comma after "Bidirectional command"?  And the word 
"acknowledgement" is mis-spelled in the hyphenated spot.  I've corrected 
the text below:
 
For recovery purposes the iSCSI target and initiator maintain a data 
acknowledgement reference number - the first input DataSN number 
unacknowledged by the initiator. When issuing a new command this num-ber 
is set to 0. If the function is TASK REASSIGN, which establishes a new 
connection allegiance for a previously issued Read or Bidirec-tional 
command, ExpDataSN will contain either a new data acknowledge-ment reference number 
or the value 0 indicating that the data acknowledgement reference number 
is unchanged. The initiator MUST discard any data PDUs from the previous 
execution that it did not acknowledge and the target MUST transmit all 
Data-in PDUs (if any) starting with the data acknowledgement reference 
number.  The number of retransmitted PDUs, may or may not be the same as 
the original transmission depending on if there was a change in 
MaxRecvDataSeg-mentLength in the reassignment. The target MAY also  send 
no more Data-In ! PDUs if it sent all its data in PDUs with DataSN less 
than ExpDataSN. 

----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
08/17/2002 01:58 AM

        To:     "'Mallikarjun C.'" <[email-masked]>
        cc:     Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI - ExpDataSN

> From: Mallikarjun C. [mailto:[email-masked]]
> Sent: Friday, August 16, 2002 3:29 PM
> To: KRUEGER,MARJORIE (HP-Roseville,ex1)
> Cc: Julian Satran
> Subject: Re: iSCSI - ExpDataSN
> 
> 
> Julian, 
> 
> Looks good, thanks.  A couple of quick notes.
> 
> - I suggest "an updated data acknowledgement reference number"
>    to address Marjorie's comment. i.e. S/b "a new" W/ "an updated".

That makes sense to me.

----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----

[email-masked]
08/17/2002 02:17 AM

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc: 
        Subject:        RE: iSCSI - ExpDataSN

Julian,
 
Looks good.
 
For completeness, "The target MAY also  send no more Data-In ! PDUs if it sent all its data 
in PDUs with DataSN 
   ^ not sure what that character was suppose to be
less than ExpDataSN." should be
"The target MAY also send no more Data-In PDUs if all data has been 
acknowledged."
because ExpDataSN might be 0 and all the data was already acknowledged. If 
all the PDUs had DataSN less than ExpDataSN, then all the data was also 
acknowledged so this change covers both cases.
 
Pat

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Friday, August 16, 2002 4:02 AM
To: [email-masked]
Subject: iSCSI - ExpDataSN

no more Data-In ! PDUs if it sent all its data in PDUs with DataSN less 
than ExpDataSN. 

Julo
----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----

"Mallikarjun C." <[email-masked]>
08/17/2002 01:29 AM

        To:     "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
        cc:     Julian Satran/Haifa/IBM@IBMIL
        Subject:        Re: iSCSI - ExpDataSN

Julian, 

Looks good, thanks.  A couple of quick notes.

- I suggest "an updated data acknowledgement reference number"
   to address Marjorie's comment. i.e. S/b "a new" W/ "an updated".

- The last sentence in the first para (that starts "The target MAY also 
send ")
   is unclear.  I assume you're stating that target may redo the whole I/O
   if it wants to.  If that's the case, I suggest dropping this sentence, 
since
   we cover that in 5.2.2.  If that's not what you intended, please 
rephrase.

Thanks.
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
[email-masked]

----- Original Message ----- 
From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
To: "'Julian Satran'" <[email-masked]>; <[email-masked]>
Sent: Friday, August 16, 2002 12:01 PM
Subject: RE: iSCSI - ExpDataSN

> unacknowledged by the initiator. When issuing a new command this num-ber 
is
> previous execution that it did not acknowledge and the target MUST 
transmit
> MaxRecvDataSeg-mentLength in the reassignment. The target MAY also  send 
no