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

From: "Rod Harrison" <[email-masked]>
Date: Tue, 25 Sep 2001 21:45:35 +0100

John,

	I understand the difficulty with reconstructing data from the media,
I personally wouldn't attempt that in a target. I was under the
impression though that this was the Orlando WG consensus, forgive me
if I have misremembered.

	- Rod

-----Original Message-----
From: John Hufferd [mailto:[email-masked]]
Sent: Tuesday, September 25, 2001 9:02 PM
To: Rod Harrison
Cc: [email-masked]
Subject: RE: iSCSI - positive data ack - change proposal

Rod,
I think having iSCSI get the data off of the physical device to
respond to
a resend request, may add more complexity then you are currently
thinking
about.  That is because, it may be going back to get data that has
been
changed by a write that could have come in from another connection.
This
gets all very complicated to control.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

"Rod Harrison" <[email-masked]>@ece.cmu.edu on 09/25/2001
06:09:54 AM

Sent by:  [email-masked]

To:   Julian Satran/Haifa/IBM@IBMIL, <[email-masked]>
cc:
Subject:  RE: iSCSI - positive data ack - change proposal

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: [email-masked] [mailto:[email-masked]]On Behalf Of
Julian Satran
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: "John Hufferd" <[email-masked]>
Date: Tue, 25 Sep 2001 13:01:35 -0700

Rod,
I think having iSCSI get the data off of the physical device to respond to
a resend request, may add more complexity then you are currently thinking
about.  That is because, it may be going back to get data that has been
changed by a write that could have come in from another connection.  This
gets all very complicated to control.

.
.
.
John L. Hufferd

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

Matthew,

Julo

                    "BURBRIDGE,MATTH
                    EW                     To:     Julian
Satran/Haifa/IBM@IBMIL,

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

Julian

This looks good!

A couple of comments:

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

Julo

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

Dear colleagues,

Comments?

Julo