RE: iSCSI: Flow Control

["Douglas Otis" <dotis@sanlight.net>]

Jim,

I am in full agreement with you.  I was just indicating the present scheme.
Also rather than a end to end scheme, a buffer to buffer scheme would be
more appropriate as there would be internal FIFOs that are being controlled
and not the end device.  Let Fibre-Channel control the fiber medium.  For
this, resolution to the FIFO is required.  If you directly control buffers
rather than commands and data separately, the ultimate level of resolution
should be the FIFO based on buffers or frames.

Doug

> -----Original Message-----
> From: Jim McGrath [mailto:Jim.McGrath@quantum.com]
> Sent: Wednesday, October 04, 2000 7:45 PM
> To: 'Douglas Otis'; Michael Krause; IPS@ece.cmu.edu
> Subject: RE: iSCSI: Flow Control
>
>
>
>
> Why use an indirect means instead of a direct means?
>
> The problem here is that a single command can overwhelm my
> resources, since
> it can consume a near infinite amount of buffer space.  This is similar
> (although a bit better) to the situation in FC-AL, where the login credit
> the target gave an initiator could apply to any one of the possible 256
> queuable commands.  So to provide a 2 credit (4 Kbyte) immediate
> data window
> to an initiator at login I had to reserve 1 MB of buffer space.
>
> I may want to let you send me a lot of commands (for scheduling purposes),
> but not get the data for them yet.  The two issues (command flow and data
> flow) are really very separable.
>
> I think people can live with the allocation of resources for commands and
> the allocation of resources for data.  But allocating one without
> addressing
> the other is not a solution to the problem of immediate commands and data
> people have been raising.
>
> Jim
>
> -----Original Message-----
> From: Douglas Otis [mailto:dotis@sanlight.net]
> Sent: Wednesday, October 04, 2000 3:10 PM
> To: Michael Krause; IPS@ece.cmu.edu
> Subject: RE: iSCSI: Flow Control
>
>
> Michael,
>
> The present scheme used by iSCSI limits commands as a indirect means of
> controlling traffic.  This provides the dynamic element per
> response in that
> even if the initiator wished to send data that might be
> discarded, it would
> need an opportunity in terms of the command window.  If you detect traffic
> between devices unrelated to this flow control method, your methods of
> allowing internal bandwidth would still be to stop incoming
> commands as the
> dynamic method of control at this time- capping maximum commands
> across the
> medium becoming congested.
>
> Doug
>
> > -----Original Message-----
> > From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> > Michael Krause
> > Sent: Wednesday, October 04, 2000 1:44 PM
> > To: IPS@ece.cmu.edu
> > 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
> >
>