Subject: RE: [ippm] Way to store traceroutes

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 13 Jan 2005 13:47:23 +0100

Dear Randy, all,
	
thanks for your suggestion, actually we have already had a look at the
disman draft (Juergen Quittek, the current author of the draft is
working next door to us) and we will take it as a starting point for our
work.

Best regards,
Saverio Niccolini

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Randy Presuhn
> Sent: 12 January 2005 21:47
> To: [email-masked]
> Subject: Re: [ippm] Way to store traceroutes
> 
> Hi -
> 
> > From: "Saverio Niccolini" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Wednesday, January 12, 2005 6:29 AM
> > Subject: [ippm] Way to store traceroutes
> 
> 
> ...
> > The ToC is still at a very initial state; in particular we are still
> > working on the most important part: "Storing traceroute
measurements".
> ...
> > Any comment is appreciated.
> ...
> 
> You might take a look at RFC 2925
(http://www.ietf.org/rfc/rfc2925.txt)
> (http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-
> 06.txt
> will soon replace it) to see how the disman WG addressed the
> problem of storing traceroute measurements.  Comments on the RFC or
> the update would be welcome on the disman WG mailing list.
> 
> Randy Presuhn
> disman WG chair
> 
> 
> 
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ippm

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

---

From: "Dunn, Jeffrey" <[email-masked]>
Date: Thu, 13 Jan 2005 12:56:36 -0500

Saverio,

It might also be useful to add a text field for operator comments, such
as machine and OS type, operator name, etc.

Best Regards,
 
Jeffrey Dunn
System Test Manager

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Saverio Niccolini
Sent: Wednesday, January 12, 2005 9:30 AM
To: [email-masked]
Subject: [ippm] Way to store traceroutes

Dear IPPM mailing list,
here, at NEC Europe Network Laboratories, we have seen that the IPPM
charter is requesting someone to contribute with a draft on "Way to
store traceroutes".
I would be glad to contribute to it together with Dr. Sandra Tartarelli
(in CC).
After brainstorming we wrote a simple Table of Contents for the draft.
We would be glad if you could have a look at this in order to say if
this is what the IPPM charter had in mind when speaking of "Way to store
traceroutes".
The ToC is still at a very initial state; in particular we are still
working on the most important part: "Storing traceroute measurements".

ToC:
-- Introduction
	-- Motivation (of this draft)

-- Definition of Traceroute
	-- Scope of traceroute
	-- Protocols (UDP/ICMP)
	-- Set of parameters (for major implementations: list of
configurable parameters / default parameters)

-- Known problems with traceroute
	-- Alternatives to traceroute (e.g. tcptraceroute)

-- Report / Results
	-- Info typically reported by traceroute

-- Storing traceroute measurements
	-- set of configuration parameters
	-- Results
		-- src
		-- dst
		-- hops
		-- number of traceroutes instances
		-- metrics (min, max, etc.)

-- Security considerations

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]
============================================================

---

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 17 Jan 2005 18:48:39 +0100

Ok,
let's say like this:
we agreed that we are not going to write a MIB module but rather to take
inspiration from the DISMAN one in order to define a format to store
traceroute measurements in the context of the IPPM working group.

Best regards,
Saverio

> From: Andy Bierman [mailto:[email-masked]]
> Sent: 17 January 2005 18:25
> To: Henk Uijterwaal
> Cc: Saverio Niccolini; [email-masked]; [email-masked]
> Subject: RE: [ippm] Way to store traceroutes
> 
> At 08:36 AM 1/17/2005, Henk Uijterwaal wrote:
> >Saverio,
> >
> >>By the way, I do not know if the IPPM list agrees on this.
> >>Does the IPPM charter want to define a MIB module for traceroute
> >>measurements?
> >
> >Given the lack of interest in the previous MIB we discussed, and
> >the lack of expertise to review any proposal, I'd say: NO.
> 
> And since this seems to be an extension to a standard developed in the
> DISMAN WG, if this work belongs anywhere in the IETF, it's DISMAN.
> 
> >Henk
> 
> Andy

---

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 17 Jan 2005 18:46:24 +0100

Yes,
I think it is no problem.

Saverio

> From: Mark Santcroos [mailto:[email-masked]]
> Sent: 14 January 2005 17:17
> To: Saverio Niccolini
> Cc: [email-masked]; Juergen Quittek
> 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: "Saverio Niccolini" <[email-masked]>
Date: Mon, 17 Jan 2005 14:03:42 +0100

Hi Andy,
the purpose of our draft is to define a file format in order to store
traceroute measurements and not a MIB module.
The confusion is maybe created by the fact that we just kept the names
from the disman draft-RFC in order to facilitate comprehension of the
fields itself.

Best regards,
Saverio

> From: Juergen Quittek [mailto:[email-masked]]
> Sent: 17 January 2005 10:53
> To: Andy Bierman; Saverio Niccolini
> Cc: [email-masked]; [email-masked]
> Hi Andy,
> --On 14.01.2005 20:25 Uhr +0100 Andy Bierman wrote:
> 
> > At 07:59 AM 1/14/2005, Saverio Niccolini wrote:
> >> Dear all,
> >> 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
> 
> Saverio and Sandra already had a look at the DISMAN-TRACEROUTE-MIB.
> 
> > 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.
> 
> 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
> 
> 
> > Andy
> >
> >
> >
> >> 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
> >>

---

From: "Sandra Tartarelli" <[email-masked]>
Date: Mon, 24 Jan 2005 13:47:05 +0100

Stanislav,

> The standardized data structure would benefit from having per-hop
> summaries only if the amount of per-hop data is large.  Traditionally,
> traceroute uses three packets per hop.  Storing their actual delays
> seems like a better deal than storing the median, some interquintile
> distance, and minimum.  Even if the sample is has a size of 5 or some
> other small number, why would one even want these statistics stored
> instead of the actual data?

There seems to be a misunderstanding on this point. We assume that for
instance a network administrator might want to repeat at different times
(over days, weeks, months....) the same traceroute (i.e. with the same
parameters) to a certain destination. 
Given this, when we talk about per-hop summaries (e.g. average_RTT), we
mean a summary for all probes sent in the past to the same destination
and with the same parameters and not a summary for the three (or any
other number of) probes of the last run. 

The idea behind such a summary is to have an immediate comparison of the
current with the past network conditions, to detect possible changes.

Sandra