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



    
    
    Mallikarjun,
    
    The draft has now one single mechanism and this is optional.
    Two implemenatations that have different synch and steering will not be
    able to use them.
    
    Alternatively this group may want to mandate one for interopearbility.
    
    My take is that we can wait (until iSCSI-02 -:))
    
    Julo
    
    "Mallikarjun C." <cbm@rose.hp.com> on 04/04/2001 20:02:12
    
    Please respond to cbm@rose.hp.com
    
    To:   ips@ece.cmu.edu
    cc:
    Subject:  Re: iSCSI: synch and steering comments
    
    
    
    
    Julian,
    
    >Mallikarjun,
    >
    >I am not sure about which comment. If it is about synch and steering I
    >think that recovery from header digest errors
    >should not mandate a synch mechanism.  Some very sophisticated
    >implementations may want to take advantage of such a mechanism if it is
    >there. As this interaction may fairly complex and implementation dependent
    >we will assume that we will drop the connection in the recovery
    >descriptions we will provide.
    
    Sorry, I am not clear on what you meant (keep in mind that that I am
    not asking to mandate a synch mechanism) -
    
    Are you saying that when synch and steering is not implemented in an iSCSI
    device:
      a) it can recover from header digest errors only by dropping the
    connection
         (which the ER algorithms would assume)
    OR
      b) it can recover from header digest errors by "fairly complex and
         implementaion dependent" mechanisms which rely on the Length field
         anyway, and try to analyze perhaps several PDUs for achieving the
         framing synch again?
    
    I am assuming that it would be (a).  I am also requesting that this be made
    clear in the draft.
    
    Here's the third comment at the bottom that you missed.  Your comments
    would be very helpful.  Thanks!
    
    -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.
    --
    Mallikarjun
    
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    MS 5668   Hewlett-Packard, Roseville.
    cbm@rose.hp.com
    
    >
    >This is also partly a result of choosing Format 2.
    >
    >Regards,
    >Julo
    >
    >"Mallikarjun C." <cbm@rose.hp.com> on 02/04/2001 07:14:54
    >
    >Please respond to cbm@rose.hp.com
    >
    >To:   ips@ece.cmu.edu
    >cc:
    >Subject:  Re: iSCSI: synch and steering comments
    >
    >
    >
    >
    >Julian,
    >
    >Thanks for the clarification.
    >
    >Could you please take time to respond to the other two comments I had?
    >Or, do I take it that you will get back shortly?
    >
    >If those comments are indeed incorrect, please help me understand why
    >so.
    >
    >Thank you.
    >--
    >Mallikarjun
    >
    >
    >Mallikarjun Chadalapaka
    >Networked Storage Architecture
    >Network Storage Solutions Organization
    >MS 5668   Hewlett-Packard, Roseville.
    >cbm@rose.hp.com
    >
    >
    >>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:10 2001
6315 messages in chronological order