Project topics and materials
Get Complete Project Material File(s) Now! »
Receiver-Driven Connection-less Transport
In contrast with the current sender-based TCP/IP model, ICN transport is receivercontrolled, it does not require connection instantiation and it accommodates retrieval from possibly multiple dynamically discovered sources (chapter 4). ICN transport builds upon the flow balance principle, guaranteeing corresponding requestdata flows on a hop-by-hop basis [7]. A large body of work has looked into ICN transport (surveyed in [129]), not only to propose rate and congestion control mechanisms [133, 166] – especially in the multi-path case [43] – but also to highlight the interaction with innetwork caching [42], the coupling with request routing [79, 43], and the new opportunities provided by in-network hop-by-hop rate/loss/congestion control [159, 47] for a more reactive low latency response of involved network nodes.
Other features of the ICN architecture
A result of the above mentioned ICN properties is support for in-network caching.
The ability to perform a name lookup in router buffers can be exploited for re-use (asynchronous multicast of data via cached replica) and repair (in-network loss control), which is an important differentiator w.r.t. existing end-to-end solutions. Many studies have proven its advantages [167, 171, 131, 49], but also the differences w.r.t. application-level CDN-like caching [45, 161]. Another important implication of ICN naming, security, forwarding and transport model is native mobility support. Previous work has highlighted the benefits of ICN seamless mobility, especially in 5G context [127, 85, 172, 57, 155, 30], as mostly deriving from its “anchor-less” management approach in the data plane. As a result, ICN can handle mobility with no need for a stable point of passage of traffic, rendezvous point or namelocation mapping system.
Receiver-Driven Connectionless Transport
Transport in hICN is similar to ICN: it is receiver-driven, connection-less and supports multiple point. All these features allow for in-network caching, in-network loss and congestioncontrol as well as bandwidth aggregation over heterogeneous networks. The current hICN software uses RAAQM, the receiver-driven congestion control proposed for ICN [43]. The protocol discovers and exploits available content sources in the network, maximizing the bandwidth available at the consumer. The implementation also includes wireless optimizations such as in-network loss control mechanisms introduced in [47]. Both protocols are used in the evaluation, in Section 3.4.
In addition to congestion and flow control, the ICN transport layer, and so the hICN one, needs to provide data authentication and data integrity verification, as discussed in the previous section. More details about hICN transport design and implementation can be found in chapter 4.
Bandwidth Aggregation over HetNet
The receiver-driven transport property of ICN/hICN permits a simple but efficient realization of channel bonding over heterogeneous radios, through the use of congestion aware load-balancing, implemented as a forwarding strategy [43]. It acts at packet level with the objective of minimizing the residual latency on every available path. This scheme can furthermore be applied network-wide and brings full multi-homing/multi-path/multi-source support. This experiment uses the same setting as in the previous section, showing that the performance of ICN and hICN are consistent. The test involves two different forwarding strategies implementing two different load-balancers: a per-dash-segment loadbalancer, which tries to mimic the granularity available for applications today, and the per-packet load-balancer just described. Results are in the right-hand side of Figure 3.10, labeled multi radio. The load balancing at segment level (labeled seg.) leads most of the time to performance degradation, which is consistent with different observations made in previous work on MPTCP [83], suggesting that those technologies are more appropriate for fast recovery than for channel aggregation in the case of DASH video streaming applications. Per-packet load balancing (labeled pkt.) instead achieves an optimal traffic split over the two channels, fully exploiting available bandwidth without any incidence on the application, despite the intrinsic differences between radios. By bonding WiFi and LTE, the video client obtains the highest quality with a minimum number switches. Also in this case, both the hICN and ICN implementation are comparable.
Table of contents :
Abstract
1 Introduction
1.1 Information Centric Networking
1.2 Thesis statement
1.3 List of Publications
2 Background on ICN
2.1 Named Data
2.2 Dynamic Forwarding
2.3 Data-Centric Security
2.4 Receiver-Driven Connection-less Transport
2.4.1 Other features of the ICN architecture
3 Hybrid Information Centric Networking
3.1 Introduction
3.2 hICN Design
3.2.1 Named Data
3.2.2 Name management
3.2.3 Dynamic Forwarding
3.2.4 Data-Centric Security
3.2.5 Receiver-Driven Connectionless Transport
3.2.6 Other features of the hICN architecture
3.3 Feasibility assessment
3.3.1 Controlled End-to-End Deployments
3.3.2 Large Scale Measurements
3.4 Linear video distribution
3.4.1 Workload and Implementation
3.4.2 In-network Control
3.4.3 Seamless Mobility
3.4.4 Bandwidth Aggregation over HetNet
3.5 Related work
3.6 Discussion and Conclusion
4 Transport layer and socket API for ICN
4.1 Introduction
4.2 Namespaces in ICN
4.3 Architecture
4.4 Transport Services
4.4.1 End-points description
4.4.2 Network namespaces
4.4.3 Socket API
4.5 Implementation
4.5.1 VPP: vector packet processor
4.5.2 Forwarder Connector
4.5.3 Consumer Socket
4.5.4 Producer Socket
4.6 Performance Analysis
4.6.1 Experimental settings
4.6.2 Results
4.7 Related Work
4.8 Discussion and Conclusion
5 HTTP over hICN
5.1 Introduction
5.2 Reverse pull transport service
5.2.1 Initialization
5.2.2 Naming
5.2.3 Publish Notification
5.2.4 Additional considerations
5.3 Optimized Reverse pull for HTTP
5.4 Multipoint-To-Multipoint communication
5.5 Evaluation of HTTP over hICN: Multicast and Server Load
5.6 Related Work
6 RTC over hICN
6.1 Introduction
6.2 hICN-RTC Architecture
6.2.1 hICN-RTC Communication Model
6.2.2 hICN-RTC Advantages
6.3 Synchronization Protocol
6.3.1 Protocol Discussion
6.4 hICN-RTC Evaluation
6.4.1 Scalability
6.5 Related work
6.6 Conclusion
7 Virtualized ICN
7.1 Introduction
7.2 Related work
7.3 The vICN framework
7.3.1 Functional architecture
7.3.2 Resource model
7.3.3 Resource processor
7.3.4 Orchestrator and Scheduler
7.4 Implementation
7.4.1 vICN codebase
7.4.2 Slicing
7.4.3 IP and hICN topologies
7.4.4 Link emulation
7.4.5 Monitoring capabilities
7.5 Examples
7.5.1 Use case description
7.5.2 Scalability
7.5.3 Programmability
7.5.4 Monitoring and Reliability
7.6 Conclusion
8 Conclusions and Future Work
8.1 Summary
8.2 List of contributions
Bibliography
