Subject: Re: iSCSI: synch and steering comments

From: "Mallikarjun C." <[email-masked]>
Date: Sun, 01 Apr 2001 22:14:54 PDT

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.
[email-masked]

>I've marked it with ---
>
>Matt Wakeley <[email-masked]> on 31/03/2001 10:25:25
>
>Please respond to Matt Wakeley <[email-masked]>
>
>To:   IPS Reflector <[email-masked]>
>cc:
>Subject:  Re: iSCSI: synch and steering comments
>
>
>
>
>Julian,
>
>There were many comments in this message.  To which comment are you
>refering
>to?
>
>-Matt
>
>[email-masked] wrote:
>>
>> Mallikarjun,
>>
>> It is clearly communicated in the paragraph above it - but fine I will
>add
>> it here too.
>>
>> Julo
>>
>> "Mallikarjun C." <[email-masked]> on 30/03/2001 00:54:20
>>
>> Please respond to [email-masked]
>>
>> To:   [email-masked]
>> 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.
>> [email-masked]
>
>
>
>

---

From: [email-masked]
Date: Mon, 2 Apr 2001 14:49:11 +0200

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.

This is also partly a result of choosing Format 2.

Regards,
Julo

"Mallikarjun C." <[email-masked]> on 02/04/2001 07:14:54

To:   [email-masked]
cc:

Julian,

Thank you.
--
Mallikarjun

Mallikarjun Chadalapaka

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 04 Apr 2001 11:02:12 PDT

Julian,

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

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

---

From: "Mallikarjun C." <[email-masked]>
Date: Wed, 04 Apr 2001 14:52:11 PDT

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

>
>"Mallikarjun C." <[email-masked]> on 04/04/2001 20:02:12
>

---

From: [email-masked]
Date: Wed, 4 Apr 2001 20:52:44 +0200

Mallikarjun,

Julo

To:   [email-masked]
cc:

Julian,

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?

+++ why ? +++

that there's no mandatory Synch and Steering layer either, I don't see how
two

Mallikarjun Chadalapaka