Add HERMES documentation section (draft for review)

[Burdantes]

HERMES has a blog post and a published paper, but there is not currently a good place on the M-Lab site to point someone who wants to understand what HERMES produces or how to query the data. This PR adds that missing piece.

This is still a content draft and is opened for review, not merge. Every new page has a draft banner, and I have listed the remaining open questions below.

Where it lives

I put HERMES under /tests/, in a new Analysis Systems section, rather than under /data/.

HERMES is not itself a test that M-Lab runs, but it is a system M-Lab operates. The existing site structure already follows this pattern for NDT: the main pages for the system live with the system, while /data/ points people to them.

The new group is described as systems that “analyze the measurements collected above, rather than collecting new measurements of their own.” I think that captures HERMES reasonably well without suggesting that it is another measurement experiment.

How I am framing HERMES

One thing I wanted to be careful about is not reducing HERMES to traceroute enrichment.

At a high level, HERMES detects statistically significant performance degradations across groups of NDT measurements and then tries to localize them using network paths. Annotating traceroute hops with AS, geolocation, and interconnection information is one part of that pipeline. It is also the most visually obvious part, so it is easy for it to become the description of the whole system.

I therefore kept enrichment one level down, under the methodology section. The top-level pages focus instead on the full pipeline: detection, baselines, statistical tests, localization, and the resulting events. The enrichment page starts by explaining where that component fits into the broader system.

Pages

Page	Purpose
/tests/hermes/	What HERMES is, what questions it answers, and what it publishes
/tests/hermes/quickstart/	Access, query cost, and first queries
/tests/hermes/schema/	Both tables, field by field
/tests/hermes/examples/	Worked query examples
/tests/hermes/methodology/	The HERMES pipeline, stage by stage
/tests/hermes/methodology/path-enrichment/	The path-enrichment component
/learn/traceroute/	A general-audience traceroute explainer

I put the traceroute explainer under /learn/ rather than HERMES because it should also be useful to readers of scamper1, reverse traceroute, and IPRS. /learn/ already describes itself as moving toward this kind of material. I also linked it from the relevant traceroute test pages.

The schema page treats hermes.events_enriched as the main interface users should query, with hermes_union.events_with_as_and_geoloc documented as the operational table underneath it. I also included a complete mapping from the legacy field names to the canonical ones.

The field names, types, and structure currently come from create_events_enriched.sql, 04_mapping_union.sql, and the pipeline DDLs in m-lab/hermes.

Things I would especially like checked

@sermpezis:

1. Does the overall HERMES/enrichment framing look right? And does Analysis Systems under /tests/ feel like the right home for it?

2. Things that still need to be resolved before merge

   • Access. The HERMES tables live in mlab-collaboration, and users with access to measurement-lab can already query them. This means the existing M-Lab BigQuery access model and QuickStart can be reused.
   • The example queries still need to be tested against the live table. Before publication, each query should be run and its scanned-bytes estimate recorded.
   • Row grain and coverage window need confirmation. I currently describe a row as one NDT measurement belonging to a monitored group, based on the schema and row counts.
   • Field types should be checked against INFORMATION_SCHEMA.COLUMNS. They are currently inferred from the pipeline DDLs and SQL rather than read directly from the live tables.
   • events_enriched does not currently expose the statistical-test outputs. The Mann-Whitney, Welch’s t, and Wasserstein results are present in the operational table but are not projected into the published view. I documented the current workaround, but this means the stable interface is missing some of the fields that most directly describe HERMES’s statistical results.
   • The grid icon could be better. The current one is cropped from the HERMES logo. It works at 80 px, but the surrounding tiles use simple line art, so a dedicated icon would fit better.

   Preview

   The sandbox-* branch is accessible. Here is a rendered URL that should be much easier to review than the Markdown diff: http://website.mlab-sandbox.measurementlab.net/tests/hermes/.

   One unrelated issue surfaced while editing _pages/05-tests.md: the grid uses Bootstrap’s floated col-* classes, so tiles with different heights leave whitespace holes. I have intentionally kept that fix out of this PR. It is a one-line stylesheet change on fix/grid-tile-float-whitespace, and keeping it separate should make this PR easier to review as a content change.

   ---

   This change is 

[sermpezis]

Instead of repeating links to resources, I suggest adding a link to the documentation e.g., to /tests/hermes/#start-here (so that we don’t have duplicate info in the website)

[sermpezis]

To avoid having duplicate info in the website, I suggest removing these links and keep only the main link to Hermes

[sermpezis]

What's "historical names"?

[sermpezis]

Suggested change

	**A hop's RTT is not a link's latency.** RTT to a hop is a round trip that includes the return path from that hop, which may differ entirely from the path back from the destination. Rising RTT at a hop does not localize a problem to that hop by itself — which is precisely why HERMES combines path evidence across many measurements rather than reading a single traceroute.
	**A hop's RTT is not a link's latency.** RTT to a hop is a round trip that includes the return path from that hop, which may differ entirely from the path back from the destination. Rising RTT at a hop does not localize a problem to that hop by itself.

[sermpezis]

I suggesting writing this differently / in a way that highlights the generality of the traceroute enrichment pipeline. Here we describe the annotation. Indeed that is part of HERMES (and we should provide pointers and context), but it may confuse people if we presented as a part of another pipeline.

For example, sth along the lines:

• Start with the generic statement
  A raw traceroute hop is an IP address and some round-trip times. On its own that cannot answer "which network was this, and where was it?" — the questions localization depends on. This page describes how the traceroute enrichment pipeline turns each hop into an annotated hop, which sources it uses, how it records where each annotation came from, and how it flags annotations that are probably wrong.
• And then provide links to HERMES: (i) write that the pipeline is part of HERMES and (ii)
  It produces the annotated paths that HERMES uses as evidence when localizing a performance degradation and (iii) For the HERMES system, see the [HERMES overview]({{ site.baseurl }}/tests/hermes/); for the stage's place in the pipeline, see the [methodology]({{ site.baseurl }}/tests/hermes/methodology/)

[sermpezis]

• remove confirm
• clarify/define (or add pointer) what measurement group is

[sermpezis]

Add also a line with (text and) pointer to the annotated traceroute pipeline