[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BER versus ASCII (was: RE:)

Jeurgen and David have given some important counter-examples, but I would
like to add a couple comments.

Primarily, in order to do any meaningful comparison you need to look at an
entire message worth of data.  It's not particularly useful to look solely
at an arbitrary value, because there are other parts of the message that
are not being taken into consideration.  You can find "values" of
arbitrary type and "human-readable" length that are shorter or longer in
either ASCII or BER encodings, not to mention that "ASCII encoding"
doesn't imply any particular format for specifying data types, field
lengths, delimiting of different values, variable references (object
identifiers), and so on.

To start to make a meaningful comparison you need to define the format
beyond just saying it's in "ASCII".

In your boolean example, for instance, I take your implication of ASCII
using 1 byte to mean that a boolean is the "0" or "1" (or maybe "F" or
"T") characters.  How do you know when you receive one of these characters
that what you're looking at is a boolean value?  That information is not
available in that 1 byte; it is, however, implied by one of the other two
bytes in the BER encoding (well, sort of -- SNMP doesn't use ASN.1's
BOOLEAN built-in type, so typically it would actually say it's an
integer).  Also, since that 1 ASCII character doesn't tell you implicitly
that it's a boolean value of length 1, how do you know where that value
ends and the next begins?  You don't, without a delimiter or other
mechanisms, which you aren't including in your comparison.  In other
words, you're still going to need at least 2 or 3 bytes for ASCII.

Numeric values, as has been mentioned, give you significant savings over
ASCII for large values.  The maximum ASCII length of a 64 bit integer
value, for example, is 19 bytes (signed) or 20 (unsigned).  The maximum
BER length for a 64 bit integer incoding is 8 bytes (signed) or 9
(unsigned), plus 2 for for tag and length (which aren't included in the
numbers for an ASCII value, though it still must be specified).

Not mentioned about numeric values, however, is their significance in
object identifiers.  You may wish to argue that "sysDescr.0" is shorter
than "" and that is what you would include in the ASCII
encoding, but you can't do that because object names are not required to
be unique.  Object identifiers are.  In BER, that OID is 9 octets (plus 2
for tag/length); in ASCI it's already nearly double for single-digit
subidentifiers at 17 (plus unspecified ASCII format delimiters etc).  The
inefficiency of ASCII for an object identifier encoding skyrockets as you
start to consider longer OIDs and OIDs that contain 32 or 64 bit valued

At any rate, my point is "ASCII" doesn't specify a message encoding
format.  It only specifies a character set.  In order to make a reasonable
comparison, you need to decide on the actual format of your "ASCII"
messages, and you need to know exactly what the BER rules are so that you
can have accurate numbers to compare.  For exercise, you might choose XML
as a message format and compare that to BER.

For reference, the ASN.1 Basic Encoding Rules can be obtained from ITU-T.
You can obtain the version used by SNMP (X.209) or the current version NOT
used by SNMP (X.690) both for free.  However, the X.209 version requires
you to go through some registration procedure before you can get access.
The X.690 version doesn't require this but it may have extra information
not particularly relavent to SNMP (that is, moreso than X.209).

The X.690 and related "current" ASN.1 publications can be obtained from:


The X.209 version can be obtained from:


In order to download it for free you need to use the "I wish to REGISTER
in order to download up to three (3) Recommendations free of charge"
option there.

[Note: I'm not affiliated with ITU-T or their electronic bookshop in any
way.  I just went through the procedures to obtain a copy of the specs
myself recently.]

On Wed, 5 Dec 2001, Subrata Goswami wrote:

> hi juergen, thanks for spotting the arithmetic flaw.
> i assume you to 11 bytes by assuming one byte for type, one
> byte for length right, and one byte each for each character, right ?
> so for string types , ASCII is better than BER. BER also restricts
> your string size to 256 characters.
> let us do the same this for boolean values.
> ASCII: 1 byte
> BER  : 3 bytes
> So here too ASCII is better by 200 % better.
> Let us look at some integers (e.g. 4294967295)
> ASCII: 10 bytes
> BER:   6  bytes.
> so only in case in integers BER is 40% better.
> well, let us look at the CPU power. There is no significant
> difference in handling strings and booleans. How about integers ?
> In case of ASCII, the string has to be parsed ( i am sure there are
> some neat algorithms to do that very efficiently).
> given all these using BER is marginally more efficient.  but ASCII provides
> other benefits: i) hell of a lot easier to debug on the wire. ii) most
> management
> platforms are natively ASCII. iii) CPU power increase 2 folds every 18
> months
> ("Moore's Law").
> -----Original Message-----
> From: owner-eos@ops.ietf.org [mailto:owner-eos@ops.ietf.org]On Behalf Of
> Juergen Schoenwaelder
> Sent: Wednesday, December 05, 2001 5:26 PM
> To: sgoswami@umich.edu
> Cc: eos@ops.ietf.org
> Subject: Re:
> >>>>> Subrata Goswami writes:
> Subrata> well, let us look at the following string (say for sysDescr):
> Subrata> "my system".
> Subrata> 1) ASCII: 9 bytes 2) BER: 4+4+18 = 34 bytes.
> Subrata> So I would say ASCII is 400 % more efficient. am i right ?
> BER requires only 11 bytes in this case. You first need to understand
> who something works before you can argue about it. Also note that your
> math is incorrect: 4+4+18 gives 26 and not 34.
> Also note that BER encoding communicates the type and the length of
> the string variable. Now show me the ASCII encoding that does the same
> with less than 11 bytes...
> /js
> --
> Juergen Schoenwaelder      Technical University Braunschweig
> <schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
> Phone: +49 531 391 3289    Muehlenpfordtstr. 23, 38106 Braunschweig, Germany
> Fax:   +49 531 391 5936    <http://www.ibr.cs.tu-bs.de/~schoenw/>