Subject: iSCSI: synch and steering comments

From: "Mallikarjun C." <[email-masked]>
Date: Tue, 27 Mar 2001 9:44:43 PST

Julian,

Following are the comments I have on Synch and Steering in rev05.

-Suggest replacing "it" in the following sentence in section 1.2.8.2, page 23
 (first sentence in a new para):
 
 "According to our model of layering, iSCSI considers the information 
    it delivers (headers and payloads) as a contiguous stream of bytes 
    mapped to the positive integers from 0 to infinity."
 
 with "that a Synch and Steering layer" to make it clear.  The sentence
 is ambiguous about the direction of delivery with the way it is.
 
-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.
 
-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?)
 
-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.
 
-I am somewhat confused about the following statement in section 1.2.8.2:
    "The Synch and Steering Layer is required to add to every sent data 
    item (IP packet, TCP packet or some other superstructure) enough 
    information to enable the receiver to steer it to a memory location 
    independent of any other piece. "
 
 Clearly from the way I understood the markers in Appendix.C, it doesn't
 comply with this requirement.  A more generic statement would be:
    "The Synch and Steering Layer is required to add adequate 
    information to the data stream to enable the receiver to quickly 
    steer the stream to its final memory location, even in the face of 
    discontiguities in the stream. "
--
Mallikarjun 

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
[email-masked]

---

From: [email-masked]
Date: Fri, 30 Mar 2001 09:52:25 +0200

Matt,

I though the question was about the text. The text of the Synch and
Steering reffers to both Synch and Steering mechanisms.
Steering to memory when you are in Synch can be accomplished using protocol
specific information or a General Purpose RDMA.

When you are out of Synch a general purpose RDMA can do the placement while
a synch can help you reach the next boundary.

Julo

Matt Wakeley <[email-masked]> on 29/03/2001 16:58:35

Please respond to Matt Wakeley <[email-masked]>

To:   [email-masked]
cc:
Subject:  Re: iSCSI: synch and steering comments

> +++ Markers are but one example and have only the Synch component. The
> statement refers to a full steering (RDMA) scheme +++

Julian,

No "full steering (RDMA) scheme" is required. A Sync mechanism that that
implements framing such that the first item in each frame is an iSCSI
header
is all that is required to enable steering because the iSCSI header
contains
all the required steering information (task tag, data offset).

-Matt

---

From: [email-masked]
Date: Sat, 31 Mar 2001 10:40:06 +0200

I've marked it with ---

Matt Wakeley <[email-masked]> on 31/03/2001 10:25:25

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:
> Some comments.
> >Answers in text. Thanks, Julo
> >
> >
> ..
>
> >+++ 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.
>
> >
> >   ++++
> >
> >+++ 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.
>
> >
> >+++
> >
> >+++ 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