|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: login issue - partial consensus callI 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 |