RE: iSCSI - positive data ack - change proposal

["Rod Harrison" <rod.harrison@windriver.com>]

Julian,

	I understand that the NOP is not actually an ACK itself. However,
given the way an initiator must process a non-immediate NOP-IN ping
request I believe it can be used to gain some understanding of when
buffers associated with DATA-IN PDUs might be released.

	I don't really want to argue for using the NOP this way, I don't
think it's a great idea. I just wanted to throw it in to show that a
target can get most of what it needs even without a specific ACK
mechanism.

	Please keep in mind this was based on the assumption that long
transfers that might cause the target problems are rare, and so this
use of NOP would be rare. If this is not the case then I believe an
in-band ACK is necessary.

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Tuesday, September 25, 2001 4:03 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - positive data ack - change proposal


Rod,

My English is not that good Rod. What I meant to say about the NOP is
that
it does not convey information (it can't be used by itself as an
ack!).

I can understand that ack is seldomly needed but we can certainly
improve
targets (make them less expensive) by having it.

I can understand also that data (for real applications) could be
rebuilt.

But you should not get the list into believing that there is a simple
alternative.


Julo



                    "Rod Harrison"
                    <rod.harrison@wind       To:     Julian
Satran/Haifa/IBM@IBMIL,
                    river.com>                <ips@ece.cmu.edu>
                    Sent by:                 cc:
                    owner-ips@ece.cmu.       Subject:     RE: iSCSI -
positive data ack -
                    edu                       change proposal


                    25-09-01 15:09
                    Please respond to
                    "Rod Harrison"





Julian,

           The NOP mechanism is awkward, no question, but I wasn't
thinking
it
was something we should specify and mandate. Rather it is something
that a target might do under extreme, and hopefully unlikely
conditions.

           - Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
Julian Satran
Sent: Tuesday, September 25, 2001 1:02 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - positive data ack - change proposal


Matthew,

I can fix the text and the ack for the last - we can dispense with,
but
unlike we gather more support we will have to drop this.   I think
that the
NOP mechanism is awkward but is awkward and as the target shares the
penalty for SNAK it has no real incentive to the F bit in every PDU.

Julo



                    "BURBRIDGE,MATTH
                    EW                     To:     Julian
Satran/Haifa/IBM@IBMIL,
                    (HP-UnitedKingdo        ips@ece.cmu.edu
                    m,ex2)"                cc:
                    <matthew_burbrid       Subject:     RE: iSCSI -
positive data ack -
                    ge@hp.com>              change proposal

                    24-09-01 12:38
                    Please respond
                    to
                    "BURBRIDGE,MATTH
                    EW
                    (HP-UnitedKingdo
                    m,ex2)"





Julian

This looks good!

A couple of comments:

Please could you add a paragraph to state that a target does not
necessarily
need to wait for the acknowledgment of a sequence before starting
transmission of the next sequence - for performance reasons.

In section 3.7.1 it states that "Upon receiving an Data-In PDU with
the F
set to 1 in a session with ErrorRecoveryLevel 1 or higher the
initiator
MUST
issue a DataACK type of SNACK indicating the next expected DataSN for
this
task".  Is this true for all incoming data sequences including the
final
sequence of the transfer?

Cheers

Matthew


-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Sunday, September 23, 2001 2:46 AM
To: ips@ece.cmu.edu
Subject: Re: iSCSI - positive data ack - change proposal


Here is updated version (in the previous I had excluded the sequences
ended
with Status with no good reason.

Julo

(See attached file: ack.txt)

----- Forwarded by Julian Satran/Haifa/IBM on 23-09-01 04:41 -----



                    Julian Satran

                                         To:     ips@ece.cmu.edu

                    22-09-2001           cc:

                    14:04                From:   Julian
Satran/Haifa/IBM@IBMIL
                                         Subject:     iSCSI - positive
data
ack - change
                                          proposal










Dear colleagues,

As  I mentioned earlier all the elements needed for positive data-ack
are
already in place.

I am suggesting the following changes to the document to reintroduce
the
data-ACK.

Comments?

Julo

**** Attachment ack.txt has been removed from this note on 23
September
2001 by Julian Satran ****