The fourth plane : what a quantum testbed runs instead of a script

disclosure first, same as the aerial fiber post: i am on this one. Amlou et al., “A Measurement Plane for Quantum Networking,” arXiv:2607.13291, NIST and Université Grenoble Alpes. i am one of nine authors and not the first, so most of the design credit belongs elsewhere, but i am inside it and cannot review it from outside. what does not change is the format. there is still a section at the end about what i would push on, and this time most of it is aimed at my own paper.

the reason to write it up here is that this blog has spent two posts complaining about the thing it is about.

the quantum LAN post ended by arguing that ebits per second deserves to be the metric of a distribution network and is losing, because nobody states an integration time, a basis set, or a position on accidental subtraction. the flex grid post asked, twice now, for somebody to publish a reconfiguration time. and the post on the Bristol q-ROADM last week ran into the same wall from the other side: a week of per-link data on installed fiber, and the interesting time series is not in the paper.

those are all the same complaint. the measurements exist. what does not exist is a way to say what was measured, in a form somebody else can run.

what a plane is

this word comes from telecom and it is worth ten seconds if you have not met it.

a network element is usually described as three planes, which are not physical parts but separations of concern.

• the data plane moves user traffic. it is the fast path, the thing the ASIC does.
• the control plane decides where traffic goes. routing protocols, label distribution, the thing that computes the forwarding table the data plane uses.
• the management plane configures and monitors the box. SNMP, NETCONF, the CLI you log into, the counters you scrape.

the split is the reason a router is buildable. each plane has its own protocols, its own failure modes, and its own rate of change, and a person can work on one without holding the other two in their head. SDN was, among other things, an argument about where the line between the first two should sit.

quantum networking has been importing this vocabulary for a few years. there is a data plane, which is the entanglement itself. there are control planes: QUANT-NET has a two-level one, ArQNet has a coordinator built on SDN principles, and QNodeOS proposes an operating-system abstraction for the node. this is a healthy amount of work and the vocabulary transferred cleanly.

the paper’s claim is that measurement does not fit in any of the three, and should be its own plane alongside them rather than a feature bolted onto one.

why measurement does not fit

the argument has two halves and i think the second one is the interesting one.

the first half is that everybody is writing scripts. measurement in quantum testbeds today lives inside device-specific control software and ad hoc scripts. that couples the experiment to the hardware it happened to run on, makes anything reusable a rewrite, and makes a distributed multi-step procedure into a person with four terminal windows and a lab notebook. this is a familiar complaint from classical networking, and classical networking answered it: perfSONAR and RIPE Atlas deploy measurement as distributed services, and mPlane wrote down a capability model for describing what a measurement device can do.

so far, so ordinary. if that were the whole argument the answer would be “run perfSONAR.”

the second half is why you cannot. the classical platforms are built around independent observations. a probe pings a target, records a latency, ships the record. probes do not need to agree with each other about anything except roughly what time it is, and no probe’s result depends on what another probe was doing at that instant.

a quantum measurement is not shaped like that. to measure a polarization fringe you must set an analyzer at Alice, set another at Bob, have both time taggers agree to nanoseconds, acquire in the same window, and then compute a quantity that only exists jointly. there is no such thing as Alice’s half of a coincidence. the paper puts this as needing “synchronized state preparation, multiple-device participation, and phase-dependent feedback,” and the shortest version is that the unit of measurement spans nodes.

that is the gap. classical measurement infrastructure has the distribution and the programmability and assumes the observations are independent. quantum testbeds have the joint observations and no infrastructure. the paper is an attempt to take the first and add the second.

the four layers

the architecture is four layers, and they are worth naming carefully because the useful idea is in the middle two.

resource agents sit next to the hardware. one per device, containerized, translating a specific instrument’s API and data format into a common message interface. a time tagger agent hands out timestamps; a polarization controller agent takes an angle and moves a motor. this is a driver layer, and its job is to be the only place in the system that knows what brand anything is.

capabilities turn device access into named operations. a capability is described by a label, the endpoint that provides it, a name, a schema for its parameters, a schema for its results, and metadata. crucially they compose: a coincidence capability consumes timestamps from two remote time-tagger agents, and a polarization-analysis capability wraps the coincidence capability and adds the analyzer settings.

experiment coordination turns capabilities into procedures. which capability, in what order, with what parameters, carrying state and results between steps. a polarization-fringe workflow is a loop that sweeps an analyzer angle and invokes polarization-analysis at each setting.

the application layer is where a person says what they want: a Python client library and a web GUI.

the implementation is Docker containers talking over NATS, with JSON schemas on the messages, Python underneath, and REST plus messaging for the GUI. none of that is exotic and all of it is the point: this is deliberately a boring distributed system, which is the correct thing for a layer whose job is to still be running in three years.

the part i would underline

the capability descriptor is the load-bearing idea, and it is easy to read past because it looks like plumbing.

a capability publishes the schema of what it accepts and the schema of what it returns. that means “coincidence” stops being a word in a methods section and becomes a thing with declared inputs. what integration time. what window. what basis. what it does about accidentals.

hold that thought until the last section, because it is the closest anything has come to the reference procedure the LAN post was asking for, and the paper does not claim it.

one fringe, all the way down

the clearest way to see what the layers buy you is to watch a single experiment go down through them and come back.

the thing i want to draw attention to is how little of that sequence is about physics. one workflow description goes in. what comes back is a fringe. everything between is dispatch, schema validation, two motor moves, two timestamp acquisitions and one join, and in the version this replaces, all of it was a script that only ran on that bench.

what it actually ran

the testbed is two nodes in separate buildings on the NIST campus, about 1.4 km of fiber between them. an SPDC source at Alice, single photon detectors at both ends, motorized polarization analyzers at both ends, and time taggers synchronized over White Rabbit. each node runs a local server hosting its resource agents.

two experiments.

coincidence detection. pull synchronized timestamps from both time-tagger agents, histogram them with a 1 ns coincidence window, find the peak. the raw streams sat about 7.1 µs apart from path and system delays, corrected in software, and after that there is a clean peak at zero delay. the claim attached to this is not the peak, which is unremarkable; it is that the analysis ran online, during the experiment, instead of on files afterwards.

a polarization fringe. Alice fixed at each of −45°, 0°, 45° and 90°; Bob swept. the coordinator walked the settings, invoking the polarization-analysis capability at each pair, and the fringe came back at 98% visibility.

and the number the paper puts on the improvement is that experiment-specific logic went from hundreds of lines of script to a short workflow specification.

that is the whole result. it is a feasibility paper and it says so: “this work demonstrates feasibility rather than scale limits.”

what i’d push on next

so, my own paper. four things, roughly in order of how much i think they matter.

1. a measurement plane that does not measure itself. the headline improvement is “hundreds of script lines to a short workflow specification,” and that is not a measurement. it is the kind of claim the paper exists to make unnecessary. what is the end-to-end latency of one capability invocation. how long did the fringe sweep take, against how long the same sweep took by hand. what is the overhead of NATS plus JSON schema validation against a direct device call. those numbers are three afternoons of work with the system already running, and their absence is conspicuous in this particular paper in a way it would not be in somebody else’s.

2. close a loop, and pick the loop by its deadline. the paper says the architecture supports online measurement and feedback, and both demonstrations are open-loop sweeps. that gap is honest but it is the gap. and there is a specific loop to close, sitting in the group’s own data: on the 62 km aerial link, daytime polarization drift takes fidelity below 95% in under 20 seconds. so a controller that corrects polarization from a live measurement has a budget of a few seconds for the whole path, measure to actuate. does this architecture fit inside that? nobody knows, because of item 1. the latency number is not a benchmark, it is a feasibility criterion for the thing the plane is for.

3. make the capability descriptor into the reference procedure. this is the one i would actually build, and it is why i wanted to write this post.

the LAN post’s complaint was that ebits per second is losing as a metric because there is no stated procedure behind it: no integration time, no basis set, no declared position on accidental subtraction. the fix i asked for was a spec.

a capability descriptor is already 80% of that spec. it has a name, a parameter schema and a result schema. if the coincidence capability’s schema required an integration time, a basis set and an accidentals policy, and if the capability carried a version, then a paper could report “ebits/s, coincidence capability v1.2, parameters as attached” and a reader could run the identical procedure on different hardware. the metric would stop being a word and become an executable.

that costs a registry and a versioning convention, both of which the paper explicitly does not have. it is a small amount of work with a much larger payoff than another supported instrument.

4. three nodes, because two is not a network. two nodes is the smallest thing on which a joint measurement exists at all, and it does prove the point. but the coordination problems that motivated the whole design turn up at three: an entanglement swap at a middle node is a workflow where one participant’s result gates what the other two do, and the coordinator has to carry a herald between them rather than a parameter. that is qualitatively harder than a sweep and it is the case the architecture claims to be for.

the short version

• telecom splits a network element into data, control and management planes. quantum networking has imported all three, and has control-plane work in QUANT-NET, ArQNet and QNodeOS.
• measurement does not fit in any of them, because it is currently ad hoc scripts glued to specific instruments, and because a quantum measurement spans nodes in a way a classical probe does not.
• there is no such thing as Alice’s half of a coincidence. that single fact is why perfSONAR’s model does not transfer, and it is the argument for a fourth plane.
• four layers: resource agents next to the hardware, capabilities as named composable operations with schemas, a coordinator that sequences them, and an application layer where a person describes what they want.
• Docker, NATS, JSON schemas, Python. deliberately boring, correctly so.
• validated on two NIST buildings, 1.4 km of fiber, White Rabbit timing, a 1 ns coincidence window and a 7.1 µs offset corrected in software. the polarization fringe came back at 98% visibility.
• the reported win is hundreds of lines of script becoming a short workflow specification, which is a real win and is not a number.
• the capability descriptor is the interesting object. parameter and result schemas are most of what a citable measurement procedure needs, and adding a version and a registry would turn ebits per second from a word into something reproducible.
• it is a feasibility paper and says so. two nodes, no closed loop, no latency figures, and no story about what happens when a node stops answering.

writing about a paper you are on is uncomfortable in a specific way: the things you would criticise are the things you know are on somebody’s list. so the fair summary is that the architecture is right and the evidence is thin, and the thinness is fixable with the system that already exists. the part i would defend against anybody is the diagnosis. every complaint this blog has made about missing numbers in the last six months has the same root, which is that a measurement in this field is a paragraph in a methods section rather than a thing you can invoke. that is worth a plane.