|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI - Change - Login/Text commands with the binary stage co deArgh, in my attempt to be concise, I forgot to ask about why the target would ignore the X-bit and consider this as a new command/prompt. Shouldn't that suffice to see that it is a replay of a text command, instead of a new one? I realize that with I-bit set, CmdSN may not be trackable, yes? Stephen -----Original Message----- From: Wheat, Stephen R Sent: Monday, August 27, 2001 7:48 AM To: ips@ece.cmu.edu Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co de Julian, So the Target ignores C-replay CmdSN, mistaking C-replay to be a post-D prompt. How can that be? Stephen the Terse (still looking for bookmark rationale) -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, August 23, 2001 10:05 PM To: ips@ece.cmu.edu Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co de Stephen, I wonder if 123 words (your note) are really needed to say that bookmarks have no role at all. For an exchange going well and on a single connection bookmarks are not doing more that their paper counterpart. It is when things go wrong that you need them. Assume that you have the following sequence: a)I->T text B=0 b)T->I text B=1 Bkmk1 c)I->T text B=1 Bkmk1 d)T->I text B=1 Bkmk2 e)I ->T... Assume now that D got lost (digest) and the initiator reissues C. Without a Bookmark the target will think that he got a prompt after D when in fact he got a replay of C In summary the bit acts like the paper bookmark and the bookmark field is more like the word-processor bookmarks - it hold information relevant to the party that built it. Julo "Wheat, Stephen R" <stephen.r.wheat@intel.com> on 24-08-2001 01:21:04 Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com> To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co de OK; that makes more sense. But now, why do we have it? This whole discussion could have been avoided if it wasn't there in the first place. How many that follow me in reading this will have the same questions? Why should the spec provide something that has no value in the execution of the spec? It seems to me that this is superfluous, and as such doesn't belong in the spec. I.e., this seems more clearly a unnecessary item ever-more-so than alias. Would you mind doing a query of the group as to who has objection to removing the bookmark field? I really hope my relatively new exposure to all of this has value to you and the other authors on the readability/clarity of the spec. Thanks, Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Thursday, August 23, 2001 11:10 AM To: Wheat, Stephen R Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co de Stephen, Bookmark is an opaque thing. The initiator copies it dutifully from the target. The target may choose to put some information there or leave it 0 etc. Regards, Julo "Wheat, Stephen R" <stephen.r.wheat@intel.com> on 23-08-2001 18:03:45 Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com> To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co de Julian, Thanks for your response. OK, then if you follow your temptation, then the bookmark field goes away and the B-bit does it all, yes? Otherwise, I'm still missing the sequence of events where the bookmark fields contributes to syncronization or segregation or both. Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 22, 2001 11:10 PM To: Wheat, Stephen R Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co de Stephen, I've fixed the 2 offending occurrences of Initiator Text Tag (It was a typo - thanks). The bookmark was introduced to: relieve the target from the need to maintain state for a number of pending sequences - you can have only one bookmark (with some state in it) I am tempted to make it one bookmark/initiator allow to certify to the target that the initiator is still there and willing to get more information (when you clear the bookmark you can delete whatever state you maintained). Regards, Julo "Wheat, Stephen R" <stephen.r.wheat@intel.com> on 22-08-2001 20:48:25 Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com> To: Julian Satran/Haifa/IBM@IBMIL cc: Subject: RE: iSCSI - Change - Login/Text commands with the binary stage co de Julian, just to you. In a couple of places, this refers to "Initiator Text Tag". What is that? Is it a typo? Also, I've been pondering the bookmark field. Why does this field exist beyond the B bit, if the bookmark's validity is invalidated by having received a command with a different ITT? There must be a scenario where the following doesn't work. Please advise. I->T Text SendTargets=all (F=1,B=0) T->I Text <part 1> (F=0,B=1) I->T Text <empty> (F=1,B=1) T->I Text <part 2> (F=0,B=1) I->T Text <empty> (F=1,B=1) ... T->I Text <part n> (F=1,B=0) Thanks, Stephen -----Original Message----- From: Julian Satran [mailto:Julian_Satran@il.ibm.com] Sent: Wednesday, August 22, 2001 1:30 AM To: ips@ece.cmu.edu Subject: iSCSI - Change - Login/Text commands with the binary stage code 1.1.5 Bookmark An opaque handle copied from a previous text response. It is supposed to allow a target to transfer a large amount of textual data over a sequence of text-command/text-response exchanges. The target associates the bookmark it issues with the Initiator Task Tag and a received Bookmark is considered valid by the Target only if received with the same Initiator Task Tag and if the target did not receive on the same connection a text command with a different Initiator Text Tag since it ************* ^^^^ ???? issued the Bookmark.
Home Last updated: Tue Sep 04 01:03:53 2001 6315 messages in chronological order |