RE: Multiple Connections. How would they work?

[julian_satran@il.ibm.com]

Bob,

Sorry but NO. 01 has a notion of a session - that is an organized
collection and the numbering for commands is done across a session to
reestablish order.
Recovery is also on a session base - a failed connection can have it's
commands reissued.

Julo

Robert Snively <rsnively@Brocade.COM> on 08/09/2000 18:46:27

Please respond to Robert Snively <rsnively@Brocade.COM>

To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
cc:
Subject:  RE: Multiple Connections. How would they work?





As I read it, the model in 01 was a "single" model, not a "symmetric"
model.  It did not place any limit on the number of "singles", but
did not place any relationship values among them either.  That makes
ordering exactly the same as the present SCSI structure, which may
have any number of initiator/target connections and paths, but treats
each one of them as individual and, for most purposes, independent.

That is a model I would favor, since I see no way to create
interdependent paths without objectionable and expensive relationships
being maintained among hardware NICs in  either the hardware or
software layers.  These relationships have typically been handled
very well and in highly optimized ways by wedge drivers and
high availability file systems.

Bob

>  The 00 draft (Adelaide) had the commands go down over one
>  specific control
>   stream while the data went on any available connection.
>  Synchronizing them and providing for hardware implementation
>  across several
>  adapters was felt to be complex.
>
>  However command ordering was trivial.
>
>  The symmetric model in 01 requires ordering and this is why
>  you have the
>  command ordering.
>  A proposal to get back to the asymmetric model but decide
>  ahead of time (?
>  when) what
>  path data will be taking was forwarded by Kalman.
>
>  We call this the asymmetric model (it can still evolve).