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

[julian_satran@il.ibm.com]

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