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

[julian_satran@il.ibm.com]

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.