Please review: Preliminary discussion of CRN approaches

Zeitler, Carl Carl.Zeitler at
Thu Jul 20 04:52:46 PDT 2000

* From the T10 Reflector (t10 at, posted by:
* "Zeitler, Carl" <Carl.Zeitler at>
See comments interspersed below.

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

-----Original Message-----
From: Robert Snively [mailto:rsnively at Brocade.COM]
Sent: Wednesday, July 19, 2000 2:52 PM
To: t10 at; fc at
Subject: Please review: Preliminary discussion of CRN approaches

* From the fc reflector, posted by:
* Robert Snively <rsnively at Brocade.COM>

Well, some of the information is in.  I am not counting votes yet (we will
do that at the FCP-2 meeting in Seattle), but I am filling out benefits
of each approach.  I am attributing these views as best I can. Note that
the rigorous ordering of awaiting command complete status is the presently
accepted mechanism for managing ordering, so that present day drivers 
do not require either type of CRN.  All of these discussions reference
implementations (or in some cases, implementations in late stages of

Please review these, fill in the holes, and get your views on the reflector

A)  Considerations on using CRN per target

    1)  Overview

	The implicit assumption is that by assuring the ordering of each
	command operation on an I_T nexus, the delivery to the logical unit
	will necessarily be correctly ordered.  To do this, a CRN on an
	I_T nexus basis would be appropriate. (Wakeley, 7/11)

    2)  Benefits of using CRN per target

	a)  Driver independence

		At present, there are no drivers that have any knowledge of
		CRN functionality.  Using CRN on an I_T nexus basis would
		allow the HBA to enforce ordering at a low level, without
		the awareness of the driver and without the requirement to
		rewrite the higher drivers for FC CRN use. (Wakeley, 7/11)

	b)  Interface independence

		At present, all the drivers for other interfaces do not
		an explicit indication of ordering for commands.  Since
		is no architectural support for CRN in any of the other
		SCSI technologies, it is unlikely that FC CRN drivers will
		created except for very special cases.  (Wakeley, 7/11)

**I fully agree with Mattt.  Furthermore, SCSI over VI over IB and SCSI over
TCP/IP will not require special ordering.  So that leaves Fibre Channel with
this unique ordering requirement at the application level.  Chances of our
favorite OS's changing to meet a unique FC requirement are slim to none.
Such a requirement will put us at a competitive disadvantage.

    3)  Problems of using CRN per target

	a)  Stalling of unaffected logical units

		A failing or missing command for one logical unit stalls
		all logical units, even those doing unrelated tasks
		managed by a different driver, until the failing one 
		is recovered. (Snively, 7/18)
**Right or wrong, I've always believed that performance in error situations
is not a priority, data integrity is.  If the link is lousy, performance
will be abysmal to worse, regardless of LUN or Target CRN orientation.  The
same holds true for congestion situations, but the argument is a little
weaker, i.e., frames get tossed in class 3 and busied and retransmitted in
Class 2.  Again your on the brink of or over the cliff and are in need of
some reconfiguration to really solve the problem.  Otherwise you are just
putting balm on the effects.  

	b)  Error recovery bypass of ordering

		The error recovery driver must selectively disable CRNs
		(I assume by posting a 0 value) to sneak stuff by the
		to complete the recovery for a logical unit. (Snively, 7/18)
**The use of CRN=0 is necessary for recovery, regardless of LUN or Target
orientation.  I don't see the difference.

	c)  Task management an exception for the I_T nexus

		Task management must still be outside the CRN structure in
		to perform some of the recovery mechanisms.  (Snively, 7/18)

**Correct, regardless of CRN orientation.

	d)  Requirement to support both ordered and non-ordered on same

		Bridge devices attach disk drives (no ordering requirements)
		tape drives (ordering requirements) behind a single target.
		them to both support target oriented CRNs is inappropriate. 
		(Baldwin, 7/18)

**Anyone who mixes data intensive tape and transaction oriented discs on the
same interface deserves what he gets, hopefully an education that you don't
mix the sheep and the goats, or you don't care about performance and cost is
overriding.  But again it is only in error situations where you get this
blocking effect.

		Note that this may be addressable by using the task ordering
		attributes to automatically include or exclude individual 
		commands from the ordering process (Snively, 7/19)

	e)  No protection for ordering problems outside the FC fabric.

		Some queue structures historically used in HBAs and in 
		targets do not enforce ordering.  The result is that the
		application's ordering requirements may be subverted by
		the driver to HBA queuing or by the target to logical unit
		queuing.  Note that more modern implementations may have
		cured all cases of this. (Snively, 7/19)

B)  Considerations on using CRN per LUN

    1)  Overview

	The explicit assumption is that any application that cares about
	ordering will provide ordering information that will be transported
to the
	only natural destination of an application request, the logical
	Logical units or operations that do not require such rigorous 
	verification of ordering will operate with the loose ordering 
	presently assumed for FC fabrics. (FCP-2r4)

    2)  Benefits of using CRN per LUN
	a)  Explicit low-level management of ordering
		Ordering can be applied as required for those logical units
		require it. (FCP-2r4, Baldwin 7/18)
**See A) 2) b) comment above.
	b)  Ordering protected across queue boundaries

		The desired ordering of commands from an application to a 
		logical unit is preserved independent of queuing issues 
		associated with application to driver queues, driver to
		HBA queues, fabric re-ordering, and target to logical unit
		(Snively 7/19)
**See A) 2) b) comment above.
    3)  Problems of using CRN per LUN

	a)  No drivers are available to pass CRN through to a logical unit.
	b)  Drivers will require FC specific capabilities to use CRN anyway.
		(Baldwin 7/18)
**I see no motivation to do this in the future.

**In summary I vote with Matt to use CRN on a Target basis.  

Bob Snively
Brocade Communications           Phone  408 487 8135
1901 Guadalupe Parkway
San Jose, CA 95131               Email   rsnively at
* 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