Re: Connection Consensus Progress

[csapuntz@cisco.com]

Hi David,

> I've seen:
> R1) Parallel transfers to/from and failover support for
> 	tape devices.  In contrast to disks, multiple SCSI
> 	connections to the same tape do not work (e.g.,
> 	blocks can be written in the wrong order).
> R2) Obtaining parallelism for a single SCSI command
> 	across multiple transport connections using
> 	different physical links.
> R3) Obtaining parallelism for a single SCSI command
> 	across multiple transport connections using the
> 	same physical links.
> R4) Optimize failure handling, so that a single TCP
> 	connection loss doesn't immediately translate
> 	into a SCSI error visible to higher level
> 	(time-consuming) recovery logic.
> R1) and R2) are beyond the capabilities of existing SCSI-
> based systems (note that a parallel bus is a single link). 
> R3) and R4) are related to the use of TCP as a transport.

That's a good summary. However, I'm a bit confused by what you mean by
single SCSI command. iSCSI today doesn't obtain parallelism for a
single SCSI command. A single SCSI command is executed over a single
transport connection.

Also, you don't need a session concept to get parallelism per se.
You need it to get parallelism + ordered task queueing.

> R3) needs more explanation, as TCP is known to be able
> to saturate Gigabit Ethernet, given enough data to
> transfer.  Is the argument for R3) that for the
> transfer sizes likely to be seen in iSCSI, TCP
> spends enough of its time in slow start and the
> like that multiple TCP connections gain performance?

This is not the strongest argument, but: At 10 gigabits, one processor
may not be able to saturate the link. Using multiple transport
connections allows you to more readily use multiple processors.

Note that these multiple processors can come in the
form of either an SMP or multiple NICs.

-Costa