Another OSI UL efficiency idea

[D_P_Sanford <@mwmgate1.mitre.org:D_P_Sanford@caasd1>]

---------------------------- Forwarded with Changes ---------------------------
From: [e-mail] at -smtp-
Date: 5/16/94 11:15PM
*To: [e-mail]  at -smtp-
Subject: Another OSI UL efficiency idea
-------------------------------------------------------------------------------
If I have interpreted this correctly, by using a hashed value, this 
essentially becomes a application stack combined with a compression algorithm. 
Based on work that has gone on in the aeronautical environment (ASN.1/PER 
compared with DLAC), are conclusions are that for field encoded data (e.g. not 
free text) if you make all optional fields optional to send, write an 
efficiently encodeable abstract syntax module and encode using PER unaligned, 
there is little enough noise in the signal that compression algorithms don't 
provide any appreciable benefit.

Dave

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.