RE: iSCSI: SNACK R2T/Data

["Somesh Gupta" <somesh_gupta@silverbacksystems.com>]

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

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> Julian Satran
> Sent: Wednesday, September 19, 2001 11:22 AM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: SNACK R2T/Data
> Importance: High
>
>
>
> 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.
>
>
>
>
>
>