Transport layer retries for targets

Ricky Nite Ricky.S.Nite at bitmicro.com
Thu Sep 15 07:19:47 PDT 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* "Ricky Nite" <Ricky.S.Nite at bitmicro.com>
*


Hello Randy, Dave,

These old docs might be helpful (just verify with the latest SAS spec):
http://www.t10.org/ftp/t10/document.03/03-229r1.pdf (p.26 Read DATA
Frame ACK Lost)
http://www.t10.org/ftp/t10/document.03/03-186r5.pdf (summary of SAS-1.0
behavior)

Ricky Nite
BiTMICRO


-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Randy
Chapman
Sent: Thursday, September 15, 2005 6:57 AM
To: t10 at t10.org
Subject: RE: Transport layer retries for targets

* From the T10 Reflector (t10 at t10.org), posted by:
* Randy Chapman <Randy_Chapman at pmc-sierra.com>
*
Thanks Brian.

-----Original Message-----
From: Day, Brian [mailto:Brian.Day at lsil.com]
Sent: Wednesday, September 14, 2005 3:41 PM
To: Randy Chapman; t10 at t10.org
Subject: RE: Transport layer retries for targets


Randy...

I do not believe you are referring to a valid balance point as defined
in section 9.2.6.3.3.4 of the latest SAS 1.1 rev 9e.
A balance point would be where there are no outstanding ACKs for any
frames transmitted.... the spec describes it more precisely than that.

In the example I believe you are suggesting, the target is sending the
data frames as non-interlocked, and sending them back to back without
waiting for the corresponding ACKs.  In this case, the most recent
balance point is before frame A, not after C.
So when it has the ACK/NAK timeout, it would need to resend starting at
frame A again.

The transport retries does handle the frames being lost as well.

Brian


-----Original Message-----
From: Randy Chapman [mailto:Randy_Chapman at pmc-sierra.com]
Sent: Wednesday, September 14, 2005 3:58 PM
To: t10 at t10.org
Subject: RE: Transport layer retries for targets

* From the T10 Reflector (t10 at t10.org), posted by:
* Randy Chapman <Randy_Chapman at pmc-sierra.com>
*
Hi Brian and Dave,

Consider the case where target sends A,B,C,D read DATA frames and, say,
C gets lost. Am I correct that the transport layers in fact can not
recover properly from this? Reason being, initiator sends 3 acks back to
target, target times out waiting for the 4th and thinks that the ack/nak
balance point is C, retransmits D. But, C was lost, not D. In this case
higher layers on the initiator have to re-issue the read command to
recover. Make sense?

Randy Chapman
PMC-Sierra Inc.

-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org]On Behalf Of Sluiter,
David
Sent: Wednesday, September 14, 2005 1:26 PM
To: Sluiter, David; t10 at t10.org
Subject: RE: Transport layer retries for targets


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sluiter, David" <dsluiter at exabyte.com>
*
Hi Brian,

Thanks for your reply.

Just to be clear, in my second question I meant that the target had
received
3 ACKS for frames A, B & D (ACK for frame C was lost) which the target
sees as ACKs for frames A, B & C (ACKs a, b & c), so the balance point
for the target is frame D, which is the one it should resend with
correct DATAOFFSET and CHANGING DATA POINTER set.

So anyways, what you're saying is that it doesn't matter to the
initiator that the ACKs are out of sync. The initiator relies on the
DATAOFFSET value and CHANGING DATA POINTER bit to straighten out its
buffer, which is cool.

Thanks,
Dave Sluiter
Exabyte
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



------------------------------------------------------------
CONFIDENTIALITY NOTICE
This email and any attached documents may be confidential
and property of BiTMICRO Networks, Inc. If you are not the
intended recipient, you may not disclose, copy, distribute,
or act in reliance on the information in this email.

Also note, this email and attached documents are scanned for
the presence of virus.  Changes made to this email after it
has been sent is not the responsibility of BiTMICRO Networks, Inc.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org





More information about the T10 mailing list