PDL, College of Computer Science and Technology, NUDT

yongquanf@nudt.edu.cn

PDL, College of Computer Science and Technology, NUDT

zqlai@nudt.edu.cn

PDL, College of Computer Science and Technology, NUDT

dsli@nudt.edu.cn

Internet memory DNS CXL big memory Heterogeneous memory networks (CXL pools, HBM/DDR/SRAM hierarchies, processing-in-memory arrays) form a big memory system, which exposes fragmented addressing to ML inference runtimes. This document describes Memory DNS (MemDNS), a semantic-addressing framework that applies DNS principles -- domain names, hierarchical delegation, caching, TTL, and authoritative records -- to tensor data placement in Big Memory Systems (BMS), deployed as limited domains (RFC 8799). The focus is "automated pivoting": the resolution and control machinery that automatically switches data access paths (replica selection), migrates data across media (placement pivoting), and recovers from faults (failover pivoting), driven by closed-form decision models (Appendix A; key logic pseudo-code in Appendix C) instead of ad-hoc thresholds. The document specifies record semantics, resolution flow, cache/TTL behavior, delegation, pivot decision models, and protocol considerations, together with a reference implementation summary.

Introduction Machine-learning inference systems are dominated by data movement rather than compute. Tensors must be placed across and accessed from a hierarchy of memory media -- registers, SRAM, HBM, DDR, and CXL-attached pools -- whose bandwidth and latency differ by orders of magnitude. Existing abstractions (distributed shared memory, CXL.mem unified addressing, device meshes) hide physical heterogeneity behind a uniform address space; this hides exactly the structure that placement optimizers need, and it prevents the runtime from automatically pivoting data access between media as access patterns and load evolve. This document proposes Memory DNS (MemDNS; not to be confused with Multicast DNS (mDNS) ): an application of the Domain Name System's machinery -- hierarchical names, delegation, caching, TTL, and authoritative resource records -- to the addressing of tensor data in big memory systems (BMS). A tensor shard is named by a domain such as "model/encoder/layer3/weight/shard2"; resolution returns a set of physical placement records (node, medium, physical coordinates, replicas, read/write attributes). The emphasis is AUTOMATED PIVOTING: the resolver and its control loop automatically switch the data access path among replicas (runtime pivot), migrate data across media on hot/cold changes (placement pivot), and fall over to surviving replicas on faults (fault pivot), using closed-form decision models (Appendix A; key logic pseudo-code in Appendix C) instead of ad-hoc thresholds. The design intentionally reuses DNS semantics where they transfer (hierarchical names, TTL-based freshness, per-resolver caching, zone delegation) and extends them where memory requires it (replica-aware records, physical-coordinate exposure, medium-aware selection, and migration as a first-class operation). MemDNS targets big memory systems operated as limited domains -- for example, a CXL fabric within a single data center -- and does not address Internet-scale interoperability. The relationship to the Internet DNS is discussed in . summarizes a reference implementation (C library, 38 test suites, guest-kernel validation) that exercises every mechanism described here.

Terminology This document uses DNS terminology as defined in where applicable. Additional terms:

Big Memory System (BMS):

a system in which compute nodes access memory over a network (e.g., CXL), or a hierarchy of media with network-like latency characteristics.

Domain:

a hierarchical name identifying a tensor shard or a memory region, e.g., "model/encoder/layer3/weight/shard2".

Placement record:

a resource record mapping a domain to one or more physical placements (node, medium, physical coordinates, replica set).

Pivot:

an automatic switch of the data access path, the data placement, or the serving replica, driven by the resolution machinery rather than by application code.

Background: Big Memory Systems (BMS) A BMS exposes several tiers:

• node-local fast media (HBM/SRAM): high bandwidth, low latency, limited capacity;
• node-local bulk media (DDR): larger capacity, higher latency;
• pooled/remote media (CXL pools ): large capacity, network-scale latency (typically 2-10x HBM latency, 10-100x lower bandwidth);
• processing-in-memory arrays (optional ): compute-capable storage where data movement can be avoided entirely.

A BMS is a tiered system; each compute node sees: | node-local bulk (DDR) | +------------+ | pooled remote (CXL) | | | PIM arrays (optional) | | +-----------------------------+ +--> memory network (e.g., CXL fabric) ]]> Three properties make static placement inadequate:

1. Access patterns drift: expert hotness in mixture-of-experts models, embedding popularity in recommendation models, and KV cache working sets all change over time. Data must pivot between tiers automatically.
2. Replicas create choice: a tensor may have a fast local copy and a slow remote copy; the runtime must pivot to the cheapest reachable replica per request source.
3. Faults are local: a failed node or region must not break the whole system; resolution must pivot to surviving replicas.

Existing addressing (DSM/CXL unified addresses, device meshes) does not expose the medium/placement structure needed for these pivots; MemDNS makes it explicit and machine-resolvable.

Memory DNS (MemDNS) Design

Domain Space and Records The domain space D is a prefix-ordered hierarchy of names over a character set of [a-zA-Z0-9_/.-], without empty components. A domain identifies a tensor shard or a memory region. The mapping from logical index space to physical coordinates is an affine homomorphism: where S is a k-by-r stride matrix, b a bias, and m the modulus vector of the physical coordinate group (e.g., bank/row/column moduli). Resolution exposes these coordinates so that placement optimizers can eliminate bank conflicts structurally. A placement record (type MEM-A) contains:

• owner domain name;
• TTL (authoritative freshness, see );
• read/write mode (RO / WO / RW);
• one or more shards, each with an index range and a replica set; each replica carries node id, medium type, bandwidth, latency, load, and the affine map to physical coordinates.

The record is a tree (data structure): In a C-like notation: CNAME records can alias one tensor name to another (e.g., a model checkpoint to its deployed version). NS-type records express zone delegation ().

Resolution Flow A resolver answers a query (domain, index range, request source node) as follows:

1. local cache lookup (); on hit, return;
2. direct regional server lookup; on hit, cache and return;
3. root delegation lookup (longest-prefix match over delegated zones, ); query the target regional server; on hit, cache and return;
4. otherwise, resolution fails cleanly (NODATA-like ).

The resolution workflow: | return cached record | +-----------------+ +------------------------+ | miss v +-----------------+ hit +------------------------+ | 2. regional |------>| cache and return | | server | +------------------------+ +-----------------+ | miss v +-----------------+ no zone +------------------------+ | 3. root |-------->| 4. fail cleanly | | delegation | | (NODATA-like) | +-----------------+ +------------------------+ | longest-prefix match v +-----------------+ hit +------------------------+ | target regional |------>| cache and return | +-----------------+ +------------------------+ | miss v +------------------------+ | 4. fail cleanly | | (NODATA-like) | +------------------------+ ]]> An A-type placement record with zero replicas is unreachable data: resolution fails rather than returns the record (otherwise stage-2 mapping silently produces no entries). The clean-failure exit is the analogue of negative caching in the DNS , materialized as bounded MEM-FAIL records (). Failure reasons can be reported in the style of Extended DNS Errors . Full resolution additionally performs shard matching (splitting the requested index window at shard boundaries), replica selection (), and physical-coordinate mapping (lambda above), returning the chosen node, medium, and coordinates together with an estimated access latency. Full resolution is a four-stage data-plane workflow:

1. shard matching: split the index window against each shard's range; collect the non-empty sub-ranges;
2. replica selection: per matched shard, pick the replica minimizing cost(r) ();
3. coordinate mapping: apply the shard's affine map to the sub-range, then coalesce adjacent coordinates into segments;
4. transfer and return: execute the DMA (Direct Memory Access) batch and reassemble the data in logical order with an estimated access latency.

Caching and TTL Semantics Local caches are per-resolver, full-associative FIFO by default, with an optional clock-style second-chance mode (recently-hit entries survive one extra eviction pass). Insertion and eviction use a preallocated node pool (size equal to the cache capacity) to avoid allocator cost on the hot path. TTL is the authoritative freshness window of a record: a record created at time t0 with TTL T is authoritative while current_time <= t0 + T (G-19). On expiry the resolver evicts the cached copy and re-queries upstream. Publishing a new version of a record requires invalidating the cached entry first (upstream replace destroys the old record; a cached borrowed pointer would dangle). Consequently, staleness is excluded by the update contract: after invalidation the new version is visible on the next resolve. TTL semantics follow the authoritative-freshness view of the DNS . Unlike serving-stale designs , this design excludes staleness by construction through the update contract. The failure window of a record within a publish period P is exactly max(0, 1 - T/P) of queries (Appendix A.1).

Delegation and Scalability Zones delegate to regional servers by prefix. The delegation table is kept sorted; resolution binary-searches per domain-prefix depth (only the domain's own prefixes can match), giving O(depth * log N) lookup instead of a linear scan. Bulk registration appends in O(1) and lazily re-sorts once (O(N log N) amortized). Delegation is idempotent (re-delegating a prefix replaces the regional pointer) and supports undelegation (performed before destroying a regional server to avoid dangling pointers). For scale, a hierarchical network topology (cards -> leaf switches -> spines -> racks) yields closed-form hop counts (same leaf 2, same spine 4, same rack 6, cross rack 7 in the four-layer model), enabling topology-aware replica selection and migration without dense distance matrices.

Automated Pivoting Pivoting is the resolver/controller's automatic switching of data access. Three pivots are specified; all are driven by closed-form models (Appendix A) and can be overridden by policy. The pivoting control loop: | decision (plan) | +------------------+ +------------------+ | +------------------+---------------+------------------+ v v v +------------------+ +------------------+ +------------------+ | runtime pivot: | | placement pivot: | | fault pivot: | | replica select | | hot/cold migrate | | failover | +------------------+ +------------------+ +------------------+ ]]>

Runtime Pivot: Replica Selection For each matched shard, the resolver selects the replica minimizing where net() is the network latency from the request source to the replica's node (closed-form hops x per-hop latency in hierarchical topologies). This is a per-request pivot: as the request source distribution changes, the chosen replica changes automatically. Selection prefers the cheapest reachable replica; ties are broken deterministically (e.g., first in record order). Source-dependent resolution has a direct precedent in the DNS: the EDNS Client Subnet option , which likewise makes the answer depend on the requester's location. Placement of replicas themselves (the k-median objective over access sources) is a control-plane function; on hop-metric topologies the cost is constant within a leaf, so leaf-aggregated k-median is exactly equivalent to card-level k-median and costs O(N + k*L^2) instead of O(N^2) (Appendix A.4).

Placement Pivot: Hot/Cold Migration A control loop observes per-domain access frequency and latency (or accepts injected observations) and plans a migration when the frequency-weighted benefit exceeds the one-time DMA cost plus hysteresis: dma_time * 1.1 ]]> The destination minimizes dma_time + f * cost(dest) among candidates; the request source is taken into account (src-aware destination choice). On success the controller adds the new replica, sets the old record's TTL, performs the copy, and removes the old replica (DNS update contract, ). The migration workflow is:

1. observe per-domain access frequency and latency (or accept injected observations);
2. plan: compute benefit (above); if benefit > dma_time * 1.1, choose the src-aware destination minimizing dma_time + f * cost(dest);
3. execute: add the new replica; set the old replica's TTL; perform the DMA copy; remove the old replica;
4. update: invalidate cached copies, then replace the record ; the new version is visible on the next resolve.

Migration is unidirectional (hot -> fast tier) by default; a near-zero-frequency shard on an expensive medium can be demoted to the pool (cold demotion). Write amplification is bounded: with no cool-back path and 10% hysteresis, each domain migrates at most once per hot period, so WA <= number of domains (one pass each), independent of drift frequency (Appendix A.2).

Fault Pivot: Failover Replica redundancy provides failover: with two replicas, removal of one leaves resolution serving the other; removal of all replicas makes the record unreachable and resolution fails. Zone-level faults are isolated: a failed zone's records resolve to failure while other zones continue to serve. Resolver restart reconnects to the same authoritative tree; zone rebuild (undelegate -> destroy -> recreate -> re-delegate) restores service. Rebuild is preceded by local-cache invalidation (the cache holds borrowed record pointers, ). The zone-rebuild workflow is:

1. invalidate local caches holding borrowed record pointers;
2. undelegate the zone prefix;
3. destroy the regional server;
4. recreate the regional server;
5. re-delegate the prefix; resolvers reconnect to the same tree on restart.

Cache-Benefit Pivot (Closed Form) Whether the local cache should even serve a domain depends on the miss cost M (in-process ~0.2 us; networked/remote up to milliseconds). With hit cost H, maintenance cost m, and hit rate h, the cached average latency is The cache is net-positive iff M > M* = H + m(1-h)/h (Appendix A.3). Resolvers expose M to the control plane so that caching can be disabled when the miss path is cheap (small in-process systems) and enabled when it is expensive (distributed BMS), pivoting the caching policy itself.

Protocol Considerations

Record Types This document defines the following conceptual record types. No wire encoding is standardized; sketches one for illustration only.

• MEM-A: placement record (owner, TTL, RW mode, shards, replicas with node/medium/bandwidth/latency/affine map).
• MEM-NS: zone delegation (prefix -> regional server).
• MEM-CNAME: tensor-name alias.
• MEM-MIGRATE: control record for a planned migration (src replica, dest replica, data size, benefit estimate); created by the controller, consumed by the executor.
• MEM-FAIL: transient negative record marking a zone/record as unreachable (failure pivot cache).

Wire Encoding Sketch (Illustrative) This section sketches a Type-Length-Value (TLV) wire encoding for the conceptual records of , for illustration only; it is not normative. A future standards-track encoding could use CBOR instead. All multi-octet fields are in network byte order. A record is a sequence of TLVs; the first TLV is the record header. The record header layout: Header fields:

• rtype (1 octet): 0x01 MEM-A | 0x02 MEM-NS | 0x03 MEM-CNAME | 0x04 MEM-MIGRATE | 0x05 MEM-FAIL;
• ttl (4 octets): authoritative freshness, seconds;
• rw (1 octet): 0x01 RO | 0x02 WO | 0x03 RW;
• owner (variable): domain name, octets of the canonical "a/b/c" form, length-prefixed (1 octet).

Body TLVs:

• 0x02 shard: lo/hi index range (each 4 octets) per dimension, dimension count (1 octet) first;
• 0x03 replica: node (4 octets), medium (1 octet, registry ), bandwidth (4 octets, GB/s x 1000), latency (4 octets, ns), affine stride matrix (k*r*8 octets), modulus vector (k*8 octets);
• 0x04 src-replica: node (4) + medium (1);
• 0x05 dest-replica: node (4) + medium (1);
• 0x06 data-size (8 octets) + benefit (8 octets, ns);
• 0x07 fail-window (4 octets, seconds; bounded, ).

Unrecognized TLV types are skipped (their length is known); a malformed record (length overflow, unknown rtype) causes the whole record to be rejected (fail closed).

Relationship to the DNS Protocol MemDNS reuses DNS concepts (hierarchy, delegation, caching, TTL, CNAME/NS semantics) but is NOT the Internet DNS: domains are memory tensor names, records carry physical placement, and resolution is an in-process or in-network function with microsecond budgets rather than a global distributed database. MemDNS deployments are limited domains , and the acronym MemDNS (Memory DNS) is unrelated to Multicast DNS (mDNS) . Interoperability with the Internet DNS is neither required nor precluded; a MemDNS root could in principle be served by a DNS server with an extended record type, but latency budgets make that deployment-specific.

Reference Implementation A reference implementation ("MemDNS" , C library + framework integration) exercises every mechanism in this document:

• resolver hierarchy with per-resolver caches, pooled nodes, clock eviction, TTL contract, prefix invalidation;
• delegation with lazy sorting, per-depth binary search, idempotent re-delegation, undelegation;
• shard matching, replica selection (src-aware), coordinate mapping (incremental + wrap-free segment fill);
• migration controller (frequency-weighted, hysteresis, cold demotion), fault injection suite (remove/restore, zone isolation, replica failover, resolver restart, zone rebuild);
• validation: guest-kernel (qemu + Linux 6.6 + devdax) resolution and data-plane runs; third-party simulator cross-checks.

The closed-form models (Appendix A) and key logics (Appendix C) are empirically verified: TTL failure window bit-exact against max(0,1-T/P); miss-cost threshold M* = 0.217 us with benefit converging to the hit rate at millisecond miss costs; WA upper bound = domain count.

Security Considerations This section follows the guidelines of . The threat model is a multi-tenant big memory system in which an attacker can observe or inject resolution traffic, publish forged records, or issue unauthorized migration requests; the objectives are layout confidentiality, resolution integrity, and availability against cache thrashing. The mitigations below mirror the defenses for DNS cache poisoning . MemDNS records describe physical memory placement; exposure of these records to unauthorized parties reveals memory layout and access patterns. Deployments authenticate resolver-to-server and server-to-server communication in multi-tenant settings, and encrypt record payloads where layout secrecy matters. The update contract requires invalidate-before-replace; an attacker able to inject invalidation can force resolution churn (denial of service via cache thrashing). Control records (MEM-MIGRATE) are accepted only from authorized controllers to prevent malicious migration (data movement attacks, media wear amplification). Fault-pivot negative caching (MEM-FAIL) is bounded in time to avoid permanent black-holing of a recovered zone.

IANA Considerations This document has no IANA actions. The registries below are included for illustration only; should a future standards-track document standardize the encoding of , an Expert Review registry could be defined along these lines: Registry name: Memory DNS Record Types (illustrative)

Type	Name	Reference
0x01	MEM-A	this document, Section 6.1.1
0x02	MEM-NS	this document, Section 6.1.1
0x03	MEM-CNAME	this document, Section 6.1.1
0x04	MEM-MIGRATE	this document, Section 6.1.1
0x05	MEM-FAIL	this document, Section 6.1.1
0x06-0xEF	Unassigned
0xF0-0xFF	Private use

Registry name: Memory DNS Medium Types (illustrative)

Value	Medium	Reference
0x01	SRAM/SMEM
0x02	HBM
0x03	DDR
0x04	CXL
0x05	PIM array

Informative References Compute Express Link Consortium MemDNS project MemDNS project

Closed-Form Decision Models A.1. TTL failure window: with authoritative TTL T and publish period P, the fraction of queries that fail (record expired, no fresh copy) is max(0, 1 - T/P); the break-even point is T* = P. Verified bit-exact. A.2. Migration write amplification: with unidirectional migration and 10% hysteresis, WA <= #domains (each domain migrates at most once per hot period); lifetime scales as 1/(1 + WA) under a fixed program/erase budget. A.3. Cache benefit threshold: M* = H + m(1-h)/h; the cache is net-positive iff miss cost M > M. Benefit converges to h as M -> infinity. A.4. Hierarchical k-median: under hop-metric topologies the cost is constant within a leaf; leaf-aggregated k-median with local search is exactly equivalent to card-level k-median and runs in O(N + k*L^2).

RFC 8499 Terminology Mapping

RFC 8499 term	MemDNS counterpart
Fully Qualified Domain Name (FQDN)	Canonical tensor domain (e.g., "model/enc/l3/w/shard2")
Resource Record (RR)	Placement record (MEM-A)
CNAME	MEM-CNAME (tensor-name alias)
Zone	Memory zone (delegated prefix)
Authoritative server	Regional server holding the record
Resolver	In-process/in-network MemDNS resolver
Recursive resolution	Cache -> regional -> root walk
Cache	Per-resolver local cache (TTL)
TTL	Authoritative freshness window
Negative caching	MEM-FAIL bounded fail window
Zone transfer	not applicable; publish via invalidate+replace
DNSSEC	future work; layout integrity/auth

Zone transfer is not applicable: the control plane publishes via invalidate+replace. Layout integrity and record authentication (a DNSSEC analogue) are future work . Differences: MemDNS domains carry tensor semantics and physical placement; resolution budgets are microseconds (in-process or in-network) rather than Internet-scale; updates are push-based (invalidate-before-replace) rather than zone-transfer-based.

Key Logic (Pseudo-Code) C.1. Resolution () C.2. Replica Selection () C.3. Migration () dma(dest) * 1.1: # 10% hysteresis return dest if freq < 1 and current.medium in {HBM, SRAM}: return CXL # cold demotion return null execute_migration(d, dest): invalidate_cache(d) # invalidate-before-replace add_replica(d, dest) old.set_ttl(grace) dma_copy(old, dest) remove_replica(old) dns_update(d) # visible on next resolve ]]> C.4. Failover ()