Re: multiple connections

[julian_satran@il.ibm.com]

Command numbering won't be needed anymore - every command with an
outstanding status
is restarted. As for the 2 commands - synch can be achieved by setting data
first and then sending commands.

Julo

"Matt Wakeley" <matt_wakeley@agilent.com> on 06/09/2000 11:17:09

Please respond to Matt Wakeley <matt_wakeley@agilent.com>

To:   ips@ece.cmu.edu
cc:    (bcc: Julian Satran/Haifa/IBM)
Subject:  Re: multiple connections




julian_satran@il.ibm.com wrote:

> Dear colleagues,
>
> With all the heated debate about multiple vs. single connection a request
I
> made a while ago got no significant reply (neither for nor against).
>
> The request was to consider a proposal made by Kalman Meth to reconsider
> the asymmetric model with the addition of a path selection made by the
> initiator.

One downside I see to this proposal is that for a host with multiple iSCSI
nics, it will have to issue two commands (in this order): one to the "data
path
nic" to describe where the data is to be read from/written to, and one to
the
"control path nic" to send the command.  This would be communication to two
cards instead of one.  Also, note that the communication to the data path
nic
MUST complete before the control path nic sends the command, requiring some
kind of sync mechanism.


> This proposal allows removing the command counters - as commands use a
> single TCP connection. The single connection can also be a shared
> data+control connection.

For the case of the command connection failure and fail-over to a new
connection, I don't see how you can get away from the command counters.
When a
fail over occurs, you will need some way of finding out what commands made
it
to the target and which didn't.  The easiest way to do this is with command
numbering.

>
>
> In case of multiple connection the data path to be used is selected and
> maintained until the command ends.
>
> Thanks,
> Julo

-Matt Wakeley
Agilent Technologies