Re: iSCSI: cmd_sn management on rejected PDUs

[Luben Tuikov <luben@splentec.com>]

"Pittman, Joseph" wrote:
> 
> I have a question about sequence number management when
> command PDUs are rejected.
> 
> If an initiator sends a non-immediate command PDU which the
> target rejects, does this command consume a cmd_sn?  For
> example, consider this case:
> 
>   - initiator sends a non-immediate text request with a
>     non-zero target transfer tag, sequence number 37
>   - target looks up the target transfer tag, doesn't recognize
>     it, and generates a reject/UNKNOWN_TT_TAG message
> 
> Should the next command PDU sent by initiator use cmd_sn=37
> or cmd_sn=38?

Draft 10, pg. 28:
  The target iSCSI layer sets ExpCmdSN to the largest
non-immediate CmdSN that it can deliver for execution
plus 1 (no holes in the CmdSN sequence).

Thus, if everything was normal before the initiator sent
the buggy PDU w/ CmdSn 37, then ExpCmdSN at the target
will not change, and be 37.

Previously at the initiator ExpCmdSN was 37 (if all was ok
before that), and you'd apply the rules on page 29. Let's
do the last one (more general):

Initiator upon recv. Rej. PDU:
 IF Rej. PDU ExpCmdSN (=37) < ExpCmdSN (=37) THEN
    Ignore
 ELSE
    ExpCmdSN = PDU ExpCmdSN
 ENDIF

So, ExpCmdSN at the initiator is now still 37,
and the next PDU the initiator will send will bear CmdSN 37.

This solves the problem of cycling through CmdSN too quickly.
In a large network (say company X, doing video editing), 32 bits
is too small and we don't want to go through them too quickly.

The above IF THEN ELSE can be optimized to <= and thus
is equivalent to:
  IF Rej. PDU ExpCmdSN > ExpCmdSN THEN
     ExpCmdSN = PDU ExpCmdSN
  ENDIF

At which point the text will have to say 
``If ... less than or equal ... then it is ignored ...''.

P.S. All integer comparisons are in terms of RFC1982.

-- 
Luben