Subject: Re: [ippm] Way to store traceroutes

From: Mark Allman <[email-masked]>
Date: Wed, 02 Mar 2005 16:15:11 -0500

I am interested in this topic for a number of reasons.  I have thought
about how to store measurements and meta-data about measurements (which
is at least as important as the measurements).  A bunch of our thoughts
have been captured in ...

    Mark Allman, Ethan Blanton, Wesley Eddy. A Scalable System for
    Sharing Internet Measurements. Proceedings of the Passive and Active
    Measurement Workshop, March 2002.
    http://www.icir.org/mallman/papers/simr-pam2002.ps

I am not yet sure I completely understand the motivation behind bring
this up within the IETF at the moment.  Maybe someone could fill in that
detail?

Also, CAIDA is currently implementing a measurement repository and so
they are defining ways to store all sorts of meta-data-ish kinds of
things.  I think it'd be good to involve them in this process if this is
something that IPPM is going to do.  (Because they may well be a user of
the output and they have thought about the issues quite a bit and will
likely have some useful input on the storage scheme.)

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

I would actually very much argue against a binary form of
representation.  The way these things are stored is only really
important (from an IETF or "standards") perspective in terms of dealing
with "interoperability" ... i.e., in terms of sharing these
measurements.  It doesn't matter to me how you store the measurements
you take and keep for yourself, nor does it matter to you how I keep
mine.  It only matters when we want to swap.  So, given that ... I think
XML is the right way to exchange information.

First claim: XML is wasteful.  Well, yes... but, it compresses.  Not to
the size of a binary representation, but never-the-less still decently.
Second claim: XML is "expensive" to parse.  That depends on what you are
considering in the calculation of "expense".  I consider it easy to
parse given that there are libraries all over the place for every
language known to man to do it.  I.e., I don't have to implement some
binary slurping of some new data format.  So, XML is *cheaper* for *me*.
For the computer parsing XML is no doubt more expensive.  But, I am very
much happy to exchange computer cycles for my cycles any day of the
week.  Maybe I am weird.

Also, you didn't give the flip side.  While XML is a bit wasteful and it
is more expensive for computers to parse the big win in XML is that XML
is *extensible*.  Binary formats tend to get locked in (even binary
formats that have version numbers).  E.g., look at the libpcap packet
trace format.  It's there.  We can't change it.  It'd be really really
nice if we could change it because it'd be really really nice to further
annotate packet traces sometimes.  But, we're stuck.  This is a little
apples and oranges --- libpcap is meant to collect packets very fast and
collect *tons* of "measurements" (packets) and etc. and so it's harder
to argue that it should be something like XML.  But, the point is still
valid about traceroutes I think.  Packaging traceroutes and passing them
around does not involve the same sort of performance constraints.
Extensibility offers such niceness in terms of all sorts of things from
notes inserted by data collectors to new aspects of the measurement that
will be taken in the future but are not today and so will be left out of
the binary format (e.g., if traceroute sticks in the AS number of every
IP address in 3 years, where is that in your binary format?  you're up a
crick and will have to go through the bother of defining a new one ...).
So, we should use XML.  This is what XML is perfect for.

And, finally, if someone really cares about processing speed (and, no
doubt that is an issue sometimes) then a small XML->binary tool is
pretty straightforward.  I.e., we can always take something generic and
streamline it for particular purposes.  But, we needn't get rid of the
generic extensible version because sometimes we might need a streamlined
version.

I think not doing XML would be a large mistake.

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

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

---

From: "Sandra Tartarelli" <[email-masked]>
Date: Thu, 3 Mar 2005 11:37:10 +0100

Dear Mark,

Thanks for your email and for the attached paper. We will certainly read
it. 

> I am interested in this topic for a number of reasons.  I 
> have thought about how to store measurements and meta-data 
> about measurements (which is at least as important as the 
> measurements).  

Nice to know. Of course if you are interested in contributing with some
text to the draft (current version:
http://www.ietf.org/internet-drafts/draft-niccolini-ippm-storetraceroute
s-00.txt) we will appreciate it. 
 
> Also, CAIDA is currently implementing a measurement 
> repository and so they are defining ways to store all sorts 
> of meta-data-ish kinds of things.  I think it'd be good to 
> involve them in this process if this is something that IPPM 
> is going to do.  (Because they may well be a user of the 
> output and they have thought about the issues quite a bit and 
> will likely have some useful input on the storage scheme.)

We assume that CAIDA people read the IPPM mailing list, so if they are
interested in contributing to this activity, we hope they will comment
on this on the mailing list. Their contribution is obviously more than
welcome.

Best regards,

Sandra Tartarelli

> representation.  The way these things are stored is only 
> really important (from an IETF or "standards") perspective in 
> terms of dealing with "interoperability" ... i.e., in terms 
> of sharing these measurements.  It doesn't matter to me how 
> you store the measurements you take and keep for yourself, 
> nor does it matter to you how I keep mine.  It only matters 
> when we want to swap.  So, given that ... I think XML is the 
> right way to exchange information.
> 
> First claim: XML is wasteful.  Well, yes... but, it 
> compresses.  Not to the size of a binary representation, but 
> never-the-less still decently.
> Second claim: XML is "expensive" to parse.  That depends on 
> what you are considering in the calculation of "expense".  I 
> consider it easy to parse given that there are libraries all 
> over the place for every language known to man to do it.  
> I.e., I don't have to implement some binary slurping of some 
> new data format.  So, XML is *cheaper* for *me*.
> For the computer parsing XML is no doubt more expensive.  
> But, I am very much happy to exchange computer cycles for my 
> cycles any day of the week.  Maybe I am weird.
> 
> Also, you didn't give the flip side.  While XML is a bit 
> wasteful and it is more expensive for computers to parse the 
> big win in XML is that XML is *extensible*.  Binary formats 
> tend to get locked in (even binary formats that have version 
> numbers).  E.g., look at the libpcap packet trace format.  
> It's there.  We can't change it.  It'd be really really nice 
> if we could change it because it'd be really really nice to 
> further annotate packet traces sometimes.  But, we're stuck.  
> This is a little apples and oranges --- libpcap is meant to 
> collect packets very fast and collect *tons* of 
> "measurements" (packets) and etc. and so it's harder to argue 
> that it should be something like XML.  But, the point is 
> still valid about traceroutes I think.  Packaging traceroutes 
> and passing them around does not involve the same sort of 
> performance constraints.
> Extensibility offers such niceness in terms of all sorts of 
> things from notes inserted by data collectors to new aspects 
> of the measurement that will be taken in the future but are 
> not today and so will be left out of the binary format (e.g., 
> if traceroute sticks in the AS number of every IP address in 
> 3 years, where is that in your binary format?  you're up a 
> And, finally, if someone really cares about processing speed 
> (and, no doubt that is an issue sometimes) then a small 
> XML->binary tool is pretty straightforward.  I.e., we can 
> always take something generic and streamline it for 
> particular purposes.  But, we needn't get rid of the generic 
> extensible version because sometimes we might need a 
> streamlined version.
>