Re: iSCSI: "Wedge" drivers

["Randall R. Stewart" <randall@stewart.chicago.il.us>]

Black_David@emc.com wrote:

> John described a model in which an initiator discovers
> that multiple TCP/IP connections are part of the same
> session.  That seems awkward by comparison to having
> each participant tell the other what the alternate
> transport addresses are (or how to find them) as the
> latter avoids having to splice a new connection into
> one that's already actively doing I/O.  SCTP sets up
> multiple addresses in this fashion, FWIW.
> 

David:

This is exactly what SCTP does in setting up an association.
The peer endpoints exchange there address lists when establishing
the association. So if you have 3 NIC cards each with seperate 
IP addresses, your endpoint will pass the 3 addresses as valid
(presuming you bound all of the addresses). 

SCTP will automatically (on retransmission due to fast retransmit
algorithm or T3-Timer expiration) retransmit to one of the alternate
addresses. Presuming you are not using the unreliable extension
that will NOT do retransmissions :). 

I think (from my limited understanding of your discussion so
far) that SCTP will solve the failure scenario in this case.
Points it does not help with are:

1) Load balancing across NIC's. This was taken out
   of the specification long ago and is now left up
   to the upper layer application... so if you wanted it
   the SCSI layer above would need to be overriding
   the primary destination address (The primary is set
   at startup and can be changed or overridden). All the
   addresses should be available by API query of the endpoint
   as well.

2) Implementations in hardware. I don't see this happening for
   quite some time since SCTP is so new it will be some time
   before someone sticks it in a ASIC... IMHO.. of course I have
   been wrong a lot of times :0

One other point that is worth noting... SCTP is designed to
be a bit more configurable than TCP. Most of the parameters
are designed to be tweaked. I think on a private Intra-Net you
can get a lot more control of some of the failure thresholds and
parameters than you will in most common TCP implemenations that
are out there today. This could be of some benefit to the IPS working
group...

R



-- 
Randall R. Stewart
randall@stewart.chicago.il.us or rrs@cisco.com
815-342-5222