Re: iSCSI - change - negotiation reset

[Santosh Rao <santoshr@cup.hp.com>]

Julian,

Please see comments below.

- Santosh


Julian Satran wrote:

> 3.10.3 Target Transfer Tag
> 
> When the Target Transfer Tag is set to the reserved value 0xffffffff, it tells the target that this is a new request and the target should reset any internal state associated with the Initiator Task Tag.

I believe the above is in violation with general protocol rules
regarding uniqueness of task tags. initiator Task Tags are required to
be unique for a given initiator and it should be considered a protocol
error when an initiator re-uses an initiator task tag while a prior
instance of the task tag is still active at the target.

Such re-uses of an active task tag by an initiator are REJECTed by the
target with a reason of "protocol error" or "task in progress". (It is
also not clear which of the 2 reason codes is to be used in this case
?).

In general, task tag resources MUST NOT be reused by initiators without
first ensuring that their prior usage had been completed, either through
successful completion of the prior task, or a completed error recovery
of the prior task through an Abort Task or some higher recovery
mechanism such as session teardown.

I suggest that operational parameters be cleared by an initiator by
either issuing an Abort Task for the text command, or tearing down the
connection, or re-negotiating new parameters and the above special-cased
rule be removed.


> Long text responses are handled as in the following example:
> 
> I->T Text SendTargets=all (F=1,TTT=0xffffffff)
> T->I Text <part 1> (F=0,TTT=0x12345678)
> I->T Text <empty> (F=1, TTT=0x12345678)
> T->I Text <part 2> (F=0, TTT=0x12345678)
> I->T Text <empty> (F=1, TTT=0x12345678)
> ...
> T->I Text <part n> (F=1, TTT=0xffffffff)

Regarding the above description of long text exchange handling, is it a
requirement that the initiator should send an EMPTY text command in
response to a long text response ? Can it originate any keys or respond
to any keys in continuing a long text exchange ? (This would occur on
long text exchanges involving X-* keys, and not SendTargets).



> Text response PDU

> 3.11.3 Target Transfer Tag
> 
> If the target receives a Text Request with the Target Task Tag set to the reserved value of 0xffffffff it resets its internal state associated with the given Initiator Task 
Tag.


Please see above comments on this rule. It violates "unique task tag"
protocol rules & requires targets to special case the handling of task
tags.
 

> 
> ---------------------------------
> 
> 3.17 Reject
> 
> Byte /    0       |       1       |       2       |       3       |
>    /              |               |               |               |
>   |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
>   +---------------+---------------+---------------+---------------+
>  0|1|1| 0x3f      |1| Reserved    | Reason        | Reserved      |
>   +---------------+---------------+---------------+---------------+
>  4| Reserved      | DataSegmentLength                             |
>   +---------------+---------------+---------------+---------------+
>  8/ Reserved                                                      /
>  +/                                                               /
>   +---------------+---------------+---------------+---------------+
> 24| StatSN                                                        |
>   +---------------+---------------+---------------+---------------+
> 28| ExpCmdSN                                                      |
>   +---------------+---------------+---------------+---------------+
> 32| MaxCmdSN                                                      |
>   +---------------+---------------+---------------+---------------+
> 36| DataSN or Reserved                                            |
>   +---------------+---------------+---------------+---------------+
> 40| Reserved                                                      |
>   +---------------+---------------+---------------+---------------+
> 44| Reserved                                                      |
>   +---------------+---------------+---------------+---------------+
> 48| Digest (if any)                                               |
>   +---------------+---------------+---------------+---------------+
> xx/ Complete Header of Bad PDU                                    /
>  +/                                                               /
>   +---------------+---------------+---------------+---------------+
> yy/Vendor specific data (if any)                                  /
>   /                                                               /
>   +---------------+---------------+---------------+---------------+
> zz
> 
> Reject is used to indicate an iSCSI error condition (protocol, unsupported option etc.).
> 
> 3.17.1 Reason
> 
> The reject Reason is coded as follows:
> 
> 
> +------+-----------------------------------------+------------------+
> | Code | Explanation                             | Can the original |
> | (hex)|                                         | PDU be re-sent?  |
> +------+-----------------------------------------+------------------+
> | 0x01 | Full Feature Phase Command before login | no               |
> |      |                                         |                  |
> | 0x02 | Data (payload) Digest Error             | yes  (Note 1)    |
> |      |                                         |                  |
> | 0x03 | Data-SNACK Reject                       | yes              |
> |      |                                         |                  |
> | 0x04 | Protocol Error (e.g., SNACK request for | no               |
> |      | a status that was already acknowledged) |                  |
> |      |                                         |                  |
> | 0x05 | Command not supported in this session   | no               |
> |      | type                                    |                  |
> |      |                                         |                  |
> | 0x06 | Immediate Command Reject - too many     | yes              |
> |      | immediate commands                      |                  |
> |      |                                         |                  |
> | 0x07 | Task in progress                        | no               |
> |      |                                         |                  |
> | 0x08 | Invalid SNACK                           | no               |
> |      |                                         |                  |
> | 0x09 | Target Transfer Tag Reject for this     | no               |
> |      | Initiator Task Tag                      |                  |
> |      |                                         |                  |
> | 0x0a | Long Operation Reject - Can't generate  | yes              |
> |      | Target Transfer Tag - out of resources  |                  |
> |      |                                         |                  |
> | 0x0b | Negotiation Reset                       | no              |
> +------+-----------------------------------------+------------------+

It is still not clear on when the target would need to use a
"Negotiation Reset" reject reason code. Any reject from the target of a
text command results in a reset of operational parameters and an
explicit reason code such as "Negotiation Reset" is not required.



> ----------------------------------
> 6. Operational Parameter Negotiation Outside the Login Phase
> 
> An initiator MAY reset an operational parameter negotiation by issuing a Text request with the Target Transfer Tag set to the value 0xffffffff after receiving a response with the Target Transfer Tag set to a value other than 0xffffffff.  A target may reset an operational parameter negotiation by answering a Text request with a Reject.

I suggest the above rule not be allowed, since it special cases the
protocol handling of "non-unique task tags".


-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################