Discovery performance evaluation

Once the discovery algorithm’s subroutine has finished, the discovery simulation script computes performance figures based on the resulting global discovery state. By default, it computes and outputs the following values:

• Global interface coverage: |P I_{|T I}∪S_|| = |P I|+|S_{|T I}|−|_|P I∩S|

• Global link coverage: |_|P L_{T L|}|

such asS is the set of sources used for the discovery process, P I and P Lare respectively the

sets of probed interfaces and probed links throughout the discovery,T I andT Lare respectively

the sets of all interfaces and links of the topology.

Note that in order to obtain a correct computation of interface coverage, the removal of the

number of ”discovered” sources, i.e. |P I ∩S|, is required before adding the known a priori

In addition to these, detailed analysis provides the following values demonstrated as an example in Table 4.3:

• Number of probed interfaces per type and per level: |P I∩T I_t,l|

• Number of interface probes per type and per level: P_{i∈P I}probesi

• Interface coverage per type and per level: |P It,l_{|T It,l}∪S_|| = |P It,l|+|St,l_{|T It,l}|−|P It,l_| ∩St,l|

such as T It,l is the set of interfaces from levell ∈ [0,4] and of typet ∈[0,1], and probesi the

number of probes received by the interface iduring probing.

level dense transit outer ISPs customers

coverage 0.909 0.774 0.315 0.382 0.358

probed 19 120 421 578 4991

probes 1309 2912 1816 1099 4991

Table 4.3: Per-level discovery distribution of router topology

Finally, the number of inter-level and intra-levellinksdiscovered is provided by another connectivity

matrix as shown by the example from Table 4.4. Its layout is similar to the inter-level table previously described in Section 4.2.1.

level dense transit outer ISPs customers total (I,PP,PC)

dense 0,18,0 0,15.5,33 0,0,124 0,0,151 0,0,1642 0,33.5,1950 transit 0,15.5,0 0,8,50 0,0.5,202 0,0,188 0,0,1099 0,24,1539 outer 0,0,0 0,0.5,0 0,1,93 0,0,165 0,0,1283 0,1.5,1541 ISPs 0,0,0 0,0,0 0,0,0 0,0,74 0,0,967 0,0,1041 customers 0,0,0 0,0,0 0,0,0 0,0,0 0,0,0 0,0,0 total (I,PP,PC) 0,33.5,0 0,24,83 0,1.5,419 0,0,578 0,0,4991 0,59,6071

Table 4.4: Discovered internal and inter-level link connectivity matrix of the router topology Note that currently, all these figures give an evaluation of the interface/router-level topology discovery. An evaluation of the AS-level discovery could however be implemented and is the

C-BGP notes and modification

The first point is that C-BGP, performing a traceroute from a source router to a destination router only requires the announcement of a prefix originating at the destination router, propagating its route through the whole network. Although in reality a route back to the source has to be available for the return packets, in C-BGP, only the forward path needs to be known as this is the information returned by traceroute.

A second point is that C-BGP routers are fitted with data structures,i.e. a local and adjacent RIBs, which are used to respectively store the best BGP routes and the routes exchanged with neighbor routers. Several route announcements lead to the accumulation of information in these structures and is the main reason for the C-BGP simulator’s memory consumption, especially when dealing with large topologies. It was observed that although these data structures are needed to compute the routers’ routing tables required by traceroute, there is no further need to

maintain them in memory once the forward path is returned. An additionalclear-ribscommand

was therefore implemented in the C-BGP simulator and is called after each completed prefix propagation. The source code of this modification can be found in Appendix B.

Test design and results

This chapter elaborates on the objectives initially set out by the thesis and identifies ways to reach them using the now-available discovery simulation framework. A test plan is then accordingly laid out as well as the resulting choice of topologies on which to work. Finally, the test results are presented along with their interpretation.

5.1

Test design

This part of the thesis has three main objectives: validate the previously described implementation, analyse both algorithms’ (classic traceroute and Doubletree) performance in comparison with previously obtained results and optimise their performance benefiting from the points described in Section 4.1.1.

Although progressive testing has been carried throughout the development process, it is not sufficient. Validation of the implementation must be performed in order to ensure correct results. A formal approach being rather complicated to apply, the pragmatic approach of providing debugging features is provided to this regard and provides human-readable output of the many steps performed by a simulation. A detailed verification is thus performed on an

example covering the most possible1 _{input cases yet small enough to be hand-verifiable.}

Once the validity of the process has been established, it could be interesting to see the results it yields using a large-scale topology, which hypothetically could be more ”representative” of the Internet. These results could be used to provide a more detailed analysis of the discovery process than those available in the real-world, and thus enlighten previous work results or performance claims.

The final objective is to identify the means to optimise Internet topology discovery through the analysis of simulated results. These means including the development of heuristics, covered by Section 5.1.1, such as the placement of monitors and destinations according to their location in the network. A statistical approach to the problem is then described in Section 5.1.2 in an attempt to apply optimal experimental planning methods to it. A test plan is ultimately laid out according to the required features to be tested.