Re: [atlas] Map-based visualisations for Atlas data

[Emile Aben]

On 08/12/15 09:50, Robert Kisteleki wrote:
> Hi,
> 
> On 2015-12-05 14:43, Baptiste Jonglez wrote:
>> Hi,
>>
>> Is there a way to reuse and adapt the code for the maps available here?
>>
>>   https://atlas.ripe.net/results/maps/
>>
>> It could be interesting to have a generic map-based visualisation, where
>> all probes matching a certain set of conditions would be displayed.
>>
>> Possible applications include:
>>
>> - monitor IPv6 deployment for an AS, by displaying all probes matching
>>   "asn_v6 = XX".  It would probably be useful to also display probes
>>   matching "asn_v4 = XX", as a baseline, using a different color
>>
>> - monitor DNS resolver outage geographically, by matching on system tags
>>   like "resolving A doesn't work".
>>
>> - match on user tags, like "IXP" or "core", to monitor deployment of Atlas
>>   at specific locations/types of networks.
> 
> There's some development needed, but it'd be possible to add a generic map
> that is filterable by probe tags (and other filters present today). What we
> cannot do today is doing this historically, as that'd require keeping track
> of probe tag status for all probes at arbitrary points in time.
> 
>> In all those examples, the "time slider" functionality would be extremely
>> useful, to see the evolution over time.  It could be even nicer if the
>> slider could move automatically, so as to provide nice animations.
> 
> The time travel functionality is available on all maps (unless we forgot
> some :-) where the measurement is/was ongoing.
> 
> We tried doing animations / movies and while it's not impossible, it's
> extremely resource intensive both on the server and the client side (for 9K
> probes...). It's possible to do it as a gimmick, but we don't see it as a
> realistic public service.

Experiments with external platforms like CartoDB do work though:
https://labs.ripe.net/Members/emileaben/visualising-network-outages-with-ripe-atlas

(figures 2)

but just animation without other info is quite hard to follow (at least
for me), so i think adding more information ( like figure 4 ) is very
helpful if you want to make stuff more then a gimmick.

cheers,
Emile

Re: [atlas] Map-based visualisations for Atlas data

[Robert Kisteleki]

Hi,

On 2015-12-05 14:43, Baptiste Jonglez wrote:
> Hi,
> 
> Is there a way to reuse and adapt the code for the maps available here?
> 
>   https://atlas.ripe.net/results/maps/
> 
> It could be interesting to have a generic map-based visualisation, where
> all probes matching a certain set of conditions would be displayed.
> 
> Possible applications include:
> 
> - monitor IPv6 deployment for an AS, by displaying all probes matching
>   "asn_v6 = XX".  It would probably be useful to also display probes
>   matching "asn_v4 = XX", as a baseline, using a different color
> 
> - monitor DNS resolver outage geographically, by matching on system tags
>   like "resolving A doesn't work".
> 
> - match on user tags, like "IXP" or "core", to monitor deployment of Atlas
>   at specific locations/types of networks.

There's some development needed, but it'd be possible to add a generic map
that is filterable by probe tags (and other filters present today). What we
cannot do today is doing this historically, as that'd require keeping track
of probe tag status for all probes at arbitrary points in time.

> In all those examples, the "time slider" functionality would be extremely
> useful, to see the evolution over time.  It could be even nicer if the
> slider could move automatically, so as to provide nice animations.

The time travel functionality is available on all maps (unless we forgot
some :-) where the measurement is/was ongoing.

We tried doing animations / movies and while it's not impossible, it's
extremely resource intensive both on the server and the client side (for 9K
probes...). It's possible to do it as a gimmick, but we don't see it as a
realistic public service.

Regards,
Robert

> Is all this currently feasible, and if not, would it be hard to implement?
> 
> Thanks,
> Baptiste
> 

[atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

[Stephane Bortzmeyer]

http://root-servers.org/news/events-of-20151130.txt

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

[Daniel Karrenberg]

On 8.12.15 16:16 , Nico CARTRON wrote:
> On 8 December 2015 at 16:07:02, Stephane Bortzmeyer (bortzme...@nic.fr
> ) wrote:
>> http://root-servers.org/news/events-of-20151130.txt 
> 
> Thanks Stéphane for your reactivity, as usual :)
> 
> “Such test traffic may not be indicative of what happens to normal
> traffic or user experience”.
> 
> Not entirely sure what this means behind, or is it just them trying to
> minimise the impact?


Real resolvers
- use caching,
- retry queries,
- can use all authoritative servers for a zone,
- perform recursion, and (again)
- use caching.

The typical TTL for caching in the root zone is 48 hours.

dnsmon does not do any of this. it measures the responsiveness of
particular servers.

This means dnsmon is a diagnostic tool for DNS root name server
operators and not a diagnostic tool for the DNS service.

Daniel
inventor of dnsmon (the first version)
co-inventor of RIPE Atlas
advisor for for k.root-servers.net operations (one of "them")

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

[Philip Homburg]

On 2015/12/08 16:45 , Daniel Karrenberg wrote:
> Real resolvers
>   - use caching,
>   - retry queries,
>   - can use all authoritative servers for a zone,
>   - perform recursion, and (again)
>   - use caching.
> 
> The typical TTL for caching in the root zone is 48 hours.

I wonder if in the case of local DNSSEC validating resolvers behind
DNSSEC-unware resolvers in CPEs, this model is still valid.

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

[Nico CARTRON]

Hi Chris,
On 8 December 2015 at 16:35:29, Chris Amin (ca...@ripe.net) wrote:

On 08/12/2015 16:16, Nico CARTRON wrote: 
> On 8 December 2015 at 16:07:02, Stephane Bortzmeyer (bortzme...@nic.fr 
> ) wrote: 
>> http://root-servers.org/news/events-of-20151130.txt 
> 
> Thanks Stéphane for your reactivity, as usual :) 
> 
> “Such test traffic may not be indicative of what happens to normal 
> traffic or user experience”. 
> 
> Not entirely sure what this means behind, or is it just them trying to 
> minimise the impact? 

It could be a bit of expectation management on their part. I agree with 
the statement that DNSMON and other similar tools do not provide direct 
insight into end user experience, but that is also not their goal. 
DNSMON at least is deliberately designed to measure from stable vantage 
points (RIPE Atlas anchors, formerly TTM boxes), and makes no attempt to 
simulate how recursive resolvers and end user operating systems may 
behave. In fact, it avoids such attempts, even to the point that it 
never retries a failed query, which most clients would do. I would argue 
that this is a feature of the system, providing as it does a nice clear 
signal that functions as a good metric for traffic between recursive 
resolvers and the authoritative servers. 

For reference, this is what DNSMON "saw" during the reported time 
period, which seems to correspond to the times in the report: 

[…]
Fully agreed, but I still don’t see why they are downplaying the event like 
this.

Tools such as DNSMON are useful, and of course need to be taken with a grain of 
salt and not blindly believed “as it”.

A lot of users/eyeballs have noticed problems, so pretending this did not 
happen is not really… constructive.

(OK, they did not pretend this did not happen, but downplaying is kind of the 
same to me).



Cheers,

-- 

Nico

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

[Daniel Karrenberg]

On 8.12.15 16:56 , Philip Homburg wrote:
> On 2015/12/08 16:45 , Daniel Karrenberg wrote:
>> Real resolvers
>>  - use caching,
>>  - retry queries,
>>  - can use all authoritative servers for a zone,
>>  - perform recursion, and (again)
>>  - use caching.
>>
>> The typical TTL for caching in the root zone is 48 hours.
> 
> I wonder if in the case of local DNSSEC validating resolvers behind
> DNSSEC-unware resolvers in CPEs, this model is still valid.

At the risk of turning this into another DNS discussion list: Why are
you wondering exactly? DNSSEC validating resolvers do cache, don't they?

Daniel
whose CPE runs unbound

Re: [atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

[Philip Homburg]

On 2015/12/08 17:08 , Daniel Karrenberg wrote:
>> I wonder if in the case of local DNSSEC validating resolvers behind
>> DNSSEC-unware resolvers in CPEs, this model is still valid.
> 
> At the risk of turning this into another DNS discussion list: Why are
> you wondering exactly? DNSSEC validating resolvers do cache, don't they?

To give an example, the ssh client I use is linked with getdns. Getdns
will try to fetch RRSIG records, etc. from the local resolver. If that
fails, getdns will become a full recursive resolver.

When ssh starts, the cache of getdns will be empty. And after DNS
resolution whatever is cached will not be used anymore.