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

RE: BER versus ASCII (was: RE:)



Thanks Michael, see my answers below.

Subrata



-----Original Message-----
From: owner-eos@ops.ietf.org [mailto:owner-eos@ops.ietf.org]On Behalf Of
Michael Kirkham
Sent: Thursday, December 06, 2001 2:09 AM
To: Subrata Goswami
Cc: eos@ops.ietf.org
Subject: 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.

>That is a good description. Does not the MIB specify what type of value an
>attribute should have ? I would think it is redundant information.


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

>Agreed. This is the only situation are where BER has some advantages.

Not mentioned about numeric values, however, is their significance in
object identifiers.  You may wish to argue that "sysDescr.0" is shorter
than "1.3.6.1.2.1.1.1.0" 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
subidentifiers.

>Well, that is not exactly true.  Object names are unique as are the OID's.
>Otherwise the SNMP manager would have a hard time resolving an object
>name to OID. Have you come across any situation where the same object
>name corresponds to different OIDs in the same MIB ?

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.

> Agreed. What I am saying is BER really needed ? It appears more as an
> obfuscation layer. The MIB definition (in ASN.1) contains all the relevant
> information about an attribute and the type of values it is allowed to
have.
> Given that I think if agent undestands the MIB definition (in ASN.1 form)
> then BER is not required.  For example we can simplify the varbind to
> look as (s y s D e s c r, m y - b o x) rather than
> (06 08 2B 06 01 02 01 01 01 01 00, 04 06 m y - b o x)
> The OID for sysDescr.0 is 1.3.6.1.2.1.1.1.0, which also can be used
instead of sysDescr.
> That way each time an attribute value is exchanged, we do not send its
type along.
> To shorten integers, a simpler encoding can be adopted. The delimiters can
be some
> byte (e.g. 00).
> Would doing somethig like this imply agents spend more CPU cycles ?

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:

http://www.itu.int/ITU-T/studygroups/com17/languages/

The X.209 version can be obtained from:

http://ecs.itu.ch/cgi-bin/ebookshop/

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.

> Thanks for the info, this is a really good email.