RE: iSCSI - positive data ack - change proposal

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

Julian,

	You did, and this is the reply I sent you ...

	"If there are holes in the data sequence the initiator will send a
SNACK before it process the NOP-IN, the target will see this and not
discard that data. Remember that a SNAK effectively ACKs everything up
to the BegRun point.

	Think of the NOP mechanism as something like a sync point, when the
target receives the response it knows the initiator has at least seen
all the data up to the point the NOP was sent. I understand that this
doesn't guarantee the data is in host memory, but the chances of the
initiator needing to SNAK after receiving the data is small."

	I don't really want to argue in favour of doing things this way with
NOP, it was meant to be a way out of tight corner if we have no data
ACKs.

	The basic question still remains, do we need to ACK DATA-IN or not?
If the consensus is that we do, we can move forward and figure out the
best way to send the ACKs, rather than defining a mechanism we might
not use.

	- 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 7:51 PM
To: ips@ece.cmu.edu
Subject: RE: iSCSI - positive data ack - change proposal



Rod,

I have a long day and I intended to answer you but I  don't recall if
I
did.
If I did I apologize for the duplicate.

If I did not here it is:

-1) The NOP just won't do it. NOP does not help detecting holes due to
digest failures and that is the main reason target
is keeping data buffers (if it can't recover them from the media -
like
from a tape) - to be able to ship them for SNACK.


-2) The traffic argument is minor - as I said earlier the ACKs are no
more
or less desirable than R2T. An extremely conservative target may issue
an
R2T for every PDU. Should we be concerned? All the rest of the
mechanisms
are already there.

The target will not stop transmitting data (speed will not be
affected) as
Matthew suggested.

Julo



                    "Rod Harrison"
                    <rod.harrison@wind       To:     Julian
Satran/Haifa/IBM@IBMIL,
                    river.com>                <ips@ece.cmu.edu>
                                             cc:
                    25-09-01 19:21           Subject:     RE: iSCSI -
positive data ack -
                    Please respond to         change proposal
                    "Rod Harrison"





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 ****