SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: synch and steering comments



    
    
    Answers in text. Thanks, Julo
    
    "Mallikarjun C." <cbm@rose.hp.com> on 27/03/2001 19:44:43
    
    Please respond to cbm@rose.hp.com
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  iSCSI: synch and steering comments
    
    
    
    
    Julian,
    
    Following are the comments I have on Synch and Steering in rev05.
    
    -Suggest replacing "it" in the following sentence in section 1.2.8.2, page
    23
     (first sentence in a new para):
    
     "According to our model of layering, iSCSI considers the information
        it delivers (headers and payloads) as a contiguous stream of bytes
        mapped to the positive integers from 0 to infinity."
    
     with "that a Synch and Steering layer" to make it clear.  The sentence
     is ambiguous about the direction of delivery with the way it is.
    
    +++ I adjusted to clarfy direction ++
    
    -Suggest adding the following statement to section 1.2.8.2.
    
     All conventional, in-order data arrival notifications generated by TCP
     are passed through to iSCSI by the Synch and Steering layer after
     appropriate data placements while none of the out-of-order data placements
     that it performs are communicated to upper layers.
    
    +++ I have added the following to 1.2.8.2
    
       On the incoming path the Synch and Steering layer does not change the
       way TCP notifies iSCSI about in-order data arrival.  All out-of-order
       data placements
       performed by the Synch and Steering layer are hidden from iSCSI.
    
       I have aloso changed a bit the figure to convey better the fact that TCP
       and Synch&Steering are related (not strictly layered +++
    
       ++++
    
    -Section 1.2.8.2 states that a Synch and Steering layer is optional.
     It has to be qualifed that it is optional only for those iSCSI devices
     which perform connection recovery on header digest errors, since that's
     how they cope with loss of framing. (I guess this may change in next rev?)
    
    +++ with the new format I think that we have:
    
    - one more chance if we go for format 1 or
    - drop the connection on header error
    
    In both cases we can leave synch and steering optional
    
    +++
    
    -It appears to me that at least one Synch and Steering layer must be
     defined/referred to as the minimal implementation in the main draft to
     enable interoperability, when implementations do implement Synch and
    Steering.
    
    +++ why ? +++
    
    -I am somewhat confused about the following statement in section 1.2.8.2:
        "The Synch and Steering Layer is required to add to every sent data
        item (IP packet, TCP packet or some other superstructure) enough
        information to enable the receiver to steer it to a memory location
        independent of any other piece. "
    
     Clearly from the way I understood the markers in Appendix.C, it doesn't
     comply with this requirement.  A more generic statement would be:
        "The Synch and Steering Layer is required to add adequate
        information to the data stream to enable the receiver to quickly
        steer the stream to its final memory location, even in the face of
        discontiguities in the stream. "
    
    +++ Markers are but one example and have only the Synch component. The
    statement refers to a full steering (RDMA) scheme +++
    
    
    --
    Mallikarjun
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668   Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    
    
    


Home

Last updated: Tue Sep 04 01:05:14 2001
6315 messages in chronological order