hi Robert, > On 07 Jan 2015, at 09:13, Robert Kisteleki <[email protected]> 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
