Achieving Throughput via Fine-Grained Path Planning in Small World DTNs

TL;DR

This paper presents REAPER, a distributed routing framework for small world DTNs that uses fine-grained contact statistics to achieve high throughput and energy efficiency by effective path planning with low overhead.

Contribution

It introduces an empirical contact model and a novel, fully distributed routing protocol, REAPER, that leverages temporal knowledge for improved performance in small world DTNs.

Findings

REAPER achieves high throughput and energy efficiency.

It outperforms existing protocols in various traffic conditions.

REAPER maintains low control overhead due to small world structure.

Abstract

We explore the benefits of using fine-grained statistics in small world DTNs to achieve high throughput without the aid of external infrastructure. We first design an empirical node-pair inter-contacts model that predicts meetings within a time frame of suitable length, typically of the order of days, with a probability above some threshold, and can be readily computed with low overhead. This temporal knowledge enables effective time-dependent path planning that can be respond to even per-packet deadline variabilities. We describe one such routing framework, REAPER (for Reliable, Efficient and Predictive Routing), that is fully distributed and self-stabilizing. Its key objective is to provide probabilistic bounds on path length (cost) and delay in a temporally fine-grained way, while exploiting the small world structure to entail only polylogarithmic storage and control overhead. A simulation-based evaluation confirms that REAPER achieves high throughput and energy efficiency across the spectrum of ultra-light to heavy network traffic, and substantially outperforms state-of-the-art single copy protocols as well as sociability-based protocols that rely on essentially coarse-grained metrics.

Figures

Full text

1 Evaluation

In this section, we evaluate the performance of REAPER in comparison with a variety of replication-based, link-metric based single-copy and social based DTN protocols. The case of replication-based protocols is relatively straightforward: as the network is driven towards near-capacity, the performance of many multiple-copy protocols[Epidemic00, SprayWait05, MaxProp06] breaks down well before reaching the regime of ultra-heavy load. We do not therefore evaluate these protocols more comprehensively here. With respect to the single-copy protocols, we eschew consideration of those popular link-metric based single-copy protocols that use some notion of global knowledge of contacts or infrastructure such as well-known landmarks [Per09, OptimalProbForwarding09]. Instead, we focus on the two canonical representatives of the remaining protocols: MEED-DVR, an optimization algorithm based on the “Minimum Estimated Expected Delay (MEED)” [MeedDvr07] metric; and “Probabilistic Routing Protocol using a History of Encounters and Transitivity (PROPHET)” [Prophet04], which uses incremental forwarding based on node meeting probabilities that are aged according to three parameters (the designers’ parameter choices have been honored in this evaluation). With respect to sociability metric-based protocols, we focus on the canonical state-of-the-art representative, BUBBLE Rap[Bubble11], which uses node communities and moving average degrees to route to the destination and is known to perform better than other centrality-based protocols (e.g., Simbet[Simbet]). Our comparative evaluations with MEED, PROPHET, and BUBBLE Rap are based on ns-2.34 simulations over synthetic mobility traces generated for two mobility scenarios. We instantiate four versions of REAPER, with packet deadlines of $96$, $72$, $48$ and $24$ hours, to evaluate the sensitivity to deadline selection in the simulations.

1.1 Simulation Details and Parameters

For reasons of space, we discuss only one mobility scenario which is based on probabilistic human mobility model (the other which is based on a more deterministic vehicle mobility model is relegated to a technical report [archive]). This scenario is based on the Time Variant Community Model (TVCM) [TVCM09]. We instantiate parameters for the TVC model to faithfully approximate mobility patterns on a university campus, to obtain a synthetic University Campus Trace for $25$ nodes and one fixed base station. We choose $18$ communities in a simulation area of $1000\times 1000$ meters that are classified into $10$ home communities, $4$ work communities, $3$ food communities and $2$ recreation communities (with $1$ recreation community acting as a food community as well). Every community is $100\times 100$ meters in dimension. There are $6$ equal time periods that occur in a day, from $7:00$ AM till $7:00$ AM the next day. The campus map and node transition probabilities are detailed in[archive]. Our simulation spans $7$ virtual days. Between the second and third days, the network generates data packets at various rates between $1$ bps to $9.6$ Kb/s for $86300$ seconds each. Each link has the ns-2 default link capacity of $1$ Mbps, even though the network is found to be connected to the base station only about $1\%$ of the time, and the actual achievable capacity is estimated to be lower than $10$ Kbps. Thus, the traffic rates range from ultra-low to ultra-high for this network.

1.2 Comparison with Single-Copy Protocols

1.2.1 Average Path Length (Cost)

All four versions of REAPER have substantially lower average path lengths (Fig. 1(a)). As expected, PROPHET has the highest number of transmissions (about $22\times$ that of REAPER at the heaviest load), since the other two protocols globally optimize their respective metrics. Further, REAPER exploits the small world to yield logarithmic path lengths and is about $4.5\times$ better than MEED-DVR.

1.2.2 Throughput and Delivery Probability

As observed in Fig. 1(b), at ultra-high load (i.e. 9.6 Kb/s) REAPER_96, REAPER_72, REAPER_48 and REAPER_24 respectively have 135%, 128%, 128%, 114% higher throughput than MEED-DVR and 200%, 175%, 175%, 150% higher throughput than PROPHET. While all the protocols have the same throughput for low loads (i.e., from $1$ bps to till about $0.1$ Kb/s offered load), the throughput subsequently drops due to increased depletion of network capacity. A consequence of this is the loss in their delivery probabilities (Fig. 1(c)). Notably, PROPHET and MEED-DVR lose capacity much quicker than all four versions of REAPER. REAPER uses capacity more efficiently. In general, the four flavors of REAPER perform increasingly better with increasing deadlines. This is because shorter deadlines entail the use of longer paths to the destination and also result in higher packet drops due to possibly early expiration of deadlines.

1.2.3 Average Delivery Delay

Fig. 1(d) plots the average delivery delays in the low traffic regime (up to 0.096 Kb/s) where all protocols have a 100% delivery ratio111We limit comparison to the low-traffic regime to get a fair comparison: the average delivery delay metric gets biased once packet losses start occurring.. We see that REAPER_96 and REAPER_72 perform comparably with MEED-DVR, while REAPER_48 and REAPER_24 have lesser average delays in the expected order of their deadlines. The good delay performance in REAPER despite deadlines is once again attributable to the use of time-dependent optimal paths.

1.3 Comparison with Sociability-Based Routing

We now evaluate REAPER in comparison with the social routing benchmark Distributed BUBBLE Rap (DiBUBB)[Bubble11], a protocol that classifies nodes into distinct communities and uses the average node degree over the past $6$ hours as a measure of individual centralities. Routing proceeds in an incremental fashion till the destination class is reached, and similarly to the destination node by forwarding to higher-degree members in the same class or to the base station itself. Because community detection is computationally expensive and incurs considerable overhead, we use an optimized version of the proposed algorithm SIMPLE[Bubble11] for our evaluation. Like DiBUBB, REAPER exploits the small-world to achieve high throughput using logarithmic average path costs, albeit with traditional link metrics. In fact, REAPER uses slightly higher average path costs to the destination ($1.86$ vs $1.3$ with packet deadlines of $24$ hours, and $1.59$ vs $1.24$ with deadlines of $48$ hours in the regime of ultra-heavy traffic). This slightly increased costs, however, results in noticeable benefits: REAPER achieves respectively about 30% and 10% higher throughput in the two cases. This result hints strongly at the benefits of fine-grained path planning: REAPER can change the planned path on the fly based on the remaining time for a packet, and maintain throughput by potentially forwarding packets that are near expiration over slightly longer routes. Social-based forwarding is oblivious to this dynamic change in urgency of a packet based on its remaining time, and uses the exact same paths for all packets regardless of their priorities (deadlines). In terms of overhead, much greater benefits are observed. Since DiBUBB always needs to transfer $\mathcal{O}(n\log{}n)$ community and familiarity sets per contact, REAPER has an $\mathcal{O}(n)$ to $\mathcal{O}(n\log{}n)$ times lower overhead than the former. The improvements observed in throughput and average path costs or protocol overhead at even ultra-high network loads over the compared schemes gives us confidence that REAPER would perform competitively with other distributed algorithms.