Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!CHEETAH.NYSER.NET!mrose
From: mrose@CHEETAH.NYSER.NET (Marshall Rose)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Efficiency (or lack thereof) of ASN.1
Message-ID: <5759.644780751@cheetah.nyser.net>
Date: 7 Jun 90 17:45:51 GMT
References: <11946@asylum.SF.CA.US>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: tcp-ip@nic.ddn.mil
Organization: The Internet
Lines: 49

I think history is being a little loosely interpreted here.  The
committee working on X.400 was the first to define an OSI application.
As such, they defined X.409(84).  When other OSI applications began
being defined, the abstract syntax/transfer syntax (ASN.1 and BER) were
split out into ISO8824/ISO8825 and X.208/X.209.  It is true that the
original use of the ASN.1 stuff was MHS, but ASN.1 was not invented
solely for that purpose--the MHS people just happened to be in the
position to need it first.

The strength of something like ASN.1 is its ability to describe a wide
range of data structures using a machine-parsable notation.  One of the
design goals of the OSI people involved was to make sure that it did not
limit the precision of the things being described.  Hence, INTEGERs
needn't be of fixed length, etc.  A side-effect of this is that you need
an encoding algorithm which can accommodate variable length data.

In theory, you can use many different algorithms to encode things
defined using ASN.1, but at present, only one such algorithm has been
standardized, the Basic Encoding Rules.  The reference by Huitema you
are referring to is a second algorithm defined at INRIA, based on Sun's XDR.

The motivation for using ASN.1 in the SGMP and SNMP is simple:
industry has already decided on the lingua franca of the 90's (ASN.1/BER),
and it is counter-productive to invent

		  yet-another-description-and-encoding-standard

So, the goal was to select a small, workable subset that could be
implemented easily, and allowed for some useful optimizations.  Then, if
an implementor is really concered about efficiency, then the routines
can be done by hand with great care. (Probably the most important part
is to have efficient encode/decode support for integers, which
interestingly enough is where the performance characteristics of BER and
XDR differ the most.  By optimizing in once place, you can dramatically
improve the speed of your encoder.)

Using the BER, rather than a non-standard algorithm, over an optimized
ASN.1 was chosen because regardless of the availability of alternate
encoding algorithms, anyone implementing ASN.1 still has to implement
the BER since that's what all ASN.1-capable applications use.  So, if
you are going to ask a vendor to implement something else for their
ASN.1 library to use with application X, you have essentially told them
to do twice as much work.

Since the time of the initial SGMP work, experience has shown that if
you limit use of ASN.1 carefully, you can implement an efficient BER
mapping, this seems to be the most reasonable compromise.

/mtr