Re: Towards Consensus on TCP Connections

[Stephen Bailey <steph@cs.uchicago.edu>]

> As I've explained in a previous post, I see a need for low-cost bandwidth in
> excess of 1 Gb/s for low-end single-LUN iSCSI disks. This bandwidth should
> be available to a single iSCSI command from an initiator. 

The gating factor for whether iSCSI succeeds is not going to be 200
MB/s instead of 100 MB/s out of a single LUN.

If iSCSI works at ALL in a cost effective way that can be implemented
in a disk, there'll be wild dancing in the streets and you'll all (or
maybe your companies will) be rich beyond the dreams of avarice.

The easier you can make it for the implementors, the more likely it
will succeed.

> When I consider tapes, the alternative of multiple SCSI connections looks
> even less appealing. Unlike disks, tape reads and writes are not idempotent,
> so SCSI-level error recovery is quite complex because the initiator needs to
> discover the current state of the tape.

I don't see how multiple TCP connections in an iSCSI session can solve
this problem in a way that works for tapes either.  Specifically, the
time to discover that the path you're using has failed and switch to
another one (O(seconds)) is going to be longer than the amount of data
the tape has in it's buffer.  In this case, it seems an upper layer
failover mechanism could work just as well (poorly).

Steph