RE: iSCSI virtualization proposal

["John Hufferd/San Jose/IBM" <hufferd@us.ibm.com>]

iSCSI Team,
I feel that we have enough to do just to get iSCSI to be a robust function
that fully supports SCSI on TCP/IP networks across Intranet and Internet.
Lets not wander off on these type of things before we finish the protocol
spec and the projects that I have already listed that we need to work on to
make the protocol whole (Boot, Naming, Discovery, Connection Process, MIBs
etc.)  If you are looking for work please volunteer for one of these
Projects.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403
Internet address: hufferd@us.ibm.com


Charles Monia <cmonia@NishanSystems.com>@ece.cmu.edu on 10/12/2000 03:33:34
PM

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
Subject:  RE: iSCSI virtualization proposal



Hi:

At first glance, this seems to be doable without messing with the SCSI
device semantics.  If so, it's not a T10 issue at all.  It may not even be
an iSCSI transport issue.

Aesthetically, I believe the right way to implement this feature is through
hooks in the transport layer. Since we're talking about iSCSI rather than
legacy devices, though, another somewhat convoluted and inelegant approach
would be to have the iSCSI targets and the host initiator reverse roles,
such that the drives use SCSI write commands to push data to the host
buffer
(after all, this is SCSI, isn't it?).  Most devices on legacy interconnects
don't have the ability to reverse rolls, so such an approach is not easily
transferrable to existing implementations.

To return to my main point, the feature is very useful if it works
transparently, within the framework of existing device semantics and
commands.  It becomes a lot less useful otherwise.

Charles

> -----Original Message-----
> From: John Hufferd/San Jose/IBM [mailto:hufferd@us.ibm.com]
> Sent: Thursday, October 12, 2000 11:16 AM
> To: ips@ece.cmu.edu
> Subject: Re: iSCSI virtualization proposal
>
>
> Yaron,
> Jim has a valid point that this is not iSCSI focused.  I see this as a
> Third Party Virtualization, of which a number of companies have such
> products out today.  They also have special host code to
> support this, as
> you will need here.   But more to the point, it is not iSCSI
> specific and
> therefore should be pursued with T10.  If that Standard is
> established,
> then and then only, we should consider it as part of iSCSI.
> Lets keep this
> out of our discussion on Gateways, Proxies, etc. it does not
> fit there.
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403
> Internet address: hufferd@us.ibm.com
>
>
> Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 10/12/2000 10:35:47 AM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   Yaron Klein <klein@eng.tau.ac.il>
> cc:   ips@ece.cmu.edu
> Subject:  Re: iSCSI virtualization proposal
>
>
>
>
> Yaron,
>
> Is this something specific to iSCSI or more general (e.g.,
> applicable to
> SVP or FCP or even parallel)?  If so, I would suggest that
> this is an issue
> for T10.
>
> Additionally, this can be interpreted in some sense as the
> initiator being
> a copy manager and receives (as a target) from the manager (now an
> initiator) an  EXTENDED COPY command in which the destination
> of the data
> is the initiator. This point of view  changes the sematics a bit (and
> doesn't quite fit the suggestion from Charles to pass status
> back through
> the manager).  Do we get the same net function this way? Is
> there anything
> that iSCSI needs to do?  Can it all be accomplished with
> implementations
> within the existing spec?
>
> I honestly don't know the answer to these questions (as I
> haven't really
> thought about this that hard).
>
> Jim Hafner
>
>
> Yaron Klein <klein@eng.tau.ac.il>@ece.cmu.edu on 10-12-2000
> 02:54:12 AM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  iSCSI virtualization proposal
>
>
>
> Proposal for iSCSI virtualization:
>
> The problem:
>
> In order to implement iSCSI virtualization in a local
> network, we need the
> following topology:
>
>   -----------
>   |
>   | host    |
>   |
>   -----------
>
>
>
> ---------------------------------------------------------
>      |              |                |
>      |              |                |
>      |              |                |
> ----------      ----------      ----------      ----------
> |        |      |        |      |        |      |
> | Manager|      | Disk A |      | Disk B |      | Disk C |
> |        |      |        |      |        |      |
> ----------      ----------      ----------      ----------
>
> When the host is an iSCSI initiator, the disks are iSCSI
> targets and the
> manager is with iSCSI target port to the host and iSCSI
> initiator port to
> the disks.
>
> The host considers the manager as a "flat" disk space with
> iSCSI port and
> is unaware of the disks. The manager manages the disks in
> some algorithm to
> construct a combined virtual volume.
>
> Consider the following example:
>
> Each disk contains 1000 blocks. The virtual volume is thus
> 3000 blocks. The
> hosts sends an iSCSI command to the manager to read 40 blocks
> from address
> 500. The physical addresses are: A ? 400:409, B ? 300:319 and
> C ? 600:609.
>
> In the current iSCSI protocol, the traffic scenario is:
>
> Host -> manager: iSCSI command, read from 500 size 40.
> Manager -> A: iSCSI command, read from 400 size 10.
> A -> manager: iSCSI data.
> A -> manager: iSCSI status.
> Manager -> host: iSCSI data.
> Manager -> B: iSCSI command, read from 300 size 20.
> B -> manager: iSCSI data.
> B -> manager: iSCSI status.
> Manager -> host: iSCSI data.
> Manager -> C: iSCSI command, read from 600 size 10.
> C -> manager: iSCSI data.
> C -> manager: iSCSI status.
> Manager -> host: iSCSI data.
> Manager -> host: iSCSI status.
>
> Problem 1: Traffic on the line is double! Each data packet is
> transferred
> twice (from disk to manager and from manager to host).
>
> Problem 2: The manager is a bottleneck. Both data and
> commands of all the
> system (assuming many hosts and disks) is transferred via it.
>
> Solution:
>
> Lets add in the iSCSI status message, in the "iSCSI status" field, the
> following option:
>
> 2 - iSCSI reflection
>
> Which means that the status contains add-ons of iSCSI command
> that the host
> should implement. These commands will implement the original
> request. In
> our example it will look as:
>
> Host -> manager: iSCSI command, read from 500 size 40.
> Manager -> host: iSCSI status (with reflection), iSCSI
> commands (for A, B
> and C)
> host -> A: iSCSI command, read from 400 size 10.
> A -> host: iSCSI data.
> A -> host: iSCSI status.
> host -> B: iSCSI command, read from 300 size 20.
> B -> host: iSCSI data.
> B -> host: iSCSI status.
> host -> C: iSCSI command, read from 600 size 10.
> C -> host: iSCSI data.
> C -> host: iSCSI status.
>
> Benefits:
>
> * Data traffic on the line is single.
> * No bottleneck on the manager.
>
>
> Note: The manager is a software pack. It can be an
> independent unit, in the
> host or in one of the disk. It is just schematically stated
> as independent
> unit.
>
> In conclusion, the addition of the reflection feature in the
> protocol is
> minor change, can be optional and will enable the enormous
> potential of
> virtualization.
>
> Comments are more than welcome,
>
> Yaron Klein
> SANRAD
>
> klein@sanrad.com
>
>
>
>
>
>