RE: iSCSI: Flow Control

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

OK,
I can buy that Peer to Peer Session stuff.  So we, at least we seem to be
in agreement on these items. (The length of "normal" Sessions, the length
of Peer to Peer Sessions, and the Dynamic Buffering requirements for
Storage Controllers.)

So let me push this slightly.  I also believe that when Storage Controllers
are sold as iSCSI Internet (by that I mean long distance connect) capable,
there will be a RAM Storage Feature that is recommended by the Vendor.  Any
one that just wants to use the Storage Controller in areas where SCSI Buss
or FC distances apply today, might not need the additional RAM feature.

I think that is the way this stuff will be sold (and need to be sold) and
vendors will then compete on their more optimum ways of using the RAM
buffers.

There may be a variant of the above where the Vendor Sells the RAM Storage
Feature based on the number of Concurrent Sessions the customers wants to
sustain.  And of course there will be combinations of RAM Storage Features
for number of Sessions and Distance.  Vendors will compete on how simple
(in relationship to Cost and performance) their approach is viewed relative
to the Distance and number of Sessions needed.

If others believe this, then the stuff we have been talking about with
regards to  Flow Control is Mute and can be left up to TCP/IP and the
various vendors implementations of the iSCSI/SCSI buffering algorithms.

.
.
.
John L. Hufferd


Michael Krause <krause@cup.hp.com>@ece.cmu.edu on 10/04/2000 01:44:25 PM

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


To:   IPS@ece.cmu.edu
cc:
Subject:  RE: iSCSI: Flow Control



At 12:34 PM 10/4/00 -0700, John Hufferd/San Jose/IBM wrote:

>Michael Krause,
>First, a session usually lasts from Boot Time till it is Booted again or
>stopped.  The variant to this is a Storage Device being used in a manor
>like a Mount or Map done with NAS.  Even then, most folks, have that setup
>so the Mounting and Mapping is done at bring up, though it is sometimes
>done at other times, but even then it is left around.  So I think the
thing
>you can say about Session Time as the term is used in the iSCSI context is
>that it is LONG.
>
>I do not think we have consensus about the notification of available
>buffers.  With the way many systems work, is (as stated above), all
devices
>are set up at startup of the Host, and the Session is kept around by the
>Host, even if there hasn't been anything which use that device all
>day/week, etc.  So I am not sure if having a certain amount of buffer
space
>reserved for each Host (which could be 100s-1000s) would be an especially
>good idea.

I believe we are in agreement both in terms of duration and the need to
have dynamic buffer management.  I will clarify that there will also be
sessions that are not host focused, e.g. the peer-to-peer direction of a
storage object to another device, e.g. multi-media streaming and these
sessions will be shorter lived - possibly on a per transaction basis where
a transaction is something of reasonably large in value (e.g. 100's MBs of
data movement).

Mike