notes from FCL Error SSWG teleconference, 29 July 1997

Douglas Hagerman Hagerman at
Sun Aug 3 14:01:01 PDT 1997

* From the T10 (formerly SCSI) Reflector (t10 at, posted by:
* Douglas Hagerman <Hagerman at>
Notes from FCL Error SSWG teleconference, 29 July 1997.

Jim McGrath (Quantum) indicated that he would not be able to attend
the Fibre Channel meeting in Honolulu. Doug Hagerman (DEC) agreed to
write up some notes, which is what these are, and put them on the
FC reflector.

The discussion was held assuming familiarity with previous discussions,
mostly related to various "Problems with Tapes on Fibre Channel"
including the proposal T10/97-184R2.TXT which has been sent
to the reflector recently.

Neil Wannamaker (Crossroads) asked whether recovery should be done
at the sequence level or the exchange level, considering that PLDA
makes special definitions of how abort sequence works. In PLDA, if
a sequence is abort then the whole exchange is aborted. In the
proposals so far published, the exchange is still active after the ABTS.
He also wanted to know whether this approach would apply to XOR commands
used with disks.

Jim Coomes (Seagate) said that for one thing, the ULP will always need
to ultimately be able to recover from errors at the low level. He also
said that if a suitable low-level proposal could be developed, he would
expect a gradual migration of disks over to that protocol in some
cases, perhaps including XOR commands.

Bill Martin (Gadzoox) listed some of his concerns about the current
proposals, including:

- The RRQ process currently requires keeping track of too many timers,
especially if there are lots of errors and nesting gets deep.

- There is no question that ABTS must be supported (Doug had earlier
suggested its elimination) because it's required by FC-PH, it brings
some required features, and because it's built into existing hardware.

- The proposals need to basically re-do the work that the FCSI profile
developers did, because all the issues have previously been approached.
The only problem was that in the FCSI case the concept of recovery
within an exchange was rejected because only disks were being considered,
so if that's going to change then all the old FCSI issues need to be
looked at again.

- Regarding the need to always send an R_RDY before sending a frame
(to indicate the availability of buffer space for the expected ACK),
Bill described a situation using switches that gives a problem. Suppose
there is a loop attached to a fabric, with an NL_Port device on the loop.
Suppose some other devices on the fabric want to send some frames (say, 10)
to the device. The other devices send R_RDYs, then frames, to the fabric.
The R_RDYs indicate that the devices have buffer space for the expected
ACKs for those frames.

Then the fabric opens the loop, sends the R_RDYs to indicate
that it has buffer space for the ACKs it expects to receive, then sends
the frames to the device, then closes the loop. The NL_Port gets the
R_RDYs and frames, then opens the loop to send the ACKs back to the
switch which will then send ACKs back to the original devices that sent
the frames in the first place.

The original devices that send the frames have control over
how many frames they send and can thus maintain the required ACK buffer
space. However, the switch doesn't throttle incoming frames so it
can't reserve the required ACK buffer space.

The group did not have any clean answer to this, although it appeared to
several participants that on the surface it seems like it would actually
be possible for the switch to only accept incoming Class 2 frames if
it had buffer space both for the frame itself and for the ACK it expects
to receive as a result of forwarding the frame to the recipient. The issue
requires more clarification, particularly with comment from switch

The discussion moved on to the question of in-order delivery. Doug had
outlined a method for keeping track of where incoming user data is to
be stored using the existing FC-PH relative offset mechanism. Jim Coomes
asked whether it would be easier to continue to use the guaranteed
in-order delivery specified by FLA, which makes it easier to keep
track of where to store the data. Relative offset is not implemented
in current chips.

Bill pointed out that if that is the rule, then there is a possible
performance problem if you BSY or RJT a frame. For example, suppose you
reject the second of three in-order frames. Then the sequence count
gets mixed up and you need to do an ABTS. Several people mentioned that
the switch vendors had recently said that they would only do in-order
delivery anyway, so it will not be a problem. The question is whether
in a mixed-vendor fabric it is possible to guarantee in-order delivery.
Doug suggested that at T11 it be asked whether the switch vendors
are willing to make a formal declaration that in-order delivery is to
be considered a basic concept of all Fibre Channel Fabric implementations,
and that the protocols may make that assumption.

Further discussion of these topics will be held during the T11 meeting
during the first week of August.

Doug Hagerman
Storage Architecture
Digital Equipment Corporation
+1 508 841 2145
please reply to hagerman at
regardless of what the reply-to: field says
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list