UL efficiency ideas

[Peter Furniss <[e-mail]>]

OSI Upper layer efficiency

Peter Furniss
 ([e-mail]  Phone & fax : [phone])
17 December 1993

1 First points

1.1 What do you mean "inefficient"

An essential in considering OSI upper-layer efficiency is to get clear what 
the requirements are - in what sense are the present protocols 
unacceptable and what functions of the present protocols need to be 
retained. Obviously there will be more than one answer but some of the 
measures of inefficiency are:

	a) OSI UL protocols are large and complex and therefore 
implementations have to be  large and complex
	b) The division into the layers makes implementations inefficient
	c) The protocols require the transmission of more bits than 
necessary

The first two of these are untrue, and the present minimal OSI/thinosi work 
has been largely an attempt to clarify this. A slogan for the thinosi work 
was that the OSI upper-layer protocols were lightweight protocols specified 
in heavyweight documents, and that the solution was to implement the 
protocols not the documents ! Like most slogans, this is a simplification. 
The important point is that, for a particular purpose (e.g. for support of a 
particular component in a distributed application) there is no need to 
include in the implementation parts of the protocols that are not used. The 
more tightly restricted the range of function, the simpler the 
implementation can be. It will still be conformant (though it may possibly 
have trouble with over-zealous, simple-minded conformance requirements) 
and will interwork fully, in its defined role, with more comprehensive 
implementations.

The problem of division into layers is a red herring. It was never a 
requirement that the (upper) OSI layers should correspond to parts of an 
implementation. Since ACSE, Presentation and Session have a one-to-
one mapping between services, and, in OSI, Session (for example) is 
never used on its own, there is no point in having a separate session 
interface. Although, for historical reasons, some early implementations do 
have distinct layers, at least  some more recent ones are integrated.

<<<
The third inefficiency measure is certainly true in part, but there is 
ambiguity in the words "than necessary" - necessary for what. 
Consideration of this aspect needs to keep in mind the distinction between 
two possible paths:

	PATH A) If the requirement includes the ability to interwork or inter-
negotiate with implementations of existing protocols, there is no possiblity 
of not sending or understanding "irrelevant" bits. The other end (knowing 
only the old protocol) needs or sends those bits because the old 
specification told it to. The new implementation must do what the old one 
was told to.

	PATH B) If there is not a requirement for interworking, there is no 
need to be constrained by the old protocol. The new protocol need only 
include the features and encodings that are needed by the new, disjoint, 
interworking community.

This distinction is fundamental to any possible improvements in efficiency 
that changes the protocol. If interworking with the installed base (or even 
the pre-specified, but not yet installed OSI base) is required, various 
"unnecessary" baggage must be present. We can try to reduce this 
baggage, but some will remain. (There may be a lot of such baggage - 
most of the peculiarities of OSI Session are due to maintaining 
compatibility with earlier specifications)

Conversely, if interworking is not needed, we can start with a (nearly) 
blank sheet of paper. Whether what we write is then OSI is however a 
moot point. There needs to be a careful consideration of which facilities of 
the existing OSI upper-layers are needed and which can be dropped.

1.2 Which protocols

The term "upper-layer OSI protocols" is itself ambiguous. Sometimes it 
used to mean ACSE, Presentation and Session - the protocols that are 
used directly or indirectly by application-layer protocols (the fact that ACSE 
is itself nominally in the application-layer adds to this confusion). 
Sometimes it means everything above transport, including the application 
layer protocols. This ambiguity is retained in this paper! Most of the 
discussion concerns the supporting upper-layers (sometimes referred to as 
A/P/S ) at least some of it can be applied to application protocols proper. 
2 Minimal OSI/ thinosi

The minimal OSI and thinosi activities in OIW/EWOS, X/Open and the 
IETF have all been concerned with defining particular use of the upper-
layer protocols as they are currently defined. The intent was to lead to 
implementations that would be fully able to interwork with existing 
implementations - following path A above. This limited the degree of novel 
standardisation that was possible at the protocol level (but not at the API 
level of XTI/mOSI). In particular, the interworking requirement means that 
a mOSI implementation must be able to interpret any of the alternative 
valid encodings that might be sent to it by another system. However, this is 
minimised by

	a) restricting the range of applications that mOSI is expected to 
support
	b) not requiring accurate analysis of invalid received protocol

Limiting the range of applications means the mOSI implementation need 
not concern itself with parts of the upper-layer protocols that are defined in 
the standard but will not occur in practice. This is just regular profiling as is 
implicit in the dependency requirements of any application layer standard. 
It is indeed implicit in any of profile or application dependency requirement 
that if you are only going to support application XYZ, you only need to 
have implemented the supporting features that it needs. 

Not requiring accurate analysis of invalid protocol is a counter to the 
tendency in the protocols (rarely) and conformance tests to do this. This 
requirement makes little sense for an upper-layer protocol - it can be 
assumed that the transport layer is accurately delivering what was sent, 
and so an error detection and reporting capability is essentially attempting 
to make all implementations conformance test each other. If one of the 
implementations is sending invalid protocol, then interworking has already 
broken down. Useful open interworking requires the sending of valid 
protocol and the interpretation of any valid received protocol. Error 
detection may be useful in resolving failures to interwork, but is not 
needed for success.

In implementation terms for mOSI, omitting the requirement for error 
detection is particular important for fields of the supporting protocol that 
are "irrelevant" to the supported application. If, for example, an application 
makes no use of the called invocation identifier in the ACSE AARQ (A-
ASSOCIATE request), the parsing of the AARQ can just skip over the field 
while looking for whatever fields are relevant.

The thinosi proposals also include recommendations for which options are 
followed in encoding the Presentation and ACSE protocols. The thinosi 
"cookbook" recommends that constructed encodings use the indefinite 
form. This choice was made because it limits (to one) how many of the 
length fields must be adjusted around an enclosed field of whose length 
varies. For example, with a stream of connectionless A-UNIT-DATA pdus, 
all with the same naming, addressing and context parameters but an 
embedded user data field which differs in length use of the indefinite form 
means the header apart from the length field itself remains constant and 
the user-data field will always start at the same offset. The interworking 
requirement however means that a receiver must be able to accept any of 
the variants that it may receive - the cookbook just recommends, it cannot 
require. (The cookbook recommendations have also been proposed for 
inclusion, via the defect process, in the Presentation and ACSE 
connection-oriented and connectionless protocol standards).

3 Skinny stack and application layer protocols

In part the mOSI/thinosi work grew out of the X Windows System over OSI 
"skinny stack" specification (EWOS ETG 13) and implementation. (The 
term "skinny stack", which really only applied to the implementation, was 
found to cause trouble because it could be understood to mean less 
protocol, which it was not or less implementation, which it was). The 
extension to minimal OSI - that is to the OSI upper-layers in support of 
basic communications applications that made only minor use of those 
layers - is only one of the possible extensions. The essential skinny stack 
ideas - implement only what you must for the purpose at hand, forget layer 
boundaries, pre-encode to send, match against patterns to decode - can 
be applied to application protocols as well. In fact, this has the possibility 
of simplifying the implementation even further. For an application protocol 
that uses the ASN.1/BER encoding, the entire 
Presentation+ACSE+Application pdu combination can be treated as a unit 
(Session has different "encoding rules"). It will be known for sure which of 
the fields of the PDUs are "relevant" and which can be ignored. (Whereas 
for mOSI, several fields remain user options).

A skinny stack implementation of an application protocol and its supporting 
stack will be very much smaller than one that uses a generalised stack. It 
will be an effective solution for very small systems that use only one or a 
few application protocols - and the more restricted the systems use of the 
protocol, the greater the benefits. For systems that use many application 
protocols it may be less useful, as each application would include its own 
Session, Presentation and ACSE implementations. This probably would 
not be harmful to performance (on any measure), but might complicate 
managment and maintenance. 

<<<
The advantages of this path are that no new protocol specification is 
needed for the supporting layers (or the application layer, if an appropriate 
specification exists - CMIP and MMS are obvious examples). Distributed 
systems with a large number of small, special-purpose components and 
relatively few larger, multi-purpose systems (controllers or managers in 
workstations) could use skinny stacks in the small components and off-
the-shelf general purpose software in the larger. The ability of the skinny 
stacks to interpret *any* valid encoding for their application would make it 
unnecessary to have special purpose communication software in the 
workstation.

If formal conformance testing was required for all the components (for 
regulatory reasons, rather than just to make sure they worked effectively) it 
might be necessary to fix the over-zealous tests so they checked only 
what was needed, rather than what would be appropriate in a general-
purpose implementation. This would probably be most easily achieved by 
presenting a draft operational requirement - once it is clear that what is 
wanted is a test that a light switch sends and understands conformant 
session protocol, testers will have a well-defined target.
4 Reducing the bandwidth - path A

Thinosi/mOSI did not attempt to reduce bandwidth at all, but to reduce 
code size and running time. The encoding choices were made with that in 
mind. Alternative choices can be made with the intent of minimising the 
size of the PDUs transmitted but keeping within the interworking 
requirement of conformance to the existing protocol specifications.

The intent here is reduce the "irrelevant" bits that are sent. Which are 
irrelevant will, of course, depend on the requirements of the application - in 
particular whether the upper-layer naming and addressing elements are 
needed, how many presentation contexts are involved, whether 
application data is carried on the ACSE services. As an example, we will 
consider an application that is "sole user" (apart from ACSE) of an 
application association, with a single presentation context and that does 
not send user-data on ACSE. This is one of the forms of a "Basic 
Communications Application" in the mOSI sense. Using the encodings 
recommended in the thinosi cookbook (and the "default" object identifiers 
of CULR-3), the cost in octets of for the upper-layer pci is

a) using the thinosi encodings (which use indefinite length for all 
constructed values)

			Session	Presentation	ACSE		Total

Connect-request	16		82		15		113
Connect-accept	16		57		32		105
Data			4		16		-		20
Release-request	4		15		7		26
Release-response	4		15		7		26
A-abort *		7		33		6		47
S-abort		5		-		-		5

(* with no user data on abort, this is pretty pointless - with user data the
 numbers become 4+ 46+19=65)

b) If we change all of the encodings to definite length, we save all the end-
of-contents. This saves us some octets at the cost of processing time. 
Since there is no user-data on the ACSE services, all the lengths are less 
than 127 and so take up a single octet.

			Session	Presentation	ACSE		Total

Connect-request	16		60		11		87
Connect-accept	16		43		22		81
Data *			4		6+3 lengths	-		13 to 19
Release-request	4		9		5		18
Release-response	4		9		5		18
A-abort		7		21		4		33
S-abort		5		-		-		5

P-DATA is rather complicated because the overhead is affected by the 
size of the data. There are three nested contstructions around the data. 
The 4+16=20 figure in the thinosi encodings is two indefinite lengths (1 
header and 2 trailer octets each) and a long definite (length of length = 3, 
and three length value octets), which gives a fixed length header of 16 
octets and can handle data lengths upto 16 million. Using definite lengths, 
if the user data is less than 120 and short form definite lengths are used 
for all three constructions, the total header length becomes 4+6+3*1=13. If 
the length is between 128 and 247, definite lengths of two octets (1+1) will 
give a total of 4+6+3*2 = 16. If the length is between 256 and 65535, each 
definite length will take three octets, giving a total of 4+6+3*3 = 19. (User 
data lengths just below 128 and 256 give intermediate totals, as the 
various nested lengths switch to the next longer form).

The figures in this table are probably the most useful baseline for further 
consideration.

Some possible further reductions will now be considered:

c) Use simple, not full encoding.

If the application's abstract syntax imports all of ACSEs, and defines a 
transfer syntax for the combination (details of how to state this are left as 
an exercise), the presentation context can be omitted and the combination 
proposed (no, demanded, there is no negotiation) as the default context. 
Simple encoding is then used in data phase.

The price for this is removal of any possibility of transfer syntax 
negotiation. More seriously for interworking, it is of questionable validity. 
Although some implementations are believed to use (or attempt to use) the 
default context in this way, it is in contradiction to the Presentation 
standard. 

What would be legitimate, though also unlikely to be useful for 
interworking, would be to have the merged a-s and t-s, but put them in the 
presentation context definition list, not as default context. This means 
there is a single element in the defined context set, in which case simple 
encoding in data phase is usable, but you could still negotiate a transfer 
syntax.

The disadvantage of this is that it has consumed ACSE into the 
applications abstract syntax. Although this was intended to be possible 
according to the ACSE specification, it has not been generally recognised, 
and implementations do not currently handle syntaxes that incorporate 
ACSE. Getting the combined syntax specification right would not be easy 
either.

These numbers assume the definite lengths form.

			Session	Presentation	ACSE		Total

Connect-request	16		27		11		54
Connect-accept	16		11		22		49
Data			4		2		-		6
Release-request	4		2		5		11
Release-response	4		2		5		11
A-abort		7		4		4		15
S-abort		5		-		-		5


d) Session version 1

Since there is no user data on the acse primitives, and we are not using 
the naming fields of acse, we could live with the 512 user-data limit from 
session version 1. This cuts down the session elements of the connect 
exchange from 16 to 8. (That's right - 8 octets to communicate 1 bit - 
because version number is inside the optional connect/accept item, but 
that has a mandatory element "protocol options". (see the answer to 
question 1))

This will interwork happily, but as responder might receive version 2 (+ big 
aetitle ?) connect requests.

e) Typed data

Using Session TYPED-DATA, instead of S-DATA saves two octets on the 
data message. (You don't need the spurious GIVE-TOKEN. DATA and 
TYPED-DATA are mis-named - they should be called TOKEN-
CONTROLLED-DATA and DATA respectively. See the answer to question 
1) This will interwork happily - it is only the perversity of mappings that stop 
it being normal.

This gives, as the best figures while maintaining interworking, using 
definite lengths, session version1 and typed data, for small, but "Fully-
encoded" P-DATA user data:

			Session	Presentation	ACSE		Total

Connect-request	8		60		11		79
Connect-accept	8		43		22		81
Data 			2		9		-		13
Release-request	4		9		5		18
Release-response	4		9		5		18
A-abort		7		21		4		33
S-abort		5		-		-		5

5 But what do the upper-layers do for us

Before examining further alternatives it is worth considering what A/P/S 
protocols offer as added value on top of transport. It is these features that 
need to be incorporated in any alternative protocol, or rejected as being 
unnecessary for a particular requirement. The following features 
deliberately use inexact language and (sometimes) avoid technical terms 
as it is the effective role, not the specified function that is important:

a) The first octet of each session pdu identifies what part of the 
conversation is being sent - ie which of the rows of tables above is 
received 

b) Session and presentation connects include selectors that can be used 
for upper-layer routing.

c) Presentation is primarily concerned with presentation context - the 
identification and negotiation of the abstract and transfer syntax of the 
application data. There are several aspects to this:

	i) the presentation context identification of each piece of application 
data allows different message types (APDUs) to be distinguished, without 
fear of ambiguity, even if the representation of two messages from 
different sets (abstract syntaxes) happens to be the same
	ii) the presentation context identification can (usually) be used to 
distinguish separate streams of dialogue - because each stream will 
usually be using a separate set of message types
	iii) abstract syntax negotiation states/agrees which sets of message 
types will be used on the association
	iv) transfer syntax negotiation (for each particular presentation 
context) allows alternative representations of the same message to be 
offered

d) Presentation provides bracketing around the encodings of application 
data, so they need not contain their own length fields

e) ACSE provides naming fields (AP-title, AE-qualifier and invocation 
identifiers) that can be location-independent

f) ACSE carries an application context that identifies what the 
communication will be about, and what should be assumed about the 
intents and capabilities of the partners.

g) ACSE identifies which of its APDUs is being used (they all have 
different tags)

h) With its recent extension, ACSE can carry security information

j) All three protocols have facilities for version negotiation and, in the 
connect-request, extensibility rules that allow old implementations to 
ignore fields they do not recognise

Of these features:
	a) Something will always be needed to distinguish broad categories 
of message that all travel on the same supporting service (in this case, on 
T-DATA)
	b) The upper-layer selectors are redundant if the upper-layer 
implementation is integrated
	c) i) will only be necessary when there are multiple abstract 
syntaxes - but, since ACSE is considered to be in the application layer, 
there always are. 

	c) ii) works provided all the ASEs involved are different, but 
becomes rather complicated otherwise. Something that is not concerned 
with message type identification is needed for the general case of 
identifying the appropriate recipient of a message. Assuming that what the 
message type is tells you who it is for does not always work (try sending 
an anonymous birthday card to twins!)

	c) iii) and f) : The application and presentation contexts have some 
overlap of function. Since an application context definition identifies which 
ASEs, and thus which sets of message types, will be involved, c) iii) can 
be no more than a parameterisation of the application context, and will 
usually be unecessary.

	c) iv) is probably the most useful feature of the upper-layers, and 
the least used at present As is described below, it offers considerable 
scope for extensible, conformant optimisation in the processing OR the 
transmission of application protocols.

	d) Anything whose encoding is not self-delimiting will require this 
feature - conversely, if the supporting layers provide the feature, it need 
not be duplicated in the application protocol (i.e. the application protocol 
need not be self-delimiting)

	e) The ability to carry the names of the communicating entities 
explicitly, rather than inferring them from the addressing (via reverse 
lookup) is likely to be needed generally, but cannot always achieve what is 
hoped for. It cannot be relied on for effective authentication of the sender, 
though it can give a weak identification. Depending on how fast directory 
updates take place, it may allow a subsequent return call to the same 
entity on a different lower layer address. But it certainly does allow an un-
authenticated assertion of who the other party is.

	f) In a particular instance, an application context will either be 
completely redundant or absolutely essential! Often the entity that is 
listening on a particular lower layer address will only support one 
application context. If a call is made to that address, the only advantage in 
communicating the application context explicitly is to identify "wrong 
numbers". In other cases, the entity may be capable of several different 
things, and the application context is needed to tell it what the call is 
about.

	g) Since each ACSE APDU has (at present) a unique mapping to 
Session, this is redundant. However, if different ACSE APDUs could travel 
on the same immediately supporting service, the distinction is needed - in 
fact it has taken on part of the role of the session SI field in a). 

	h) Where needed, and perhaps especialy combined with the 
naming fields, carriage of security information will be vital

	j) Inventing a non-extensible protocol can be expected to be the 
last action of a doomed design team

5.2 On transfer syntax negotiation

Although all (?) OSI-originated protocols to date use ASN.1 and Basic 
Encoding Rules, Presentation was designed to allow multiple transfer 
syntax's (bits on the line) for a particular abstract syntax (set of 
messages).  Presentation is also intended to be just as happy with non 
ASN.1 abstract syntax's. (ASN.1 can be said to have the same 
relationship to abstract syntax notations as PL/I to programming 
languages - it is not the only, not the first and could be bettered). "Non-
OSI" application protocols will often not distinguish their abstract and 
transfer syntax's, but the distinction is usually possible.

<<<
What Presentation does allow is for alternative transfer syntax's to be 
offered by an association initiator, alongside a standard transfer syntax. 
Thus, for an ASN.1-defined application protocol, BER will usually be 
mandatory for support. But an implementation can also offer, say Packed 
Encoding Rules, or an internally-convenient representation known only to 
clones. If the responder recognises the alternative, it accepts that and the 
subsequent exchanges use the alternative encoding, at the saving of 
bandwidth (for PER) or processing time. If the responder does not support 
the alternative, it will negotiate to BER, and communication will succeed, 
at greater expense. It is important to realise that the alternative encoding 
does not require universal standardisation - the use of Object Identifiers to 
name transfer syntax's means the "registration" of the syntax can be 
devolved to any body. If the efficiency required is in bandwidth, the 
registration of a special-purpose, application-dependent highly-
compressed encoding, that took account of which messages were most 
frequently transmitted would be possible.

On this last idea, it is perhaps worth pointing out that the Presentation 
protocol does *not* perform the encoding and decoding functions between 
the local and transmitted forms of the application data. Although many 
implementations offer a "Presentation interface" along with tools for 
ASN.1/BER encoding and decoding, and the Presentation texts often talk 
as if the encoding were done in layer 6, all the Presentation protocol does 
is identify what is being sent and (often) how long it is. Placement of 
function that is assigned to the Presentation layer need bear no 
relationship, in a real system, to which part of the implementation performs 
that function. (This is just a specific case of the general rule that the OSI 
layer boundaries divide only documents, not parts of real systems)

6 Where have we got to so far

A recap of which parts of the problem space have been dealt with (with 
luck):

a) If the requirement is for general-purpose multi-application OSI with open 
interworking, but there is inefficiency because the implementations 
available are capable of more than is needed, and structured on the 
pattern of the Reference Model 
	-> demand implementations of the protocols not the documents

b) If the inefficiency is because conformance requirements are over-
rigorous
	-> explain to the conformance testers they are strangling the OSI 
goose and it will not lay any eggs of any metal if it is dead

c) If the application includes single-purpose, limited systems for which 
even efficient, general-purpose implementations are too large, but they are 
to interwork with general-purpose OSI systems
	-> use a special-purpose implementation, cut to the bone

d) If the encoding of the application protocol is too large for comfort, but 
general interworking is desired
	-> specify a compressed encoding and offer it as an alternative in 
context negotiation

What has not been dealt with:

e) The octet overhead of A/P/S is excessive for the bandwidth available - 
80 octets is too much for the environment

7 Reducing the bandwidth - path B

<<<
Applying the distinction stated at the beginning, if you cannot afford to 
send 80 octets on the connect exchange, you cannot do OSI as it is today. 
New upper-layer protocols can be devised to support OSI application 
protocols, but they will not interwork with existing OSI implementations and 
are not "OSI" in any useful sense at the moment. Similarly, new protocols 
that fitted into a (revised or unchanged) OSI model could be devised.

If such a new protocol achieved International Standard status, its inclusion 
in OSI would presumably depend on the title of the Standard ! However, 
one should beware of new "versions" of protocols that are really 
completely separate protocols but are described in the same document. 
Presentation and ACSE X.410 mode versus normal mode cannot 
internegotiate and support disjoint sets of applications. Although they 
share some PDU formats, putting them in one document gains nothing 
technically.

However, if the bandwidth restriction is so severe that the loss of general 
interworking is a price that must be paid, it is worth considering how to 
minimise the loss and maximise the gain. It is assumed that the bandwidth 
restrictions apply only to a part of the future OSI network - that we are 
concerned with particular links rather than rewriting OSI for everybody 
(because that would be rewriting OSI for nobody)

The application situations where bandwidth restrictions are severe can 
perhaps be considered in various groups:
	a) The application communication is entirely, and always, over 
bandwidth restricted links between special systems
	b) The application communication is partly over restricted links, but 
can be relayed on to  "normal" systems
	c) The application communication is usually over restricted links 
between special systems, but will sometimes directly involve "normal" 
systems

Specific examples, all over a limited bandwidth air-ground link, might be
	a) air traffic control messages 
	b) rebooking onward flight reservations using OSI TP, initiated from 
aircraft, but ending at the main booking systems transaction monitor
	c) file transfer to pick up local weather information to the aircraft - 
but some out-of-the-way places still have old (1993) implementations - 
transfer rate in this case will be poor, and may not work - but if everyone is 
lucky it is better than nothing.

The distinction between these categories are in the possible solutions. 
Clearly if the last, c), is to use normal negotiation, the connection offer 
must be something that follows the existing formats - so it will have to be 
at least 80 octets. After that, if it turns out to be a new version, minimised 
encodings are possible.

<<<
At the other extreme, for case a), there is relatively little requirement for 
true "openness" in connection (this is quite distinct from openness in 
supply of equipment). Rather than send a set of independent parameters 
(equivalent to the context and syntax names of normal OSI), pre-defined 
sets of options and combinations could be identified, either by short 
integers or object identifiers. All that needs to be communicated on the 
connect message is that this approach is being followed, and which of the 
sets of messages will be used, plus perhaps a few bits for extensibility (or 
functional unit negotiation). Using short integers would either cause big 
arguments about the code space (and need a central registry) or be limited 
to bilateral significance. Object identifiers would be general (essentially 
these would super-application contexts) but slightly more expensive. Even 
the AE-titles could be abbreviated to be references to some distributed 
table, or by assumption of a regular form.

This method in its simplest form does not provide the general negotiation 
features of present-day Presentation. Such negotiation could be added (a 
list of super-application-contexts, or a syntax that allowed wild-carding in 
the object identifier), but, as always, negotiation costs some bandwidth.

The remaining case, b), implies that the semantics that are expected at the 
eventual "normal" system are at least implicit on the limited bandwidth link, 
although this could be achieved by an application gateway/protocol 
converter. This could use the super-application-context on the limited side, 
and convert it into the normal form before passing it to the regular system.

If an approach of this kind (for a)) is followed, it will probably be wise to 
make it possible to distinguish the message from any present day Session 
- so the first octet should not be the same as any of the present Session 
SI values. May I start the bidding at 65.

8 Interworking

(just a clarification - not part of the main thing)

The terms "interworking" and (version) negotiation are sometimes used in 
different senses, leading to considerable confusion. This section attempts 
to define the term as used in this document.

When referring to interworking between a new and an old "flavour" of a 
protocol (be they termed versions, options, sets of functional units or 
whatever), it is understood here to refer to the possibility of interoperation 
in support of a real (end-user) application whose requirements make it 
possible to use the old and the new, and where the initiator would like to 
use the new, but the responder supports only the old.

Interworking excludes cases where the application (or service user) can 
only be supported by the new version. If the application needs features of 
the new version, it can only be invoked where supported by the new. The 
association/connection establishment will only offer the new version.

Negotiation (of "flavour") only makes sense where the application can use 
either version, but the new version is in some sense preferable - thus 
between implementations supporting both versions the new will be used, 
but the old version can be used if one partner only supports that. In this 
case, with a typical connection-oriented establishment phase, an initiator 
capable of both will offer both, and a responder knowing only the old will 
force the exchanges to the old. This may require the initiator to behave 
(more or less) differently to the way it would behave if using the new 
version. This may or may not be detectable to the user, but somehow the 
work of the application will (with luck) be achievable.

Negotiation is not considered to include directory look-up to find out which 
version a potential responder will support.

One mechanism to achieve interworking is to try to use different versions 
until success is achieved. This cannot generally be considered negotiation. 
However, it could be regarded as a limited form of negotiation if the old 
version includes in its specification a specific response to an attempt to 
use the new version. An example of this is in Session where the 
requirements of CULR-1 (9.2.1) - all session version 1 implementations 
"should" respond to CN SPDU (connect) offering version 2 only with an RF 
SPDU (refuse) indicating that version 2 is not supported. This would allow 
an attempt to connect using version 2 only (perhaps with a 5000 octet user 
data parameter) to be rejected, but the initiator could try again with version 
1 - but only if application permitted the user data to be postponed to the 
data phase or not sent. This could be called "fail-and-retry" negotiation. It 
is important to note that without the CULR-1 requirement on the old 
(version 1 only) implementation, this would not work. Repeated attempts to 
establish using alternative versions without such hints are not negotiation.

Interworking excludes cases where the "application" is a tester or harness 
that is deliberately probing the protocol implementation to see if it can tell 
which version is in use. Testing may show that two implementations can 
be expected to have difficulty interworking for real. It is inappropriate to 
refer to interworking in the communications between the tester and the 
implementation under test (except when referring to a supporting layer - an 
tester for an application-layer protocol built on TP0/CONS cannot 
interwork directly with an IUT built on TP4/CLNS, but that is a problem of 
transport-layer interworking).



9 Some stray thoughts

These points do not have a home at present, but I am loath to chuck them 
out.

Much of the "excess" overhead in the connect exchange is for extensibility 
and to make clear that you are NOT using some element you could have 
done (e.g. the sequence around the (usually) single transfer syntax is a 
pain, but is how you state you are not offering to negotiate it). 

ACSE could be shortened by greater use of implicit tags and defaults (the 
accept is especially grotesque)

The first message of a connection MUST be extensible. PER is not very 
good at this.
UL efficiency	1	Peter Furniss