|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI - ExpDataSNThanks - to all - Julo ----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----
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 Max! RecvDataSeg-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. ----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----
> -----Original Message----- > From: Mallikarjun C. [mailto:cbm@rose.hp.com] > 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 -----
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:Julian_Satran@il.ibm.com] Sent: Friday, August 16, 2002 4:02 AM To: ips@ece.cmu.edu 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 PD! Us 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 ----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----
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 cbm@rose.hp.com ----- Original Message ----- From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com> To: "'Julian Satran'" <Julian_Satran@il.ibm.com>; <ips@ece.cmu.edu> Sent: Friday, August 16, 2002 12:01 PM 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. > > 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. > > >
Home Last updated: Sat Aug 17 12:18:56 2002 11647 messages in chronological order |