Should SIP require detection of duplicate tags?

Gene Milligan Gene_Milligan at
Thu May 5 07:34:38 PDT 1994

Steve Finch wrote:
>Currently, SAM states that the requirement to detect duplicate tags is
>determined by the appropriate protocol standard.  The reason is that for
>some protocols the set of possible tags is enormous.
 I don't think this is the reason. Large tag values merely reduce the frequency
that a tag would have to be reused. I think the reason is that the
architectures are quite different. SBP doesn't have tags and therefore there
can not be a requirement to detect their duplicates. SBP has an equivalency, an
address. But the address can only contain one item not duplicates. Fiber
Channel has the potential for out of order delivery which perhaps produces some
nuance to duplicate tag detection.  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
>How bit is enormous?  SIP can have 15 initiators and up to 256 tags per
>initiator, for a total of 65,280 possible tags.  Is this enormous enough?
 Mox Nix
>There are only two conditions that duplicate tags will ever be issued:  a
>broken host computer, or a qualification program designed explicitly to
>test duplicate tag detection by a target.
 Another condition could be two initiators operating with the same ID due to
faulty jumpers or a broken SCAM.
>The real question is:  should a target device be REQUIRED to protect the
>system from an errant host who is issuing duplicate tags?  Yes, this
>capability would help detect strange errors like the host picking or
>dropping bits in hardware as it assigned tag numbers.  But if this is a
>concern, maybe we should add a command verification phase to SIP to make
>sure that the write he just issued was really to block 1354 and not 1350
>with a bit error.
>Why burden a target with the requirement to add a capability that is only
>needed if the system is broken?  No sane host ever issues duplicate tags,
>and insane hosts can do a lot worse things than sending duplicate tags.
 The answer to these arguments depends upon the application. Best effort to
guaranteed data integrity.
>Since SAM does not require duplicate tag detection, let's not require it in
 My first inclination is that SIP combined with SPI should equal SCSI-2 plus
specific enhancements voted in by acceptance of proposals.  It seems to me that
it would be very difficult to specify an interoperable method for handling
duplicate tags if they are not detected. I think I would have to see a very
detailed proposal of how to handle all the nuances of undetected duplicates. I
might agree to a proposal that makes it mandatory for initiators to never under
any circumstances to issue a duplicate tag and makes target detection optional
as long as what happens with the option is still specified. But why bother?
Gene Milligan -- Gene_Milligan at
Seagate Technology   -   920 Disc Drive   -   Scotts Valley, CA 95066 USA
Main Phone 408-438-6550   -   Email Problems postmaster at
Technical Support: BBS 408-438-8771  Fax 408-438-8137  Voice 408-438-8222  

### OGATE Version 8 message trace and attachment information:
### MsgFileName: m:\mgate\outbound\52.MSG
### Org Date:    05-05-94 06:54:32 AM
### From:        Gene Milligan at SEAGATE
### To:          scsi @ @ internet
### Subject:     Re: Should SIP require detection of duplicate tags?
### Attachments: none

More information about the T10 mailing list