SAS-2: Comment on proposal 90r1: SAS-2 Transmit Identify Three Times

Elliott, Robert (Server Storage) Elliott at
Wed Jun 20 11:43:21 PDT 2007

Formatted message: <A HREF="r0706202_f.htm">HTML-formatted message</A>

	From: owner-t10 at [mailto:owner-t10 at] On Behalf Of
Stephen FINCH
	Sent: Wednesday, June 20, 2007 9:30 AM
	To: T10 Reflector
	Subject: SAS-2: Comment on proposal 90r1: SAS-2 Transmit
Identify Three Times
	I haven't seen an update on this proposal, but I did want to see
some discussion prior to the T10 week, so here goes.
	In SAS-2 today a phy sends only one Identify frame and makes one
attempt to receive an Identify.  If the phy receives an SOAF and that
address frame is of the wrong length or has incorrect CRC, the reception
attempt fails and the exchange of the Identify frame fails.  The phy
does not go into normal operation and a phy reset sequence is the only
option for recovery. 
RE: Although that's how the standard is worded, I suspect some receivers
do not give up after the first SOAF, since it differs from how they
parse OPEN address frames.
	The goal, as I understand it, is to allow (not require) a phy to
send its Identify frame three times and to allow it to discard invalid
frames and not treat the detection of an invalid frame as a fatal error.
The reception process would time out if no Identify frame was received
before the Receive Identify Timeout timer times out.
RE: Correct.
	The issues, as I see them are:
	1.  There is no timing specified as to the repetition of
Identify frames.  
	The Identify frames could be sent back-to-back, with no
intervening idle dwords, or they could be spaced far apart, up to
something just short of the Receive Identify Timeout period.   
RE: That is the intent. 
	It appears there are implementations that are not capable of
receiving back-to-back frames with no intervening idle dwords.	If a phy
with such a receiver were connected to a phy that transmitted the
Identify three times in a row without intervening idle dwords, then the
goal of this proposal would not be obtained. 
RE: Any design like that is not compliant with current SAS rules.  In
SAS we avoided including any arbitrary delays in the protocol - we allow
SSP frames to be sent back-to-back (... EOF SOF ...), ACKs and RRDYs to
be back-to-back, etc.
Since there are only two address frames so far (IDENTIFY and OPEN),
back-to-back address frames are rare so far.
This is legal today:
(SOAF ...IDENTIFY address frame ... EOAF) (SOAF ... OPEN address frame
... EOAF)
An expander can almost send back-to-back OPEN address frames in an
unusual case:
1. End device sends an OPEN address frame to an expander.
2. Expander sends an OPEN address frame to the end device  This is
slightly later than #1, but "crossing-on-the-wire".
3. Expander and end device determine that the expander's OPEN loses the
crossing-on-the-wire comparison, so the expander responds with AIP.
4. The expander decides that it has a higher priority OPEN to send out
instead, so sends out a new OPEN address frame.
The AIP always occurs, so the expander would not send out the second
OPEN address frame directly back-to-back.  In SAS-1, only one AIP was
required; in SAS-1.1, three AIPs were recommended; in SAS-2, three AIPs
are required.  If a bit error occurs and only one AIP is sent, the
receiver will see the second OPEN address frame back-to-back (with only
an invalid dword in between).  Depending on the design, the link layer
logic might see the frames as being back-to-back.
	I see no advantage to sending the multiple Identifies with
"significant" time delay between them.
	I would propose that, if a phy transmits three Identifies that a
minimum of six idle dwords be transmitted between the Identify frames
and no more that 16 idle dwords be transmitted between Identify frames.
(If these numbers aren't agreeable, let's find numbers that are.) 
RE: The minimum number should be zero.	See below concerning maximum.
	2.  If one side transmits the Identify three times and the other
side only once, then the side that send only one will enable its higher
layer protocol state machines after sending only one.  It is possible
(and I can argue probable if the phy reset sequence occurred as a link
recovery event) that the phy sending only one Identify could send an
Open Address frame before the phy sending three Identify frames has
entered normal operation.  This would result in a timeout of an Open
RE: Once the IDENTIFYs are started, there is an implied requirement of 1
ms to complete them (because the receiver is known to timeout).   Since
OPEN waits 1 ms for a response and the IDENTIFYs will be done within 1
ms, there is some some time left for the OPEN response.  The recipient
with the shorted response time is the one that was slow in sending out
IDENTIFYs, so it should know to penalize itself and respond faster.
On 3/7/2005, discussing 05-086, the WG voted 9-3 to not define
transmitter time limits to make implicit rules like that explicit
(generally: a transmitter must complete its action within 0.5 ms if the
receiver is enforcing a 1 ms timeout) (see minutes in 05-094).	I would
still like to see that change, but have no reason to believe a revived
proposal would be better received.  If we don't define maximum
transmitter times in all other parts of SAS, then the identification
sequence shouldn't have them either.
	 Not an unrecoverable event, but still not a desirable event
either.  So, should we require all phys to not send an Open Address
frame until some time frame after the successful exchange of an
Identify?  Like 1 ms? 
RE: I'd prefer not to add an arbitrary delay.
SI_IR_IRC could declare to the link layer that it's ready to go after
transmitting one of three IDENTIFY address frames (rather than waiting
for all three) and receiving one IDENTIFY address frame; the other two
IDENTIFYs would still be sent, but SI_IR_IRC wouldn't wait for them.
	One last question, should all SAS-2 compliant devices be
required to send three Identify frames?
RE: No, I think it is too late and not important enough to mandate.  I
propose it be optional in SAS-2 and mandatory in the next version.
	Additional note:  The text and state changes to the IR state
machines (3 of them), as they appear in the latest proposal, are not
sufficient.  If we can agree to the above issues, then we can work on
these issues.
RE: We could modify SI_IR_IRC as suggested.  What else do you think is
"not sufficient"?
	Steve Finch
Rob Elliott, elliott at 
Hewlett-Packard Industry Standard Server Storage Advanced Technology 

More information about the T10 mailing list