Another OSI UL efficiency idea

[Peter Furniss <[e-mail]>]

This is an outline of an efficiency approach recently discussed informally in 
the UK. It has some remarkable properties - no compatability problems, and 
could be orthogonal to other approaches being discussed.

Most  upper-layer connection/association establishment exchanges are 
between systems that communicate fairly frequently. Most, if not all, of the 
parameters of the S-CONNECT, P-CONNECT, A-ASSOCIATE received will 
be identical to some previous connection attempt. The efficiency 
enhancement proposed here takes advantage of this. Although the efficiency 
gain will not always be achieved, it will usually will give considerable 
bandwidth improvement. It will also gain a round trip. There appear to be NO 
compatibility problems. 

Mechanism

The initiating system creates the CN+CP+AARQ+user-data pdu internally, 
before establishing a Transport connection. It creates a 32-bit (or 16, tbd) 
hash of this buffered value, and puts this hashed value in the user-data of 
the T-CONNECT request.

The responding system compares the hash value received on the T-
CONNECT indication against a local database of stored values. If this 
succeeds, it knows from the database what the upper-layer connect message 
would be, and can immediately determine its answer 
(AC+CPA+AARE+userdata), including presentation negotiation and any 
application-layer initialisation semantics. It hashes this reply and puts the 
reply-hash on the user data of the T-CONNECT response.

The initiating system on getting the reply-hash in  the T-CONNECT confirm 
does its own lookup and determines what the upper-layer response is going 
to be. It sends a minimal pdu on T-DATA to indicate the reply-hash has been 
recognised and can then proceed directly to data-phase of the 
connection/association. The minimal pdu can be non-blocking.

If the lookup at the responder fails, the responding system remembers the 
received value and puts a field on the user data of the T-CONNECT 
response that means the hash was not known. On receiving this value, the 
initiator sends the CN+payload as normal on T-DATA. When this is received 
by the responder, it can add the received value to the database and construct 
the reply. There is a new parameter in the Session AC pdu, initially with a 
dummy value. The complete reply is hashed and the hash-value substituted 
for the dummy. The reply is sent as normal, on T-DATA. The initiator can now 
build its database for the reply.

Features

The cleanest architectural form of this is to treat it purely as a Session matter. 
The values to be hashed are the Session CN+userdata and the AC(with a 
dummy hash value)+userdata. This simple version may be the best bet, at 
least initially.

However, the mechanism will have wider use if various values that are likely, 
if present, to be different between each connection can be omitted from the 
hashing. Most of these will be quite small (invocation identifiers for example) 
and could be sent in the T-CONNECT userdata. The omission from the 
hashing could be done by each protocol being allocated a one-octet bitmap, 
carried in the T-CONNECT userdata with the hash value, that defines which 
fields have been excluded from the hash. Each protocol, including application 
protocols, would need to define the bit:variable field relationship.

It is assumed that upper-layer selectors, AE-titles, version and functional unit 
negotiation/declaration, application context and the abstract and transfer 
syntax would be included in the hashing. An application where a large 
number of systems spoke to each other with AE-titles being exchanged 
would require large databases of hash values, and it might not be worth 
bothering - trading bandwidth and a round-trip for a disk search is doubtful. 
However, in many applications the database will be quite moderate.

There is a slight possibility of false hits in the hash database - two different 
CN+userdata messages producing the same hash value. It can be assumed 
these will be detected by the initiator, which will find the reply does not agree 
with what was expected. The initiator then assumes the optimisation has 
failed, and proceeds to use the normal protocol.

Back-compatibility is achieved provided existing implementations are ignoring 
the user-data on T-CONNECT (not used by Session). The initiator, finding the 
T-CONNECT confirm has nothing in its userdata, proceeds to use the normal 
protocol.

This approach avoids any loss of upper-layer function - the full presentation 
context negotiation mechanism (for example) is still available.

This optmisation obviously could be combined with other proposed upper-
layer efficiency approches.