Re: iSCSI: draft review - timers

[Matt Wakeley <matt_wakeley@agilent.com>]

Julo,

FC works as follows:
initiator sends a command to the target (the initiator task tag is the OX_ID)
opening a new exchange for the I/O.  The target may respond with it's RX_ID
(the "target task tag"), but it doesn't have to.  For example, if the command
was a target read, there is no need for the target to assign a RX_ID because
the initator will never send anything back to the target for the read
command.  Targets typically will assign a RX_ID for target writes when the
"transfer ready" is sent to the initiator. When the target sends the status,
it terminates the exchange.

If the initiator now sends the same command using the same OX_ID/RX_ID pair,
Fibre Channel target devices today will treat the command as a completely new
command.  There is no "task tag matching" across Fibre Channel Exchanges.
There is no way defined today for the target to "retry" the command, unless
FCP-2 error recovery is implemented, which is *very* stateful.

I'm sorry if you're not convinced, but that's the way the fibre channel world
works TODAY.

-Matt

julian_satran@il.ibm.com wrote:

> Matt,
>
> Your example is not convincing.    As long the tag is intact the FC
> end-node will know that this is a retry (the restart bit is somewhat of a
> luxury in iSCSI).  You might be right that requiring 3 timers is an
> overkill but why not
> let the gateway people among us tell us what they think.
>
> Regards,
> Julo
>
> Matt Wakeley <matt_wakeley@agilent.com> on 07/11/2000 22:04:05
>
> Please respond to Matt Wakeley <matt_wakeley@agilent.com>
>
> To:   IPS Reflector <ips@ece.cmu.edu>
> cc:
> Subject:  iSCSI: draft review - timers
>
> Section 1.2.3 Timers and timeouts says:
>
> >Initiators MUST implement the following timers:
> >
> >- T1 - Command delivery timer
> >- T2 - Status delivery timer
> >- T3 - Data delivery timer
>
> for the purpose of
>
> >Timers support recovery for gateways between an iSCSI transport
> >and an unreliable transport (e.g., FCP).
>
> with the action taken when they expire of:
>
> >At any timer expiration (timeout) the initiator must resend the
> >command or task management PDU with the restart bit set.
>
> I disagree with the logic of having these timers. If a gateway is
> translating between a reliable and an unreliable transport, it must
> also provide on it's own the recovery actions relating to that
> unreliable transport.
>
> For example, if the Status or Data delivery timer expires, the
> stated recovery is to resend the command with the restart bit set.
> However, this "restart" bit is only defined for iSCSI.  Other
> transports such as fibre channel know nothing about "restart" and
> thus this functionality is useless.
>
> Further, there is the argument:
>
> > The timers are meant to enable a gateway to FC to work stateless.
>
> The gateway to FC MUST be statefull.  Take this example:
>
> iSCSI sends a SCSI command to the gateway, and the gateway forwards
> it to FC.  Now, suppose the response gets trashed on the FC.  So the
> iSCSI initiator times out and will resend the command with the
> "restart" bit set.  Now, when then gateway receives the "restart"
> command, what is it going to do with it?  Let's say it statelessly
> retransmits the command.  There is no "restart" bit defined in FCP.
> So the effect is that the FC target will receive the command twice
> and perform the command twice.  Thus, the gateway MUST be statefull
> if the unreliable transport is to recover from errors - it must
> implement FCP2 error recovery!
>
> This is part of the "added value" of a gateway.  I do not see why
> iSCSI, which runs over a reliable transport, needs to be burdened
> with enabling unreliable transports via "stateless" gateways.
>
> -Matt Wakeley
> Agilent Technologies