RE: iSCSI: Flow Control

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

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.
.
.
.
John L. Hufferd


Michael Krause <krause@cup.hp.com>@ece.cmu.edu on 10/04/2000 06:53:52 AM

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


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



At 07:00 PM 10/3/00 -0700, Jim McGrath wrote:

>The mapping may be a bit trickier.  If the host side manages resources
(like
>buffers) on a per connection basis, then that should be the level.  The
>other dimension is time.  Storage traffic is bur sty, so the time span for
>resetting the resource levels should be within the scope of a "burst time"
>or "burst cycle".  This is probably seconds, or perhaps minutes, but not
>hours.  How long would we expect a session to last?  (The problem with
>previous efforts was it was tied into device/host login, which could last
>for days).

A session's duration is a function of the operation being performed so I
don't think there is any way to quantify to a "best" value either for a
minimum or a maximum (don't really want to track this within an
implementation other than what is the current resource).  Burst times are
also a function of the type of operation being supported - some data base
queries or large data set (e.g. technical applications) processing can be
very storage intensive for many hours at a time.  As such, the login
mechanism is a nice initialization point but the dynamic mechanism needs to
be present to deal with "real-life" operations which are not steady state
activities.

I don't see people objecting to this requirement so is this something that
can be viewed as consensus?

Mike