hi Robert,
On 07 Jan 2015, at 09:13, Robert Kisteleki <robert@ripe.net> wrote:
Hi,
On 2015-01-05 14:35, Brian Trammell wrote:
Since the target will be an anchor which has known expected content, will these measurements include some indication of whether application-layer rewriting was detected?
The primary purpose is to measure and to collect and provide this data. We can surely implement such checks and related visualisations in the UI and perhaps, if there's support for it, in the form of status checks (see https://atlas.ripe.net/docs/status-checks/).
That seems reasonable.
However, first I'd like to see consensus on what data we should collect, if any :)
ACK. :) Just connecting to anchors via HTTP gives you a few things: information about the routable address of the probe (which I presume is one of the things the anchor reply is used for at the moment), connectivity along a path (but only to an anchor) where ICMP is (for some silly reason mumble mumble) impaired. And looking at time-to-first-byte and time-to-last-byte changes over time gives you some interesting information about the global state of network. Jared's suggestion would make the whole thing much more operationally useful (...says the non-operator...) but at the expense of somewhat more infrastructure. The someone-along-the-path-is-messing-with-HTTP alert I suggested is only of operational interest in a few contexts; I mention it because my Big Thing right now is trying to quantify all kinds of end-to-end impairment. Cheers, Brian