Subject: Re: iSCSI: synch and steering comments

From: [email-masked]
Date: Wed, 28 Mar 2001 16:01:29 +0200

Answers in text. Thanks, Julo

"Mallikarjun C." <[email-masked]> on 27/03/2001 19:44:43

Please respond to [email-masked]

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

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.

+++ I adjusted to clarfy direction ++

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

   I have aloso changed a bit the figure to convey better the fact that TCP
   and Synch&Steering are related (not strictly layered +++

   ++++

-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

+++

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

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

--
Mallikarjun

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

---

From: Matt Wakeley <[email-masked]>
Date: Thu, 29 Mar 2001 06:52:05 -0800

> In both cases we can leave synch and steering optional

If framing is implemented, then you don't have to drop the connection on a
header error, since the next frame by definition contains the beginning of the
next header.

-Matt

---

From: Matt Wakeley <[email-masked]>
Date: Thu, 29 Mar 2001 06:58:35 -0800

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: Matt Wakeley <[email-masked]>
Date: Thu, 29 Mar 2001 11:59:01 -0800

Doug,

You don't have to play your broken record about modifying TCP.

What I stated is correct.  Just because it could require a "change" to TCP is
not relevant.

-Matt

Douglas Otis wrote:
> 
> Matt,
> 
> If you intend to use TCP, there is no method yet to reliably obtain this
> type of header alignment.  Unless you are to modify TCP to become a record
> based protocol, this type of behavior is a modification of TCP and beyond
> the IPS charter.  If you wish this type of behavior, you should consider
> RFC-2960 instead.
> 
> Doug
>

---

From: "Douglas Otis" <[email-masked]>
Date: Thu, 29 Mar 2001 11:47:02 -0800

Matt,

Doug

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 29 Mar 2001 14:17:21 PST

>all the required steering information (task tag, data offset).

Exactly my thinking.  Matt is right on.

I think the current statement in the draft I quoted above should be changed
to be more generic to include markers (suggested sentence above), since I 
don't see any reason to exclude markers as a type of synch and steering layer.
In fact, Appendix C is (appropriately) titled "Synch and Steering with Fixed 
Interval Markers".

--
Mallikarjun 

Mallikarjun Chadalapaka

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 29 Mar 2001 14:54:20 PST

Julian,

Some comments.

>Answers in text. Thanks, Julo
..

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

>   and Synch&Steering are related (not strictly layered +++

That's a good idea.

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

> enable interoperability, when implementations do implement Synch and

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