Re: iSCSI: synch and steering comments

["Mallikarjun C." <cbm@rose.hp.com>]

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
>
>
>
>