FCP-2 problem

[Zeitler, Carl]

* From the T10 Reflector (t10 at t10.org), posted by:
* "Zeitler, Carl" <Carl.Zeitler at compaq.com>
*
Have been on vacation so missed out on all the fun.  I believe Matt's
solution works.  Another solution is to Abort the Exchange.  In other words,
if the Initiator receives an REC for any OX_ID currently in use, the
Initiator aborts the Exchange currently using the ambiguous OX_ID.  This is
a double error situation and had thought that we had agreed to do Abort
Exchange in double error situations at the last meeting. (It could be a
single error situation, where FCP_CONF is lost and the REC from the Target
and the new Command with the same OX_ID from the Initiator pass each other.
This could be mitigated by cycling OX_ID usage.)    

If there is no FCP_CONF, then the only solution I can think of is to not
reuse the OX_ID, as previously suggested, for >R_R_TOV.  However this
requires that the Target discard the context after R_R_TOV or you have the
same problem.  So the Target would have to guarantee that it shall discard
the context(a Class 3 Recovery Qualifier?) between R_R_TOV and R_R_TOV +
E_D_TOV(?).  And the Initiator shall not reuse the same OX_ID for R_R_TOV +
E_D_TOV(?).  

Working with only half a deck (no Class 2 ACKS)in error recovery situations
is a challenge.

Regards, Carl

Carl Zeitler
Compaq Computer Corporation
MS 150801, 20555 SH249, Houston, TX 77070
Phone:281-518-5258 Fax: 281-514-5270
E-Mail: Carl.Zeitler at compaq.com


-----Original Message-----
From: Matt Wakeley [mailto:matt_wakeley at agilent.com]
Sent: Wednesday, June 14, 2000 10:39 PM
To: Fibre Reflector; T10 Reflector
Subject: Re: FCP-2 problem


*
* From the fc reflector, posted by:
* Matt Wakeley <matt_wakeley at agilent.com>
*
> >Does use of FCP_CONF_REQ on the response resolve the issue? The target
will
> >release the resource after receiving FCP_CONF and the OXID is free. The
REC
> >sent after the lost command will then not receive an ACC, as the OXID is
> >invalid.


> I had kicked this idea around too. This makes it better, but not perfect.
The
> issue I came up with is:
>
> If the FCP_CONF and the second command are dropped, you have the same
problem.
> The REC will end up recovering the first command, while the initiator
thinks the
> second command has been completed.

One way to do this is, for commands that do not involve data transfer,
require that
the target request FCP_CONF, and require the initiator perform an REC after
sending
the FCP_CONF, to verify that the FCP_CONF got there before reusing the
OX_ID.  Ugly,
but I think it'll work if we don't want to change the REC or SRR payloads.

McGRATH:
>  So another solution is to make sure you
>  do not reuse an OX_ID until you are really sure that this sort of problem
>  cannot occur.

And how do you determine that?

> In this case, using two values in alteration would work OK.

I don't think so.  Consider the following:

Initiator sends SPACE command (OX_ID=1).

SPACE command completes, and target sends response (and keeps status of the
exchange
around).
<just for completeness, let's say the FCP_RSP requested a FCP_CONF, which
the
initiator sent, but was lost, so the target is retaining the status of
OX_ID=1>

Initiator sends WRITE command (OX_ID=2) (target is performing command
queuing, so
the status of exchage with OX_ID=1 is not deallocated)

WRITE command completes, and target sends response (and keeps status of the
exchange
around).

Initiator sends SPACE command (OX_ID=1), but the command is lost... same
issue as
before. The target still retains the state of the original space command.

-Matt Wakeley
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org