Re: iSCSI: synch and steering comments

[julian_satran@il.ibm.com]

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.

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