Subject: RE: iSCSI - positive data ack - change proposal

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Tue, 25 Sep 2001 14:37:54 +0100

Julian, Rod, et al.

I agree since there is alot of objection for positive ACKs and I hear very
few voices for, then it does seem better to leave it out especially as I do
not have a refererence model to try it out.  If it does start proving to be
a problem then we can re-visit it then.

Cheers

Matthew

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, September 25, 2001 1:02 PM
To: [email-masked]
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        [email-masked]

                    m,ex2)"                cc:

                    <matthew_burbrid       Subject:     RE: iSCSI - positive
data ack -      
                    [email-masked]>              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:[email-masked]]
Sent: Sunday, September 23, 2001 2:46 AM
To: [email-masked]
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:     [email-masked]

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

---

From: Santosh Rao <[email-masked]>
Date: Tue, 25 Sep 2001 09:58:46 -0700

All,

I hear at least 3 voices (Rod Harrison, Somesh Gupta, myself) who are still
against the proposal to provide data acks and Matthew Burbridge seems willing
to forgo his request below. Why are we re-opening this issue and questioning
the Orlando WG consensus on this issue ? What is the process to re-visit a
prior WG consensus that has been reached on any issue ?

I feel that we should focus on simplifying the draft at this late stage and not
continue to add new features. Any such new features, if required, could be
addressed in a subsequent rev of the draft. Continuing to add new features at
this late stage will only slow us down further.

Thanks,
Santosh