Path: utzoo!attcan!uunet!snorkelwacker!apple!fernwood!vixie!asylum!karl
From: karl@asylum.SF.CA.US (Karl Auerbach)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Efficiency (or lack thereof) of ASN.1. Was: Re: What is the IAB?
Message-ID: <12058@asylum.SF.CA.US>
Date: 9 Jun 90 00:55:02 GMT
References: <23825@bellcore.bellcore.com> <9006030129.AA00899@psi.com> <11946@asylum.SF.CA.US> <266E82D2.592A@intercon.com>
Reply-To: karl@asylum.UUCP (Karl Auerbach)
Organization: The Asylum; Belmont, CA
Lines: 56

In article <266E82D2.592A@intercon.com> amanda@mermaid.intercon.com (Amanda Walker) writes:
>The restricted variant of ASN.1
>that is used in SNMP can actually be pretty quick to parse.  Most of the
>publically available ASN.1 parsers that I have seen are overly complex...

"pretty quick to parse" is a relative term.  I've optimized my ASN.1
tools to handle the SNMP subset and they are fairly efficient, on a
relative scale.

The trouble is that even the limited subset of ASN.1 used by SNMP
represents a fair computational load.  Optimizing it and saying that
the result is good is a lot like saying that you have optimized a
bubble sort -- no matter how well optimized, it is bad news when presented
with anything more than trivial input.

The argument that one can optimize ASN.1 is a red herring.  The
trouble is that ASN.1 requires that one look at a significant number
of bytes, no matter how well optimized.

For things where one has a fairly fixed structure (SNMP being a prime
example) the flexibility of ASN.1 isn't warranted.  As a general
representational tool ASN.1 is OK (not great, but OK).  But for things
that happen often and where the content is fairly predictable (in
structure), a less universal tool ought to be considered.

I'm into my fourth ASN.1 BER encoder/decoder tool.  It does everything
in the ASN.1 BER specification (except floating point) and obeys all
kinds of constructorization/definite-indefinite length strategies and
I have not yet found an input sequence that breaks it (although
massivly deep constructors can cause it to reject an otherwise
legitimate input sequence.)  It was designed to be moved to hardware
as a co-processor.  I'm still profiling and optimizing the code paths
to do fastpathing, bulk operations and pattern matches when possible.
It is small (less than 20K bytes of compiled code on an Intel *86
processor) and, for ASN.1, fast.

My ASN.1 encoder/decoder for SNMP is far smaller, about 3K bytes of
compiled code on an Intel *86 class machine.  And considerably faster.
But even with this efficient code (at least I think it is efficient) I
find that ASN.1 parsing/encoding burns a significant portion of the
overall CPU cycles required to handle an SNMP request.

The potential flexibility of ASN.1 just isn't worth the expense in
situations (like SNMP) where we don't need the flexibility.

We of the internet community ought not to fall into the OSI trap of
thinking that just because ASN.1 exists that it is the perfect tool.*

				--karl--

*I used to own an English sports car (Jensen Healy) and I carried a
set of calibrated hammers.  Each was tuned to correctly bash whatever
thing wasn't working at the time.  A tiny hammer for the carburators,
a mallet for the fuel pump, and a sledge for the front suspension.  To
me, the use of ASN.1 for SNMP is akin to using the sledge to adjust
the carburator.