Re: iSCSI: plugfest4 issues

[Luben Tuikov <luben@splentec.com>]

"Robert D. Russell" wrote:
> 
> 
> 3. Section 9.13.3 states:
>    "For a new session, the target MUST generate a non-zero TSIH and
>    return it in the Login Final-Response (see Section 4.3 Login Phase).
>    In all other cases, this field should be set to the TSIH provided
>    by the initiator in the Login Request."
> 
>    The phrase "in all other cases" is ambiguous.  Some companies are
>    interpreting it to mean "sessions other than a new session", while
>    others are interpreting it to mean "Login Responses other than
>    the Login Final-Response in a new session".
> 
>    So what is the intent?  On a new session, clearly the target MUST
>    return the non-zero TSIH in the Login Final-Response, but can it
>    also return a non-zero TSIH in the first, second, ... Login Partial
>    Responses that precede the Login Final-Response?

The intent is that for a new session the initiator MUST set
the TSIH to the reserved value of 0, during login. During login
the target will copy TSIH from the request to the response,
effectively setting it to 0.

On the last login response (the one which completes the switch
to FFP, I<-T), the target will set TSIH to a valid non-reserved
value (which it generated whenever).
From that point on the initiator should always set TSIH
to that value. (FFP, connection reinstatement, etc.)

Though not explicit, compiling everything mentioning TSIH
in the draft, evident this becomes.

> 4. There has been some misunderstanding with the phrase "not advanced".
>    For example, in section 9.8.2 StatSN it says:  "The StatSN field will
>    contain the next StatSN.  The StatSN for this connection is not
>    advanced."
> 
>    In spite of the presence of the word "next", some implementations are
>    interpreting this to mean that this PDU will always contain the same
>    value for StatSN as was sent in the previous response.  Perhaps it
>    would help if the words "after this PDU is sent" were added to the
>    last sentence quoted above so that it would read: "The StatSN for
>    this connection is not advanced after this PDU is sent."

Actually the above two sentences are correct and in harmony.

Anything SN in the draft, at any point in time, contains the
next value to be assigned. This is the intent, as counting starts
from 0 and setting xxxxSN = 0, works out as intended. This is also
deduced from looking at the equation which gives the queue size.

So particulartly for 9.8.2 (R2T) since no status is reported
one does (w.l.g.) packet->statsn = conn->statsn;
but when status is reported (w.l.g) MOV_AND_INC_SN(packet->statsn, conn->statsn),
which does an assignment (packet->statsn = conn->statsn) and increments
conn->statsn (over the reserved value of course) somewhat atomically.

The only difference is incrementing _after_ assignment, assignment
always being first.

Similarly for I->T, when I=0 and I=1, regarding cmdsn, etc.
 
>    section 9.19.2: "However, when the Initiator Task Tag is set to
>    0xffffffff,  StatSN for the connection is not advanced after this
>    PDU is sent."

Which makes sense, since if ITT = the reserved value, then
the Target is initiating the Nop sequence and it is NOT
reporting status.

-- 
Luben