Re: iSCSI: synch and steering comments

[julian_satran@il.ibm.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