Re: iSCSI: synch and steering comments

[julian_satran@il.ibm.com]

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