Re: iSCSI: synch and steering comments

[Matt Wakeley <matt_wakeley@agilent.com>]

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