Transport layer retries

Sheffield, Robert L robert.l.sheffield at intel.com
Tue Aug 9 09:01:00 PDT 2005


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Robert L" <robert.l.sheffield at intel.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C59CFB.89CF6595
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

I konw there are folks out there who have thought about this a great
deal more than I have, but let me take a stab at it anyway...
I see a few possibilities with this one:
1 - Leave it to the marketplace. SCSI provides a number of configurable
(or not) options, and the standards don't even try to make sure that
what a target implements among those options is useful for an initiator
/ application. From that standpoint, if a target implements transsport
layer retries, it would make sense that it should allow the bit in the
mode page to be changeable so that the initiator could (and would if it
doesn't support TLR) turn off TLR. In fact - probably the default mode
for the target should probbly be TLR off - so an initiator that doesn't
know anything about TLR doesn't have to know to turn it off if the
initiator doesn't support it.
2 - If TLR is not supported by a target - then the bit has to be
non-changeable. After-all, setting the bit isn't going to magically
teach the target how to do TLR.
3 - SAS could stipulate that if a target implements TLR that the
enable/disable bit SHALL be changeable and default to disable. But why?
Market forces should be plenty adequate to ensure this is what's
implemented anyway - and does the standard really have to exclude a =
case
where someone really doesn't want to disable TLR (i.e. the target won't
work if the initiator doesn't support it too)?
4 - One could argue that a mode page is not the correct place to
enable/disable transport-layer retries. After all - transport layer
retries is a transport-layer function, not an application-layer
function. This was the argument used for first-burst disable. SAS
provides a transport-layer mechanism to prevent first-burst from being
used, just so the application layer doesn't have to get involved. Maybe
something similar could be established for SAS TLR - e.,g., a special
NAK (like RNAK)?)  that not only rejects a retry frame, but sends the
message that the device on the other end won't ever accept a retry
frame.
=20
That's about all I can figure on this one.
=20
Bob

  _____ =20

From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Bill
Martin
Sent: Tuesday, August 09, 2005 7:19 AM
To: t10 at t10.org
Subject: Transport layer retries



SAS 1.1 allows for discovery of whether a target supports transport
layer retries, but in the spirit of SCSI, the standard does not require
that the mode page bit be changeable.  In the event that the mode page
bit is not changeable, and the initiator does not support transport
layer retries, what is the mechanism for stopping continuous retries by
the target until a timeout occurs?  The definition of the retry
mechanism in 9.2.4.4.2 and 9.2.4.5.2 require that if retransmitted =
frame
is received the initiator shall operate on it properly.  Finally, the
number of times that a frame will be retransmitted is vendor specific,
so if the initiator sends NAK, it may be retried over and over.

=20

Thanks for any insight.

=20

Bill Martin
Sr. Principal Engineer
Standards and Interoperability
Sierra Logic, Inc.
916 772-3658

916 765-6875 (Cell)
bill_martin at sierralogic.com

=20


------_=_NextPart_001_01C59CFB.89CF6595
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>

<META content=3D"MSHTML 6.00.2900.2627" =
name=3DGENERATOR><o:SmartTagType=20
name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTag=
Type><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in =
1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: =
personal-compose
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D010294915-09082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I konw there are folks out there who have =
thought about=20
this a great deal more than I have, but let me take a stab at it=20
anyway...</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D010294915-09082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I see a few possibilities with this=20
one:</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D010294915-09082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>1 - Leave it to the marketplace. SCSI provides =
a number of=20
configurable (or not) options, and the standards don't&nbsp;even try to =
make=20
sure that what a target implements among those options is useful for an =

initiator / application. From that standpoint, if a target implements =
transsport=20
layer retries, it would make sense that it should allow the bit in the =
mode page=20
to be changeable so that the initiator could (and would if it doesn't =
support=20
TLR) turn off TLR. In fact - probably the default mode for the target =
should=20
probbly be TLR off - so an initiator that doesn't know anything about =
TLR=20
doesn't have to know to turn it off if the initiator doesn't support=20
it.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D010294915-09082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>2 - If TLR is not supported by a target - then =
the bit has=20
to be non-changeable. After-all, setting the bit isn't going to =
magically teach=20
the target how to do TLR.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D010294915-09082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>3 - SAS could stipulate that if a target =
implements TLR=20
that the enable/disable bit SHALL be changeable and default to disable. =
But why?=20
Market forces should be plenty adequate to ensure this is what's =
implemented=20
anyway - and does the standard really have to exclude a case where =
someone=20
really doesn't want to disable TLR (i.e. the target won't work if the =
initiator=20
doesn't support it too)?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D010294915-09082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>4 - One could argue that a mode page is not =
the correct=20
place to enable/disable transport-layer retries. After all - transport =
layer=20
retries is a transport-layer function, not an application-layer =
function. This=20
was the argument used for first-burst disable. SAS provides a =
transport-layer=20
mechanism to prevent first-burst from being used, just so the =
application layer=20
doesn't have to get involved. Maybe something similar could be =
established for=20
SAS TLR - e.,g., a special NAK (like RNAK)?) &nbsp;that not only =
rejects a retry=20
frame, but sends the message that the device on the other end won't =
ever accept=20
a retry frame.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D010294915-09082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D010294915-09082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>That's about all I can figure on this=20
one.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D010294915-09082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D010294915-09082005><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Bob</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> owner-t10 at t10.org=20
[mailto:owner-t10 at t10.org] <B>On Behalf Of </B>Bill =
Martin<BR><B>Sent:</B>=20
Tuesday, August 09, 2005 7:19 AM<BR><B>To:</B> =
t10 at t10.org<BR><B>Subject:</B>=20
Transport layer retries<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">SAS 1.1 allows for =
discovery of=20
whether a target supports transport layer retries, but in the spirit of =
SCSI,=20
the standard does not require that the mode page bit be =
changeable.&nbsp; In the=20
event that the mode page bit is not changeable, and the initiator does =
not=20
support transport layer retries, what is the mechanism for stopping =
continuous=20
retries by the target until a timeout occurs?&nbsp; The definition of =
the retry=20
mechanism in 9.2.4.4.2 and 9.2.4.5.2 require that if retransmitted =
frame is=20
received the initiator shall operate on it properly.&nbsp; Finally, the =
number=20
of times that a frame will be retransmitted is vendor specific, so if =
the=20
initiator sends NAK, it may be retried over and=20
over.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Thanks for any=20
insight.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><st1:PersonName w:st=3D"on"><FONT face=3DArial =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Bill=20
Martin</SPAN></FONT></st1:PersonName><BR><FONT face=3DArial =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">Sr. Principal =
Engineer<BR>Standards=20
and Interoperability<BR>Sierra Logic, Inc.<BR>916=20
772-3658</SPAN></FONT><o:p></o:p></P>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">916 765-6875=20
(Cell)<BR>bill_martin at sierralogic.com</SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BODY></HTML>

------_=_NextPart_001_01C59CFB.89CF6595--





More information about the T10 mailing list