RE: iSCSI - bookmarks change

["Eddy Quicksall" <eddy_quicksall@ivivity.com>]

If the ITT is going to be kept, why not also have the TTT? The same argument
used to justify the ITT for the initiator could be used to justify the TTT
for the target.

Eddy

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Thursday, September 06, 2001 1:12 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - bookmarks change



Mark,

Comments in text - Julo

Mark Bakke <mbakke@cisco.com>@cisco.com on 05-09-2001 22:21:31

Please respond to Mark Bakke <mbakke@cisco.com>

Sent by:  mbakke@cisco.com


To:   Julian Satran/Haifa/IBM@IBMIL
cc:   ips@ece.cmu.edu
Subject:  Re: iSCSI - bookmarks change




The timeouts are the reason several of us had wanted something
other than bookmarks in the first place; that's when we had
proposed the "option 5" scheme that allowed an initiator to
control the amount of data to be sent, and the target to not
have to keep any state for text commands.  Since the initiator
has to keep state anyway (while waiting for responses), we did
not want to also have to keep state on the target.

+++ I understand that. I went through this line of though, and saw that
the
the target will anyhow have to implement a time-out as it can't
completely
rely aon the initiator for more than a single request/response (and even
there not).
It was preferable then to let thing be as simple as possible - 1
response/request. +++

Anyway, the bookmarks will work fine; I just want to see
this not get too complicated, and not have too many options.

If we are going to use bookmarks, I would at least like to
see only one outstanding text command at a time, regardless
of what we do with the ITT.  I really don't see any difference
between looking up an ITT or just looking at some value in
a connection structure; I'll have the latter anyway.

+++ Just regularity - the ITT mechanism is there and will be used for
every
PDU
and for some recovery+++

I don't see the difficulty.  Anyway, leaving ITT in does not
hurt anything in the target, if we can at least change the
SHOULD to MUST, the target can do the lookup either way.

If we simply have to have a way for a special implementation
to do multiple outstanding text commands, we could say:

    An initiator SHOULD have only one outstanding command on
    a connection at any given time.

    A target receiving a text command while another text command
    is in progress on the same connection MAY reject either or
    both commands.
+++ OK +++
Standard implementations would then have only one outstanding
command at a time; vendor-specific implementations could have
multiples if they wish (providing that both initiator and target
support them).

--