Verify query to SP test step: implicit assumption of synchronous SP fetch

[olga-13]

Observed behavior
While running the netrid test suite against our Net-RID Display Provider implementation, one test intermittently fails. That is the case of "ASTM NetRID Display Provider behavior test scenario" -> "Verify query to SP test step".

DP queried SP check

astm.f3411.v22a.NET0240 requires that a Display Provider queries a Service Provider for areas with a diagonal no greater than NetMaxDisplayAreaDiagonal (7km).

If the Display Provider failed to issue requests when it was queried for valid areas, it is in violation of this requirement.

The test appears to expect that a call to a third-party Service Provider is triggered synchronously by each Display Application request to our Display Provider. Our implementation instead maintains a background periodic pull from applicable Service Providers (~1 Hz, scoped to viewports of currently active Display App sessions), and serves Display App requests from the most recent cached snapshot. The test's timing/ordering expectation is met sometimes and missed sometimes, depending on where our periodic cycle sits relative to the Display App request.

sequence.zip

Test check
Scenario: 2) ASTM NetRID Display Provider behavior
Case: Display Provider Behavior
Step: Verify query to SP
Event: 37 DP queried SP

Difference from expected behavior
After tracing the failure we believe the test encodes an assumption, i.e. synchronous SP fetch, that isn't required by ASTM F3411-22a.

Why we believe the pattern we implemented is conformant: Section 5.5 of ASTM F3411-22a describes the SP <-> DP interaction as decoupled from the DA <-> DP interaction, and explicitly names periodic pull as the reference pattern.

• Section 5.5.4.2 — "four general phases relative to a request" lists step (2) as: "once applicable Net-RID Service Providers are identified, the Net-RID Display Provider makes periodic requests to the applicable Net-RID Service Providers for Remote ID data for UAS in the area." The periodicity is at the phase level, not tied to individual Display App requests.
• NOTE 12(e) under 5.5.4.4 is explicit about the cadence: "this requirement is written assuming a pull approach, meaning the Net-RID Display Provider requests data from the Net-RID Service Provider on a periodic basis, such as once per second. A subscription-based implementation can also meet the intent of this requirement as long as the push interval aligns with the NetSpDataResponse95thPercentile and 99thPercentile response times." Two shapes are called out — periodic pull at ~1 Hz, or subscription push at equivalent cadence — both independent of the DA request rate. On-demand fan-out isn't listed as an alternative.
• NET0450 requires the DP to "provide the most recent data available that is relevant, aggregated from all applicable Net-RID Service Providers." The word "available" presumes a locally maintained snapshot refreshed by an independent process.
• Response-time budgets compose serially under on-demand. NET0420 gives DP -> DA its own 95th-percentile budget; NET0260 gives SP -> DP a separate one. Under a synchronous fetch model the DA-visible latency is SP response time + DP overhead, and the DP can't reliably hit its own 95th percentile once tail latencies from N Service Providers accumulate.