RE: iSCSI: Session Partial Resolution Clarifications

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

I think our experience with Fibre Channel illustrates that establishing
initial credit at login ("login BB credit") will not get what people want.
One possible solution is to keep the concept of an initial credit, but to
allow the target to dynamically manage this credit allocation with its
initiators.  For instance, if one set of initiators starts becoming very
active, then the target may allocate more initial credit to them and
subtract it from others.  In practice this might solve the allocation
problems that have hindered this feature in Fibre Channel.  

Note that a target could accomplish this by logging out and then logging
back in with a new credit setting, but this approach has two practical
problems.  First, there will be a period of time when the initiator/target
pair are not logged in with respect to one another, and so cannot execute
commands.  Second, doing this frequently will probably drive the software
folks nuts - using login in this manner would appear to be similar to the
overuse of RESET or MODE SELECT to solve all problems (i.e. the sledgehammer
approach).

So if there is a side protocol for changing initial credit allocations, then
we can keep everyone always logged in, but not freeze a credit allocation at
login.  In particular, targets will actually be able to use this if they had
the freedom to readjust credits as the loads change (always remembering that
the credits are not reclaimed until the initiator confirms their
deallocation).  I'd recommend that this side protocol look like something
familiar (ie. the login process or the dynamic credit flow control process)
rather than invent something entirely new.

Jim



-----Original Message-----
From: Black_David@emc.com [mailto:Black_David@emc.com]
Sent: Wednesday, September 20, 2000 7:43 AM
To: ips@ece.cmu.edu
Subject: iSCSI: Session Partial Resolution Clarifications


A few clarifications based on the last day's worth of email.

- The "flow control" issue is definitely still
open.  The sliding window mechanism is one way of
addressing this, but I'd venture that it may not
be the one that would get chosen if this were the
only goal.  So the "flow control" issue is definitely
open, and if that results in putting back the
reference numbers and sliding windows, so be it ...
but not without a serious consideration of other
design alternatives such as capacity advertisement
on login and credit-based mechanisms.  Keep in
mind that this is iSCSI-level flow control; the
WG does not have a license to tinker with TCP's
flow and congestion control.

- The requirement for OPTIONAL support of multiple
connection sessions has not gone away; the intent is
to address it in a separate document in order to
make progress on the main document.  I'm assuming
(and should have stated, sorry), that the main iSCSI
document will continue to contain a negotiation
mechanism sufficient to set up any of the connection
models that have been proposed.  My understanding is
that contains sufficient "hooks" as that term has
been used by Matt Wakeley and Michael Krause, but
alternative views (e.g., we need to set aside n bytes
of Reserved fields for future use in the headers now)
are welcome.

- Those who want to continue to debate multiple connection
sessions on the list need to explain what will be
different that will avoid spending another 6 weeks and
not getting to consensus.  In the absence of such an
explanation, expect to see active discouragement of such
traffic on the list.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------