Drone airspace deconfliction with no leader

Three equal DSS instances — Frankfurt, Tokyo, Los Angeles — each on its own device of a leaderless replicated log. No leader, no election, no shared database. Every instance applies the ASTM F3548 operational-intent rule in the same log order:

accept an intent only if its key names every accepted intent it intersects (space, altitude, time); otherwise 409.

Load: a busy single cell, with the semantics of InterUSS's FlightsInSub.py (10 s intents, random path in one cell, altitude 0–10 000 m in a 1 m band, key = every OVN the writer holds, 0.01–0.1 s between requests). Each USS talks to the DSS instance on its own server.

The recording runs on one machine (three instances on loopback) so it fits in a GIF. Every number below is from the three real servers.

Results — three continents

Target from interuss/dss#1541: busy cell, ≥ 2 write QPS, p99 < 5 s, 5xx < 1 %.

run	seal period	writers	accepted/s	p50	p95	p99	5xx	same decision on all three
wan_1s_8writers	1 s	8	3.27	1.97 s	2.90 s	3.09 s	0 / 152	yes
wan_250ms_32writers	250 ms	32	48.7	0.47 s	0.53 s	1.55 s	0 / 1,779	yes — 1,779 / 1,779
wan_150ms_32writers_NOT_AGREEING	150 ms	32	67.4	0.27 s	0.33 s	1.26 s	0	no — 3 differ
wan_100ms_32writers_NOT_AGREEING	100 ms	32	87.6	0.21 s	0.29 s	0.46 s	0	no — 49 differ
wan_150ms_32writers_confirmed	150 ms + confirm	32	29.6	0.92 s	1.12 s	3.25 s	0 / 1,031	yes
wan_100ms_32writers_confirmed	100 ms + confirm	32	33.5	0.91 s	1.01 s	2.23 s	0 / 1,126	yes — 1,126 / 1,126

One instance stopped halfway (Los Angeles):

run	Frankfurt + Tokyo after the stop	first answer after the stop	longest gap before → after
wan_1s_8writers_la_stopped	0 / 111 errors	0.55 s	2.11 s → 2.13 s
wan_150ms_32writers_confirmed_la_stopped	0 / 632 errors	0.36 s	0.51 s → 0.95 s

Nothing to elect: the other two keep deciding. (The 5xx in those files are requests sent to the stopped instance.)

No two accepted intents intersect without the later one's key naming the earlier, in every run.

What the rows mean

• Seal period is when a device treats a range of log positions as settled. It is a setting.
• Below 250 ms the instances stopped agreeing. Across continents some records still arrived after one device had sealed; that instance skipped them, the others did not. Fast and wrong — those rows are here to show it, not as results.
• "+ confirm": an instance decides a range only after every reachable instance reports the same log content for it. That fixes agreement at every setting. Today it costs p50 ~0.9 s, because each confirmation opens a new connection across continents (Frankfurt–Tokyo ≈ 230 ms round trip; Los Angeles, in the middle, sees p50 0.54 s). Not optimised yet.

What this is not

• Not faster than InterUSS's Raft datastore (discussion 1633: ~95 QPS, < 300 ms, 9 nodes with simulated latency). The argument is no leader, not speed.
• Only PUT operational_intent_references; bounding boxes instead of polygons; no subscriptions, notifications, queries or deletes; DSS0215 not checked; three instances, not > 24.
• Our load generator with their test's semantics — not uss_qualifier or their locust files.
• An instance that does not answer is skipped when confirming (otherwise one dead instance stops the rest). A live but cut-off instance holding a record the others lack could still break agreement.
• The engine is not open source. The DSS rule layer and the load generator ran on top of it.

Check the numbers yourself

python3 verify.py

results/*.csv: one row per request — t_send (unix s), latency_s, HTTP code, writer, shim = the instance asked (0 Frankfurt, 1 Tokyo, 2 Los Angeles). results/decisions/<run>/<city>.txt: position intent-id status OVN missing, one line per decided position, per instance — verify.py compares the three.