Potential diversity

As domains are generally connected to several neighbors, several paths may be available to reach a single destination domain/network. First because each of the external connections may propose a path to reach the destination. Second because each neighbor may also receive several paths which could potentially be propagated. Figure 1.4 illustrates the potential path diversity a source domain may

!"#$%& '$()*+, '$()*+,

'$()*+,

'$()*+, -&*,+)(,+")

!"#$%&'()

Figure 1.4: Inter-domain potential paths

benefit in order to reach a destination domain.

As underlined in Section 1.1.2, domains communicate with their neighbors us- ing the Border Gateway Protocol (BGP) [46]. BGP fulfills the role of globally an- nouncing prefix reachability between individual IP networks belonging to different administrative domains (i.e., ASes).

Mühlbauer et al. [47] underline that an important potential and un-exploited path diversity exists in the current Internet. Nevertheless the current inter-domain rout- ing protocol BGP truncates all this potential by selecting only one route, potentially using an arbitrary tie break.

CHAPTER 1. 53

It is also interesting to notice that the BGP decision process steps hardly take into account the quality of the path. One may argue that the minimization of the AS path may lead to both minimize the propagation delay and the potential bottlenecks and points of failure. Nevertheless, as this step is in second position, it is not a predominant selection. Moreover, minimizing the AS path length is not equivalent to minimizing the length of the path. Indeed some domains may add a few number of routers whereas other domains may add an important number of routers in the path, leading to extra communication delays and potential bottlenecks. Last there are no obvious relation between AS path length and the path characteristics as other metrics may greatly impact the characteristic of a path (e.g., the bandwidth).

1.2

Motivations for Inter-Domain Multipath

The use of internet is very diverse. All the flows that cross it have not the same properties and do not need the same path characteristics. For instance on one hand Voice Over IP sends very few amount of data but requires very small propa- gation delays and very low jitter. On the other hand downloading a file may require the sending of an important quantity of data while not requiring a small propaga- tion delay or jitter, compared to other uses. A lot of other application flows (e.g., mail, chat, streaming, P2P... [12]) require different profiles which are commonly expressed with criteria like delay, jitter, bandwidth and packet loss rate [13].

Even if there exists a lot of different application needs, a global over-dimensioning of network service provider capacities may fit all these needs. Nevertheless over- capacity is not generally adopted. Consequently a lot of congestion points exist in the internet, and half of them are located in inter-domain exchange points [11]. Bypassing these congestion points would probably make the path length increase, which increases the propagation delay, or go through links which price are higher. Path characteristics differ a lot and a path which is good for one application could be bad for another.

Beside the technical characteristics of flows and their adequacy with the paths, some specific flows are critical, in the sense that they should not drop for a long time, even if the underlying path fails. Such flows require at least a second usable path which is to be used if the first one fails (i.e., a disjoint path). Paths are cur- rently not well protected by the convergence of BGP. For instance, path exploration can make the Internet converge in several minutes [48, 49], which is a too high convergence delay, even for the uses that do not specifically require high reliability (e.g., web browsing).

From a security point of view, some BGP weaknesses give the opportunity to malicious ASes to hijack prefixes (i.e., falsely originate prefixes) [50, 51]. It can either be used to impact payments of providers or to attract and analyse the traffic. Inter-domain multipath may also be used to detect prefix hijacking [52].

These needs could potentially be filled with the adoption of the "Routing as a service" paradigm proposed by Lakshminarayanan et al. [53]. They propose to exploit some alternate paths via deflecting the traffic through Internet checkpoints. The path which is to be followed by a specific stream becomes a resource that

is to be sold by NSPs to clients. This type of paradigm allows for both the use of paths adapted to the traffic characteristics and the unblocking of new income revenue for NSPs. Nevertheless this paradigm requires the availability and usability of different routes whereas, in the current Internet, only one path is selected to reach a destination.

From an NSP point of view, inter-domain traffic engineering (TE) is an incentive to develop inter-domain multipath. The simultaneous use of several paths is an opportunity to balance the load between end-to-end paths and to avoid bottlenecks, could they be close or far away. A lot of work have been done to allow intra- domain TE [54, 33, 55]. Nevertheless, from an inter-domain perspective, traffic engineering is limited as it only focuses on external links [56, 57] (e.g., for load balancing or to direct the traffic to a different neighbor). A perspective to unlock the traffic engineering capabilities is to centralize the routing plane, outside the routers, in order to get a global knowledge about the network. Some works [58, 59, 60, 61] have been proposed to separate the control plane from the data plane and expose the perspective given by such a separation. Nevertheless, they mostly focus on intra-domain traffic engineering.

1.3

Solution Requirements

In this section we define the required design criteria in order to produce an inter-domain multipath proposal which is realistically applicable in today’s Internet, These design criteria are based on valuable insights into successful system design from [14] and [15].