Geographic Location for Media over QUIC Relays

1.1. Design Goals

• Minimal protocol impact: Reuse existing MoQ catalog, metrics, or discovery mechanisms where possible.¶

• Interoperability: Use standard geographic representations (WGS84, GeoJSON) and widely recognized identifiers (IATA codes).¶

• Extensibility: Allow optional altitude, region codes, and path metrics (RTT, PT) without mandating them.¶

3.1. Relay Selection by Proximity

A subscriber in New York (NY) may have multiple relays available (e.g., A, B, C, D). With geocode and RTT/PT metrics, the client or an orchestration layer can select the relay that minimizes latency or satisfies geographic constraints.¶

3.2. Geo-Distributed Orchestration (GDOR)

Some clients require their media data to remain locally or geo-fenced within specific jurisdictions for privacy and security compliance (e.g., GDPR, HIPAA, or sector-specific regulations). An operator may require that:¶

• EU subscriber traffic flows only through EU relays.¶

• Media for a given jurisdiction is processed within that jurisdiction.¶

• Path selection avoids certain regions for policy or cost reasons.¶

Geocode enables GDOR by allowing relays to advertise their jurisdiction (e.g., via country/region codes) and by allowing path computation to respect geographic boundaries. Service providers can use relay geocode and the advertised neighbor topology to track the geographic path of media packets as they traverse the MoQ relay mesh, supporting compliance audits and geo-fencing enforcement.¶

3.3. Path and Vicinity Awareness

In a relay mesh (e.g., A↔B↔C↔D), knowing the geocode of each relay allows:¶

• Vicinity: Computing great-circle distance or approximate propagation delay between relays.¶

• Path: Understanding the geographic route (e.g., NY → Relay D → Relay A → SVC) and optimizing it.¶

3.4. Metrics Integration

Deployments commonly measure RTT to Relay and PT (Propagation Time) to Relay as key metrics. Geocode complements these by providing a stable, policy-relevant attribute (location) that does not change with network conditions, while RTT/PT provide dynamic performance signals.¶

4.1. Primary Format: WGS84 Coordinates

Relay geocode MUST be representable as WGS84 coordinates (as used in GeoJSON [RFC7946]):¶

• latitude: Decimal degrees, -90 to 90.¶

• longitude: Decimal degrees, -180 to 180.¶

• altitude (optional): Meters above WGS84 ellipsoid.¶

Example (JSON):¶

json { "latitude": 40.6413, "longitude": -73.7781, "altitude": 4 } ¶

4.2. Optional: IATA Code

An IATA airport code MAY be included as a human-readable geographic identifier. IATA codes are widely used for airports and major metro areas and provide a compact, recognizable reference (e.g., JFK for New York, LHR for London).¶

Suggested IATA codes for common relay regions (informative):¶

The IATA code SHOULD correspond to the nearest major airport or metro area where the relay is located. It is advisory only; precise routing MUST use latitude/longitude when geographic accuracy is required.¶

4.3. Optional: Region and Jurisdiction

For GDOR and compliance, relays MAY advertise:¶

• country: ISO 3166-1 alpha-2 (e.g., "US", "DE").¶

• subdivision: ISO 3166-2 (e.g., "US-NY", "DE-BY") as in [RFC9388].¶

5.1. JSON Schema

The following JSON structure defines the relay geocode advertisement. It MAY be carried in MoQ catalog extensions, metrics ([MoQMetrics]), or a dedicated discovery resource (e.g., well-known URI).¶

json { "$schema": "http://json-schema.org/draft-07/schema#", "title": "MoQ Relay Geocode", "type": "object", "required": ["relay_id", "latitude", "longitude"], "properties": { "relay_id": { "type": "string", "description": "Unique relay identifier" }, "latitude": { "type": "number", "minimum": -90, "maximum": 90 }, "longitude": { "type": "number", "minimum": -180, "maximum": 180 }, "altitude": { "type": "number", "description": "Meters above WGS84 ellipsoid" }, "iata_code": { "type": "string", "pattern": "^[A-Z]{3}$", "description": "IATA airport/metro code" }, "country": { "type": "string", "pattern": "^[A-Z]{2}$", "description": "ISO 3166-1 alpha-2" }, "subdivision": { "type": "string", "description": "ISO 3166-2 subdivision" }, "rtt_ms": { "type": "number", "description": "RTT to this relay (ms), if advertised" }, "pt_ms": { "type": "number", "description": "Propagation time to relay (ms), if advertised" }, "neighbors": { "type": "array", "items": { "type": "object", "properties": { "relay_id": { "type": "string" }, "rtt_ms": { "type": "number" }, "pt_ms": { "type": "number" } } }, "description": "Adjacent relays and inter-relay metrics" } } } ¶

5.2. Example Advertisement

Relay D in New York area, with path metrics:¶

json { "relay_id": "relay-D", "latitude": 40.6413, "longitude": -73.7781, "altitude": 4, "iata_code": "JFK", "country": "US", "subdivision": "US-NY", "rtt_ms": 16, "pt_ms": 12, "neighbors": [ { "relay_id": "relay-A", "rtt_ms": 7, "pt_ms": 3 }, { "relay_id": "relay-C", "rtt_ms": 12, "pt_ms": 5 } ] } ¶

5.3. Integration with MoQ

• Catalog: A relay MAY include geocode in catalog metadata for namespaces or tracks it serves.¶

• Metrics: Geocode MAY be part of metrics exposed per [MoQMetrics] for relay selection and monitoring.¶

• Discovery: A relay MAY serve geocode at a well-known path (e.g., /.well-known/moq-relay-geocode) or via a Setup Option in SETUP.¶

The exact wire format and negotiation are left to a companion specification or a future revision of the MoQ transport or metrics documents.¶

6.1. Great-Circle Distance

Given two relays with geocode (lat1, lon1) and (lat2, lon2), the approximate great-circle distance in kilometers can be computed using the Haversine formula or an equivalent. This provides a stable measure of physical proximity independent of network topology.¶

6.2. Path Metrics

When relays advertise neighbors with rtt_ms and pt_ms, a client or orchestration system can:¶

1. Build a relay graph: Nodes = relays, edges = neighbor relationships with RTT/PT.¶

2. Compute paths: Shortest path by RTT, by PT, or by geographic distance.¶

3. Apply GDOR constraints: Filter paths to those that stay within required jurisdictions (using country, subdivision).¶

6.3. Vicinity Semantics

• Same metro: Relays with the same iata_code or within ~50 km.¶

• Same region: Relays with the same subdivision or country.¶

• Cross-border: Path crosses country boundaries; may trigger compliance checks.¶

7.1. Privacy

• Geocode reveals relay location. Operators who wish to hide exact location MAY advertise only country and subdivision, or a coarse-grained geocode (e.g., rounded to 0.1°).¶

• IATA codes are less precise than coordinates and may be preferred when exact location must not be disclosed.¶

7.2. Integrity

• Geocode advertisements SHOULD be integrity-protected (e.g., over TLS as with MoQ) and, when used for compliance, SHOULD be verifiable (e.g., signed by a trusted authority).¶

7.3. Misuse

• Adversaries could advertise false geocode to attract traffic or evade geographic restrictions. Relays SHOULD be authenticated; geocode from untrusted sources SHOULD be validated or ignored.¶

9.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC7946]

Butler, H., Daly, M., Doyle, A., Gillies, S., Hagen, S., and T. Schaub, "The GeoJSON Format", August 2016.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

9.2. Informative References

[MoQMetrics]

Jennings, C., "Metrics over MOQT", Work in Progress, Internet-Draft, draft-jennings-moq-metrics-02, 2025, <https://datatracker.ietf.org/doc/draft-jennings-moq-metrics/>.

[MoQTransport]

IETF MOQ WG, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-17, 2026, <https://datatracker.ietf.org/doc/draft-ietf-moq-transport/>.

[RFC8801]

"Discovering Provisioning Domain Names and Data", July 2020.

[RFC8805]

"A Format for Self-Published IP Geolocation Feeds", August 2020.

[RFC9388]

"Content Delivery Network Interconnection (CDNI) Footprint Types: Country Subdivision Code and Footprint Union", June 2023.