Re: single vs multiple channels for iSCSI commands

[Matt Wakeley <matt_wakeley@agilent.com>]

Hi Costa,

Costa Sapuntzakis wrote:

> I would like to stake out a position against any approach that involves
> using multiple simultaneous TCP connections per iSCSI session.
>
> The design of iSCSI (and the hardware that implements it) becomes
> significantly simpler when there is just 1 TCP connection/session.

I disagree.  An upper layer multiplexing entity receives SCSI I/Os and
distributes each to a HW adaptor. A mirror image of this entity at the other
end gathers the I/Os from all the adaptors and presents them to the scsi layer
(in the order that the initiator received them from its scsi layer).  Since
multiple adaptors may be involved, it must be software that is performing
these functions.


> Parallel paths in the network can still be exploited by setting up
> multiple sessions with multiple TCP connections.

This will still need the multiplexing entity I described above, so what's the
difference?  In order to talk to a device using multiple paths (for increased
bandwidth), multiple TCP connections must be set up and the I/Os distributed
amoung them and gathered together again at the target.  And if the target
requires ordering, then either you can't use multiple TCP connections (and not
enable higher bandwidth than a single link) or invent some protocols to enable
ordering.

Having multiple TCP connections per session provides the protocol to deliver
to the target scsi layer the commands in the same order the initiator scsi
layer issued them.


> So far, I have heard of two applications that allegedly require strict
> ordering: tape backup and remote asynchronous mirroring. New SCSI commands
> or even higher-layer techniques can be used to satisfy these applications.

As you say, "new" commands, etc.  One of the objects of iSCSI is to enable
existing applications.


> For example, I have heard that some high-bandwidth tape applications blast
> self-describing blocks of data to tape, making the order in which data
> gets read/written to tape less relevant.

"Some" applications does not cover "all" applications.


> For the case of high bandiwdth remote asynchronous mirroring, a special
> SCSI remote asynchrnous mirroring command set could be introduced.
> I believe remote asynchronous mirroring principally consists of one
> command: WRITE, so the command set would probably be small.

This would require a change to be made by T10.

> Ditching multiple simultaneous connections/session would help convince us
> of the correctness of iSCSI and allow us to move onto other important
> issues and help the time to market.

You can prototype with 1 TCP connection per session and build on that later.

-Matt