SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Question on StatRN usage



    
    
    Now I'm confused - the Pittsburgh draft indicates that StatRN usage is
    optional.
    When did it become mandatory?
    
    <!--StartFragment-->Responses in transit from the target to the initiator
    are also num-
         bered.  The StatRN (Status Reference Number) is used for this pur-
         pose.  If the target uses data packet numbering and all the inbound
         data have been acknowledged, or the target is able to regenerate
         inbound data, then the target may free all the resources allocated
         for the task execution just after sending a response.  The same
         holds for targets not allowing full command recovery.  The result
         summary, just enough to rebuild the status PDU, will be kept by
         those iSCSI target implementations that support status recovery
    
    
    
    Satran, Smith, Sapuntzakis, Meth                                [Page 5]
    
    iSCSI                         June 2000
    
    
         after connection failure.  As the only cause for long delays in
         responses can be failed connections and received responses free-up
         resources, we felt that score boarding responses at the initiator
         could be accomplished by simple bitmaps and there is no need to
         flow-control responses. Status acknowledgment is done by the ini-
         tiator through ExpStatRN (Expected Status RN) and large difference
         between StatRN and ExpStatRN indicates a failed connection.
    
         iSCSI initiators are required to implement the numbering scheme if
         they support more than one connection.
    
         iSCSI targets are not required to use the numbering scheme for
         ordered delivery even when they support multiple connections. How-
         ever they are required to provide ExpCmdRN and MaxCmdRN values that
         will enable the initiator to make progress.
    <!--EndFragment-->
    
    
       Prasenjit Sarkar
       Research Staff Member
       IBM Almaden Research
       San Jose
    
    
    julian_satran@il.ibm.com@ece.cmu.edu on 10/18/2000 01:57:12 AM
    
    Sent by:  owner-ips@ece.cmu.edu
    
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI: Question on StatRN usage
    
    
    
    
    
    Mallikarjun,
    
    StatRN implementation is MUST. Its role is to count statuses (responses)
    that where sent and allow
    bulk acknowledgement. As such I did not feel any need to place restrictions
    and 0 is a legal value.
    As the standard allows 2**32 Initiator Tags you could have 2**32 in flight
    status responses (! obviously I think it will never
    happen).  Obviously if you know that the target has N outstanding commands
    and finished commands and it gets
    from an initiator an ExpStatRN more the N distant from where it is
    something is wrong!
    
    Julo
    
    
    
    
    "Mallikarjun C." <cbm@rose.hp.com> on 18/10/2000 03:58:54
    
    Please respond to cbm@rose.hp.com
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  iSCSI: Question on StatRN usage
    
    
    
    
    Julian,
    
    Could you please comment on the following on StatRN usage?  Let me
    know if I am misinterpreting the draft.
    
    Current iSCSI draft seems to allow StatRN values from 0 through
    2**32-1.  It does not qualify the value of 0 as it does for CmdRNs.
    Assuming that 0 is legal, how would a receiving initiator distinguish
    between the target implementation that numbers (assigns StatRNs)
    read data PDUs and the one that doesn't?  A StatRN of 0 in a read data
    packet could be miscontrued and scoreboarded at the initiator, when
    all the target was saying is that it doesn't implement StatRN for
    data (assuming that 0 happens to be a legal StatRN at the moment).
    
    Options are:
    - explicitly state that StatRN value of 0 is not legal.  This is
      simple, and my preference.  A statRN of 0 in data PDUs in this case
      indicates non-implementation.
    - rely on a login dialogue to call out the capability.
    
    Even if we choose the first option, I propose introducing a login/text
    key request/response through which an initiator can ask a target not
    to number iSCSI data PDUs since he cannot scoreboard all the (potentially
    unlimited # per each read command) data PDUs.  Note that the converse
    case for target is not critical since target controls the write data
    transfers
    and can hope to have scoreboarding room always available.
    
    Thanks!
    --
    Mallikarjun
    M/S 5601
    Networked Storage Architecture
    HP Storage Organization
    Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:06:37 2001
6315 messages in chronological order