Re: iSCSI - bookmarks change

[Santosh Rao <santoshr@cup.hp.com>]

Eddy,

I am also in favor of keeping the TTT in text command/responses and had
proposed the same about 4 months ago.
(See : http://www.pdl.cmu.edu/mailinglists/ips/mail/msg04527.html).

In any multi PDU exchange, such as a WRITE scsi cmd, or a multi-pdu text
command, the target should be allowed to use a TTT that allows it to perform a
lookup for its state information for that exchange.

This is the simplest scheme and prevents any special case code in targets to
perform a lookup of their state information for an exchange.

Regards,
Santosh




Eddy Quicksall wrote:

> 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).
>
> --
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard