Re: iSCSI: Partial Session Consensus

[julian_satran@il.ibm.com]

David,

Counters as an option is quite ugly and violates some of our design rules -
that said
that a protocol analyzer capturing the traffic on the wire will be able to
read headers
starting from any arbitrary point.  We can add a next header thing or a
flag - but I did not
hear explicit objections to the counters.

And if you come to think about it most implementations will want to support
everything so they will have the counters implemented and we will have the
added complexity
of a next header field or 2 lengths for headers - none too appealing.

I suggest we wait a couple of days?

Julo

Black_David@emc.com on 12/09/2000 19:24:25

Please respond to Black_David@emc.com

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  iSCSI: Partial Session Consensus




In reading the mailing list traffic on Asymmetric
vs. Symmetric models for multiple TCP connections
in an iSCSI session, I don't believe that there is
consensus on the issue phrased in that fashion.

I believe that there is consensus on a couple of
underlying issues:

(1) An iSCSI session containing a single TCP connection
     should not be required to use the currently specified
     iSCSI command reference numbers and sliding window
     mechanism because TCP will deliver commands in order.
(2) Use of more than one TCP connection per iSCSI session
     is OPTIONAL.

The consensus on (1) is rough; if anyone disagrees with
this for a reason other than wanting to use the Symmetric
model when an iSCSI session contains multiple TCP connections,
please say so on the list.  My reading of consensus is
based on the fact that much of the recent discussion of the
Asymmetric model has been motivated by single connection
sessions, whereas essentially all of the recent discussion
of the Symmetric model seems to have been focussed on
multiple connection sessions.

The consensus on (2) is sufficiently long standing to be a
closed issue.  The resolution to the "deadlock" scenarios posted
by Costa is that the target must not stop reading from the TCP
connection - SCSI provides means for a target to throw away
things it can't deal with (e.g., TASK SET FULL), and with
regard to the ordered command issues, I believe Steve Byan
is correct when he says:

     I think this is a T10 bug, and iSCSI should defer to T10 to fix it.

In addition to Steve noting that disks tend not to use ordered
commands, I would note that a single tape device/drive tends
not to have multiple simultaneous initiators sending commands
to it, both of which limit the practical impact of this potential
problem.

I don't see consensus on the model for iSCSI sessions that
contain multiple TCP connections.  The consensus on (1)
above for single TCP connection sessions does not take the
Symmetric model out of consideration for multiple TCP connection
sessions.  If multiple sessions are negotiated on connection
establishment, command reference numbers could be added to
subsequent headers as a result of that successful negotiation.
In order to make progress, this additional complexity should not
be used as an argument against the consensus in (1) for single
connection sessions.

I hope the consensus on (1), or something close to it holds,
as if it does not, we may have to form an offline design team or
teams to work on this set of session issues, and that could take
some time ... meanwhile, discussion of Asymmetric vs.
Symmetric for multiple connection sessions should continue.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------