In order to evaluate the benefits provided by MEDINA in a realistic scenario, we
simulate its deployment on the Internet2 network, considering its publicly available PoP-level topology and static link weights. In our experiment in each PoP there is a MEDINAnode and the amount of storage in the node is proportional to the population
5.3 Evaluation
Lake City to 84 TB for New York). We expect that in a real deployment populous cities would be served by multiple nodes, but we preferred to keep the simulation simpler while still having the algorithms operate in an equivalent situation.
Reproducing the evaluation performed in [81], we apply a gravity model to a baseline traffic volume Tb of 8 million IP flows per 5-minute interval to obtain
the traffic volume TVi,e for each IE-pair (B is the set of edge nodes and Pj is the
population served by the edge node j):
TVi,e= Tb∗ Pi∗ Pe ∑j,k∈BPj∗ Pk
Specifically, we assume that the total traffic between 2 PoPs is proportional to the product of their population sizes. We assume that the flow size (number of bytes per minute transferred) is Pareto-distributed with shape 0.606 and scale 92 [88] and that a single flow cannot transfer over 750 MB per minute (corresponding to a 100 Mbps rate).
The traffic assignment function implements a simple heuristic to distribute the load among the nodes considering for each one of them: (i) the amount of available storage, (ii) the number of IE-pairs the node is associated to, (iii) the expected traffic through each associated IE-pair (based on the forwarded traffic). Specifically, the storage available to a node is divided among the associated IE-pairs proportionally to the expected traffic in each IE-pair. The result of this allocation is a set of constraints that are shared with the other nodes involved in the same IE-pair. Finally, the hash space for the IE-pair is divided among the nodes in the path proportionally to the constraints advertised by them. Moreover, each MEDINAnode constantly monitors
the used storage space and, whenever it concludes that the available space is reducing excessively fast, it recomputes the contraints (with new traffic estimates) and sends a message to the other MEDINAnodes associated to the same IE-pairs to recompute a
more fair assignment. As a result, if traffic through the various IE-pairs matches the expectation (within a predefined threshold), the algorithm converges to a steady state that does not require further communication among the nodes. Exceptional changes in the traffic characteristics trigger the computation of new constraints to converge to a different distribution plan.
Figure 5.4 and Figure 5.5 present the results of this simulation. Figure 5.4 shows that, even with our simple heuristic, most nodes’ used storage increases at
0 20 40 60 80 100 29 0 5 10 15 20 25 Used space (%) Hours HOUS LOSA SEAT WASH NEWY CHIC SALT KANS ATLA
Fig. 5.4 Per node used storage.
a similar pace over time. However, as shown in Figure 5.5, some nodes forward less traffic than others, hence nodes cannot all capture the same fraction of their traffic. Specifically, as the storage space becomes a critical resource, these nodes take a larger share of the traffic they forward compared to nodes traversed by a larger number of flows, thus lessening the capture burden on the latter. Even with this simple heuristic, it takes around 29 hours to reach a point where all the nodes in a path are completely full and successive flows cannot be captured. As a result, in this scenario the captured traffic can be available to the NOC for offline processing (e.g., network forensics) for more than a day. Presumably, with that amount of time, the raw data of interest can be retrieved by the NOC during periods of limited network activity.
Figure 5.5 shows the amount of traffic that each node forwards and the fraction they capture. On average a node captures only around 25% of the traffic it forwards, thus MEDINA allows to reduce by a factor of 4 the amount of resources needed for processing and storing the traffic in each node compared to the case of capture happening independently in selected nodes. Consequently, MEDINA also allows reducing the amount of additional traffic in the network if all the captured packets are to be sent to a NOC. Moreover, the NOC does not have to identify and remove duplicated packets. It is worth noting that in a real scenario the gain is even greater
5.4 Related Work 0 20 40 60 80 100 120 140
HOUS LOSA SEAT WASH NEWY CHIC SALT KANS ATLA
Flows (TB) Nodes Forwarded Captured 18.6% 45.8% 29.5% 7.3% 66.3% 33.4% 8.2% 8.6% 5.2%
Fig. 5.5 Per node captured and forwarded traffic.
than in our experiment where a PoP-level topology is considered: core routers could also support MEDINAand share the traffic capture burden.
A more complex heuristic could provide a more equal load distribution among the nodes, but it also would come at the cost of a larger amount of information exchanged among the nodes and a longer computation time to obtain the assignment.
5.4
Related Work
A number of techniques have been proposed to distribute the traffic processing load among network devices in a coordinated fashion, especially for monitoring tasks. The work presented in [89] proposes to distribute monitors in the network that determine the monitoring target by periodically sharing information on the monitored flows. This information is shared as an aggregate by means of counting bloom filters. This solution aims at reducing duplicate monitoring, however, since frequently the first monitor in the path is responsible for the flow, the load is not fairly distributed among all the monitors. Moreover, since each monitor must be constantly aware of the flows others are responsible for, bloom filters must be exchanged frequently,