[Dnsmon-test] DNSMON testing

Robert Kisteleki robert at ripe.net
Tue Mar 4 12:23:07 CET 2014 

Hi,

Answering some comments you have...

On 2014.03.04. 10:52, Peter Koch wrote:
> All,
> 
>> We are ready for the first phase of testing the new DNSMON service.
> 
> I'm chiming in very late after Robert kindly twisted my arm.

I'm happy to serve ;-)

> I like the new
> interface very much. It is easier to handle and gives more knobs to turn.
> Of course the downside of the latter is, it might be more confusing.
> 
> Some observations and questions: starting with the "unanswered queries"
> view sounds reasonable to me and I'm glad to see that retries will be disabled
> in the undeerlying measurements.  The default values for 'green' and 'red'
> might deserve some explanation somewhere (I know I can change them, but what
> do they mean to the occasional user?).

The defaults are the same as in the old DNSMON, so whatever they meant to
users still applies.

> It might be my browser (Safari), but when changing the upper (red) value
> in the text field I have to fight gainst a "100" (or even "1000")
> showing up and leading to weird input.

We can look at that if it's a genuine bug.

> The "relative RTT" value is interesting, but I'm not really sure that the
> green/red signalling is it.  "green" implies good and "red" implies bad,
> but expectations really depend on where the probes are and whether a server
> is anycast or not.  A (coloured) graph with an "average" line would

Indeed for anycast, relative graphs can show you lots of interesting things.
But otherwise this view fills a particular user need; don't use it if it
doesn't help you ;-)

> probably reflect the situation better.  Add to the wishlist: in the personal
> view it would be nice if one could enable/disable certain vantage points, not
> meaning to stop the measurement, but to use (or not) the results in the display.

That's indeed a possible enhancement.

> I understand it's time to not start with a v4 only view, but treating v4 and v6
> as completely different hosts in the visualisation is again confusing.
> I know I can switch to v4, v6, or both, but that's not what I mean.
> the v4/v6 for the same server name could be grouped closer together.
> Not sure that mixing the results (taking averages over both) would be
> good, especially since anycast clouds might give counter intuitive results
> (traffic for the saame name being directed to different endpoints).

I believe this to be an enhancement to the old DNSMON, as that didn't
combine the IPv4/IPv6 view, meaning you had to check two pages to see it
all. Now you can see it in one page if you want to. But you don't have to.

> Along that line, some of the servers have two IPv4 adresses (or even 2 * IPv6),
> just there is one line (cf. ns0.ja.net).  How is the measurement applied
> against the two (or more) addresses?

That's a good one, will check.

> It appears that the result in this private test are diplayed in near real
> time, where DNSMON had an artificial delay of 2 hours.  We've had a similar
> discussion re: availability of atlas measurement results and I'd like to
> repeat that we'd not want to give away an easy feedbck loop for people
> with too much time on their hands.  Can I safely assume that the two hour
> delay will be reinstantiated as soon as the servcie becomes public?

I don't think you can "safely assume", but I'm not authoritative on this.

> Finally, with the "going live" around the door, what is the migration plan?
> In other words: will both services run in parallel to give us time to
> migrate our own software from DNSMON data to ATLAS data?  How quick can
> (historic) DNSMON data be fed into the new system?

We don't have plans to feed old data into the new system. Different set of
vantage points, different syntax if not semantics, different backends,
different visualisations. So this is not really feasible.

We're discussing internally in what shape or form the old DNSMON data and/or
visualisation should still be available, and for how long.

Regards,
Robert

> Thanks,
>   Peter
>