Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"

[julian_satran@il.ibm.com]

I will clarify. Julo

Santosh Rao <santoshr@cup.hp.com> on 05/04/2001 03:06:10

Please respond to Santosh Rao <santoshr@cup.hp.com>

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   Jon Hall <jhall@emc.com>, ips@ece.cmu.edu
Subject:  Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"




Julian,


"6.7.1.1 Recovery Within-connection

   At the initiator, the following cases lend themselves to
within-connection recovery: (1)Lost iSCSI numbered Response recognized
by either receiving it with a data digest error or receiving a Response
PDU with a higher StatSN than expected. The initiator MAY request the
missing responses through SACK, in which case the target MUST reissue
them. "


To me, the following statement :
"The initiator MAY request the missing responses through SACK, in which
case the target MUST reissue them."

implies that the target MUST be able to re-issue a SCSI Response PDU,
when a Status SACK is received, which implies the target MUST maintain
the I/O state information around [until StatSN is acknowledged.]

Section 1.2.2.2 of my version of iSCSI rev 05 (taken from
http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-05.txt) reads
as follows :

"1.2.2.2 Response/Status Numbering and Acknowledging

   Responses in transit from the target to the initiator are numbered.
   The StatSN (Status Sequence Number) is used for this purpose. StatSN
   is a counter maintained per connection.  ExpStatSN is used by the
   initiator to acknowledge status.

   Status numbering starts after Login. During login, there is always
   only one outstanding command per connection and status numbering is
   not needed.
   The login response includes an initial value for status numbering.



Satran, J.       Standards-Track, Expire October 2001               12

                                iSCSI                   March 1, 2001


   To enable command recovery the target MAY maintain enough state
   information to enable data and status recovery after a connection
   failure.
   A target can discard all the state information maintained for
   recovery after the status delivery is acknowledged through ExpStatSN.
   A large difference between StatSN and ExpStatSN may indicate a failed
   connection.

   Initiators and Targets MUST support the response-numbering scheme. "


Can you please clarify where in the above section is there an example
that Status SACK can be rejected by targets ? Further, the Reject PDU
(Section 2.20.1) only allows a reject reason of Data SACK reject. There
is no reason code of "Status SACK Reject".

All this to me implies that Status SACK support is mandatory and targets
MUST maintain I/O state information until the StatSN is acknowledged.

Can you please clarify if this is not the case, and if so, what is the
intent of the above text ?

- Santosh


julian_satran@il.ibm.com wrote:
>
> Santosh,
>
> I can't find the place where this is stated. SNACK as a PDU type is
> mandated. But it can be rejected outright.
>
> 1.2.2.2 show explicitely that SACK can be rejected. We can add a protocol
> specific parameter in the target Logical Unit Control Page (non-setable)
by
> which the target will indicate support for SNACK.
>
> Julo
>
> Santosh Rao <santoshr@cup.hp.com> on 04/04/2001 23:53:32
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   Jon Hall <jhall@emc.com>, ips@ece.cmu.edu
> Subject:  Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"
>
> julian_satran@il.ibm.com wrote:
> >
> > Jon,
> >
> > Inexpensive implementation are always free to do away with recovery.
That
> > si true for targets too.
>
> That's not the interpretation one gets from reading the spec and prior
> discussions on this list. Per the spec, support for Status SACK is
> mandatory while support for data SACK is optional.
>
> IOW, targets MUST retains state information to satisfy a potential
> status SACK request.
>
> - Santosh
>
> > But not specifying the mechanism for the more expensive one we make
them
> > non-interoperable.
 - santoshr.vcf