RE: iSCSI: login issue - partial consensus call

["Mallikarjun C." <cbm@rose.hp.com>]

Let me make one last attempt to explain why I dislike B.

>And in reply to David's suggestion for a mandatory management interface to
>disable the C-bit. If iSCSI can mandate that, then it can mandate a
>management interface for setting/configuring ISID partitions and the
>problem goes away of non-cooperating HBAs.

Jim is right on.  Enforcing ISID partitioning, or C-bit setting -
either works for well-behaved initiators.  Neither works with 
incorrect implementations.  To tilt the balance, option A is simpler.
--
Mallikarjun 


Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions Organization
MS 5668	Hewlett-Packard, Roseville.
cbm@rose.hp.com


>Folks,
>
>Though I'm getting ready to throw in the towel on this issue (mostly
>because it isn't really worth the fight), I want to state again my rational
>for not supporting Option B.
>
>Option A is the simplest for everyone.
>
>Option B has much more complexity and is subject to the same results as
>Option A if the C bit is used indiscriminantly.  How use of the C-bit is
>controlled is actually outside the scope of the standard because
>enforcement of requirements is by the receiving end of the protocol and
>there's nothing for the target to do in this case.  The target can't say "I
>don't think you really meant that".  A "good" initiator will never set the
>C bit unless it really wants it and understands the consequences.  A "bad"
>initiator (because of bad programming) will set the C bit first and then
>handle the rejection as a retry (but when there is no rejection, the bad
>effects have already happened).   A "good/bad" initiator may not set the C
>bit first, but then set it after a rejection because it thinks it owns the
>ISID space (e.g., doesn't even know or care that there might be another HBA
>around) -- and we all know systems that behave this way!
>
>The net of this is, in my opinion, that what we're trying to protect
>against with Option B won't really be protected, so why bother with the
>extra protocol.
>
>And in reply to David's suggestion for a mandatory management interface to
>disable the C-bit. If iSCSI can mandate that, then it can mandate a
>management interface for setting/configuring ISID partitions and the
>problem goes away of non-cooperating HBAs.
>
>Jim Hafner
>
>
>Black_David@emc.com@ece.cmu.edu on 09/06/2001 07:10:37 am
>
>Sent by:  owner-ips@ece.cmu.edu
>
>
>To:   Nick.Martin@compaq.com, ips@ece.cmu.edu
>cc:
>Subject:  RE: iSCSI: login issue - partial consensus call
>
>
>
>Trying to close this issue, I think Nick's points are valid and
>answer the question about when the "C-bit" would not be set --
>when the entity sending the command suspects (or wants to protect
>against) a problem in ISID assignment.  That appears to make option
>B) the right choice:
>
>       B) Should iSCSI mandate making this intended cleanup explicit
>          by setting a bit (Say C-bit, for Clear) in the Login Command
>          PDU to prevent an accidental session cleanup with a buggy
>          initiator code?
>
>I have the following additional comments:
>(1) A new bit is needed.  Reuse of the X-bit for this purpose has been
>     rejected by rough consensus of the WG.
>(2) In order to deal with the worst case, every iSCSI implementation
>     MUST have an administrative interface that can prevent this new
>     "C-bit" from ever being set, even if the implementation thinks
>     that setting it is the right thing to do.  This provides a
>     way to deal with situations in which sessions are getting
>     stomped on by ISID problems.
>(3) Some additional words about ISID usage are needed to encompass
>     scenarios in which ISID assignment is not present, does not
>     assign enough ISIDs, or fails for some reason.
>
>Comments are welcome.  Further objection to B) needs to explain
>why Nick's scenarios should not be considered.  I was disappointed
>to see a prior statement that the ISIDs would be different "by
>definition" - this is in the same category as saying that software
>and protocol implementations are bug-free "by definition".  Keep in
>mind that Nick is correct in saying:
>
>> The problem is that iSCSI does not and will not specify how two HBAs
>> from different vendors installed in the same Initiator should or could
>> get a range of ISIDs for their exclusive use.  This will be operating
>> system specific and vendor defined.
>
>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
>---------------------------------------------------
>
>> -----Original Message-----
>> From: Martin, Nick [mailto:Nick.Martin@compaq.com]
>> Sent: Wednesday, September 05, 2001 5:50 PM
>> To: KRUEGER,MARJORIE (HP-Roseville,ex1); ips@ece.cmu.edu
>> Subject: RE: iSCSI: login issue - partial consensus call
>>
>>
>> Marj,
>>
>> You mention vendors not knowing how to play right.
>> The problem is that iSCSI does not and will not specify how two HBAs
>> from different vendors installed in the same Initiator should or could
>> get a range of ISIDs for their exclusive use.  This will be operating
>> system specific and vendor defined.  It is uncertain that the same tool
>> or repository would be used by all HBA vendors in any environment.
>> Given this, accidental overlap in ISID space is not unlikely.
>>
>> Given that there is no one way to play right, we must make sure that
>> everyone can at least play nice.
>>
>> My expectation is that sessions are infrequently established and long
>> lived.  ISIDs may be re-used at will by their current owners.  When no
>> "already owned" ISIDs are available, or an attempt to re-use an "already
>> owned" ISID failed, and HBA would need to a) "probe" for a new available
>> ISID or b) fail the request to establish the session.  Session recovery
>> should not be attempted unless a session is known to have failed.
>>
>> If tools are available, and the administrator has used them correctly,
>> then HBAs will not collide in ISID space.  If the tools are not
>> available or were not used correctly, I would hope the second HBA can
>> still attempt to come up without impacting the sessions established by
>> the first.
>>
>> Again, I state my support for a login with existing ISID harmlessly
>> fails (the Target state does not change) unless a session recovery
>> indicator is set.  Also if a session recovery indicator is set, and the
>> ISID is not in use (by this Initiator at this Target), the login also
>> fails.
>>
>> Thanks,
>> Nick
>> -----Original Message-----
>> From: KRUEGER,MARJORIE (HP-Roseville,ex1)
>> [mailto:marjorie_krueger@hp.com]
>> Sent: Friday, August 31, 2001 12:09 PM
>> To: Martin, Nick; ips@ece.cmu.edu
>> Subject: RE: iSCSI: login issue - partial consensus call
>>
>>
>> > In particular this enables independent agents within the same
>> initiator to
>> > attempt a login without knowing all ISIDs in use by other agents.
>> Each
>> > agent would know the ISID of sessions it had successfully
>> established,
>> but
>> > not the ISIDs for sessions established by others.  It can use the
>> ISIDs it
>> > knows to recover sessions it owns.  If an agent gets a  failure
>> attempting
>> to
>> > establish a new session, it would pick a different ISID and
>> > retry (or just quit), rather than disrupting a session of another
>> agent.
>>
>> The intent of the presentation on SCSI/iSCSI modeling, and the text in
>> the
>> draft, is to illustrate how this example is not a recommended
>> implementation
>> choice due to the probability of violating the SCSI/iSCSI
>> rules pointed
>> out.
>> If the "independant agents" had partitioned the ISID space,
>> there would
>> be
>> no collision on login and no time wasted.  Your illustrated
>> implementation
>> could spend significant time "trying" ISID's in use by the "other
>> agents".
>>
>> However, I'm starting to have more sympathy with Julian's concerns due
>> to
>> the apparent risks of different vendors' initiator implementations not
>> following the rules.
>>
>> I just imagined having vendor A's HBA installed and happily servicing
>> applications, installing vendor B's "plug-n-play" implementation, and
>> having
>> all A's sessions aborted cause B doesn't know how to play right :-(
>>
>> Marj
>>
>
>
>
>