SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

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



    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.
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    


Home

Last updated: Tue Sep 04 01:03:53 2001
6315 messages in chronological order