Re: Requirements specification

[Stephen Bailey <steph@cs.uchicago.edu>]

> The current requirements specify that the protocol must support
> multiple connections per session.  So far the only justification
> for this that I have clearly heard is performance, current and future
> systems will demand bandwidth that will require aggregation. Is there
> any other reason for multiple connections?

ST attempted to provide support for ``striping'' at a protocol level
which is somewhat comparable to performance scaling application of the
multiple connections per session proposal for iSCSI.

Basically, it was a failure.  It handled one very specific class of
application (not very well).  As others here have mentioned, the error
handling was horrendous.  I'd say we spent WAY too long trying to iron
the bugs out, and it STILL had square wheels AND unaddressed reachable
states.

When we did SST, we specifically prohibited use of ST striping both
because it wouldn't work well, and because the SCSI stacks of high end
platforms already support LUN-level striping which was perfectly
adequate.  The high end applications that needed more than a single
channel's worth of data, were always signed up for additional system
integration work to make a less general technology do the trick.  In
order to guarantee the target performance levels, they had to perform
a complete system analysis and engineering effort anyway.

Everybody else seemed more interested in the best performance which
was available `inexpensively'.  That corresponds to using a single
(general purpose) channel, and scaling with channel technology.

We concluded that as long as channel speeds were increasing briskly it
didn't make sense to spend any effort on a low level striping scheme.
If network technology generations start coming years apart, it might
make sense again.

A similar argument applies to availability (multipathing).  High end
SCSI stacks do it, and the relatively smaller set of applications that
need the feature will be engineered/integrated end to end for the
requirement.  The integrators needn't sling code, there are
off-the-shelf components to do it, but they DO have to make sure that
the technology is applied properly.  They can't just expect it to work
under any circumstances.

> The second area that I brought up was the requirement of one session
> per initiator target pair instead of one per LUN (i.e. SEP).  I am
> willing to accept the design constraint that a single target must
> address 10,000 LUNs which can be done with a connection per
> LUN. However, statements of scaling much higher into the areas where
> 64K port limitations appear I think is not reasonable.

The ST/SST experience is on the opposite side of this argument.  The
main issue is that when you move from a bounded storage configuration
to a storage on a generalized network, you have to assume a leap in
the scale of connectivity.  That's one of primary advantages using a
network.

If you do not use all reasonable techniques at your disposal to reduce
the number of connections, you will run out of connection resources.
On the initiator end, iSCSI is unlikely to be the only substantive
consumer of connection resources on a channel.  It's bad platform
citizenship for a protocol to assume that it can consume the majority
of any shared resource.  On the target end, storage targets tend to be
a cost sensitive business, and more connections is more state, so more
cost.  If the standard specifies one LUN per connection, the clear
expectation is that (multi LUN) targets must support many (initiators
* LUNs) connections.

The other crunch point for connections in ST was that the hardware
acceleration included connection specific behavior.  There is some
increment of hardware complexity (not necessarily design complexity)
per supported connection.  If iSCSI hardware acceleration has this
same characteristic, conserving connections will probably be even more
important.

Steph