# Achieving Sender Anonymity in Tor against the Global Passive Adversary
## 8 Experiments  
In this section, we provide experimental validation of Ring2 Tor. Specifically, our aim is to show that the network performance is not compromised by the adoption of our protocol. Our analysis was performed through the network simulator NS3 [39]. We simulated an overlay network with rings of size \(k=50\) and with no fault tolerance (clearly, fault tolerance has no impact on the communication-phase performance, only on the set-up phase). Tor routers were set as separated network nodes. Regarding the links between the Tor routers, we set a delay such that the total time to perform a download of 50 KB was about 1.5 s, which represents the actual time (as of October 2021) taken to download a file of this size in the real-life Tor network [40]. The resulting delay is then 150 ms. The above considerable delays reflect the fact that, according to the current Tor-router-selection algorithm, no two routers in the same circuit belong to the same class B network (/16 subnet) or the same family [41]. Regarding the link between client nodes, we set a delay of 10 ms, capturing that the purpose of the node-selection algorithm--to form rings is the opposite of that of Tor router selection--to obtain homogeneity among nodes in a ring (and thus an effective anonymity set). Therefore, nodes belonging to the same ring are geographically close to each other. We used an http traffic generation model that simulates web browsing traffic according to the specification suggested by 3 GPP2 [42]. We focus our analysis on three metrics: _(communication) latency_, _(traffic) overhead_ and _throughput_. The communication latency is defined by the application layer, as it measures the time between the instant at which the sender sends an http request and the instant at which it receives the complete response. Observe that, to be fair, we did not consider as initial time the instant in which the sender received an available token, but the instant in which the http client generated the request. As traffic overhead, we took the average ratio between the number of empty tokens circulating in the ring and the total number of circulating tokens. Finally, the throughput was defined as per usual--that is, the average exploited data rate per node. The results are reported in Figures 9-13. Figure 9: Latency vs. percentage of senders in Ring2 Tor. Figure 11: Overhead vs. Number of tokens in Ring2 Tor. Figure 12: Throughput vs. percentage of senders in Ring2 Tor. Figure 13: Throughput vs. numbers of tokens in Ring2 Tor. The plot in Figure 9 shows that our solution introduces an acceptable latency for different sender percentages. Specifically, when the percentage of senders is less than 50, the latency ranges from 3.8 s to nearly 7 s, which are values not too far from those found for Tor [43], considering the results obtained for low-volume http traffic. For high volumes, the difference between Ring2 Tor and Tor increases, because Tor's performance improves. However, the absolute values of latency experimented for Ring2 Tor for realistic http traffic can be considered acceptable. As expected, the latency increases as the sender percentage does, since, in the rings, many filled (reserved and used) tokens move. On the other hand, the latency decreases as the number of tokens moving in the ring increases. The plots in Figures 10 and 11 can be used to set the number of tokens that a generator needs to maintain in a ring. Indeed, by fixing the maximum percentage of overhead tolerable and the percentage of senders in the rings, we can find the minimum number of tokens. For example, if the maximum overhead is set to 27%, even with a high percentage of senders equal to 70%, we obtain a latency of 6.5 seconds by setting 120 tokens in the ring. As expected, the overhead decreases as the percentage of senders increases, because there will be more filled tokens circulating into the ring.