--- title: "rbush" summary: headinfo: | ---

Operators understand that research has needs, and we very
much appreciate the results thereof, especially when it
results in

o improved protocols
o pathology removal
o tools, ...

We have too many POPs and routers to add hardware to each

But scattered probes seem to be where the ISPs are going
See Louie Mamakos's one way delay work

But work such as Waikato's has use in hardware testing, as in
his switch example

This stuff is great to calibrate or otherwise confirm
measurements we make in other ways

A real positive is that it works on Junipers too

Flow data are only interesting in the long term, as we can
not do anything to change the habits of a few million users

Knowing protocol use/distribution is useful in design, but it
is static, i.e. we think about it when we make architecture
decisions such as cacheing

When the size of the measurement data is within an one or two
orders of the size of the data being measured, we have a real
operational problem

So protocol use would be a nice quarterly report from CAIDA,
and we'd check occcasionally to see if we are abnormal

As Daniel McRobb pointed out, this obviates the worry that
IPsec obscures port numbers

We actually had to build for ourselves

o distributed aggregators
o collecting flow, cef accounting, mac accounting, ...
o converting to a canonic form
o backflow to a centralized oracle database
o complex reporting system based on knowing prefix, next hop AS, and end AS mapping

It was not fun. It took two attempts, the first a junky
throwaway by a consultant

The payoff was worth it

But, to operate our network going forwrd, we need

o traffic volume (by next hop AS, city-pair, peer, ...)
o support for traffic engineering
   - L2 folk
   - MPLS and beyond
o quality issues such as latency and packet loss
o SLA compliance (connectivity, delay, drop, ...)
o QoS/DiffServ contract compliance (cust and peer)
o Multicast

And these interact, as Anja Feldmann pointed out

There are a lot of links and a lot of routers

The links are thick, OC3 & OC12, and getting thicker

There is a lot of data

So we can not put probes as close to links as we might like.

And both routers and local servers MUST AGGREGATE

Related Objects

See https://catalog.caida.org/paper/1999_isma9901/ to explore related objects to this document in the CAIDA Resource Catalog.