Subject: RE: prequeal to WG lat call om the LSR mib module

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 6 Jun 2003 17:13:59 +0200

All...

As soon as you get to see the MIB module, you can all check
for yourself. Here is why I have a serious concern with using
24-octet index objects. Specifically for the mplsXCTable, where 
3 of such 24-octet objects are used as index.

My comments below are based on a pre-relase version of the doc I got
to see/check, so if things have changed since then, it may not be
100% accurate.

Take the mplsXCTable. It has 3 of these objects as index onjects.

It has 7 columns of which 5 are read-create. The read-create objects
are all pretty small in size. Like 3 integer based that would contain
some 9 octets on the wire together, then an LSPID (4 or 8 octets
on the wire), and another index type, possibly 26 octets on the wire.
So the actual DATA values on the wire to create (or read) such a row
consists of max 43 octets.
 
The OID for the mplsXCEntry is: 1.3.6.1.2.1.10.166.2.1.9.1

So if each of the indices is 24 octets, then it adds 3*25 or 75 octets
to each OID. So the OID for each column is 87 octets.
 
So to transport the 5 objects (containing max 43 octets of real data)
you potentially have to send 435 + 43 or 478 octets.
Add to that the overhead for SNMP header and PDU header data, and
it does not even fit in a 484 SNMP packet anymore and so a 
createAndGo may not be working in some implementations anymore.

When you had 3 Unsigned32 as index. the OID for each column
would have been max 29 octets or so. So the total would have
been 145 + 23 is some 168 or so octets (the data for the 
mplsXCLabelStackIndex would also be reduced from 26 to 6).

Thanks,
Bert

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Sat, 7 Jun 2003 09:12:54 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Wijnen, Bert (Bert)
> Sent: Friday, June 06, 2003 11:14 AM
> To: MPLS WG
> Subject: RE: prequeal to WG lat call om the LSR mib module
> 
> 
> All...
> 
> My comments below are based on a pre-relase version of the 
> doc I got to see/check, so if things have changed since then, 
> it may not be 100% accurate.
> 
> It has 7 columns of which 5 are read-create. The read-create 
> objects are all pretty small in size. Like 3 integer based 
> that would contain some 9 octets on the wire together, then 
> an LSPID (4 or 8 octets on the wire), and another index type, 
> possibly 26 octets on the wire. So the actual DATA values on 
> the wire to create (or read) such a row consists of max 43 octets.
>  
> So if each of the indices is 24 octets, then it adds 3*25 or 
> 75 octets to each OID. So the OID for each column is 87 octets.
>  
> So to transport the 5 objects (containing max 43 octets of 
> real data) you potentially have to send 435 + 43 or 478 
> octets. Add to that the overhead for SNMP header and PDU 
> header data, and it does not even fit in a 484 SNMP packet 
> anymore and so a 

	Well Bert, it is always an matter of time versus space.
The use of the larger index allows implementations to efficiently
index things in O(1) fashion rather than doing O(N)->O(N)^3 searches
based on a single Unsigned32. I speak from real experience on this.
Consider what implementations that have distributed label tables 
must do on a GetNext operation in a configuration such as this.
Note that each application resides in a different process
space:

	Application		Incoming Labels Owned by Application
	LDP			{ 15, 29, 45 }
	VPN			{ 30, 31, 32 }
	TE  			{ 16, 17, 18 }
	
	Using the original indexing of (ifIndex, mplsLabel)
worked for the above example, but as VERY inefficient
for a GetNext operation. Think about what happens when
the manager issues a GetNext(14). In this case, I first
have to visit each application and ask it if it has a
label that is greater than 14. This costs O(N)* num appliations 
in the worse case. 

	Now consider how most implementations store the outgoing 
label.  It is my understanding that most implementations do
not index on the outgoing label; rather only on the incoming
one since they do not own the outgoing label. This means
that to find the outgoing label, you have a search
that requires you do search first through all of the
incoming labels, and then for each one, search make
sure that the outgoing label is "best". This results
in O(N^2).

	My operational experience with this MIB and
my customers who are using it over the past 3 or so
years is that such searches translate into is essentially
an unusable MIB considering how many entries are
often contained -- O(100,000+) on a P router -- and 
how long it will take to download each entry * the 
number of entries in the table.

	Now consider if you had used Adrian's
original approach of (applicationId, ifIndex, label):
The searhes would be vastly faster -- O(N)
in all cases -- because you would quickly know if 
you were in the right collection of labels or not, 
and then search through its list of labels. If not
in the right collection, you simply move on to the next
one and search there. The only problem with this approach
is that you have do do at least an O(N) search to find 
the "next" best label. Using more indexing space allows
implementations to customize the index to match EXACTLY
how they index internally, thus giving the potential
for searches to happen in O(1) time, so no matter how
large the table is, you can get the data returned
to you very, very quickly with minor extra overhead on
the wire to achieve this.

	So as you can see, some extra bits on the wire
can go a long, long way to making this MIB extremely
useful.

	--Tom