Transport layer retries for targets

Randy Chapman Randy_Chapman at pmc-sierra.com
Wed Sep 14 14:57:54 PDT 2005


* 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





More information about the T10 mailing list