Should SIP require detection of duplicate tags?

[Kurt Chan]

| Fiber Channel has the potential for out of order delivery which
| perhaps produces some nuance to duplicate tag detection.  

Only if it is on a switched fabric, and even then only if it is
allowed by the attached ports.  

o On a FC loop, traffic can be discarded but never misordered, regardless
  of the class of service

o On a FC fabric which supports in-order delivery, 
   - class 3 traffic can be discarded but can never be misordered
   - class 2 traffic can be guaranteed in order if transmitting ports do not
     attempt to retry frames when busied by the fabric or receiving port

o Even on a fabric which misorders, the Abort protocols account for
  misordering before reusing tags.

| An example of this could be that an initiator issues an abort
| intended to eliminate a tag followed by the reuse of a tag and the
| fabric is unkind enough to deliver the abort second.  If the system
| operated this way it could be desirable to have duplicated tag
| detection required.

In FCP, a Fibre Channel "Exchange" is analagous to a Tag.  In general,
SCSI Initiators will abort Exchanges than attempt to recover Sequences
within an Exchange.  The Abort protocols in FC go to great lengths to
ensure interlock so that, even in the event that the fabric is
misordering frames, the Initiator is not allowed to proceed until it
has received acknowledgement from the Target that the Tag has indeed
been aborted.

For connectionless classes of service, this protocol requires the
Initiator to invoke a timer before sending a signal which allows the
Target to reuse an Exchange ID. The timer value is provided by the
Fabric to represent a time after which no misordered frames can fall
out of the Fabric, regardless of queue times within the fabric or the
path taken. The requirement for Fabrics to discard frames which live
in the fabric for longer than the specified amount of time is also
fundamental to their reliable operation - no data integrity can be
guaranteed at all if this rule is not followed for connectionless
classes of service which can misorder.

REUSING an Exchange ID before full interlock has been achieved and the
recovery timer has elapsed is a gross violation of the FC protocol.
Honoring the requirement for Unique Exchange IDs is fundamental to the
correct operation of FC.  If it is not observed, there is almost
nothing the Target can do to prevent data corruption.

Furthermore, FC has yet another layer of protection around the Exchange ID,
which is to allow the Target to assign a 16-bit Responder Exchange ID to
complement the 16-bit Originator Exchange ID. Thus, not only would the
Originator need to corrupt it's OX_ID, but also the RX_ID assigned by
the Target!

This is not to say that there aren't ways that Exchange IDs could be
inadvertantly reused prematurely, only that the magnitude of this
error is catastrophic.  The irony is that we are assuming the only
danger here is of DUPLICATE tags.  In reality, the UNDETECTABLE
catastrophe is ALIASED tags - where the Originator reuses an OX_ID
that is already in use to that Target/Lun, and all the other Sequence
Qualifiers match up to a command in progress with the result be
undetected corruption of data.  Nothing the Target can do is able to
prevent this, yet it is probably a likely scenario in defective SW.

Bottom line - I believe as the speeds of our I/O increase to Gbit and
multi-Gbit proportions, our reliance and trust on Initiator integrity
is something we will have to place ourselves at the mercy of if we
want timely, cost-effective solutions.  If the protocols are "broken"
or too complex to implement reliably, then we should attempt to
simplify them (we've already done this in FCSI).  

However, the idea of changing an architecture to accomodate the
"defect of the week" is self-defeating since (IMHO) those attempts
rarely simplify, and usually complicate.

Regards,

Kurt ("why do my short postings end up sounding like a tirade?") Chan        
kc at core.rose.HP.com