Re: Requirements specification

[Michael Krause <krause@cup.hp.com>]

At 03:15 AM 8/4/00 -0600, Mark A. Carlson wrote:
>julian_satran@il.ibm.com wrote:
> >
> > David,
> >
> > The one additional requirement is availability/fault-tolerance.
>
>Could you elaborate on this and tell us how multiple connections
>between the same two NICs enhance availability?

Availability is a function of the paths and components in use:

- Multi-port NICs provide protection from cable disconnect (the most common 
form of failure) at the NIC level.  Multi-port also allows the control data 
to be shared within the NIC making fail-over and performance enhancements 
simpler to implement.  There are many proof-of-concepts as well as products 
running today that have demonstrated these values.

- A given port is capable of surviving failure within the intermediate 
fabric, e.g. a cable disconnect between intermediate switches or a switch 
failure.  Support for multiple connections allows traffic to be segregated 
to different paths and thus survive this type of failure.

>Also, can you state what the availability requirements are?

- Application transparent survival all forms of fabric failures.

- Application transparent fail-over to alternative paths, alternative 
hardware, etc.

- Ability to deal with hot-plug / hot-removal of fabric elements in an 
application transparent way.  For example, if a hot-plug event occurs and a 
new path is established which happens to provide higher bandwidth or better 
QoS, the session layer would be able to add a new connection to flow over 
that path.  The connection arbitration policies could be adjusted to skew 
the operations to that path since it provides the better performance, etc. 
to the application.   All of this can occur without involving the 
application itself being accomplished within the iSCSI session layer.

> > Your arguments about performance are valid. However I doubt that there will
> > be enough incentives - beyond price - to develop things for high end
> > controllers and servers.
> >
> > Enabling multiple connections brings those applications the performance
> > required without any serious implications to the rest of the "family" 
> (as I outlined
> > in Pittsburgh controllers and servers that don't need multiple 
> connections/session don't  have to implement them).
>
>The serious implications that I think everyone is concerned about is the
>complexity that we are introducing into the protocol and the question of
>whether this really provides the performance that is asserted.

Suggestion is for those that advocate to show proof of concept / modeling 
that shows the benefit.  We can debate all we want but demonstration is the 
key to showing the benefits.  If we can get agreement on the basic 
operational model, I'm sure several people will step up to prove it one way 
or the other.

> > Storage traffic requirements will always exceed those of many other
> > applications.
> >
> > As for the "one-connection-per-LU" we covered this solution in long
> > discussions
> > and even several full fledged implementation - as it is compelingly simple.
> > However the resource consumption is unjustifiably high and the security
> > problems are
> > even worse (the LUs "viewed" by an initiator depend on who he says he is)
> > than
> > in the current draft.
>
>Chances are that each LUN could be owned by separate initiators and require
>authentication to separate principals anyway. I think that this is the
>requirement we need to keep in mind.

Mike