Additional ADT Questions/Comments

Banther, Michael michael.banther at hp.com
Fri Jan 9 07:23:42 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_01C3D6C4.905CB6C7
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C3D6C4.905CB6C7"


------_=_NextPart_002_01C3D6C4.905CB6C7
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Regarding question 4 of my previous e-mail (dated 6 January 2004 and
attached), allowing a port to send multiple SCSI Transfer Ready IU's
with Buffer Offset values such that the buffer space allocated is less
than the sum of the Burst Lengths can potentially require a substantial
amount of storage in the receiving port.
=20
For example consider a foolish implementation that allocates 100 Kbytes
by sending 99 SCSI Transfer Ready IU's each with a Burst Length of 2
Kbytes where the Buffer Offset follows the sequence 0, 1K, 2K, ..., =
that
is the first SCSI Transfer Ready IU allocates 2 Kbytes, the second SCSI
Transfer Ready overlaps the buffer space of the first one such that the
total allocated equals 3 Kbytes, the third SCSI Transfer Ready IU
overlaps the second one such that the total allocated space equals 4
Kbytes, and so on.
=20
Because the receiver of the SCSI Transfer Ready IU's must fulfill them
with data as specified by the sender, the receiver cannot simply keep =
an
aggregate of the buffer space allocated.  Instead it must keep all of
the SCSI Transfer Ready IU's whose associated bursts have not been
satisfied.
=20
I believe that the SCSI Transfer Ready IU includes the Buffer Offset
field principally for error recovery.  However the absence of normative
text limiting the use of this field, implies an overly complex
implementation to ensure interoperability.
=20
Regards,
=20
Michael Banther
Hewlett-Packard Ltd.
Telephone +44 (117) 312-9503
=20

------_=_NextPart_002_01C3D6C4.905CB6C7
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

Message Regarding question 4=20 of my previous e-mail (dated 6 January 2004 and attached), allowing a = port to=20 send multiple SCSI Transfer Ready IU's with Buffer Offset values such = that the=20 buffer space allocated is less than the sum of the Burst Lengths can = potentially=20 require a substantial amount of storage in the receiving=20 port.
  
 For = example consider=20 a foolish implementation that allocates 100 Kbytes by sending 99 SCSI = Transfer=20 Ready IU's each with a Burst Length of 2 Kbytes where the Buffer Offset = follows=20 the sequence 0, 1K, 2K, ..., that is the first SCSI Transfer Ready IU = allocates=20 2 Kbytes, the second SCSI Transfer Ready overlaps the buffer space of = the first=20 one such that the total allocated equals 3 Kbytes, the third SCSI = Transfer Ready=20 IU overlaps the second one such that the total allocated space equals 4 = Kbytes,=20 and so on.
  
 Because the receiver=20 of the SCSI Transfer Ready IU's must fulfill them with data as = specified by the=20 sender, the receiver cannot simply keep an aggregate of the buffer = space=20 allocated.  Instead it must keep all of the SCSI Transfer Ready = IU's whose=20 associated bursts have not been satisfied.
  
 I = believe that the=20 SCSI Transfer Ready IU includes the Buffer Offset field principally for = error=20 recovery.  However the absence of normative text limiting the use = of this=20 field, implies an overly complex implementation to ensure=20 interoperability.
  
 Regards,
  
 Michael = Banther
 Hewlett-Packard = Ltd.
 Telephone +44 (117)=20 312-9503
  


------_=_NextPart_002_01C3D6C4.905CB6C7--

------_=_NextPart_001_01C3D6C4.905CB6C7
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_01C3D6C4.905CB6C7
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit

X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_003_01C3D483.55595A7A"
Subject: ADT Questions/Comments
Date: Tue, 6 Jan 2004 18:31:43 -0000
Message-ID: <88A6033CBC98FF4F87E6E3FE0FC2B9581664D9 at sdcexc02.emea.cpqcorp.net>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: ADT Questions/Comments
Thread-Index: AcPUg1P6W+GWYSRSQg2Ks5GTbjMj6Q==
From: "Banther, Michael" <michael.banther at hp.com>
To: <t10 at t10.org>
Cc: "Towler, Russell" <russell.towler at hp.com>,
	"Davies, Myles" <myles.davies at hp.com>

This is a multi-part message in MIME format.

------_=_NextPart_003_01C3D483.55595A7A
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_004_01C3D483.55595A7A"


------_=_NextPart_004_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_004_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_004_01C3D483.55595A7A--

------_=_NextPart_003_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_003_01C3D483.55595A7A--

------_=_NextPart_001_01C3D6C4.905CB6C7--




More information about the T10 mailing list