Internet-Draft Automated Pivoting in Big Memory Systems August 2026
Fu, et al. Expires 27 February 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-fu-memdns-pivoting-01
Published:
Intended Status:
Informational
Expires:
Authors:
Y. Fu
NUDT
Z. Lai
NUDT
D. Li
NUDT

DNS for Automated Pivoting in Big Memory Systems

Abstract

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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 27 February 2027.

▲

Table of Contents

1. 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) [RFC6762]): 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 [RFC8799] -- 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 Section 6.2. Section 7 summarizes a reference implementation (C library, 38 test suites, guest-kernel validation) that exercises every mechanism described here.

2. Terminology

This document uses DNS terminology as defined in [RFC8499] 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.

3. Background: Big Memory Systems (BMS)

A BMS exposes several tiers:

A BMS is a tiered system; each compute node sees:

      +------------+    +-----------------------------+
      |  compute   |    | node-local fast (HBM/SRAM)  |
      |  node(s)   |<-->| 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.

4. Memory DNS (MemDNS) Design

4.1. 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:

   lambda(x) = (S . x + b) mod m

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 Section 4.3);
  • 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):

   MEM-A record
    +-- owner: domain name
    +-- ttl:   authoritative freshness window (Section 4.3)
    +-- rw:    RO | WO | RW
    +-- shards[1..n]
         +-- range: index range (lo, hi per dimension)
         +-- replicas[1..m]
              +-- node, medium, bandwidth, latency, load
              +-- affine: lambda(x) = (S . x + b) mod m

In a C-like notation:

struct placement_record {       /* MEM-A */
  domain_name owner;
  uint32      ttl;              /* seconds */
  uint8       rw;               /* 0x01 RO | 0x02 WO | 0x03 RW */
  shard       shards[];
};
struct shard {
  index_range range;            /* lo/hi per dimension */
  replica     replicas[];
};
struct replica {
  uint32      node;
  uint8       medium;           /* registry, Section 9 */
  uint32      bandwidth;        /* GB/s x 1000 */
  uint32      latency;          /* ns */
  float       load;             /* 0..1 */
  affine_map  affine;           /* S (k x r), b (k), m (k) */
};

CNAME records can alias one tensor name to another (e.g., a model checkpoint to its deployed version). NS-type records express zone delegation (Section 4.4).

4.2. Resolution Flow

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

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

The resolution workflow:

      query (domain, index range, src)
         |
         v
      +-----------------+ hit   +------------------------+
      | 1. local cache  |------>| 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 [RFC2308], materialized as bounded MEM-FAIL records (Section 6.1). Failure reasons can be reported in the style of Extended DNS Errors [RFC8914].

Full resolution additionally performs shard matching (splitting the requested index window at shard boundaries), replica selection (Section 5.1), 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) (Section 5.1);
  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.

4.3. 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 [RFC2181]. Unlike serving-stale designs [RFC8767], 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).

4.4. 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.

5. 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:

      +------------------+  per-domain freq,    +------------------+
      | agent statistics |  latency, source     | closed-form      |
      | (observe)        |--------------------->| decision (plan)  |
      +------------------+                      +------------------+
                                                 |
              +------------------+---------------+------------------+
              v                  v                                  v
      +------------------+  +------------------+  +------------------+
      | runtime pivot:   |  | placement pivot: |  | fault pivot:     |
      | replica select   |  | hot/cold migrate |  | failover         |
      +------------------+  +------------------+  +------------------+

5.1. Runtime Pivot: Replica Selection

For each matched shard, the resolver selects the replica minimizing

   cost(r) = lat(r) + data_size / bw(r) + net(src, node(r))

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 [RFC7871], 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).

5.2. 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:

   benefit = f * (cost(current) - cost(dest)) > 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, Section 4.3).

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 Section 4.3; 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).

5.3. 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, Section 4.3).

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.

5.4. 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

   avg = h*H + (1-h)*(M + m)

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.

6. Protocol Considerations

6.1. Record Types

This document defines the following conceptual record types. No wire encoding is standardized; Section 6.1.1 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).

6.1.1. Wire Encoding Sketch (Illustrative)

This section sketches a Type-Length-Value (TLV) wire encoding for the conceptual records of Section 6.1, for illustration only; it is not normative. A future standards-track encoding could use CBOR [RFC8949] 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:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | type = 0x0001                | length                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | rtype | ttl (4 octets, seconds)                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | ttl (cont.)   | rw  | owner (1-octet length + octets)         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 Section 9), 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, Section 8).

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).

6.2. 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 [RFC8799], and the acronym MemDNS (Memory DNS) is unrelated to Multicast DNS (mDNS) [RFC6762]. 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.

7. Reference Implementation

A reference implementation ("MemDNS" [memdns-impl], C library + framework integration) exercises every mechanism in this document:

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.

8. Security Considerations

This section follows the guidelines of [RFC3552]. 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 [RFC5452].

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 Section 4.3 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.

9. 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 Section 6.1.1, an Expert Review registry could be defined along these lines:

Registry name: Memory DNS Record Types (illustrative)

Table 1
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)

Table 2
Value Medium Reference
0x01 SRAM/SMEM [memdns-impl]
0x02 HBM [memdns-impl]
0x03 DDR [memdns-impl]
0x04 CXL [memdns-impl]
0x05 PIM array [pim-facil]

10. Informative References

[RFC2181]
Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, , <https://www.rfc-editor.org/info/rfc2181>.
[RFC2308]
Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, , <https://www.rfc-editor.org/info/rfc2308>.
[RFC3552]
Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, , <https://www.rfc-editor.org/info/rfc3552>.
[RFC4033]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, , <https://www.rfc-editor.org/info/rfc4033>.
[RFC4034]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, , <https://www.rfc-editor.org/info/rfc4034>.
[RFC4035]
Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, , <https://www.rfc-editor.org/info/rfc4035>.
[RFC5452]
Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, , <https://www.rfc-editor.org/info/rfc5452>.
[RFC5936]
Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, , <https://www.rfc-editor.org/info/rfc5936>.
[RFC6762]
Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, , <https://www.rfc-editor.org/info/rfc6762>.
[RFC7871]
Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, , <https://www.rfc-editor.org/info/rfc7871>.
[RFC8499]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, , <https://www.rfc-editor.org/info/rfc8499>.
[RFC8767]
Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data to Improve DNS Resiliency", RFC 8767, DOI 10.17487/RFC8767, , <https://www.rfc-editor.org/info/rfc8767>.
[RFC8799]
Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, , <https://www.rfc-editor.org/info/rfc8799>.
[RFC8914]
Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, , <https://www.rfc-editor.org/info/rfc8914>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/info/rfc8949>.
[cxl]
Compute Express Link Consortium, "CXL Specification Revision 3.1", , <https://www.computeexpresslink.org/>.
[memdns-impl]
MemDNS project, "Memory DNS: semantic addressing for heterogeneous memory systems -- implementation and evaluation", .
[pim-facil]
MemDNS project, "FACIL-style processing-in-memory array layouts as expressed through MemDNS placement records (2-D logical index, identity affine to array coordinates)", .

Appendix A. 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*L2).

Appendix B. RFC 8499 Terminology Mapping

Table 3
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 Section 8

Zone transfer [RFC5936] is not applicable: the control plane publishes via invalidate+replace. Layout integrity and record authentication (a DNSSEC [RFC4033][RFC4034][RFC4035] analogue) are future work Section 8.

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.

Appendix C. Key Logic (Pseudo-Code)

C.1. Resolution (Section 4.2)

resolve(d, J, src):
  rr = local_cache.lookup(d)
  if rr != null and not expired(rr.ttl):
    return rr
  rr = regional_server.query(d)
  if rr != null:
    local_cache.insert(d, rr)
    return rr
  (zone, server) = root.longest_prefix_match(d)
  if zone == null:
    return NODATA                  # clean failure
  rr = server.query(d)
  if rr != null and rr.replicas not empty:
    local_cache.insert(d, rr)
    return rr                      # zero-replica = unreachable
  return NODATA

C.2. Replica Selection (Section 5.1)

select_replica(replicas, src, bytes):
  best = replicas[0]
  best_cost = cost(best)
  for r in replicas[1..]:
    c = topo_latency(src, r.node)
        + bytes / (r.bandwidth * (1 - r.load))
    if c < best_cost:              # first in order wins ties
      best = r
      best_cost = c
  return best

select_multi_source(replicas, src, bytes, k):   # S8
  for r in replicas:
    w[r] = min(r.bandwidth * (1 - r.load),
               topo_path_bandwidth(src, r.node))
  return chunks proportional to w[r] / sum(w); wall = max over
  streams

C.3. Migration (Section 5.2)

plan_migration(d, freq, cost, src):
  dest = argmin_cand dma(cand) + freq * cost(cand)  # src-aware
  benefit = freq * (cost(current) - cost(dest))
  if benefit > 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 (Section 5.3)

on_replica_removed(rr, r):
  remove_replica(rr, r)
  if rr.replicas empty:
    mark rr unreachable             # resolution fails cleanly
  else:
    invalidate_cache(rr.owner)      # next resolve re-pivots

rebuild_zone(zone):
  invalidate_cache(prefix zone)
  undelegate(zone)
  destroy(server)
  recreate(server)
  redelegate(zone, server)
  resolver_restart()

Authors' Addresses

Yongquan Fu
PDL, College of Computer Science and Technology, NUDT
Zhiquan Lai
PDL, College of Computer Science and Technology, NUDT
Dongsheng Li
PDL, College of Computer Science and Technology, NUDT