Re: Another OSI UL efficiency idea

[Peter Furniss <[e-mail]>]

Dave,

> If I have interpreted this correctly, by using a hashed value, this 
> essentially becomes a application stack combined with a compression algorithm. 

Not really. It depends what the "normal" protocol stack is. As
proposed, if the hash produces a cache miss, you drop back to present
day protocol, so there is no compatibility problem. If you get a cache
hit, then you have completed the establishment an entire round trip
early.

> 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.

I dont see how you can get down to the 4 to 8 octets (including the
bit masks for the varying fields - the most complex form of the
proposal - but assuming the varying fields happen to be absent in this
case) if you have any object identifiers in there - for application
context, abstract syntax or transfer syntax or aetitles. If you are
dropping all of those, you havent really got any of the OSI
architecture/mechanisms left and you might as well go straight on
Transport.  If you are counting those as "free text", then, yes I can
understand your statement - but the neat thing about the hash idea
(which did not originate with me by the way) is that it can *include*
those "free text" fields. It can even include things like directory
name ae-titles, on the assumption that the number of systems talking
to each other can fit their hash+fullform in the cache.

Peter