Re: iSCSI: draft review - timers

[julian_satran@il.ibm.com]

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