Network Working Group Y. Fu Internet-Draft Z. Lai Intended status: Informational D. Li Expires: 27 February 2027 NUDT 26 August 2026 DNS for Automated Pivoting in Big Memory Systems draft-fu-memdns-pivoting-01 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. Fu, et al. Expires 27 February 2027 [Page 1] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background: Big Memory Systems (BMS) . . . . . . . . . . . . 4 4. Memory DNS (MemDNS) Design . . . . . . . . . . . . . . . . . 4 4.1. Domain Space and Records . . . . . . . . . . . . . . . . 4 4.2. Resolution Flow . . . . . . . . . . . . . . . . . . . . . 6 4.3. Caching and TTL Semantics . . . . . . . . . . . . . . . . 7 4.4. Delegation and Scalability . . . . . . . . . . . . . . . 8 5. Automated Pivoting . . . . . . . . . . . . . . . . . . . . . 8 5.1. Runtime Pivot: Replica Selection . . . . . . . . . . . . 8 5.2. Placement Pivot: Hot/Cold Migration . . . . . . . . . . . 9 5.3. Fault Pivot: Failover . . . . . . . . . . . . . . . . . . 10 5.4. Cache-Benefit Pivot (Closed Form) . . . . . . . . . . . . 10 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 10 6.1. Record Types . . . . . . . . . . . . . . . . . . . . . . 10 6.1.1. Wire Encoding Sketch (Illustrative) . . . . . . . . . 11 6.2. Relationship to the DNS Protocol . . . . . . . . . . . . 12 7. Reference Implementation . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Informative References . . . . . . . . . . . . . . . . . . . 14 Appendix A. Closed-Form Decision Models . . . . . . . . . . . . 16 Appendix B. RFC 8499 Terminology Mapping . . . . . . . . . . . . 16 Appendix C. Key Logic (Pseudo-Code) . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 Fu, et al. Expires 27 February 2027 [Page 2] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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. Fu, et al. Expires 27 February 2027 [Page 3] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 3. 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 [cxl]): large capacity, network- scale latency (typically 2-10x HBM latency, 10-100x lower bandwidth); * processing-in-memory arrays (optional [pim-facil]): compute- capable storage where data movement can be avoided entirely. 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: Fu, et al. Expires 27 February 2027 [Page 4] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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) */ }; Fu, et al. Expires 27 February 2027 [Page 5] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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) | +------------------------+ Fu, et al. Expires 27 February 2027 [Page 6] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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). Fu, et al. Expires 27 February 2027 [Page 7] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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 Fu, et al. Expires 27 February 2027 [Page 8] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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). Fu, et al. Expires 27 February 2027 [Page 9] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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. Fu, et al. Expires 27 February 2027 [Page 10] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 * 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). Fu, et al. Expires 27 February 2027 [Page 11] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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: * 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. 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]. Fu, et al. Expires 27 February 2027 [Page 12] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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) +===========+=============+==============================+ | 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 | | +-----------+-------------+------------------------------+ Table 1 Registry name: Memory DNS Medium Types (illustrative) Fu, et al. Expires 27 February 2027 [Page 13] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 +=======+===========+===============+ | 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] | +-------+-----------+---------------+ Table 2 10. Informative References [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, . [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, March 2005, . [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, March 2005, . Fu, et al. Expires 27 February 2027 [Page 14] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, DOI 10.17487/RFC5452, January 2009, . [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. Kumari, "Client Subnet in DNS Queries", RFC 7871, DOI 10.17487/RFC7871, May 2016, . [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC8767] Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data to Improve DNS Resiliency", RFC 8767, DOI 10.17487/RFC8767, March 2020, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, October 2020, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [cxl] Compute Express Link Consortium, "CXL Specification Revision 3.1", 2023, . Fu, et al. Expires 27 February 2027 [Page 15] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 [memdns-impl] MemDNS project, "Memory DNS: semantic addressing for heterogeneous memory systems -- implementation and evaluation", 2026. [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)", 2026. 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*L^(2).) Appendix B. RFC 8499 Terminology Mapping +====================+================================+ | RFC 8499 term | MemDNS counterpart | +====================+================================+ | Fully Qualified | Canonical tensor domain (e.g., | | Domain Name (FQDN) | "model/enc/l3/w/shard2") | +--------------------+--------------------------------+ | Resource Record | Placement record (MEM-A) | | (RR) | | +--------------------+--------------------------------+ | CNAME | MEM-CNAME (tensor-name alias) | +--------------------+--------------------------------+ | Zone | Memory zone (delegated prefix) | +--------------------+--------------------------------+ | Authoritative | Regional server holding the | | server | record | Fu, et al. Expires 27 February 2027 [Page 16] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 +--------------------+--------------------------------+ | Resolver | In-process/in-network MemDNS | | | resolver | +--------------------+--------------------------------+ | Recursive | Cache -> regional -> root walk | | resolution | | +--------------------+--------------------------------+ | 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 | +--------------------+--------------------------------+ Table 3 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) Fu, et al. Expires 27 February 2027 [Page 17] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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) Fu, et al. Expires 27 February 2027 [Page 18] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 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 Email: yongquanf@nudt.edu.cn Zhiquan Lai PDL, College of Computer Science and Technology, NUDT Email: zqlai@nudt.edu.cn Dongsheng Li PDL, College of Computer Science and Technology, NUDT Fu, et al. Expires 27 February 2027 [Page 19] Internet-Draft Automated Pivoting in Big Memory Systems August 2026 Email: dsli@nudt.edu.cn Fu, et al. Expires 27 February 2027 [Page 20]