RE: iSCSI: No Framing

["Peglar, Robert" <robert_peglar@xiotech.com>]

>-----Original Message-----
>From: Douglas Otis [mailto:dotis@sanlight.net]
>Sent: Monday, February 04, 2002 11:37 AM
>To: ips@ece.cmu.edu
>Subject: RE: iSCSI: No Framing
>
>
>Rob,
>
>Although it will be true large amounts of bandwidth will be exchanged
>between the typical SAN, such systems also use cache due to mechanical
>limitations with respect to rotation and linear access.  If it 
>were just
>storage to storage, Fibre-Channel or FC encapsulation would be 
>preferable.
>At least with that scheme, there are direct placement 
>interfaces available.

Without bogging down the list in a debate about storage subsystems, I must
say that there are examples to the contrary w.r.t. the usage of subsystem
cache. 

iSCSI is, of course, more than just storage-to-storage.  But we should not
limit iSCSI to just host-to-storage.  Remember, storage subsystems can (and
are, in some cases) both initiator and target at the same time.

The original thread began with a question (paraphrased) about '...what
applications could consume a 10G pipe for long periods of time'.  I answered
that question - disk-disk backup and subsystem replication.

FC is not sufficient.  Storage-to-storage needs all the advantages as well
as that which iSCSI has to offer the host-storage model.

>
>Direct placement is needed with low latency high bandwidth to reduce
>overhead lost during a subsequent memory copy.

This assumes a subsequent memory copy.  

>SCTP offers a means of
>implementing direct placement without kludging a portion of 
>the application
>beneath the transport.  In addition, this direct placement 
>scheme can be
>done in an general fashion to support thousands of higher 
>level protocols.
>As with most SAN, network related failures are not well 
>tolerated, so the
>added robustness of SCTP becomes highly beneficial.

Having read this list since its creation, I choose to not participate in the
SCTP/TCP religious war.  

>In establishing a large remote mirror, the highest bandwidth means of
>initialization would be physical transport of the image.  Once 
>initialized,
>only differential information is exchanged largely limited by 
>the bandwidth
>and error rate of the interconnect.

Well put.  Consider 3-10 TB of differential per day as a start.  Consider
images of 100s to 1,000s of TB, spread across 100s to 1,000s of 15KRPM (or
more, stay tuned) spindles.  Now, we're talking.

Rob

Rob Peglar
Corporate Architect
XIOtech Corporation, a Seagate Company
(314) 308-6983


>
>Doug
>
>> De-lurking...
>>
>> Right now, I'd say disk-disk backup/restore and mirroring.  
>The individual
>> disk devices of today can perform at ~70 MB/s.  One need 
>only gang 14 of
>> these together, streaming, to reach nearly 1000 MB/s, or 1 GB/s,
>> or 8 Gb/s.
>> The disk devices of tomorrow are going to perform at rates 
>approaching 100
>> MB/s per spindle.  Only ten devices are then necessary.
>>
>> This would be a single TCP stream (one initiator, one 
>target, many LUs).
>>
>> If one has to mirror (/move) 10 TB in a reasonable amount of
>> time, say, then
>> a stream of 1 GB/s is not only necessary, but paramount.  Even at
>> that rate,
>> it would still take nearly three hours to move just 10 TB.  In a
>> business-critical recovery situation, three hours is an eon.
>>
>> Don't think application (CPU/memory in a server) to storage.
>> Think storage
>> to storage.
>>
>> Rob
>>
>> Rob Peglar
>> Corporate Architect
>> XIOtech Corporation, a Seagate Company
>> (314) 308-6983
>