Improving Congestion Control in IP-based Mobile Networks

Get Complete Project Material File(s) Now! »

Packet Types and Communication Model

There are two types of packets exchanged in CCN/NDN network: 1) Interest that carries a request for a piece of information. 2) Data that carries a specific piece of information. Figure 2.1 shows their respective formats. The most important field is the name that identifies the information requested/contained by the Interest/Data packet.
CCN/NDN adopts a pull-based communication model: user who wants a data must initiate its request by sending an interest to the network. Interest is then forwarded in a name-based fashion up to the data source, which will respond with the requested data. Optionally, intermediate routers can serve the request (i,e, the interest) directly by their cache if they have data matching the interest. In CCN/NDN, we have the notion of Con-sumer and Producer: consumer is the node who sends interests to request for data and producer is the node who generates and publishes data under a specific name prefix (e.g, /www/youtube).

Enforcing Security in Producer Mobility

Security of producer mobility have only been considered to a limited extent by previous work in the ICN literature. Therefore, we begin by briefly reviewing the proposals to secure producer mobility from the ICN literature and presenting their pros and cons. After that, we survey the existing solutions in the IP world for prefix attestation1, which is an important topic to defend against in producer mobility.
Among the mobility management protocols proposed for ICN [46, 47, 48, 49, 50, 51, 52, 13], Kite [13] is the only one that takes security into account in its design and protects the network against prefix hijacking. Specifically, the authors propose to sign traced interests (which corresponds to our Interest Updates), through the producer’s private key in order to handle mobility in a secure fashion. Every router receiving a traced interest verifies the signature before updating its network state. The producer trust context (i.e. the public key to trust for validating content signature) attests the producer’s entitlement to generate traced interests. However, this approach has some drawbacks: routers must be aware of the producers’ trust context, signature verification and certificate chain traversal increases latency during handover, revoking of a prefix to a producer faces the same problem of certificate revocation, where traditional approaches based on Certification Revocations List (CRL) are quite slow and expensive [53].
In the IP world, few works have proposed prefix attestation mechanisms to prevent prefix hijacking in mobility protocols for IP networks. Cellular IP [54] and TeleMIP [55] both adopt the following approach: the first time a mobile host connects to the network, it is assigned an address and a host id by the gateway. Based on that, the mobile host generates a session key and uses the session key to prove its ownership of its assigned IP address. The session key is calculated from a network key, the IP address and the host id. During handover, the host uses the session key to authenticate itself and prove the ownership of the IP address to the new access point. The main drawback of such an approach is the use of a single network key. In the case that the key is stolen, e.g., when a router is compromised, a new network key and a refresh of all session keys must be performed. Prefix attestation has also been proposed for preventing IP prefix hijacking in inter-domain [56, 57, 58, 59, 60] and intra-domain [61, 62] IP routing. A widely used approach for achieving address attestation exploits digital signatures and certificates. A trusted address holders issues a singed certificate that attests the router’s right of announcing a specific address prefix in the network. Both sBGP [58] and soBGP [59] use a public key infrastructure to establish trust between address holder and BGP routers. Similarly, authors of [61] propose to use signed certificates to attest the list of network prefixes an OSPF router can announce to different OSPF areas (i.e., through Router Links LSA messages). While the same approach can be applied to the trace-based mobility protocols, it would suffer the same issues we discussed for Kite.
Finally, two different approaches for address attestation are proposed in psBGP [60] and s-RIP [62]. psBGP proposes a decentralized mechanism: each AS creates a prefix assertion list (PAL), that contains address ownership assertions of the local AS-es and its peers. An origin claim is validated by checking the consistency between the PALs of peers around the advertising origin. S-RIP [62] achieves prefix attestation pre-distributing the mapping between router ids and prefixes to announce in every router of the network. Both mechanisms work well when the mapping between router and prefixes is almost stable. It is worth noting that, instead, in trace-based mobility protocols for ICN such mapping may vary more frequently.

Improving Congestion Control in Mobile ICN Network

Designing congestion control suited for the mobile environment is a shared concern for IP-based network as well for ICN networks. In this section, we summarize the techniques that have been proposed to improve congestion control in the mobile environment. While a large body of work, beyond ICN, has highlighted the issues of traditional TCP-based congestion control over wireless and mobile network, very few works (in the ICN literature) have considered the same issues in the context of mobile ICN.
Therefore, we begin by discussing the approaches for improving TCP-based congestion control in wireless IP networks as they can potentially be extended also to the ICN archi-tectures. Then we discuss the few related work existing in the ICN literature to optimize congestion control in a mobile environment.

Improving Congestion Control in IP-based Mobile Networks

Extensive research results have improved TCP’s performance in mobile environments. Reusing the classifications by Balakrishnan et al.[63], we can divide existing proposals for IP net-works into 3 categories: link-layer, split-connection, and end-to-end solutions.
Split-Connection solutions split the TCP connection into 2 separate connections at the base station: one between the mobile device and the base station, and the other between the base station and the fixed host. Here it is assumed that only one end is a mobile host, and the other end (e.g a server) is in the fixed network. In this way, they can operate more efficiently over wireless links with a specialized TCP implementation tuned for wireless links. I-TCP [64], Freeze TCP, Mobile TCP [65] and SplitTCP [66] adopt this approach. Besides the differences, the advantages of such approaches relate to the capability of shielding the wired segment from the lossy wireless part without requiring end-host modification. Moreover, they are also designed to handle wireless loss as well as mobility loss. As a drawback, the buffering at the proxy between the wired and wireless segments can be considerably high and may introduce additional latency. Also, some of these approaches break the end-to-end semantics, complicating rate control at the server side.
Link-layer solutions attempt to hide wireless losses from the TCP sender through link layer techniques such as local retransmissions and forward error correction (FEC). TULIP [67], MAC MIB [68] adopt this common approach and they leverage ACKs or MAC layer observations to identify and recover wireless losses. Such link-layer proposals have the advantage of operating independently from upper layers and not maintaining per-connection state. However, the local retransmission of such approaches may cause out-of-order data delivery, leading to competing and redundant retransmissions at the TCP layer[63]. There-fore, additional mechanisms based on knowledge of TCP messaging is needed to mitigate the issue. Snoop TCP [69] is one such instance integrating TCP-aware mechanisms. It involves link interface sniffing at the base station for any segment to and any ACK coming from the mobile host and performs retransmission as well as duplicate acknowledgment suppression (to avoid unnecessary fast retransmission) at the base station. However, while such an approach can address wireless loss efficiently, it can not deal with mobility/handoff losses.
End-to-End solutions attempt to make TCP handle non-congestion related losses via modifications only at the sender and receiver. Apparently, end-to-end (E2E) approaches have the benefit of easier deployment. The E2E approaches can be further divided in 2 sub-groups based on whether it requires aid from the receiver side. SMART[70] and E2E-ELN[69] take the approach of exploiting aid from the receiver side: [70] proposes to use SACK(selective acknowledgment) to recover from multiple losses in the same TCP conges-tion window. E2E-ELN[69] proposes to use ELN (explicit loss notification) from receiver to sender to notify losses due to link error. Also, there are other approaches seeking to improve TCP performance with only sender side modifications. For example, [71] leverages inter-arrival times and [72] uses a relative one-way trip time (ROTT) for congestion signal-ing. More precisely, the spikes in ROTT measurements are used to differentiate different degrees of congestion. When spikes are observed, losses are considered as due to congestion, otherwise due to wireless transmission. TCP Westwood [73] can handle wireless losses effi-ciently based on bandwidth estimation: while continuously monitoring the rate of returning ACKs, it uses the rate to estimate bandwidth available and to reset the congestion window and slow start threshold upon timeouts. Since bandwidth estimation is almost unchanged before and after wireless losses, TCP Westwood would not reduce the congestion window upon wireless losses. Finally, [74] compares different E2E solutions without aid from re-ceivers and proposes its own ZigZag scheme. The comparison shows that each of these techniques may perform well in some particular conditions and are less effective otherwise. The existing E2E approaches have targeted to address wireless losses efficiently but it is unclear how they can deal with mobility/handoff losses in E2E approaches.

READ  History of Articial Intelligence in Video Games

Improving Congestion Control In Mobile ICN networks

So far, the ICN literature has only marginally considered congestion control implications of mobile and wireless communications. The solution space is far from fully explored as in the case for IP-based networks. Here we briefly summarize each of the proposals from the ICN literature. [75] deals with ad hoc networks and proposes Interest rate regulation and retransmission timer adaptation according to RTT variations in the wireless network. It is more efficient than mechanisms relying on a fixed retransmission timer. However, since it is designed for mobile ad hoc networks, it can be insufficient when applied to infrastructure-based mobile ICN network, which is the context of this thesis. Moreover, the solution does not take advantages of ICN primitives to distinguish the nature of the losses nor does it employ faster in network recovery, which is the primary goal of the mechanisms proposed in chapter 6 (i.e, MLDR and WLDR).
Apart from that, the work in [76] combines timer adaption based on RTT and simple ECN (explicit congestion notification) scheme that marks the incoming Data packets in case of congestion and considers all losses not due to congestion as due to wireless. While the proposal partially makes use of ICN’s in-network processing capability to improve per-formance, it does not deal with mobility losses.
Finally, a solution similar to the category of link-layer solution of IP network but rather for wireless ICN network is discussed by Klaus et al. in [77]. The solution proposes to use a link adaptation layer that detects loss by observing gaps in sequence numbers or timeouts of local acks and recovers losses by local retransmissions. However, such an approach can not deal with mobility losses (i.e., the same drawback as other link-layer solutions).
In summary, the existing proposals in ICN literature have focused on using timer adap-tation, explicit notification or link-layer solutions to improve congestion control in mobile environments. However, approaches taking advantage of ICN’s new features such as in-network processing to facilitating congestion control are still missing, which is the motiva-tion of our proposal in chapter 6.

Proof of Correctness and Stability Analysis

In this section, we investigate MAP-Me guarantees of forwarding update correctness and path stretch stability and we support them by numerical evaluation over known ISP network topologies. For the sake of clarity, the reported proofs are for single-path routing; extension to multipath is straightforward by replacing trees by DAGs.
We consider m consecutive movements of the producer in network positions fP0; P1; :::; Pmg and focus on forwarding state variations determined by MAP-Me at the time instants corresponding to either producer movements or Interest Update processing. At any such instant, as in Fig.4.1, the network is partitioned into a set of islands, whose number varies in »1; m + 1… as a function of producer movements and hence of the number of ongoing update processes. we assume that at the beginning, global routing builds a spanning tree rooted at first location P0. The tree can be a minimum SP or a shortest-path tree depending on the routing. About the completion of the update process after a movement k, we can state that Proposition 1. The MAP-Me update mechanism guarantees finite completion time of up- date k, 8k 2 »1; m… in a bounded number of hops equal to 2 max0 j<k „jPk Pj j 1” ; Proof. Assuming that IU losses are handled by the retransmission mechanism described in Sec.4.2, the hop-by-hop propagation of an IU has two possible outcomes: either (i) the next router has a sequence number, which is inferior to the IU carried sequence number; in this case, IU continues its propagation towards the root of the latest routed tree, decreased by 1 hop; or (ii) the router has higher sequence number, hence the IU is sent back with the encountered higher sequence number towards the originating routed position of the producer. Since the maximum sequence number is bounded by m, the maximum number of hops traversed by IU with sequence number k is finite.
More precisely, the maximum number of hops traversed by IU with sequence number k, IUk is bounded by twice the maximum distance between the originating router Pk and the farthest previous location Pj , j < k minus one, i.e., 2 max0 j<k „jPk Pj j 1” . Indeed, the worst case occurs when IUk encounters a more recent update k 0 > k at the hop before reaching the latest routed previous location, which can also coincide with the farthest one in terms of distance. In such a case, IUk propagates back to Pk carrying k0 sequence number before stopping. After IUk propagation, the router Pk and all its predecessors traversed by IUk to reach the last routed location are connected to the island of highest encountered sequence number, and thus the number of distinct islands is reduced by one unit. By iterating the same process on all IUs, it is straightforward to see that at IUm completion m + 1 islands associated to sequence number 0; 1; :::; m 1 will merge into the island created by IUm. Regarding the properties of an island, we can state that.
Proposition 2. Given a sequence of m consecutive movements of producer position on the routing tree rooted in P0, producer movement m induces a new tree rooted in Pm.
Proof. The initial tree rooted in P0 gives routes to producer from all network nodes. The MAP-Me update mechanism after movement m flips all directed links from Pm to the latest routed position Pj , j < m, so that they point to Pm. In the presence of multiple concurrent updates, the most recent one, i.e., the one with the highest sequence number, also propagates back along the routes of the encountered previous updates. Thus, update completion will merge different rooted trees into the one of highest sequence number, m, rooted in Pm.

Table of contents :

1 Introduction 
1.1 Current Internet Mobility Support
1.2 ICN: a New Paradigm to Address Internet Mobility
1.3 Issues with ICN Mobility Support
1.4 Thesis Contributions
2 Background on ICN 
2.1 Motivation and Principle of ICN
2.2 Packet Types and Communication Model
2.3 Packet Forwarding
2.4 Other Architectural Aspects
3 State of the Art 
3.1 Manage Producer Mobility
3.2 Enforcing Security in Producer Mobility
3.3 Improving Congestion Control in Mobile ICN Network
3.3.1 Improving Congestion Control in IP-based Mobile Networks
3.3.2 Improving Congestion Control In Mobile ICN networks
4 Producer Mobility Management 
4.1 Introduction
4.2 Design
4.2.1 MAP-Me Update protocol
4.2.2 Map-Me Notification/Discovery protocol
4.2.3 Full MAP-Me approach
4.3 Implementation
4.3.1 MAP-Me implemented in a CCN/NDN network
4.3.2 Algorithm description
4.3.3 Security considerations
4.4 Proof of Correctness and Stability Analysis
4.5 Evaluation
4.5.1 Simulation setup
4.5.2 Baseline scenario description
4.5.3 Results for baseline scenario: Fat-Tree + RWP + CBR
4.5.4 Impact of mobility pattern, radio conditions and topology
4.5.5 Impact of notifications on path stretch
4.5.6 Trace-driven urban mobility
4.6 MAP-Me and routing
4.7 Conclusions
5 Security in Producer Mobility 
5.1 Introduction
5.2 Prefix Attestation Protocol Design
5.2.1 System Model
5.2.2 Threat Model
5.3 Prefix attestation
5.3.1 Bootstrap phase
5.3.2 Secure Interest Update Validation
5.3.3 Prevent Replay attack
5.4 Security Considerations
5.4.1 Preventing Prefix Hijacking attacks
5.4.2 Denial of Service Attacks
5.5 Evaluation
5.5.1 Computational Overhead
5.5.2 Additional Storage Cost
5.6 Discussion
5.6.1 Mobile Prefix Aggregation
5.6.2 LTE/Wifi Authentication not Enough for Prefix Attestation
5.7 Conclusion
6 Congestion Control in Mobile ICN Networks 
6.1 Introduction
6.2 Design
6.2.1 Wireless Loss Detection and Recovery
6.2.2 Mobility Loss Detection and Recovery
6.3 Implementation
6.4 Evaluation
6.4.1 ICN over IEEE 802.11
6.4.2 WLDR Evaluation
6.4.3 MLDR Evaluation
6.4.4 Joint WLDR-MLDR Evaluation
6.5 Conclusions
7 Conclusion 
8 Future Work 

GET THE COMPLETE PROJECT

Related Posts