RE: iSCSI - positive data ack - change proposal

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

Mathew,

	Do you think my suggestion about using NOPs is adequate for things
like tape streaming?

	By the way, I think 128K might be a little small? I've seen quite a
few implementations negotiating 64K PDUs, so you'd get an ACK every
two DATA-INs.

	- Rod

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:matthew_burbridge@hp.com]
Sent: Tuesday, September 25, 2001 12:55 PM
To: 'Rod Harrison'; 'Julian Satran'; ips@ece.cmu.edu
Subject: RE: iSCSI - positive data ack - change proposal


Hi Rod,

I agree with what you say especially with the smaller data transfers.
For
large transfers (e.g. tape streaming) then I still think positive ACKs
are
useful and having an ACK say every 128K is not too much to ask for in
terms
of initiator processing and bandwidth.

I do think that overriding the F bit is a restriction and a new bit
should
be created.  A new bit would allow target implementations to use it if
they
desired.  Overriding the F bit is open to bandwidth abuse.

Cheers

Matthew

-----Original Message-----
From: Rod Harrison [mailto:rod.harrison@windriver.com]
Sent: Tuesday, September 25, 2001 12:43 PM
To: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2); 'Julian Satran';
ips@ece.cmu.edu
Subject: RE: iSCSI - positive data ack - change proposal



	I don't believe this proposal adequately protects the target from
resource limitations. This works fine for 1 long running read command,
but what about a full command window of read commands each taking 50
or even just 10 DATA-IN PDUs?

	Seems to me that the target will have to be so conservative that it
will end up setting the F bit on almost every DATA-IN, or at least
every few. If we end up with that many data ACKs we might as well go
along with Santosh's proposal of in-band ACKing.  Although I have to
admit I don't see how missing DATA-IN PDUs can be detected with
in-band ACKs since the next DataSN on a given command can't be
predicted. I suppose we could add a previousDataSN to the DATA-IN PDU.
I would prefer to see data ACKs dropped.

	- Rod

-----Original Message-----
From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
Sent: Monday, September 24, 2001 11:39 AM
To: 'Julian Satran'; ips@ece.cmu.edu
Subject: RE: iSCSI - positive data ack - change proposal


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