Subject: [ippm] Way to store traceroutes

From: "Saverio Niccolini" <[email-masked]>
Date: Wed, 12 Jan 2005 15:29:57 +0100

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

Any comment is appreciated.

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: stanislav shalunov <[email-masked]>
Date: 12 Jan 2005 12:35:20 -0500

Saverio,

I think that, conceptually, the draft should define a standard
representation (textual or binary) of a data structure that would hold
the results of a traceroute measurement.  It would seem to me that the
data structure itself should look something like (using a made-up
pseudocode):

RECORD
  date and time of start of measurement
  duration of single running
  IP address version (4 or 6)
  source IP address
  destination IP address
  u_int8_t protocol version (1 for ICMP, 6 for TCP, 17 for UDP, etc.)
  u_int16_t source port (unused of not meaningful -- e.g., ICMP)
  u_int16_t destination port (unused of not meaningful -- e.g., ICMP)
  u_int8_t maximum TTL
  ARRAY with indices from 1 to maximum TTL
    LIST of individual probe results
      IP address
      u_int8_t protocol version of response (usually 1, except for last)
      ICMP message description (Time Exceeded, etc.; special value for NaN)
      delay (with a special value for infinity)

Things to decide before sitting down to write the draft:

* Is this the right data structure?

* Are there any missing fields?  Unnecessary fields?

* How would it be represented?  (My hunch would be to define either
  just a textual representation or both textual and binary
  representations.)

One thing I'd argue against would be the use of XML for textual
representations without a standard binary representation.  That would
encourage wasteful practices: XML is expensive to parse.  A textual
representation that doesn't require parsing without a binary
representation would be fine as far as I am concerned.

                                                        --Stanislav

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

This message is designed to be viewed at room temperature.

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 12 Jan 2005 17:44:50 +0100

IPPM group,

>I would be glad to contribute to it together with Dr. Sandra Tartarelli

Saverio: thanks for the offer.  Traceroutes are being used by lots of 
measurement efforts, either as an independent measurement or to get path 
information to support other measurement efforts.  However, there is no
document (AFAIK) describing the tool and the output that we like to store.

>                 -- metrics (min, max, etc.)

Speaking as myself, I'd add:
   -- Time that the traceroute was collected
   -- Method (TCP/ICMP/UDP) and packet size
   -- Errors: (TR did not finish, errors returned by various
       implementations.

Henk

>Any comment is appreciated.

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Look here junior, don't you be so happy.
And for Heaven's sake, don't you be so sad.                 (Tom Verlaine)

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 12 Jan 2005 12:47:29 -0800

Hi -

> From: "Saverio Niccolini" <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, January 12, 2005 6:29 AM
> Subject: [ippm] Way to store traceroutes

...
> 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

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 13 Jan 2005 15:23:36 +0100

>   duration of single running

I assume that you mean the time it took to take the traceroute?

>     LIST of individual probe results

We should specify the value if a hop does not return a valid address.

>       delay (with a special value for infinity)

Does anybody use the delay?

Do we want to store the hostname and/or AS number for the host?

Henk

---

From: stanislav shalunov <[email-masked]>
Date: 13 Jan 2005 11:46:05 -0500

> I assume that you mean the time it took to take the traceroute?

Yes.

> We should specify the value if a hop does not return a valid address.

Right.  Special values are needed for IP address and delay here.

> Does anybody use the delay?

It might get useful some day as a measure of network delay, and for
now it's useful for estimating router load.  And very roughly, it
usually lets you tell if something is in the other hemisphere or in
the basement.

> Do we want to store the hostname and/or AS number for the host?

We already have the source IP address, if you mean that.  Do you
already want hostname?  Like a DNS name or just an opaque label?  (If
the latter, we might just say it's an opaque label.)

I'm not sure why source AS should be in traceroutes.  Could you say
how you think it'd be used (and where it would come from in the first
place)?

                                                        --Stanislav

This message is designed to be viewed in boustrophedon.

---

From: Henk Uijterwaal <[email-masked]>
Date: Thu, 13 Jan 2005 21:39:24 +0100

>how you think it'd be used (and where it would come from in the first

To facilitate analysis of the data. AS# are very helpful to see which
parts of a path are inside a single provider, and which parts are
between providers.  Data can be pulled from routing registries, BGP tables
and possibly other sources.

DNS names and some human intelligence can be used to see where a router is 
physically located.  This is by no means perfect, though in PAM2002, we 
published a paper explaining delays by looking at names and guessing the 
location of the routers.  This worked quite well.

Just storing the IP address doesn't quite work, as address blocks are
sometimes returned to the RIR's and recycled, and LIR's move blocks
across their networks.

I'm not saying that these fields should be filled, just that we should
reserve space to store the data.

Henk

---

From: stanislav shalunov <[email-masked]>
Date: 13 Jan 2005 15:58:52 -0500

Oh, I misunderstood.  I thought you were suggesting hostname and AS
for the source of the traceroute rather than the intermediate points.
Yes, for intermediate points, I agree completely: there should be
space to keep ASN and hostname.

But we must show them that they cannot terrorize the greatest nation on
the face of the Earth.  And we won't.       -- George W. Bush, 20011017