RE: iSCSI virtualization

[Charles Monia <cmonia@NishanSystems.com>]

Hi:

Whether or not this is a T10 issue is a matter of opinion.  In my opinion,
it's not.
In any event, I vote for taking this off the table.

Charles
> -----Original Message-----
> From: Robert Snively [mailto:rsnively@Brocade.COM]
> Sent: Friday, October 13, 2000 8:17 AM
> To: 'Yaron Klein'; ips@ece.cmu.edu; T10 Reflector (E-mail)
> Subject: RE: iSCSI virtualization
> 
> 
> * From the T10 Reflector (t10@t10.org), posted by:
> * Robert Snively <rsnively@Brocade.COM>
> *
> Actually, the matter is T10 and T10 only.  It appears to
> be based on some IEEE work that provided a mass storage model,
> modified for implementation on SCSI.  T10 has not yet spent much
> time on this and the mass storage model has been constrained
> by its performance characteristics to some specialized
> image filing markets, but the principles are sound enough.
> The IEEE standards that are somewhat relevant are:
> 
> 1244.1  Architecture/Data Model
>         Geoff Peck (principal), Curtis Anderson, Joel Williams,
>         Murali Sathyanarayana
> 1244.2  Session Security, Authentication, and Initialization Protocol
>         Bruce Haddon (principal 2000-), Jan Klier (principal 
> 1997-2000),
>         Curtis Anderson, Joel Williams
> 1244.3  Media Management Protocol
>         Murali Sathyanarayana (principal), Curtis Anderson, 
> Joel Williams
> 1244.4  Drive Management Protocol
>         Joel Williams
> 1244.5  Library Management Protocol
>         Joel Williams
> 
> I would propose that T10 define a scripting block similar to
> the EXTENDED COPY scripts that could be returned to an initiator
> from a directory management device.  The initiator could then 
> execute the
> returned script to obtain the desired data directly from the
> actual location of the data.  That SCSI tool would allow any
> SCSI transport layer to support this behavior.
> 
> Note that this architecture trades an additional
> access and search operation against the efficiencies of direct
> data delivery.  This performance tradeoff is not a clear cut
> win for either option and will depend on the configuration,
> SCSI transport technology characteristics, and
> types of transactions being performed.  That is one of many 
> reasons that
> host- and controller-based RAIDs have remained popular in spite of
> the availability of the alternative approach.  
> 
> 
> 
> >  -----Original Message-----
> >  From: Yaron Klein [mailto:klein@eng.tau.ac.il]
> >  Sent: Friday, October 13, 2000 4:10 AM
> >  To: ips@ece.cmu.edu
> >  Subject: RE: iSCSI virtualization
> >  
> >  
> >  Jim and John:
> >  
> >  The matter is iSCSI and iSCSI only. The title should be:
> >  
> >  Encapsulation of piggyback (SCSI) commands in the iSCSI protocol.
> >  
> >  And the virtualization is just one example of the benefits of this
> >  encapsulation option. Many other examples can be found (as Julian
> >  mentioned and more: smart proxies, virtual caches, smart 
> >  mirroring etc).
> >  My main request from the WG is to add the option: "iSCSI 
> >  reflection" in
> >  the iSCSI status (note again: iSCSI matter) in the status message.
> >  
> >  Charles:
> >  
> >  It looks as there are some applications that will require 
> >  the status to
> >  be sent first to the manager (i.e., not to the initiator) or 
> >  to both the
> >  initiator and the manager. I guess there are to ways to set it:
> >  
> >  1. In the negotiation phase, set it permanently, or
> >  2. In the iSCSI command, add another bit to determine to who 
> >  the status
> >  should be sent (initiator, manager or both).
> >  
> >  But first you should help me to convince the group to insert the
> >  piggyback option to the protocol and than we will battle for 
> >  the status
> >  issue.
> >  
> >  Regards,
> >  
> >  Yaron Klein
> >  SANRAD
> >  klein@sanrad.com
> >  
> >  
> >  
> 
> 
> -----
> Message-ID: <39E58A44.17926940@eng.tau.ac.il>
> From: Yaron Klein <klein@eng.tau.ac.il>
> To: ips@ece.cmu.edu
> Subject: iSCSI virtualization proposal
> Date: Thu, 12 Oct 2000 02:54:12 -0700
> X-Mailer: Internet Mail Service (5.5.2650.21)
> 
> 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 
>  
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo@t10.org
>