Subject: RE: iSCSI: login issue - partial consensus call

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 06 Sep 2001 11:10:54 PDT

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.
[email-masked]

>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
>
>
>[email-masked]@ece.cmu.edu on 09/06/2001 07:10:37 am
>
>Sent by:  [email-masked]
>
>
>To:   [email-masked], [email-masked]
>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
>[email-masked]       Mobile: +1 (978) 394-7754
>---------------------------------------------------
>
>> -----Original Message-----
>> From: Martin, Nick [mailto:[email-masked]]
>> Sent: Wednesday, September 05, 2001 5:50 PM
>> To: KRUEGER,MARJORIE (HP-Roseville,ex1); [email-masked]
>> 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:[email-masked]]
>> Sent: Friday, August 31, 2001 12:09 PM
>> To: Martin, Nick; [email-masked]
>> 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
>>
>
>
>
>

---

From: "Eddy Quicksall" <[email-masked]>
Date: Thu, 6 Sep 2001 16:58:03 -0400

I got a bit lost here but I think the purpose is to reset a session.
Wouldn't it make it easier if we use the TSID instead of the ISID. Since the
target controls that and can issue a unique TSID to every initiator, it
could more easily do its job.

Am I missing something?

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 2:11 PM
To: [email-masked]
Subject: RE: iSCSI: login issue - partial consensus call

Mallikarjun Chadalapaka

---

From: "Mallikarjun C." <[email-masked]>
Date: Thu, 06 Sep 2001 17:53:05 -0700

Eddy,

Two comments -

- In a reboot-after-a-crash scenario (one case where the implicit
session
  logout - aka option A - would be useful), initiator may not have any 
  old session state including the TSID.

- Current formulation is that TSIDs are not really guaranteed to be 
  unique per initiator, nor even among multiple sessions with the same
  initiator (if each is to a different target portal group).

Hope that helps.
-- 
Mallikarjun 

Mallikarjun Chadalapaka

---

From: "Eddy Quicksall" <[email-masked]>
Date: Fri, 7 Sep 2001 11:50:04 -0400

Millikarjun,

If, after a crash, the initiator does not have any state information, how
will it know the ISID?

Regarding the TSID, if we design this use for it, that will enforce the need
for the target to make it useful ... see, it would be up to the target as to
if it is unique or if it is unique only within this initiator.

Also, the TSID should be 32 bits. That would allow the target to more easily
provide uniqueness.

Eddy

-----Original Message-----
From: Mallikarjun C. [mailto:[email-masked]]
Sent: Thursday, September 06, 2001 8:53 PM
To: [email-masked]
Subject: Re: iSCSI: login issue - partial consensus call

Eddy,

Two comments -

Hope that helps.
--
Mallikarjun

Mallikarjun Chadalapaka