[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Compressing Large Indices?
- To: firstname.lastname@example.org
- Subject: Compressing Large Indices?
- From: Tim Jenkins <tjenkins@TimeStep.com>
- Date: Fri, 21 Jan 2000 11:38:32 -0500
- Delivery-date: Fri, 21 Jan 2000 08:39:54 -0800
- Envelope-to: email@example.com
I have a question related to the IPsec Monitoring MIBs that John Shriver and
I are working on.
We have a table that has a number of indices. It's actually a helper table
to look up specific rows of another table that has an arbitrary integer as
index. Unfortunately, two of the indices of the first table are variable
length octet strings. (They're actually the phase 1 IDs used in IKE, so have
a type as well as a raw octet buffer.)
This violates the sub-identifier length limits, as well as chewing up lots
of space on the wire. So, it was suggested that we use a hash of the desired
indices that are variable length to be the real indices and put the desired
indices (the IDs) in the table. Alternatively, I was thinking about using a
single hash whose inputs are all of the desired indices of this table, since
there are a few of them.
So, the questions are:
1) Is this the best approach?
2) If so, what hash should we use? (I guess I'm looking for a precedent,
rather than inventing something.)
For the hash selection, we can tolerate a hash function that is not
particularly collision resistant, since there's already the possibility of
duplicates based on the raw IDs and we have to deal with that, but the
potential table size is very large in some vendors' implementations,
certainly exceeding 10,000 entries, and perhaps even an order of magnitude
A draft of the MIB is available at
>. The tables that must be changed are "saByCreatorsTable" and
Thanks for any help,
Tim Jenkins Newbridge Networks Corporation
(613) 599-3610 x4304 Fax: (613) 599-3617