ADT Questions/Comments

Banther, Michael michael.banther at hp.com
Tue Jan 6 10:31:43 PST 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* "Banther, Michael" <michael.banther at hp.com>
*
This is a multi-part message in MIME format.

------_=_NextPart_001_01C3D483.55595A7A
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C3D483.55595A7A"


------_=_NextPart_002_01C3D483.55595A7A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Some of the engineers here have raised several questions/comments that
I'd like the ADI Working Group to consider:

1.	How should a port respond if it receives a SCSI Data IU when it
should receive a SCSI Transfer Ready IU and vice versa?  Possibilities
include NAK, ACK and discard, or ACK and terminate the task.=20
2.	If a port has received multiple non-acknowledged IU's in an
exchange due to a Maximum ACK Offset greater than one and it NAK's the
first of these IU's with PR equal zero, how should it respond to the
remaining IU's?  Remember that the sending port may have a subsequent =
IU
for the exchange in flight at the time the receiver sends the NAK.  Can
the sender continue the exchange?  If it does, how does it indicate to
the receiver that higher-level error recovery has completed and that =
the
subsequent frames are a retransmission rather than just the tail of the
multiple IU's sent before the sender received the NAK?=20
3.	Why is the Data Length field in the SCSI Data IU four bytes long
when the Payload Size field in the ADT header is only two bytes long?
Probably not a critical problem, but it does seem a bit odd.=20
4.	The SCSI Transfer Ready IU includes a Buffer Offset field.  The
description of this field includes the text, 'this field can be used to
recover from an error detected in transmission by allowing the receiver
of the data to request re-transmission of the previous burst of data.'
Under what conditions can the sender of the SCSI Transfer Ready IU
request re-transmission?  Even more important, under what conditions =
can
it not make such a request?  If the sender can request re-transmission
after responding to previous SCSI Data IU's with ACK's, a corner case
appears where the initiator can request re-transmission of Data In =
after
the target closes the exchange by sending a SCSI Response IU.=20
5.	The definition of exchange lifetimes contains a problem.  Under
the current definition, the exchange closes in the target when the
target sends a SCSI Response IU.  What happens if the initiator NAK's
the SCSI Response IU with PR equal to zero?  The target cannot abort =
the
associated SCSI task because the task has already ceased to exist, =
i.e.,
the target cannot send another SCSI Response IU with ABORTED status.
Also, the current definition allows the initiator to open another
exchange with the same Exchange ID even though the target hasn't
received the acknowledgement for the previous SCSI Response IU.  Since
the target cannot destroy the SCSI Response IU until it receives an =
ACK,
the possibility exists of the target containing two IU's with the same
Exchange ID for two different exchanges.=20
6.	Although I can't be sure without seeing ADTr10, I think that a
gap exists in the handling of the Expected Frame Number Counter.  Based
on 04-003r1, sub-clause 4.6.3 refers to sub-clause 4.7 for how the
receiver should set the Expected Frame Number counter during error
recovery.  However, neither ADTr09 nor 03-355r5 include text stating =
how
to set the Expected Frame Number Counter during error recovery.=20
7.	Sub-clause 4.7.2.1 states that the sender of a frame NAK'ed with
PR equal to one, 'shall retry sending the frame at least once and no
more than four times.'  If all attempts to re-send the frame result in
an ACK for the Initiate Recovery IU and a NAK with PR equal to one for
the frame, after the last re-send the target port will be in R1: =
Pending
Recovery state.  How does it exit that state?

That's the list so far.  We may come up with a few more before Friday.
If so I'll pass them on.
=20
Cheers,
Michael Banther
Hewlett-Packard Ltd.
Telephone +44 (117) 312-9503
=20

------_=_NextPart_002_01C3D483.55595A7A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

 Message Some of the engineers here have raised = several=20 questions/comments that I'd like the ADI Working Group to=20 consider:
 How should a=20 port respond if it receives a SCSI Data IU when it should receive a = SCSI=20 Transfer Ready IU and vice versa?  Possibilities include NAK, = ACK and=20 discard, or ACK and terminate the task. If a port has=20 received multiple non-acknowledged IU's in an exchange due to a = Maximum ACK=20 Offset greater than one and it NAK's the first of these IU's = with PR=20 equal zero, how should it respond to the remaining IU's?  = Remember that=20 the sending port may have a subsequent IU for the exchange in flight = at the=20 time the receiver sends the NAK.  Can the sender continue the=20 exchange?  If it does, how does it indicate to the receiver that = higher-level error recovery has completed and that the subsequent = frames are a=20 retransmission rather than just the tail of the multiple IU's sent = before the=20 sender received the NAK? Why = is the Data=20 Length field in the SCSI Data IU four bytes long when the = Payload Size=20 field in the ADT header is only two bytes long?  Probably not a = critical=20 problem, but it does seem a bit odd. The SCSI Transfer Ready IU includes a = Buffer Offset=20 field.  The description of this field includes the text, 'this field can be used to recover from an = error detected in=20 transmission by allowing the receiver of the data to request = re-transmission=20 of the previous burst of data.'  Under what conditions can the = sender of=20 the SCSI Transfer Ready IU request re-transmission?  Even more = important,=20 under what conditions can it not make such a request?  If the = sender can=20 request re-transmission after responding to previous SCSI Data IU's = with=20 ACK's, a corner case appears where the initiator can request = re-transmission=20 of Data In after the target closes the exchange by sending a SCSI = Response=20 IU. The definition of exchange lifetimes = contains a=20 problem.  Under the current definition, the exchange closes in = the target=20 when the target sends a SCSI Response IU.  What happens if the = initiator=20 NAK's the SCSI Response IU with PR equal to zero?  The target = cannot=20 abort the associated SCSI task because the task has already ceased to = exist,=20 i.e., the target cannot send another SCSI Response IU with ABORTED=20 status.  Also, the current definition allows the initiator to = open=20 another exchange with the same Exchange ID even though the target = hasn't=20 received the acknowledgement for the previous SCSI Response IU.  = Since=20 the target cannot destroy the SCSI Response IU until it receives an = ACK, the=20 possibility exists of the target containing two IU's with the same = Exchange ID=20 for two different exchanges. Although I can't be sure without seeing = ADTr10, I=20 think that a gap exists in the handling of the Expected Frame Number=20 Counter.  Based on 04-003r1, sub-clause 4.6.3 refers to = sub-clause 4.7=20 for how the receiver should set the Expected Frame Number counter = during error=20 recovery.  However, neither ADTr09 nor 03-355r5 include text = stating how=20 to set the Expected Frame Number Counter during error=20 recovery. Sub-clause 4.7.2.1 states that the sender = of a frame=20 NAK'ed with PR equal to one, 'shall = retry sending=20 the frame at least once and no more than four times.'  If all = attempts to=20 re-send the frame result in an ACK for the Initiate Recovery IU and a = NAK with=20 PR equal to one for the frame, after the last re-send the target = port=20 will be in R1: Pending Recovery state.  How does it exit that=20 state? That's the list so=20 far.  We may come up with a few more before Friday.  If = so I'll=20 pass them on.
  
 Cheers,
 Michael = Banther
 Hewlett-Packard = Ltd.
 Telephone +44 (117)=20 312-9503
  


------_=_NextPart_002_01C3D483.55595A7A--

------_=_NextPart_001_01C3D483.55595A7A
Content-Type: text/x-vcard;
	name="BANTHER,MICHAEL (HP-UnitedKingdom,ex2).vcf"
Content-Transfer-Encoding: base64
Content-Description: BANTHER,MICHAEL (HP-UnitedKingdom,ex2).vcf
Content-Disposition: attachment;
	filename="BANTHER,MICHAEL (HP-UnitedKingdom,ex2).vcf"

QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpOOkJBTlRIRVI7TUlDSEFFTA0KRk46QkFOVEhFUixN
SUNIQUVMIChIUC1Vbml0ZWRLaW5nZG9tLGV4MikNCk9SRzpIUC1Vbml0ZWRLaW5nZG9tLGV4MjtD
NjAwLTUzMDINClRFTDtXT1JLO1ZPSUNFOjMxMi05NTAzDQpURUw7V09SSztWT0lDRTorNDQgMTE3
IDMxMiA5NTAzDQpBRFI7V09SSzo7TVMgMkIyMjs7QlJJU1RPTCwgR0INCkxBQkVMO1dPUks7RU5D
T0RJTkc9UVVPVEVELVBSSU5UQUJMRTpNUyAyQjIyPTBEPTBBQlJJU1RPTCwgR0INCkVNQUlMO1BS
RUY7SU5URVJORVQ6bWljaGFlbF9iYW50aGVyQGhwLmNvbQ0KUkVWOjIwMDMwNzE3VDA4Mjk0OFoN
CkVORDpWQ0FSRA0K

------_=_NextPart_001_01C3D483.55595A7A--




More information about the T10 mailing list