RE: iSCSI: Flow Control

[Jim McGrath <Jim.McGrath@quantum.com>]

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).

Jim


-----Original Message-----
From: Michael Krause [mailto:krause@cup.hp.com]
Sent: Tuesday, October 03, 2000 9:31 AM
To: IPS@ece.cmu.edu
Subject: RE: iSCSI: Flow Control


At 08:22 PM 10/2/00 -0700, Jim McGrath wrote:
>I agree with Peter.
>
>We should allow immediate data, but only up to a limit previously set by
the
>target (so we have a chance that it is received).  But the target has to be
>given the ability to dynamically change (in Peter's terms, advertise) the
>resources available, and be able to do it selectively (i.e. to one
initiator
>and not another).  This inability to change the resources deployed for this
>purpose over time is why current schemes are not implemented (no target
>wants to get "caught" and so drastically underadvertizes the actual
>resources it has available).

Agree as well.  The question is does one only do this at connection set-up 
time or does one define a iSCSI operation that performs session option 
negotiation at any time within a session's lifetime.  Also if multiple 
connections are supported, is this negotiation per TCP 
connection?  Recommend doing this per connection within a session and 
allowing resources per connection and resource to vary even between the 
same endnode pair.

Mike