RPDP: Residual Performance Data Placement

• RPDP is a method for performance-aware data placement in P2P systems that computes a composite metric from throughput, latency, and capacity.
• It modifies the Kademlia DHT by decoupling storage decisions from XOR-key proximity while preserving decentralized lookup and O(log n) complexity.
• Experimental results show that RPDP reduces mean latency by ~5% and tail latency variance by ~15%, improving load distribution in heterogeneous networks.

Residual Performance-based Data Placement (RPDP) defines a method for data placement within peer-to-peer (P2P) storage systems that selects storage targets based on their current, dynamically measured residual performance rather than proximity in the DHT keyspace. RPDP addresses the heterogeneity of node capabilities and workloads by introducing a real-time node assessment and a modified Kademlia distributed hash table (DHT), maintaining decentralized storage and retrieval, and offering reduced mean and tail latency compared to traditional DHT-based placement (Pakana et al., 2023).

1. Background and Motivation

Conventional P2P storage systems, typified by IPFS and Swarm, utilize Kademlia’s XOR-distance metric to assign data to nodes. While this delivers $\mathcal{O}(\log n)$ storage and retrieval complexity and eliminates reliance on central authority, it disregards real-world heterogeneity among nodes—specifically throughput, storage capacity, and latency. The XOR-based approach can concentrate load on under-resourced nodes, resulting in imbalanced utilization and increased tail latency.

Alternative schemes incorporating criteria-based selection, such as those in systems with central metadata or reinforcement learning placement, address heterogeneity but sacrifice decentralization and scalability by introducing global mappings or coordination layers. RPDP is designed to dynamically balance performance-aware placement with strict decentralization and lightweight metadata, aiming to achieve efficient latency and load distribution without centralized or global knowledge (Pakana et al., 2023).

2. Residual Performance Quantification

RPDP introduces a composite residual performance metric for each node, combining the following temporal measures within a fixed window $i$:

• Average throughput $T_s^i$ (MB/s)
• Average latency $L_s^i$ (s)
• Available storage capacity $C_s^i$ (MB)

These are computed as: $$T_s^i = \frac{1}{|t(i,j)|} \sum_{j} t(i,j), \qquad L_s^i = \frac{1}{|l(i,j)|} \sum_{j} l(i,j)$$ where $t(i,j)$ and $l(i,j)$ are throughput and latency samples, respectively, over window $i$.

Residual throughput and latency are then normalized: $$\acute{T}_s^i = 1 - \frac{T_s^i - T_{\min}}{T_{\max} - T_{\min}}, \qquad \acute{L}_s^i = 1 - \frac{L_s^i - L_{\min}}{L_{\max} - L_{\min}}$$ A node at global maximum throughput achieves $\acute{T}=0$, indicating no spare capacity.

A single residual performance score is produced: $$P_s^i = \frac{1}{2} \left( \omega_1 \acute{T}_s^i + \omega_2 \acute{L}_s^i \right), \quad (\omega_1 + \omega_2 = 1, \ \omega_1, \omega_2 \geq 0)$$ Each node periodically reports $(P_s^i, C_s^i)$ to a local cluster monitor, which aggregates status for placement decisions.

3. Data Placement and Lookup Mechanism

RPDP amends the Kademlia DHT to support performance-based selection while maintaining decentralized lookup. Each chunk is associated with two identifiers:

• Primary ID $(d^p)$
• Secondary ID $(d^s)$

Data placement proceeds as follows:

1. Selection: The cluster monitor sorts nodes with sufficient capacity $(C_s \ge M)$ by descending $P_s$ and selects the best target(s).
2. Storage: On the selected 'actual' node $s_c$ (highest $P_s$), store $$\langle d^p=H(s_c),\,d^s=H(d),\,\text{value}=data\rangle$$.
3. Pointer mapping: On the 'virtual' XOR-closest node $s_i$ (per Kademlia), store pointer $$\langle d^p=H(d),\,d^s=H(s_c),\,\text{value}=NULL\rangle$$.

Retrieval performs a two-phase lookup:

• Step 1: Query $H(d)$. If result is real data, retrieve; if pointer, extract $d^s=H(s_c)$ and re-query for actual data.

This approach decouples placement from strict key proximity but ensures all lookups are still possible with $H(d)$ alone, without introducing central directories.

4. Algorithmic Workflow

Periodic node assessment, selection, and storage proceed as:

• Monitoring: Every $T$ seconds, nodes calculate $T_s^i$, $L_s^i$, normalize using global $T_{\min}, T_{\max}, L_{\min}, L_{\max}$ (held by cluster monitor), compute $P_s^i$, and report to monitor.
• Target selection: Monitor maintains table of $(s,P_s,C_s)$ for all nodes. On storage request, it filters for sufficient capacity, sorts descending by $P_s$, and returns top candidates.
• Data storage: Clients select monitor, obtain target node(s) for replicas, and perform direct write to $s_c$ (‘actual’), with pointer mapping at $s_i$ (‘virtual’).
• Retrieval: Begin with standard DHT lookup on primary ID; if pointer, proceed to secondary lookup using secondary ID.

Code excerpts illustrating these mechanisms align with the protocol and complexity outlined in the original source (Pakana et al., 2023).

5. Performance and Complexity Analysis

Baseline Kademlia supports one-step storage and retrieval in $\mathcal{O}(\log n)$ hops. RPDP introduces:

• Storage: Two DHT store operations and direct client→node write, a constant overhead addition.
• Retrieval: At most two sequential DHT lookups—primary, possibly secondary—so overall remains $\mathcal{O}(\log n)$.

Periodic status-update traffic is proportional to cluster size but operates at coarse granularity. This approach preserves Kademlia's essential logarithmic end-to-end complexity.

6. Experimental Evaluation

Experiments conducted within PeerSim (160-bit ID space; up to 100s of heterogeneous nodes; no churn) demonstrate:

• Workload: Synthetic; 1 MB chunks at 1 op/s; latency and throughput heterogeneity engineered.
• Latency Results (100 nodes, 3h):
  • Baseline Kademlia mean latency: 138.33 ms
  • RPDP mean latency: 131.60 ms (4.87% reduction)
• Variance: RPDP yields ~15% lower standard deviation in per-node latency.
• Scalability: As node count increases (20–200, fixed workload), both schemes’ mean latency decreases, but RPDP’s remains consistently ~5% lower and with flatter variance trajectory.

The results validate RPDP’s efficacy for reducing both overall and tail latency, and for distributing load more equitably among heterogeneous nodes (Pakana et al., 2023).

7. Applicability, Limitations, and Trade-offs

Advantages:

• Dynamically balances load based on real-time measurements, mitigating straggler effects.
• Maintains decentralization; both lookup and placement do not require global data mapping.
• Retains Kademlia's $\mathcal{O}(\log n)$ complexity.

Costs and Constraints:

• Cluster-local status collection introduces additional messaging, bounded by cluster size and time window.
• Occasional two-phase lookup incurs a small constant latency overhead.
• Assumes cluster topology remains relatively stable; frequent reconfiguration is not explicitly addressed.

Best-use contexts include:

• Heterogeneous networks featuring a wide range of peer capabilities.
• Applications particularly sensitive to tail latency.
• Medium-scale P2P environments with variable node performance.

The protocol does not address high churn or very large-scale environments requiring frequent cluster rebalancing. A plausible implication is that further extensions may be necessary for highly dynamic or extremely large deployments (Pakana et al., 2023).