Subject: Re: <draft-ietf-disman-remops-mib-04.txt>

From: [email-masked]
Date: Mon, 14 Jun 1999 11:01:42 -0400 (EDT)

>>Conceptually, I'd capture the results from the traceroute program and
>>simply stuff the results into a table.
>
>It has to be more than this or else the history table would be sufficient.
>I think the idea is to keep the results on a per hop basis so that the current
>state of each of the hops can be look at, more then just seeing the last
>traceroute test result in the history table.

The difference between output from the traceroute program(s) (that
I've seen, at least) and what's in the traceRouteResultsTable is:

-  the output from the traceroute program is summarized 
   on a per-hop basis; but
-  what's in the traceRouteResultsTable is presented on a 
   per-ICMP request basis.

So if three ICMP requests are sent per-hop, the traceroute program
presents min/max/avg numbers, but the traceRouteResultsTable will
contain three times as many entries as hops, and each entry will 
have a response time number for a single ICMP request.

It's possible to have the management station pull down the entire
traceRouteResultsTable, do the math, and find the slow hops, but
the agent can do the summarization with much less overall CPU and
network overhead.

>>If I understand correctly, ditching the TestNumber index will mean this
>>table can only keep a single set of results for a traceRouteCtlEntry.
>>This is sufficient to give me the prop delays along the path, and thus
>>provide the utility I specifically requested.
>
>>After talking with other people with hands-on network analysis experience,
>>they reassured me the historical information of what the path was and now
>>is is useful information for problem analysis.
>
>>I'd still encourage the retention of the traceRouteHopsTestNumber index,
>>but do what you must.  Jettison the whole table and move on if the
>>consensus is that this whole issue is irrelevant.
>
>To leave the TestNumber index in I have to understand better when new
>entries are added. What you said in your earlier posting is to create 
>an entry per test activation. This would be transitions of the Admin/Oper 
>status objects. I can't see this happening very often or being used to 
>create hop entries. I think it would be better to lets the appls that 
>use the MIB keep historic information.

I'm specifically thinking about the case where the traceRouteCtlFrequency 
MIB object has been set to enable periodic traceroute tests.  

OK.  I'll confess.  I re-visited the traceRouteProbeHistoryTable in
the MIB, and now understand it a bit better.  The two things I've
been suggesting:

-   Statistical summaries on a per-hop basis; and
-   Path history for identifying/understanding path changes;

can be done by retrieving the raw data from the traceRouteProbe-
HistoryTable.   I still believe it would be a more judicious trade-off
of processing/network overhead to let the agent do the statistical
summaries on a per-hop basis instead of the management station.  I 
now understand the hop history can be obtained from the 
traceRouteProbeHistoryTable.   So I agree it would acceptable to 
drop the TestNumber index (as suggested above) if preferred.

Regards,
--Alan
 
 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 423 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 423 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.int.snmp.com/
 -----------------------------------------------------------------------------