SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: Out of order response to R2T



    
    
    Barry,
    
    I can understand the rationale and the new text is strict (see attached).
    However a bad digest can result in the need to redo part or the whole R2T
    (or to reclaim all the data after the failure).
    
       If the R2T is answered with a sequence of Data PDUs the Buffer Offset
       and Length must be within the range of those
       specified by R2T, the last PDU should have the F bit set to 1, the
       Buffer Offsets and Lengths for consecutive PDUs SHOULD form a continuous
       non-overlapping range and the PDUs should be sent in increasing offset
       order.
    
    
       Regards,
       Julo
    
    "Barry Reinhold" <bbrtrebia@mediaone.net> on 29/12/2000 23:48:30
    
    Please respond to "Barry Reinhold" <bbrtrebia@mediaone.net>
    
    To:   Julian Satran/Haifa/IBM@IBMIL
    cc:   "Jon Sreekanth" <jon.sreekanth@trebia.com>, "James Smart"
          <james.smart@trebia.com>
    Subject:  Out of order response to R2T
    
    
    
    
    Julian,
         This is a bit of a delayed follow up to a conversation we had in San
    Diego.
    The issue has to do with how an initiator is allowed to respond to an R2T.
    
    Right now the iSCSI draft says:
    
    "If the R2T is
       answered with a sequence of Data PDUs the Buffer Offset and Length
       must be within the range of those
       specified by R2T and the last PDU should have the F bit set to 1; the
       Buffer Offsets and Lengths for consecutive PDUs SHOULD form a
       continuous range. "
    
    Based on previous conversations this means that an initiator can break up
    the delivery of the data into 4 segments and deliver the segments in any
    order.
    
    I would like to argue that this should be restricted such that when
    responding to an R2T the data is delivered in order. I understand the logic
    behind allowing the target to request data out of order based on the R2T.
    This is consistent with Fibre Channel protocol and disk drive needs.
    However, it is not clear to me why we should allow the iSCSI data PDUs sent
    in response to the R2T to be out of order. I have three observations on
    this:
    
    1. The concept behind the target sending the R2T (based on analogy to the
    FCP_XFER_RDY) is that the target is ready to receive data starting at
    "offset" of a given length. This does not happen when the data is delivered
    out of order forcing the end device to reassemble the information and
    making
    the check process more complicated.
    
    2. This is specifically diallowed by Fibre Channel. Fibre Channel requires
    that the data be delivered in one IU (sequence) and that the first frame of
    the sequence must have the data offset set to the value sent in the
    FCP_XFER_RDY frame. All the rest of the frames in the sequence must deliver
    data in order by FC-FS rules.
    
    For reference - FCP-2 clause 9.3
    
    "If an FCP_XFER_RDY IU
    is used to describe a data transfer and the first frame of the requested
    FCP_DATA IU has a relative offset that
    differs from the value in the FCP_DATA_RO field of the FCP_XFER_RDY IU, the
    target shall post the error code
    
    
    ôFCP_DATA Parameter mismatch with FCP_DATA_RO
    
    
    
    ö in the FCP_RSP_INFO field of
    the FCP_RSP IU."
    
    I contacted Bob Snively (author of FCP-2) to confirm this. Bob is willing
    to
    discuss the semantics of the FCP_XFER_RDY data transfer with you if you
    wish
    to pick up that thread.
    
    3. We have not seen this behavior in the field. If some device actually
    took
    advantage of this flexibility I suspect a number of implementation issues
    would come up. In my experience these types of options hinder
    interoperabiliy.
    
    Also note that if a device is going to translate from iSCSI to FC, it is
    going to have a difficult time with this. It must buffer up all the iSCSI
    frames until it finds the first piece. It the data is sent in reverse order
    and the transfer is large the buffering could be significant. Testing this
    is a difficult process, and when testing is difficult interoperability
    problems creep in.
    
    In summary I would like to suggest that out of order data delivery in
    response to an R2T is not a helpful feature, hinders ineroperability, is
    not
    compatible with Fibre Channel, and therefore makes interconnecting with
    Fibre Channel legacy devices more difficult. I would like to see us adopt
    the same semantics for iSCSI in this requard as Fibre Channel has.
    
    Thanks for your time on this,
    
    Barry Reinhold
    
    
    


Home

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