SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI - ExpDataSN




    Thanks - to all - Julo
    ----- Forwarded by Julian Satran/Haifa/IBM on 08/17/2002 05:00 PM -----
    "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
    Sent by: owner-ips@ece.cmu.edu

    08/16/2002 10:01 PM

           
            To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
            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 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 -----
    "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>

    08/17/2002 01:58 AM

           
            To:        "'Mallikarjun C.'" <cbm@rose.hp.com>
            cc:        Julian Satran/Haifa/IBM@IBMIL
            Subject:        RE: iSCSI - ExpDataSN

           


    > -----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 -----
    pat_thaler@agilent.com

    08/17/2002 02:17 AM

           
            To:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
            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: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 -----
    "Mallikarjun C." <cbm@rose.hp.com>

    08/17/2002 01:29 AM

           
            To:        "KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>
            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
    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