ADT Payload size - type analysis

BANTHER,MICHAEL (HP-UnitedKingdom,ex2) michael_banther at hp.com
Fri Feb 7 07:38:03 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "BANTHER,MICHAEL (HP-UnitedKingdom,ex2)" <michael_banther at hp.com>
*
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C2CEBE.E6F7E8F0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2CEBE.E6F7E8F0"


------_=_NextPart_001_01C2CEBE.E6F7E8F0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi all,

I have an action item to look for potential problems in payload types
with defined payload sizes (new action item i. from 29 Jan
teleconference).  This action item resulted from the discussion around
03-080r0.

To recap, 03-080r0 addresses the fact that some payload types have fixed
payload sizes.  This fact begs the question, what does a node do if it
receives a well-formed frame whose payload size does not match the size
defined by the standard?  By well-formed, I mean that the number of
bytes in the payload matches the value in the payload size field of the
frame header and that no checksum failure occurs.

03-080r0 proposes ignoring extra bytes and zero-filling missing ones.
In subsequent discussion, we agreed to ignore extra bytes and to change
|from zero-filling missing fields to keeping the existing value for those
fields.  This left the question of what to do when receiving a payload
with too few bytes but not few enough to account for one or more fields.
The group agreed that the standard would never shrink an existing field,
rather it would retain the field as obsolete.  Hence the missing partial
field problem should never arise.

All of the discussion focussed on the Port Login frame as an example.
My action item covers looking for other, non-link service, payload types
that have defined payload sizes.

adt-r01defines fixed payload sizes for the Command and SCSI Transfer
Ready payload types of the Encapsulated SCSI protocol.  For the ADC Fast
Access protocol, it also defines, via reference to ADC, fixed payload
sizes for the VHF Polling frame, AER frame, and AER Control frame.

In summary then, the potential for size - type mismatch exists in all
three defined protocols - link service, encapsulated SCSI, and ADC fast
access.  Since we don't know, ahead of time, the fields that future
generations of ADT (or ADC) might add to a these fixed size payloads, I
cannot draw specific conclusions regarding the impact that retaining the
previous value for missing bytes will have.  Potentially, interactions
between the supplied field(s) and the previous value of the missing
one(s) could result in undesirable behaviour.  I suspect that future
standards will have to make exceptions to the general rule where such
undesirable interactions could occur.

One final note, although the partial missing field case should never
occur, clearly it still can due to defects in implementation.  Just to
cover the ground thoroughly, I will add text in 03-080r1 to treat this
case as an error.

Cheers,
Michael Banther
Hewlett-Packard Company 


------_=_NextPart_001_01C2CEBE.E6F7E8F0
Content-Type: text/html;
	charset="iso-8859-1"

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

Hi all,

I have an action item to look for potential problems in payload types with defined payload sizes (new action item i. from 29 Jan teleconference).  This action item resulted from the discussion around 03-080r0.

To recap, 03-080r0 addresses the fact that some payload types have fixed payload sizes.  This fact begs the question, what does a node do if it receives a well-formed frame whose payload size does not match the size defined by the standard?  By well-formed, I mean that the number of bytes in the payload matches the value in the payload size field of the frame header and that no checksum failure occurs.

03-080r0 proposes ignoring extra bytes and zero-filling missing ones.  In subsequent discussion, we agreed to ignore extra bytes and to change from zero-filling missing fields to keeping the existing value for those fields.  This left the question of what to do when receiving a payload with too few bytes but not few enough to account for one or more fields.  The group agreed that the standard would never shrink an existing field, rather it would retain the field as obsolete.  Hence the missing partial field problem should never arise.

All of the discussion focussed on the Port Login frame as an example.  My action item covers looking for other, non-link service, payload types that have defined payload sizes. adt-r01defines fixed payload sizes for the Command and SCSI Transfer Ready payload types of the Encapsulated SCSI protocol.  For the ADC Fast Access protocol, it also defines, via reference to ADC, fixed payload sizes for the VHF Polling frame, AER frame, and AER Control frame. In summary then, the potential for size - type mismatch exists in all three defined protocols - link service, encapsulated SCSI, and ADC fast access.  Since we don't know, ahead of time, the fields that future generations of ADT (or ADC) might add to a these fixed size payloads, I cannot draw specific conclusions regarding the impact that retaining the previous value for missing bytes will have.  Potentially, interactions between the supplied field(s) and the previous value of the missing one(s) could result in undesirable behaviour.  I suspect that future standards will have to make exceptions to the general rule where such undesirable interactions could occur.

One final note, although the partial missing field case should never occur, clearly it still can due to defects in implementation.  Just to cover the ground thoroughly, I will add text in 03-080r1 to treat this case as an error. Cheers,
Michael Banther
Hewlett-Packard Company 

------_=_NextPart_001_01C2CEBE.E6F7E8F0--

------_=_NextPart_000_01C2CEBE.E6F7E8F0
Content-Type: application/octet-stream;
	name="Michael Banther (E-mail).vcf"
Content-Disposition: attachment;
	filename="Michael Banther (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:BANTHER;MICHAEL
FN:Michael Banther
ORG:Hewlett-Packard Company;Ultrium PEC
TEL;WORK;VOICE:+(44 117) 312 9503
TEL;WORK;FAX:+(44 117) 312 9978
ADR;WORK:;Bristol;Filton Road, MS 2B22;Stoke Gifford;Bristol;BS34 8QZ;UK
TITLE:R&D Engineer
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:MS 2B22=0D=0ABristol, UK
EMAIL;PREF;INTERNET:michael_banther at hp.com
REV:20011012T132245Z
END:VCARD

------_=_NextPart_000_01C2CEBE.E6F7E8F0--




More information about the T10 mailing list