SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: iSCSI: login issue - partial consensus call



    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:cbm@rose.hp.com]
    Sent: Thursday, September 06, 2001 2:11 PM
    To: ips@ece.cmu.edu
    Subject: RE: iSCSI: login issue - partial consensus call
    
    
    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
    >>
    >
    >
    >
    >
    
    
    


Home

Last updated: Thu Sep 06 21:17:14 2001
6398 messages in chronological order