|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 ****
Home Last updated: Tue Sep 25 14:17:19 2001 6723 messages in chronological order |