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



    
    
    I've marked it with ---
    
    Matt Wakeley <matt_wakeley@agilent.com> on 31/03/2001 10:25:25
    
    Please respond to Matt Wakeley <matt_wakeley@agilent.com>
    
    To:   IPS Reflector <ips@ece.cmu.edu>
    cc:
    Subject:  Re: iSCSI: synch and steering comments
    
    
    
    
    Julian,
    
    There were many comments in this message.  To which comment are you
    refering
    to?
    
    -Matt
    
    julian_satran@il.ibm.com wrote:
    >
    > Mallikarjun,
    >
    > It is clearly communicated in the paragraph above it - but fine I will
    add
    > it here too.
    >
    > Julo
    >
    > "Mallikarjun C." <cbm@rose.hp.com> on 30/03/2001 00:54:20
    >
    > Please respond to cbm@rose.hp.com
    >
    > To:   ips@ece.cmu.edu
    > cc:
    > Subject:  Re: iSCSI: synch and steering comments
    >
    > Julian,
    >
    > Some comments.
    >
    > >Answers in text. Thanks, Julo
    > >
    > >
    > ..
    >
    > >-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.
    -------------------------------------------------------------------------------
    >
    > Okay, I'd however prefer it to imply that in-order data placement is also
    > handled by Synch and Steering in the same sentence, instead of only
    > commenting on in-order notifications, and out-of-order placements.
    >
    -------------------------------------------------------------------------------
    
    > >
    > >   I have aloso changed a bit the figure to convey better the fact that
    > TCP
    > >   and Synch&Steering are related (not strictly layered +++
    >
    > That's a good idea.
    >
    > >
    > >   ++++
    > >
    > >-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
    >
    > Well, that doesn't address the thrust of my comment.  I was implying
    > that the draft should make it clear that those implementations which
    > don't support Synch and Steering should end the connection on a header
    > digest error and/or parity error, and not go into (what Somesh called)
    > a speculative mode.
    >
    > >
    > >+++
    > >
    > >-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 may be using "interoperability" in a somewhat unconventional sense
    here.
    > While the draft says that Synch and Steering layer is optional, I don't
    see
    > that it requires implementations to always support a "no synch &
    steering"
    > mode, even when they support one type of Synch and Steering layer.  Given
    > that
    > there's no mandatory Synch and Steering layer either, I don't see how two
    > iSCSI boxes that a customer buys are guaranteed to interoperate.  Please
    > comment if the draft already implies what I am asking for.
    >
    > Thanks.
    > --
    > 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:13 2001
6315 messages in chronological order