Re: iSCSI: SNACK R2T/Data

[Santosh Rao <santoshr@cup.hp.com>]

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


Julian Satran wrote:

> 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        ips@ece.cmu.edu
>                     m,ex2)"                cc:
>                     <matthew_burbrid       Subject:     RE: iSCSI: SNACK R2T/Data
>                     ge@hp.com>
>
>                     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: matthewb@bri.hp.com
>
> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Wednesday, September 19, 2001 6:28 AM
> To: ips@ece.cmu.edu
> 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 <michael_schoberg@cnt.com> on 18-09-2001 19:09:51
>
> Please respond to Michael Schoberg <michael_schoberg@cnt.com>
>
> To:   "'ips@ece.cmu.edu'" <ips@ece.cmu.edu>, 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.
begin:vcard 
n:Rao;Santosh 
tel;work:408-447-3751
x-mozilla-html:FALSE
org:Hewlett Packard, Cupertino.;SISL
adr:;;19420, Homestead Road, M\S 43LN,	;Cupertino.;CA.;95014.;USA.
version:2.1
email;internet:santoshr@cup.hp.com
title:Software Design Engineer
x-mozilla-cpt:;21088
fn:Santosh Rao
end:vcard