Subject: RE: iSCSI: SNACK R2T/Data

From: "Julian Satran" <[email-masked]>
Date: Wed, 19 Sep 2001 21:21:59 +0300

Matthew,

I am also in favor of such a mechanism.  It is easy to implement (another
form of SNACK) and we have already built-in a mechanism by which an inbound
stream can be marked for acking (the inbound sequence separator F bit).
It can also be specified as mandated only if the within-command recovery
class is present.

However I am reluctant to open again this issue except if there are more
supporters. Data ACKs where hastily dropped at the interim meeting in
Orlando.  I recall Somesh Gupta, Pierre Labat and Santosh Rao as being very
vocal against them (arguing complexity) and carrying the room with them.

Julo

                    "BURBRIDGE,MATTH                                                          
                    EW                     To:     Julian Satran/Haifa/IBM@IBMIL,             
                    (HP-UnitedKingdo        [email-masked]                                   
                    m,ex2)"                cc:                                                
                    <matthew_burbrid       Subject:     RE: iSCSI: SNACK R2T/Data             
                    [email-masked]>                                                                
                                                                                              
                    19-09-01 17:25                                                            
                    Please respond                                                            
                    to                                                                        
                    "BURBRIDGE,MATTH                                                          
                    EW                                                                        
                    (HP-UnitedKingdo                                                          
                    m,ex2)"                                                                   

I am very much in favour of having a positive ACK mechanism to control
buffer resources at the target.  If there is a very large transfer (e.g. 1
Mb) then the sender can release buffer space once it knows that the
receiver
has received the data.  It is worth pointing out that this mechanism is for
buffer control and is not for flow control which, as we all know, is
handled
by TCP.

Cheers

Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: [email-masked]

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 6:28 AM
To: [email-masked]
Subject: Re: iSCSI: SNACK R2T/Data

There is no ACK mechanism. The group wisdom was that there is no need for
one.
Incoming data and R2Ts are not acked (a mechanism that did that existed and
was based on NOP-Out).

Julo

Michael Schoberg <[email-masked]> on 18-09-2001 19:09:51

Please respond to Michael Schoberg <[email-masked]>

To:   "[email-masked]'" <[email-masked]>, Julian Satran/Haifa/IBM@IBMIL
cc:
Subject:  iSCSI: SNACK R2T/Data

Old subject, but I couldn't find any discussion on this:

When does the target know it no longer needs to hold R2T & Data PDUs?
StatSN responses are acknowledged through the ExpStatSN field received in
future I->T requests.  What's the acknowledgement method for R2T & Data
PDUs?  Is it tied to the original request and acknowledged through the
ExpStatSN acknowledgment of the request's response?

Thanks.

---

From: Santosh Rao <[email-masked]>
Date: Thu, 20 Sep 2001 08:54:43 -0700

Matthew,

We have gone through this thread of discussion regarding DataSNa long time back on
ips and the consensus has been that I/O transfer sizes  are not large enough to
justify OUT_OF_BAND acknowledgement of data. [achieved by having the initiator
generate NOP-OUTs in response to received data pdu's to send a DataSN ack.]

The primary dis-advantage with that scheme was that the data ack's were being
generated out-of-band, and therefore, implied extra cost in terms of initiator
resources for each I/O, as well as increased wire traffic per I/O, performance
penalty, etc.

I am opposed to the draft requiring initiators to send out-of-band ack's to data
pdu's through the use of initiator generated NOP-OUT pdus. This is a performance
penalty, a resource overhead, and not really justified in most I/O traffic due to
the avg. data xfer sizes.

Regards,
Santosh

---

From: "Somesh Gupta" <[email-masked]>
Date: Mon, 24 Sep 2001 19:05:56 -0700

I unfortunately have been busy elsewhere. Yes, I was, and continue to
be strenously opposed to complexity, and ACKs were a manifestation of
that.

Since we seem to be in a bit of a mudslinging mode here, the spec
now contains far more complexity than at that time (the consensus
of the room was not use to use ACKs, nobody imagined they would
come back as NACKs otherwise we would have gotten consensus
on that also).

Unfortunately, we will now end up with both ACKs and NACKs.
I feel this whole thing is based on some data and requirements
that are quite unconvincing.

Somesh

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Julian Satran
> Sent: Wednesday, September 19, 2001 11:22 AM
> To: [email-masked]
> Subject: RE: iSCSI: SNACK R2T/Data
> Importance: High
>
>
>
> Matthew,
>