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

[julian_satran@il.ibm.com]

Santosh,

Case a is what we have today.

Status numbering is not meant for ordering - it is only a helper for ack
(bulk ack).

All the resources required for status retransmission are the control block
and the status,
If you give them up you give up all forms of recovery (as command retry
will not help either).

The only recovery path remaining is a SCSI timeout and probably some form
of task management clear (as SCSI does not know what went wrong).

That  is what I had in mind when I said that we can make it optional.

However - a long time ago when we suggested making it optional for targets
most of the list wanted it mandatory.

Julo


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

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

To:   ips@ece.cmu.edu
cc:
Subject:  Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"




Julian & All,

Do we agree on the following requirements for SNACK :

a) iSCSI MUST NOT mandate either data or status S[N]ACK for intra-task
error recovery. Initiators MUST be allowed to perform command
granularity error recovery.

b) iSCSI MUST provide a mechanism by which targets can continue with I/O
resource release upon completion of an I/O. Such a mechanism may be
based on an explicit StatSN acknowledgement, (if the target supports
StatSN SNACK), or allow immiediate resource clean-up upon I/O
completion.

c) Such a mechanism MUST NOT block forward progress when holes occur in
StatSN sequence, due to format or digest errors encountered at the
initiator.

In order to meet the above requirements, "StatSN S[N]ACK" support can be
negotiated at login time and if StatSN SNACK is not supported by the
target, it MUST NOT use StatSN sequence numbering. (i.e. StatSN = 0).

By not using StatSN numbering, the "holes in StatSN" problem does not
occur, thereby, meeting requirements (a) ,(b) & (c) for targets that do
not retain I/O state information.

For targets that do retain I/O state information, StatSn SNACK is turned
on along with StatSN numbering.

- Santosh


julian_satran@il.ibm.com wrote:
>
> Santosh,
>
> I have to think about it a bit more.  The main ack mechanism is ExpStatSN
> (as I indicated in a previous note).  SNACk is meant to simplify
recovering
> holes without having to reissue commands or wait for timeout. Rejecing
> SNACK with an "unsupported" indication but resending the status on
command
> retry can hardly be considered a good alternative while rejecting SNACK
> with "no status to recover" has to be bubbled up to SCSI and that can be
> bad for tapes.
> I think that if you keep status until ack-ed SNACK makes only life easier
> as it makes the recovery request explicit an specific - unlike the
command
> retry that is vague and unspecific.
>
> Julo
>
> Santosh Rao <santoshr@cup.hp.com> on 06/04/2001 20:26:47
>
> Please respond to Santosh Rao <santoshr@cup.hp.com>
>
> To:   Julian Satran/Haifa/IBM@IBMIL
> cc:   santoshr@cup.hp.com, David Black <Black_David@emc.com>
> Subject:  Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"
>
> Julian,
>
> I did not hear back on this and am re-sending in case you did not
> receive the same. Your comments would be appreciated.
>
> (Can you clarify if you intend to make the current SNACK mechanism
> optional and if so, how it is expected to solve the "holes in StatSN"
> problem for targets that don't implement StatSN SNACK ?)
>
> Regards,
> Santosh
>
>
-------------------------------------------------------------------------------------

>
> Subject:  Re: iSCSI ERT: data SACK/replay buffer/"semi-transport"
> Date:     Thu, 05 Apr 2001 19:22:09 -0700
> From:     Santosh Rao <santoshr@cup.hp.com>
> Organization: Hewlett Packard, Cupertino.
> To:       julian_satran@il.ibm.com
> CC:       ips@ece.cmu.edu
>
> julian_satran@il.ibm.com wrote:
> >
> > Santosh,
> >
> > SNACK and SACK are the same thing (I just renamed them to avoid
confusion
> > with TCP SACK).
> > The status is acked by ExpStatSN (and only indirectly by SNACK). SNACK
> > enables fast recovery of
> > a hole (whithout having to resort to a timeout).
>
> Julian,
>
> The bottom line is that the current SNACK mechanism as defined in the
> spec will NOT work if it is made optional, and at the same time, it is
> too expensive to mandate the SNACK mechanism.
>
> The current SNACK mechanism is really a negative ACK requesting the
> target to re-send the status PDU. This mechanism has 2 dis-advantages :
>
> a) requires targets to retain I/O state information until StatSN is
> acknowledged.
> b) Does not allow forward progress with the release of I/O resources in
> the event that a target could not retain that state information or for
> some other reason could not service the SNACK.
>
> I am suggesting that the alternate model of SACK be used, wherein, a
> SACK is an individual ACK of a received status PDU. This SACK only kicks
> in on detection of a hole. The hole is implicitly plugged by the
> initiator on eventual completion of the command
> [on timeout followed by abort or retry].
>
> The advantage of this alternate model is :
> a) Does not require state information to be stored at targets beyond I/O
> completion.
> b) Allows a more reliable mechanism of resource release.
>
> The dis-advantage of this mechanism is :
> a) It results in I/O timeout when Status PDU was dropped due to a digest
> error.
>
> Once again, the question boils down to the rate of TCP checksum escapes
> and the probability of such escapes affecting status PDUs. If this is
> low enough, such a timeout on a digest error of a status PDU should be
> acceptable.
>
> >  We decided long ago
> > against individual acks as bulk acking through a window is cheaper and
> > safer (repetition).
>
> I am not suggesting removal of bulk ack scheme. My suggestion is that
> SACK kick in on a hole and the initiator revert to bulk ACK scheme once
> it considers the hole to be plugged (thru the eventual completion of the
> I/O on the timeout path followed by abort or retry).
>
> - Santosh
>  - santoshr.vcf
 - santoshr.vcf