RE: iSCSI - Change - Login/Text commands with the binary stage co de

["Julian Satran" <Julian_Satran@il.ibm.com>]

Stephen,

Yes with one bookmark per initiator my scenario is wrong and the a bit is
enough for correct operation.

Regards,
Julo


"Wheat, Stephen R" <stephen.r.wheat@intel.com>@ece.cmu.edu on 27-08-2001
17:47:40

Please respond to "Wheat, Stephen R" <stephen.r.wheat@intel.com>

Sent by:  owner-ips@ece.cmu.edu


To:   ips@ece.cmu.edu
cc:
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.