Subject: RE: [ippm] Way to store traceroutes

From: "Saverio Niccolini" <[email-masked]>
Date: Fri, 14 Jan 2005 16:59:13 +0100

Dear all,
thanks a lot for your useful suggestions.

We have tried to draft a "traceroute object" based on what we discussed
on the list and what we had in mind. We think this will serve as a
starting point of our information model.

We have taken the disman draft as a starting point and we have erased
some fields not useful in the scope of our draft (that we do not specify
here), moreover we have added and changed other ones:

NEW fields:
1) traceRouteResultsLastGoodPathDuration (duration of single running of
the last good traceroute path determination)
2) traceRouteResultsLastRun (when the last traceroute with these
characteristics was launched)
3) traceRouteHopsASNumber (AS number of the hop)

CHANGED fields:
1) traceRouteProbeHistoryTime (timestamp of when the traceroute probe
came back) was changed to traceRouteProbeHistorySentTime (timestamp of
when the traceroute probe was sent)

Please find here how the "traceroute object" looks like right now:

--traceRouteObjects
  |
  +--traceRouteCtlTable
  |  |
  |  +--traceRouteCtlEntry
  |     |
  |     +--traceRouteCtlOwnerIndex
  |     +--traceRouteCtlTestName
  |     +--traceRouteCtlTargetAddressType
  |     +--traceRouteCtlTargetAddress
  |     +--traceRouteCtlByPassRouteTable
  |     +--traceRouteCtlDataSize
  |     +--traceRouteCtlTimeOut
  |     +--traceRouteCtlProbesPerHop
  |     +--traceRouteCtlPort
  |     +--traceRouteCtlMaxTtl
  |     +--traceRouteCtlDSField
  |     +--traceRouteCtlSourceAddressType
  |     +--traceRouteCtlSourceAddress
  |     +--traceRouteCtlIfIndex
  |     +--traceRouteCtlMiscOptions
  |     +--traceRouteCtlMaxFailures
  |     +--traceRouteCtlDontFragment
  |     +--traceRouteCtlInitialTtl
  |     +--traceRouteCtlDescr
  |     +--traceRouteCtlMaxRows
  |     +--traceRouteCtlCreateHopsEntries
  |     +--traceRouteCtlType
  |
  +--traceRouteResultsTable
  |  |
  |  +--traceRouteResultsEntry
  |     |
  |     +--traceRouteResultsOperStatus
  |     +--traceRouteResultsIpTgtAddrType
  |     +--traceRouteResultsIpTgtAddr
  |     +--traceRouteResultsTestAttempts
  |     +--traceRouteResultsTestSuccesses
  |     +--traceRouteResultsLastGoodPath
  |     +--traceRouteResultsLastGoodPathDuration
  |     +--traceRouteResultsLastRun
  |
  +--traceRouteProbeHistoryTable
  |  |
  |  +--traceRouteProbeHistoryEntry
  |     |
  |     +--traceRouteProbeHistoryIndex
  |     +--traceRouteProbeHistoryHopIndex
  |     +--traceRouteProbeHistoryProbeIndex
  |     +--traceRouteProbeHistoryHAddrType
  |     +--traceRouteProbeHistoryHAddr
  |     +--traceRouteProbeHistoryResponse
  |     +--traceRouteProbeHistoryStatus
  |     +--traceRouteProbeHistorySentTime
  |
  +--traceRouteHopsTable
     |
     +--traceRouteHopsEntry
        |
        +--traceRouteHopsHopIndex
        +--traceRouteHopsIpTgtAddressType
        +--traceRouteHopsIpTgtAddress
        +--traceRouteHopsASNumber
        +--traceRouteHopsMinRtt
        +--traceRouteHopsMaxRtt
        +--traceRouteHopsAverageRtt
        +--traceRouteHopsRttSumOfSquares
        +--traceRouteHopsSentProbes
        +--traceRouteHopsProbeResponses

We believe that most of the fields are self-explaining, for the unclear
ones please refer to the disman draft:
http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.t
xt

Looking forward to receive your comments.

Best regards,
Saverio Niccolini

============================================================
Dr. Saverio Niccolini
Research Staff Member
Network Laboratories, NEC Europe Ltd.
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 90511-18
Fax:     +49 (0)6221 90511-55
e-mail:  [email-masked]
============================================================

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: Mark Santcroos <[email-masked]>
Date: Fri, 14 Jan 2005 17:16:35 +0100

How about (reserving) a field for geo/location info about each hop?

Mark

-- 
RIPE NCC - Delft University of Technology - The FreeBSD Project
[email-masked] - [email-masked] - [email-masked]

---

From: stanislav shalunov <[email-masked]>
Date: 14 Jan 2005 11:44:54 -0500

Saverio,

Your object summarizes the data on each hop rather than presenting the
raw list.  This has the following problems:

* Space for only one IP number is provided.  What if different queries
  with the same TTL elicit replies from different IPs?

* The statistics (such as average RTT, max RTT, and sum of squares of
  RTTs) are not robust.  This is not in line with the treatment of
  delay in other IPPM documents, where percentiles are used.  I
  believe that in the case of traceroute -- where the amount of data
  is small for each hop -- there's no reason to not store the
  individual delay, etc., values.

I'd argue for a list of probes for each hop instead of a summary of
the given TTL.

                                                        --Stanislav

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

"Computer Science is no more about computers than astronomy is about
telescopes."					-- E. W. Dijkstra

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Jan 2005 11:25:16 -0800

>thanks a lot for your useful suggestions.

This work is already established in the DISMAN WG.  See RFC 2925,
or its update (in progress):
http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.txt

I strongly urge you to work with the DISMAN WG to resolve
perceived deficiencies with the RemOps MIB, rather than
create a spin-off MIB.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Jan 2005 11:25:16 -0800

Andy

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 17 Jan 2005 10:52:53 +0100

Hi Andy,

> http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-06.txt

Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB.

> perceived deficiencies with the RemOps MIB, rather than

As editor of draft-ietf-disman-remops-mib-v2-06.txt I wonder
what you consider as 'perceived deficiencies with the RemOps MIB'.

In the context of IPPM, there is certainly the deficiency, that
you can only store measurements that were performed locally and that
the tables for storing measurement results are read-only.

But anyway, does the IPPM WG plan to store traceroute results in a MIB?

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 17 Jan 2005 10:52:53 +0100

Hi Andy,

Thanks,

    Juergen