Re: iSCSI: synch and steering comments

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

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