Re: iSCSI: synch and steering comments

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

Julian,

>Mallikarjun,
>
>The draft has now one single mechanism and this is optional.
>Two implemenatations that have different synch and steering will not be
>able to use them.
>
>Alternatively this group may want to mandate one for interopearbility.
>
>My take is that we can wait (until iSCSI-02 -:))

How about mandating "no synch and steering" mode for all implementations
in iSCSI-01?  Doesn't it ensure interoperability?

Since you're choosing not to comment in spite of my continued restatements
of the header-digest-error-with-no-sync question, I am assuming you agree 
with option (a) below and hope to see it stated in rev06.

Thank you.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


>
>"Mallikarjun C." <cbm@rose.hp.com> on 04/04/2001 20:02:12
>
>Please respond to cbm@rose.hp.com
>
>To:   ips@ece.cmu.edu
>cc:
>Subject:  Re: iSCSI: synch and steering comments
>
>
>
>
>Julian,
>
>>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.
>
>Sorry, I am not clear on what you meant (keep in mind that that I am
>not asking to mandate a synch mechanism) -
>
>Are you saying that when synch and steering is not implemented in an iSCSI
>device:
>  a) it can recover from header digest errors only by dropping the
>connection
>     (which the ER algorithms would assume)
>OR
>  b) it can recover from header digest errors by "fairly complex and
>     implementaion dependent" mechanisms which rely on the Length field
>     anyway, and try to analyze perhaps several PDUs for achieving the
>     framing synch again?
>
>I am assuming that it would be (a).  I am also requesting that this be made
>clear in the draft.
>
>Here's the third comment at the bottom that you missed.  Your comments
>would be very helpful.  Thanks!
>
>-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.
>--
>Mallikarjun
>
>
>Mallikarjun Chadalapaka
>Networked Storage Architecture
>Network Storage Solutions Organization
>MS 5668   Hewlett-Packard, Roseville.
>cbm@rose.hp.com
>
>>
>>This is also partly a result of choosing Format 2.
>>
>>Regards,
>>Julo
>>