provides support beyond HTTP caching or managed CDNs. We demonstrate the effectiveness of our design using measurements of a Linux- based prototype ...
Karthik Budigere Ramakrishna
Router Modelling and Packet Level Cache Implementation for Content Aware TCP (CATCP)
School of Electrical Engineering
Thesis submitted for examination for the degree of Master of Science in Technology. Espoo 06.05.2016
Thesis supervisor: Prof. Joerg Ott Thesis instructor: Ph.D. Pasi Sarolahti
A’’
Aalto University School of Electrical Engineering
aalto university school of electrical engineering
abstract of the master’s thesis
Author: Karthik Budigere Ramakrishna Title: Router Modelling and Packet Level Cache Implementation for Content Aware TCP (CATCP) Date: 06.05.2016
Language: English
Number of pages:8+65
Department of Communications and Networking Professorship: Network Technology
Code: S-38
Supervisor: Prof. Joerg Ott Instructor: Ph.D. Pasi Sarolahti Internet is more content oriented than ever before, In today’s Internet scalable content access is provided by content distribution networks (CDN), application specific caches, proxies etc. The proliferation of these systems is complex and expensive. In the past few years many data-oriented or information-centric network architectures have been proposed such as DONA, PSIRP, CCN etc, but these new clean-state architecture proposals have seen little deployment because of its expensive initial costs. In the thesis, we present CATCP - Content Aware TCP an incrementally deployable approach to bring content-aware and in-network caching to TCP. In our approach, content-aware senders cooperate with in-network segment caches, integrated with routers and other middle boxes, to support scalable content delivery to unmodified clients. This effectively supports opportunistic caching for time-shifted content access, as well as synchronous multicast delivery to concurrent receivers. Our approach is application protocol-independent, and provides support beyond HTTP caching or managed CDNs. We demonstrate the effectiveness of our design using measurements of a Linuxbased prototype implementation, and performance evaluation using ns-3 simulations along and Network Simulation Cradle. The results show CATCP can effectively reduce server side and network load.
Keywords: TCP, Content-Centric, Internet
iii
Acknowledgments First and foremost, I am indebted to my Prof. Joerg Ott, whose vision is crucial for this thesis. This thesis would not be possible without his knowledge and amiable guidance. I would like to thank him for providing me the opportunity and his guidance will continue to inspire me for years. I would like to thank Pasi Sarolahti for the help and support with TCP sender and protocol related impelmentations. Furthermore, I would like to thank all my friends and colleagues for all the insightful discussions and suggestions. It is my pleasure to be in such a wonderful atmosphere. Last but not least, I would like to express gratitude to my parents and family members for their constant love and encouragement.
Otaniemi, 06.05.2016 Karthik Budigere Ramakrishna
iv
Contents Abstract
ii
Acknowledgments
iii
Contents
iv
Symbols and abbreviations
vii
List of Figures
viii
1 Introduction 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Goal and Scope of the Thesis . . . . . . . . . . . . . . . . . . . . . . 1.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Related Work 2.1 Infomation Centric Networking (ICN) . . . . . . . . . 2.1.1 Data Oriented Network Architecture (DONA) 2.1.2 Content Centric Networking (CCN) . . . . . . 2.1.3 PSIRP/Pursuit . . . . . . . . . . . . . . . . . 2.2 IP Multicast Networking . . . . . . . . . . . . . . . . 2.3 Network Caching . . . . . . . . . . . . . . . . . . . . 2.3.1 HTTP Caching . . . . . . . . . . . . . . . . . 2.3.2 Caching and Cache Replacement Strategies . . 2.3.3 TCP Caching . . . . . . . . . . . . . . . . . . 2.3.4 Packet Level Caches . . . . . . . . . . . . . . 3 TCP Protocol Overview and Operation 3.1 TCP Header . . . . . . . . . . . . . . . . 3.2 TCP Connection . . . . . . . . . . . . . 3.2.1 TCP Connection Establishment . 3.2.2 TCP Connection Termination . . 3.3 TCP Congestion Control . . . . . . . . . 3.3.1 Slow Start . . . . . . . . . . . . . 3.3.2 Congestion Avoidance . . . . . . 3.3.3 Fast Retransmit . . . . . . . . . . 3.3.4 Fast Recovery . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . . .
. . . . . . . . .
. . . . . . . . . .
. . . . . . . . .
. . . . . . . . . .
. . . . . . . . .
. . . . . . . . . .
. . . . . . . . .
. . . . . . . . . .
. . . . . . . . .
. . . . . . . . . .
. . . . . . . . .
. . . . . . . . . .
. . . . . . . . .
. . . . . . . . . .
. . . . . . . . .
1 1 2 2
. . . . . . . . . .
4 4 4 6 7 9 10 10 11 13 14
. . . . . . . . .
16 16 18 18 19 19 20 20 21 21
v 3.4
TCP Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4 Content Aware TCP (CATCP) 4.1 Introduction . . . . . . . . . . . . . . 4.2 CATCP Basic Operation . . . . . . . 4.3 CATCP Sender Operation . . . . . . 4.3.1 Content Labelling . . . . . . . 4.3.2 Acknowledgement Processing 4.3.3 Segmentation . . . . . . . . .
. . . . . .
. . . . . .
5 Content Aware TCP Router Modelling 5.1 CATCP Router Operation: . . . . . . . . 5.1.1 Controlling Nodes . . . . . . . . . 5.1.2 Segment Caches . . . . . . . . . . 5.1.3 Cache Operations . . . . . . . . . 5.2 Receiver Operation . . . . . . . . . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
. . . . . .
. . . . .
6 Simulations and Result Evaluation 6.1 Network Simulator 3 (NS-3) . . . . . . . . . . . . . . . 6.2 Network Simulation Cradle . . . . . . . . . . . . . . . . 6.3 Basic Simulation and Result . . . . . . . . . . . . . . . 6.3.1 Basic Behavior . . . . . . . . . . . . . . . . . . 6.3.2 Timing Issues with Simultaneous flows . . . . . 6.3.3 Congestion . . . . . . . . . . . . . . . . . . . . 6.3.4 Improvements to CATCP . . . . . . . . . . . . 6.4 Simulation Results . . . . . . . . . . . . . . . . . . . . 6.4.1 Simulation Scenarios and Simulation Parameters 6.4.2 Effect of Network Load on a Shared Link . . . . 6.4.3 Effect of Congestion Control . . . . . . . . . . . 6.4.4 Effect on Regular TCP cross traffic . . . . . . . 6.4.5 Effect of caching performance . . . . . . . . . . 6.5 Experimental Results . . . . . . . . . . . . . . . . . . . 6.5.1 Interoperability . . . . . . . . . . . . . . . . . . 6.5.2 Perfect caching . . . . . . . . . . . . . . . . . . 6.5.3 Bulk Resource Retrieval . . . . . . . . . . . . .
. . . . . .
. . . . .
. . . . . . . . . . . . . . . . .
. . . . . .
. . . . .
. . . . . . . . . . . . . . . . .
. . . . . .
. . . . .
. . . . . . . . . . . . . . . . .
. . . . . .
. . . . .
. . . . . . . . . . . . . . . . .
. . . . . .
. . . . .
. . . . . . . . . . . . . . . . .
. . . . . .
. . . . .
. . . . . . . . . . . . . . . . .
. . . . . .
. . . . .
. . . . . . . . . . . . . . . . .
. . . . . .
24 24 25 27 28 28 29
. . . . .
31 31 31 32 33 36
. . . . . . . . . . . . . . . . .
37 37 40 40 40 40 42 42 44 44 45 45 46 47 50 53 54 56
vi 7 Discussion and Conclusion 7.1 Segmentation: . . . . . . . . . . . 7.2 Content label namespace: . . . . 7.3 Cache pollution and DoS attacks: 7.4 Middleboxes: . . . . . . . . . . . 7.5 Asymmetric Routing: . . . . . . . 7.6 Conclusion: . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
58 58 58 59 59 60 60
vii
Symbols and abbreviations Abbreviations ACK CATCP EID FEC FTP IP IPC ITU P2P QoS RTP RTCP RTT RWP SACK SCTP SIP SYN TCP TLS TTL UDP URG URI URL VoIP
Acknowledgement Content Aware TCP Endpoint Identifier Forward error correction File Transfer Protocol Internet Protocol Inter Process Communication International Telecommunication Union Peer-to-Peer Quality of Service Real-time Transport Protocol Real-time Transport Control Protocol Round Trip Time Random Waypoint Selective Acknowledgment Stream Control Transmission Protocol Session Initiation Protocol Synchronization Transmission Control Protocol Transport Layer Security Time-To-Live User Datagram Protocol Urgent Pointer Uniform Resource Identifier Uniform Resource Locator Voice over Internet Protocols
viii
List of Figures 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
IP Datagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP 3-Way Handshake . . . . . . . . . . . . . . . . . . . . . . . . . CATCP Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . CATCP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . Content Label Option . . . . . . . . . . . . . . . . . . . . . . . . . . Content Request Option . . . . . . . . . . . . . . . . . . . . . . . . . CATCP Router priming/updating for a flow . . . . . . . . . . . . . . CATCP Packet Insertion (caching) . . . . . . . . . . . . . . . . . . . CATCP Packet Retrieval . . . . . . . . . . . . . . . . . . . . . . . . NS-3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . Send Packet Processing . . . . . . . . . . . . . . . . . . . . . . . . . Mean number of packets transmitted per flow (starts with 1sec Interaval) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mean number of packets transmitted per flow (simultaneous) . . . . Effect of Network Load on a Shared Link (Segements Transmitted) . Effect of Network Load on a Shared Link (Segments Lost) . . . . . . Effect of Load on a Shared Link (Completion Time) . . . . . . . . . Mean flow completion time without congestion control . . . . . . . . Mean flow completion time with congestion control . . . . . . . . . . Mean flow completion time (TCP and CATCP) . . . . . . . . . . . . Effects of Cache Probability on packets transmitted for different state length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Effects of Cache Probability on packets transmitted for different number of packet caches . . . . . . . . . . . . . . . . . . . . . . . . . . . Effects of Cache Probability on packets received from cache for different number of packet caches . . . . . . . . . . . . . . . . . . . . . Experimental lab setup. . . . . . . . . . . . . . . . . . . . . . . . . . Experimental Results with 20 receivers, 64 KB, 10ms one-way delay . Experimental Results with 10 receivers, 256 KB, 0ms one-way delay . Experimental Results with 50 receivers, 256 KB, 10ms one-way delay
16 17 19 24 26 28 29 34 34 35 38 39 41 41 46 47 48 49 49 50 51 51 52 53 54 55 56
1
Introduction
In today’s world Internet is the main source for accessing different types of information for many people and it’s also main source for entertainment, people use Internet for accessing content such as movies, music, live sports events etc. In the past Internet was mainly static web pages but now Internet is more dynamic in nature because the popularity of social networking websites. The changes in Internet usage resulted in increased traffic volumes and the users are demanding about the performance and reponse time when requesting the information [36]. The current applications of the Internet are predominantly content-centric and such applications care less about the actual content location, they mainly rely on how easily, efficiently and reliably the content is available. These applications rely on network caching, dynamic caching or content distribution networks to address the problem of demand for better performance. Internet content is pre dominantly HTTP and HTTP caches to some extent reduces the load in the network and give better performance, but it operates only with HTTP protocol, other infrastructure such as content distribution networks is complex, unreliable and expensive to maintain and operate. The Internet is based on the host-centric architecture, In order to make Internet more robust and efficient there are numerous research work on future Internet architectures. One of the suggestions is changing the architecture from host-centric to content-centric architecture [26]. In order to have information-centric approach to Internet, several alternate architectures have been proposed, they are • DONA [29] • CCN [26] • PSIRP [28] All theses architectures are completely clean-state architecture, but none of them have seen wide deployment in the real world yet.
1.1
Problem Statement
The future Internet architecture will be based on the Information centric networking(ICN) and the ICN architectures that have been proposed so far have not seen wide deployment because of their clean-state architecture designs that makes it very expensive for deployment.
2 In this thesis we present an incrementally deployable approach to bring the features such as content awareness and in network caching to the end-to-end transport protocols such as TCP. The thesis mainly focuses on the design of content-aware routers that are used with the proposed CATCP.
1.2
Goal and Scope of the Thesis
In this thesis we consider the problem of how to add content-awareness to the Internet in a more incremental manner rather than proposing another clean state architecture. We consider the small incremental backward-compatible changes to changes to the transport protocol such as TCP in order to label items of content. We focus on designing the content-aware router using the router extensions thus to achieve the ubiquitous caching of labeled content within the network. We explore the benefits of in-network caching and investigate the benefits of short-term packet level caches and packet level data replication in network as a mechanism to reduce the load on network servers and upstream links. Such mechanism is beneficial for coping up with the packet loses at link level and also can be used to implement pseudomulticast service on the transport layer. Our approach differs from the proposed ICN architectures as it is incrementally deployable in the current Internet as it does not require modifications to communication stack or deployment of new architecture and still provides with all the benefits of ICN. This approach also differs from the HTTP caching as it provides packet level caching and retrieval mechanisms. The thesis mainly focuses on the design of content aware routers and the packet level caching at the routers and evaluates the benefits of in-network caching to reduce the loads on network servers. It also evaluates the various caching replacement mechanisms and its affects on the reduction of load on network servers. This work has been carried out at Department of Communications and Networking at Aalto University, Espoo. We have submited a technical report of this work to Aalto University Publications with title “Poor man’s content centric networking (with TCP)” [37].
1.3
Thesis Outline
In the introductory chapter we have discussed about the future Internet architectures and their drawback for wide scale deployment and we have discussed a incremental approach could solve the deployment problem. We further discuss the problem statement, goal and scope of the thesis.
3 Chapter 2 presents the overview of Information centric networking that is the background of the thesis, we discuss in details about the various ICN architectures, network caching and IP multicast and its problems. It briefly explains the ICN architectures such as DONA, CCN and PSIRP/Pursuit. Chapter 3 presents the overview of the TCP protocol and its operation. This is necessary to understand the TCP protocol connection setup, headers of the protocol and various options that can be used in implementation of packet level caches. Chapter 4 presents with CATCP architecture and its operation with the existing TCP protocol. The section also discusses on naming of the content and complete end-to-end operation of CATCP. Chapter 5 presents the CATCP router implementation details, new options that are used for naming, packet caching and retrieval mechanisms and the operation of router during the congestion control. It also discusses the implementation details with the data structures for the packet level caching at routers. Chapter 6 presents the results of CATCP router implementation in terms of reducing the network load using simple Internet scenario and the benefits of caching with the flash crowds scenario, it also presents the results with different cache replacement mechanisms and pseudo-multicast scenario. Chapter 7 draws the final conclusion of the thesis, summarizes the results and discusses the future work and enhancements for CATCP.
4
2
Related Work
In this chapter we discuss about the various related work related to the thesis such as Information Centric Networking, Network caches and IP Multicast.
2.1
Infomation Centric Networking (ICN)
The Information Centric Networking is the significant common approach adapted by the several future Internet architecture related research activities [3, 45] . The ICN approach takes the Internet away from the host centric approach towards the content or data oriented paradigm and facilitates to solve the many problems faced by the current Internet architecture. The goal of ICN is to provide the network infrastructure that is service that is better suited to today’s use. The ICN approach is based on in-network caching, multiparty communication through replication, and the interaction models decoupling the senders and receivers. The research in the area of ICN is new and many different network architectures are being evolved based on ICN, In this section we discuss some of the popular ICN based architectures that are being developed such as DONA [29], CCN [26] , PSIRP [28]. 2.1.1
Data Oriented Network Architecture (DONA)
The Data Oriented Network Architecture (DONA) was developed at University of California, Berkley. DONA proposes the clean-slate architecture for the Internet naming and name resolution. The Internet architecture is built based on the host-to-host model for communication. This kind of architecture is suitable for the applications such as ftp, telnet, remote login etc. These applications know the source host for the communication and the network’s role is to carry packets to the destination address. But today the majority usage of Internet is data retrieval and service access where the users care about content but not the source of the content. DONA focuses on this shift in usage from host-centric to data-centric applications. Dona proposes the use of self-certifying names for identifying the data thus replacing DNS with this. This ways DONA explores alternative new content-based network architecture in which the clients request data using its name but not the location of its storage. DONA exposes two basic primitives operations for the naming resolution they are, • FIND - used by a client to request a data by its name
5 • REGISTER - used by content providers in order to offer a particular data object for naming. In order to enable these two primitives for naming resolution DONA proposes a new class of network entity called Resolution Handlers (RH). Resolution Handlers handle name resolution and caching functionalities. Each domain or an administrative entity has one logical RH and connected hierarchically, client knows about the location of its RH through some local configuration. Each RH maintains a registration table that contains mapping information of name with both next-hop RH and distance to the copy. RH’s use longest prefix matching. When an RH receives a FIND (P:L) message, the forwarding rule is straightforward, if there is an entry in the registration table the FIND is send to the next-hop RH otherwise the RH forwards the FIND towards its parent in the hope of finding the entry. The FIND packet does not just resolve the name but it also initiates the transport exchange between the client and RH. DONA provides the name based routing protocol that ensures the packet to reach its destination. If the FIND reaches a tier-1 AS and the record is not found then an error message is sent to the source of FIND primitive. The communication after the FIND primitive are not handled by RHs and it will be routed to the destination by standard IP routing and forwarding. The service provider has to register the content that it is serving with RH. The content provider who is authorized to a service with name P:L sends a REGISTER (P:L) command to its local RH. It can also send take the form REGISTER (P:*) if the host is serving all the data associated with the principal. When and RH receives a REGISTER command form the content provider, it checks if the record exists or if the record exists then it checks if the new REGISTER comes from a copy closer than the existing entry. If the record does not exists or if its closer copy then the RH updates its registration table and forwards the REGISTER to its parents and peers. Local policies govern the forwarding of REGISTER command when it comes from a peer RH. The REGISTER command must use authentication. The local RH does the authentication. RH issues a challenge with a nonce, client or content provider must sign with private key and also provide a certificate to complete the authentication and to register the data successfully. While forwarding the REGISTER RH signs it so that the receiving RHs know that the data came from trusted RH. DONA also has the UNREGISTER command that is used by the content provider when they are no longer serving the data with label (P:L).
6 2.1.2
Content Centric Networking (CCN)
Content Centric Networking architecture has been developed by PARC. It’s a full fledged ICN architecture whose basic idea were described in a Google Tech Talk [25] and then published as part of the project called Named Data Networking (NDN) [26] funded by the US Future Internet Architecture Program. CCN is a communication architecture built on the named data. CCN communication is driven by the consumer’s data that uses naming to identify it, these are called as Named Data Objects (NDO). The naming in CCN is hierarchical and is similar to URLs. In CCN a request for a name is considered to be match any named data whose name has the requested name as a prefix. This way it can be used with the various applications where the named data objects are generated dynamically, as their full names cannot be known in advance. Name resolution happens in CCN using two types of messages called Interest and Data. A consumer/Subscriber issues the Interest messages to request for the information objects and the requested data will arrive in form of Data messages. All messages are forwarded hop by hop by content routers (CRs). Content Routers is the core for the CCN packet forwarding engine and it has three main data structures to facilitate its operation,they are • FIB - Forward Information Base • Content Store • PIT - Pending Interest Table. The FIB is used to forward the Interest packets towards the potential sources of matching data. CCN allows multiple sources of data and can query them in parallel. The content store is a buffer memory for the incoming data packets, the CRs store these packets and remembers it for as long as possible based on the caching mechanism they use (LRU or LFU replacement). The PIT tracks the Interest messages forwarded in the upstream towards the content sources, so as to returned Data can be sent downstream to it’s requesting subscribers. The entries in PIT are removed after being used to forward matching Data packets. The Interest entries that never find a matching Data will be eventually timeout and removed from the PIT. In CCN caching is done at CRs in the Content Store. It caches all the Data packets it comes across. It uses LRU or any other cache replacement policy, It cannot be used for
7 long term caches and this caching is mainly useful for packet loses and for handling the flash crowds, where many users request for the same content in close period of time. CCN named data objects are secured and can be verified for its integrity. Each Data message contains a signature over name and the information included in the message along with the information about the key used to produce the signature. This allows CRs to verify the binding between the name and the information to which it is associated. 2.1.3
PSIRP/Pursuit
The Publish Subscribe Internet Paradigm (PSIRP) [28] and its continuation project Publish Subscribe Internet Technology (PURSUIT) [19] are the projects on future Internet architectures funded by EU Framework 7 program. These projects have produced an new architecture that replaces the IP protocol stack with a publishsubscribe protocol stack. The PURSUIT architecture consists of three core functions, they are • Rendezvous • Topology Management • Forwarding In simple terms the network operation is like when the rendezvous function matches a subscription to a publication it directs the topology management function to create a route for communication between the publisher and subscriber. This route will be used by the forwarding function to preform the actual data transfer. Naming of data objects in PURSUIT is by a unique pair of IDs, they are scope ID and rendezvous ID. The scope ID groups related information objects where as the rendezvous ID is the actual identity for the data. Data objects may belong to the multiple scopes. Scopes are important for defining the sets of information objects within a given context and to enforce the boundaries based on some dissemination strategy for the scope. Name resolution in PURSUIT is handled by the rendezvous function that is implemented by a collection of Rendezvous Nodes (RNs). The Rendezvous network is implemented as hierarchical DHT, when a publisher wants
8 to advertise a data object, it issues a PUBLISH message to its local RN which is routed by DHT to the RN assigned with the corresponding scope ID. When a subscriber issues a SUBSCRIBE message for the same data object to its local RN, it is routed by the DHT to the local RN. The RN then instructs a Topology Manager (TM) node to create a route connecting the publisher with the subscriber for data delivery. The TM sends that route to the publisher in a START PUBLISH message. Which finally uses this route to send the information object via a set of Forwarding Nodes (FNs). The TM nodes in PURSUIT jointly implement the topology management function by executing a distributed routing protocol to discover the network topology, e.g., OSPF. The actual delivery paths are calculated upon request by the rendezvous function as a series of links between FNs and encoded into source routes using a technique based on Bloom filters. A tag identifies each network node and this tag will be advertised via routing protocol. When a data packet arrives at a FN, the FN simply ANDs the tags of its outgoing links with the Bloom filter in the packet; if any tag matches, then the packet is forwarded over the corresponding link. In this manner, the only state maintained at the FNs is the link tags. Multicast transmission can be achieved by simply encoding the entire multicast tree into a single Bloom filter. PURSUIT supports both on-path and off-path caching. In the case of on-path caching forwarded packets are cached at the FNs. However in case of PURSUIT the on-path caching may not be effective because of the decoupled nature of name resolution and data routing. It may use entirely new paths for the data transfers in the future. In the case of off-path caching the caches acts as publishers by advertising the available data content Rendezvous network. PURSUIT supports the Packet Level Authentication (PLA) technique for encrypting and signing the individual packets. This assures data integrity and confidentiality. It also helps in keeping the malicious publishers away. PLA can be used by FNs or at the final destination. The use of flat names for naming also permits the self-certifying names for unchangeable data by using the data objects has as rendezvous ID. The Paths are encoded into bloom filters can use the dynamic tags and help in preventing any kind of DoS attacks.
9
2.2
IP Multicast Networking
Multicasting in a network is transmission of a data to a subset of the hosts in a network [6]. Multicast is communication between one-to-many or many-to-many in a network. Steve Deering developed the multicast technique. RFC 1112 [15] provides the specifications to Host Extensions for IP Multicasting. IP multicast is based on an open service model. There is no mechanism restricting the hosts or users from creating a multicast group and to start receiving data from a group, or to start sending data to a group. The notion of group membership is only a reachability notion for receivers and is not meant to provide any kind of access control. As with all IP datagrams, multicast networks are best effort and unreliable. Each multicast group is named by a class-D multicast address. To receive data from the multicast group, hosts must join the group by contacting their routers using the Internet Group Management Protocol version 2 (IGMPv2) [18]. Once a host joins a group, it receives all data sent to the group address regardless of the sender’s source address. Hosts can send to a multicast group without becoming a receiver; such hosts are often referred to as non-member senders. Multiple senders may share the same multicast address. Whether those sources share a single multicast routing tree or have separate trees leading to the receivers is dependent on the multicast routing protocol. Senders cannot reserve addresses or prevent another sender from choosing the same address. The number of hosts joined to a group as receivers is dynamic and unknown. The status of entities (sender, receiver, or both) is unknown. The connections between the routers that form the multicast spanning tree are maintained by a multicast routing protocol. Many such protocols have been proposed and are in use today on the Internet. They include Distance Vector Multicast Routing Protocol (DVMRP) [14], Multicast Open Shortest Path First (MOSPF) [SI, Protocol Independent Multicast Sparse Mode (PIM-SM), PIM Dense Mode (PIMDM) [16, 30] etc. There are not many applications that are driving the multicast deployment. The current applications that are interested in multicast deployment are mainly Audio and Video distribution, push applications, audio and video Conferencing and large file transfer systems [17]. The multicast has evolved from MBone to Interdomain Multicast but yet to see very wide deployment because of its architecture complexities and number of other problems.
10 The Multicast network deployment has several problems, although number of problems have been addressed in the RFC 3170 [5] ”IP Multicast Applications: Challenges and Solutions”, still some of the problems need to be addressed in order to make it more deployable, they are lack of access control and group management, Problems with address allocation, security and protection against attacks to the routing and data integrity of multicast packets and lack of network management tools and high cost for deployment.
2.3
Network Caching
Network caching is a technique to keeping/storing the frequently accessed information on the network in a location closer to the host requestor. In general network caches for web traffic can store the contents of web page that is subjected to change less frequently. This way one can achieve huge amount of reduction in the network bandwidth and faster access to the end users because of the faster delivery of the requested content. Network caching is achieved in several ways by the web applications varying from standalone caches to browser-based caches. The future internet architecture research and information centric networking approaches follow the architecture design in a way to decouple the sender and receivers in a network in order to achieve this network caching is very essential. There are two kinds of network caches, on-path caches and off-path caches. In this chapter we discuss more about the different kinds of network caching mechanisms and their advantages in achieving the better network performance. 2.3.1
HTTP Caching
HTTP is one of the protocols used in Internet for the web content delivery. In order to make it more robust and efficient HTTP caches were introduced in the RFC 7234 [34]. HTTP caches are the local store of response messages. Cache stores the cacheable responses for the future use, this way it helps in reduction of response time and the network bandwidth consumption. The cache operation preserves the semantics of HTTP transfers and also eliminates the transfer of information that is already stored by the cache. Web caches can be the in form of browser caches or the proxy web cache servers. HTTP defines three mechanisms in order to control the caches, they are • Freshness
11 • Validation • Invalidation. Freshness: A fresh response is one whose age has not exceeded the freshness lifetime limit. The freshness time of a response is defined as the length of time between its generation by the origin server and its expiration time. When the response is fresh in the cache then it can be used in response to requests without contacting the origin servers. On expiration it can no longer be used from the cache as response without further validation from its origin server. The origin server using the Expires header field or the max-age response directive provides the freshness of a response. If the origin server fails to provide the expiration time then a heuristic freshness lifetime has to be calculated for the response. Validation: When a cache has stale entries that are not fresh, then it cannot be used serving the request. In this case it can use the conditional request mechanism by which it can update the metadata for the stored response or to replace the store responses with new responses. This is process is known as validation or revalidation of the stored response. Invalidation: Invalidation of cached response happens because of the unsafe request methods such as PUT, POST or DELETE has changed the state of the origin server. Intervening caches has to invalidate the responses in their caches. However in the modern systems like CDNs the usage of HTTP caching has been replaced by dynamic caching. It is difficult to use HTTP static caching due to the dynamic nature of the websites. 2.3.2
Caching and Cache Replacement Strategies
Caching in a network system is very essential, it enables the use of edge networks for the popular content thus releasing the load from the core network and prevents the core network from being overloaded to serve the popular content. Caching also enables the resilience to network failures as it can provide the dupication of data. In this section we discuss more about the caching terminologies and the cache replacement strategies in details. The follwing are the most commonly used caching terminologies,
12 • Collaborative caching - This a network system with one or multiple caches which can co-ordinate with eachother and incraese the potential to cache data. It appreas to be a single system for outside world. • Cache hit - A sucessfull request to a cache that can be fulfilled from the cached content. • Cache miss - A request to a cache that can not be fulfilled from the cached content. • Cache hit ratio - This is the ratio of cache hit to cache miss, It gives the measurement ratio for cache performance. • LRU - Stands for Least recently used, it a cache replacement startegy which remove the least requested cached item from the cache when its full. • LFU - Stands for Least frequently used, it a cache replacement startegy which remove the least frequenlty requested cached item from the cache when its full. Cache replacement strategies focus on the opertations on cache that is how it chooses to store the item in a cache and how it chooses to replace a item from cache. It also defines the rules for communication in case of collaborative caching. There are number of methods and strategies that can be applied on caches [32] [43]. The most commonly used traditional cache replacement strategies are, • First-In First-Out (FIFO) • Least Recently Used (LRU) • Least Frequently Used (LFU) LRU stands for Least Recently Used replacement strategy. In this strategy the cache maintains age on the data and when a new item needs to be added to a full cache, it replaces the least recently used data item. The main limitation of LRU is that it does not account for the volume of queries to a target. Sites visited regularly but not frequently fall out of the cache, while one-off requests stay in the cache for much longer than they should be in the cache. There are many LRU variants, including the following one called LRU/2. In LRU/2, the penultimate access times are used to run LRU, and the item with the least recent second-to-last access time is replaced. LRU/2 extends to an arbitrary number of accesses before the most recent, and this collection of strategies is called
13 LRU/K, each replacing the kth most recent information item. In SLRU (segmented LRU), new items are placed on a probationary cache ordered from most to least recently accessed; if an item is accessed again while still in this cache, then it is placed in the protected cache. When necessary, the least recently accessed in the protected cache is downgraded to the most recently accessed slot of the probationary queue. Items are purged when they are at the least recently accessed end of the probationary queue and a new item is added to the cache. FBR (Fequency based replacement) incorporates elements of LFU (below) by separating the cache into new, middle, and old sections and, when an item is accessed and it is not in the new (most recently used) section, then incrementing a reference count for the item. When replacement needs to happen, the block in the old section with the smallest reference count is purged. LFU, or Least Frequently Used replacement, maintains a counter on the data of number of access times for each item. When a new item needs to be added to a full cache, in replaces the item with the fewest accesses. One main limitations of LFU are the additional complexity (logarithmic) to add or remove an entry or to reorder entries in the heap. The other main limitation of LFU is that recent pages are not given priority. Stale entries which received many hits some time ago are kept in the cache over those which received a few hits very recently. Adaptive Replacement caching uses a LRU cache and a LFU cache on the same data, each with a ghost list tracking recently evicted entries. Cache misses which are in a ghost entry will increase the size of the ghost entry’s associated cache and evict an item from the other cache. Depending on the needs of the network, different caching strategies may be more or less successful. Internet packets have 15 minute time to live (TTL) in a cache. packets which are highly requested are likely to have already been requested again in that time span within the service domain, and packets which have not been requested again in that time span are likely candidates for replacement. This temporal locality property indicates that most queries previously submitted will be submitted again in a short time frame. Using this expectation, a few modifications to these caching strategies emerge as potential improvements on LRU or LFU performance. 2.3.3
TCP Caching
TCP packet level caching was introduced in order to improve its performance over wireless networks. TCP is a reliable protocol designed to perform well in the traditional wired networks made up links that has low bit-error rates. In order to adapt
14 TCP to the higher bit-error rates there were several adjustments made to its operation and one such proposal was to use the caches at base stations. The TCP snoop protocol [8] proposes caching of packets at base stations and also performs the local retransmissions across the wireless link in case of packet loss scenarios. The local retransmissions help to avoid the end-to-end retransmissions. The same concept was also used in distributed wireless sensor networks to improve the TCP performance [7] . TCP Snoop Protocol The TCP snoop protocol is designed to improve the performance of TCP over wireless networks, TCP Snoop protocol is described as bellow for the data transfer between a fixed host to a mobile host through a base station. The base stations routing module is modified with a new module called snoop and it’s capable monitoring the packets flowing in either direction. Snoop module maintains the TCP packet cache. It maintains the cache of all the TCP packets that are not acknowledged yet. It simply adds packets to the cache and passes the packets to the destination. The snoop module also keeps track of the acknowledgements sent by the mobile host. When a packet loss is detected that can be by the arrival of duplicate acknowledgment or by a local timeout, it retransmits the lost packet to the mobile host from its cache. This retransmission from base station will be hidden from the fixed host and helps in reducing the end-to-end retransmission delays and also prevents the unnecessary invoking of congestion control mechanisms. The snoop module has two linked operations, they are snoop-data and snoopack. Snoop-data processes and caches the packets that are being transmitted to the mobile host where has the snoop-ack processes the acknowledgements to determine the packet loss and to perform the retransmission if necessary. 2.3.4
Packet Level Caches
In recent days there have been several works exploring the idea of packet caches on routers to explore its benefits of packet level redundant content elimination. A majority of redundancy eliminations systems are using application layer object caching to eliminate redundant transfers in the network, for example web proxy caches etc. Application layer caching is tied to single applications, the packet level caches operate irrespective of applications and also studies have shown that more redundant information can be removed by focusing on the packet level caching than at the object level. To obtain the most benefit from the caching scheme, ”redundancyaware” intra- and inter-domain routing algorithms are recommended, lowering intra
15 and inter-domain link loads by 10-50 percent. These schemes assume that the routers will be capable of stripping the redundant content from the packets on the fly by comparing the packet contents against the packets stored a packet cache. The cache can be packets that are forwarded recently by the router. Routers downstream can reconstruct full packets from their own cache. Applying this technology at every link would provide immediate performance benefits by reducing the overall load on the network. If the relation between scopes and active fast forwarding paths can be identified and used for traffic optimization purposes, we can expect the resulting forwarding path to be ”redundancy-aware” as per []. Cachecast Cachecast is an approach to packet level caching and demonstrates how to achieve single source multi destination transfers by eliminating the redundant link traffic. Cachecast is full distributed and incrementally deployable architecture. The architecture consists of small caches on links that can act independently. A single cache removes redundant data from a packet on the link entry and recovers the data on the link exit. Thus, link caches are transparent to routers. The basic operation of cachecast is as show in the figure. Cachecast operates on the assumption that two consecutive packets that originate from the same source, traverse a few hops over a common path and carry the same content but have different destinations. The first packet traverses the path hop-by-hop. Each hop along the path caches the packet payload and records the output link for the packet. When the second packet enters the path, the first hop determines the output link for the packet. It recognizes that it has sent the first packet over that output link with the same payload. Since the payload is already in the next hop cache, it sends only the packet header. The same occurs on each hop until the last hop of the common path is reached. The last hop determining the output link for the second packet recognizes that it will travel a different path than the first packet. Thus, the payload is not present in the next hop cache. The last hop attaches the payload from its cache to the second packet header, sends the entire packet and records the output link. The paper leaves some questions unanswered, such as how to ensure that different flows packetize the payload so that the per-packet content is identical (for example, in the case of variable length HTTP headers). The paper claims to be incrementally deployable, but the design decisions (such as adding a content header between L2 and IP headers) raise some doubts in this respect.
16
3
TCP Protocol Overview and Operation
Transmission Control Protocol is the most widely used transport protocol in the Internet [12]. TCP is connection oriented and end-to-end reliable protocol between two hosts through network, in addition to this TCP also has mechanisms for congestion control for better performance in various scenarios. In this chapter we present the basics of TCP and its operations. The development of TCP began in 1974 by Vint Cerf and Bob Kahn, they published paper on inter-networked protocols and the central control component of it was Transmission Control Program [11, 13]. It was then divided into modular architecture and in 1981 Transmission Control Protocol was specified in the RFC 793 [33].
Figure 1: IP Datagram TCP is connection oriented and hence the TCP must establish the connection between the hosts before the transmission of data. The TCP connection establishment happens via three-way handshake mechanism. Once the connection is established the data is exchanged between the hosts. The TCP data is encapsulated in an IP datagram as show in the figure 1. The application data to be transmitted is broken in to chunks and the TCP header is added to it, this unit is called segments. The segments are passed to IP for transmission. When TCP sends a segment it maintains a timer waiting for acknowledgement from the receiving side. If the acknowledgement is now received in time then the segment is retransmitted assuming the transmission loss.
3.1
TCP Header
The TCP segment contains TCP header and TCP payload; the figure 2 shows the format of the TCP header. The size of TCP header is 20 bytes unless the options are present. Source and Destination Port: Each TCP segment contains the source and destination port number to identify the sending and receiving application. These two
17
Figure 2: TCP Header port values and source and destination IP addresses in the IP header uniquely identify each connection. Sequence Number: Sequence Number is a 32 bit unsigned integer and it identifies the first data octet of the segment. If the SYN is present then the sequence number is initial sequence number (ISN). The initial sequence number is randomly generated in order to prevent the segments to get mixed up with different connections. Acknowledgement Number: Acknowledgment number is a 32 bit unsigned integer and it contains the value of next sequence number that the sender of acknowledgement expects to receive. Header Length: Header length is 4 bit sized field and it gives the length of header filed in 32-bit words. Since its only 4 bits the size of TCP header is limited to 60 bytes. TCP Flags: There are six flag bits in TCP header; one or more of them can be set at the same time. The following are the six flags with brief description of their functionality. • URG-The Urgent Pointer is valid. • ACK-The Acknowledgement number is valid. • PSH-Push function (receiver should pass the data to application sooner) • RST-Reset • SYN-Synchronize sequence number (connection establishment)
18 • FIN-Sender has finished sending data Window Size: The TCP window size specifies the number of bytes beginning with the one indicated in the acknowledgement field that the receiver is willing to accept. Checksum: The checksum is calculated on TCP segment, This is mandatory field that must be calculated by sender and then verified by the receiver. Urgent Pointer: Urgent pointer is valid only if the URG flag is set. It’s a positive offset from the sequence number in this segment. And it points to the last byte of urgent data. Options: The TCP options are optional values in TCP header. TCP options are present at the end of the header and are multiple of 8bits in length. There are two kinds of options based on their length. • Single octet option • Options with option-kind and option-length with option data. The initial TCP RFC 793 defines three kinds of options, which are No Operation, End of Option List and Maximum segment size. Several other options are defined in the later TCP extension RFCs for adding support for new feature to TCP.
3.2
TCP Connection
TCP is connection oriented protocol and before starting the communication a connection must be established between the hosts. 3.2.1
TCP Connection Establishment
The TCP initial connection is established using the three-way handshake mechanism. This is a three-step method in which the hosts exchange SYN and ACK packets before actual communication. The three-way handshake begins with the client or the initiator sending the TCP segment with SYN flag set with initial sequence number. The intial sequence number will be generated randomly this is because to avoid the mix up of TCP segments between the different connections. The server responds with its on SYN segment which contains the initial sequence number for server and it also acknowledges the clients SYN by ACK bit set with the clients initial sequence number plus one as acknowledgement number. The client must now acknowledge the SYN received from server by ACK with acknowledgement number
19 set to servers initial sequence number plus one. This was the three-way handshake is completed and with this client and server knows each other’s initial sequence numbers. The figure 3 shows the TCP three-way handshake mechanism.
Figure 3: TCP 3-Way Handshake
3.2.2
TCP Connection Termination
The TCP connection is full duplex, which is data can be flowing in both the directions indecently. In order to terminate the connection each direction must be shutdown independently. The connection termination happens when either of the side sends TCP segment with FIN flag set. When a server receives FIN it sends back ACK with received sequence number plus one and then server sends FIN to client in order to close the server side communication. The client receives FIN from server and in same way it should acknowledge the FIN by sending the ACK with received sequence number plus one. The figure below shows the TCP connection termination mechanism.
3.3
TCP Congestion Control
TCP Congestion control is used to prevent the congestion and collapsing of the network [24, 27] and to ensure the optimal utilization of the resources (link capacity). The TCP Congestion Control is achieved by using the two basic elements of the TCP, which are Acknowledgements and Congestion Window. The TCP congestion control logic is developed based on the Adaptive Increase Multiplicative Decrease Model (AIMD). This model is helpful in probing the capacity, in this model every Acknowledgement results in the increase of maximum MSS (Maximum segment size) bytes to the congestion control window and every loss results in the reducing of congestion control window to half. The RFC 5681 [4] defines the standard TCP
20 congestion contorl algorithms. The important property of TCP congestion control is, it is sender driven, based on end-to-end acknowledgments. Control loop is end-toend, network has no other role than dropping packets (or marking them with ECN). This document specifies the four most common congestion control algorithms that are commonly used in the TCP implementations. These four algorithms are Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery. Some other concepts have been added to basic congestion control algorithm later and then became the part of original algorithm in the form of New Reno [22] algorithm. Some of these added features are Selective ACKs, Forward Acknowledgements. Additionally, there are many other congestion control algorithms have been developed for TCP. Some of them are Vegas [10], BIC [44], and Cubic [21]. 3.3.1
Slow Start
Slow start is congestion control mechanism used in TCP. This is implemented at the sender to control the amount of outstanding data transmitted in the network that is transmission rate. This is accomplished by determining the acknowledgement rate from the receiver. When a TCP connection first begins, the Slow Start algorithm initializes a congestion window to one segment, which is the maximum segment size (MSS) initialized by the receiver during the connection establishment phase. When the receiver returns acknowledgements, the congestion window increases by one segment for each acknowledgement returned. Thus, the sender can transmit the minimum of the congestion window and the advertised window of the receiver, which is called the transmission window. At some point the congestion window will become too large for the network or network conditions may change such that packets may be dropped. If Packets lost then TCP will assume the loss is becuase of network congestions. When this happens, the sender goes into congestion avoidance mode as described in the next section. 3.3.2
Congestion Avoidance
As described in the previous section, during the initial data transfer phase of the TCP connection the slow start algorithm is used. The slow start algorithm cannot be used when the congestion window is too large. When the congestion window is large then the network is overloaded and results in the packet drops and congestion. In this scenario congestion avoidance is used to slow the transmission rate. Slow start operates in conjunctions with congestion avoidance to facilitate the data transfer happening with ideal transmission rate.
21 The congestions avoidance algorithm mechanism is based on the reception of duplicate ACKs or the timer expiring. Whenever this happens it indicates the congestion in the network and during this the sender reduces transmission window to half of its current window size when the timeout happens, when it receives the duplicate ACKs then the sender invokes Fast Retransmit and Fast Recovery mechanism discussing in the upcoming sections. 3.3.3
Fast Retransmit
When a duplicate ACK is received, the sender does not know if it is because a TCP segment was lost or simply that a segment was delayed and received out of order at the receiver. If the receiver can re-order segments, it should not be long before the receiver sends the latest expected acknowledgement. Not more than one or two duplicate ACKs should be received when simple out of order conditions exist. If however more than two duplicate ACKs are received by the sender, it is a strong indication that at least one segment has been lost. The TCP sender will assume enough time has lapsed for all segments to be properly re-ordered by the fact that the receiver had enough time to send three duplicate ACKs. When three or more duplicate ACKs are received, the sender does not even wait for a retransmission timer to expire before retransmitting the segment (as indicated by the position of the duplicate ACK in the byte stream). This process is called the Fast Retransmit algorithm and was first defined in [24]. Immediately following Fast Retransmit is the Fast Recovery algorithm. 3.3.4
Fast Recovery
The sender enters to fast recovery mode immediately followed by the fast retransmit. In the fast recovery mode sender assumes that the network congestion may not exist and the lost segment was rare event, so it proceeds with congestion avoidance instead of slow start. The sender resumes transmitting with a larger window and transmits the new segments until the retransmitted segment is acknowledged this way it keeps the sufficient data under transit and prevents timout. This also results in the higher throughput under the moderate congestion [39].
3.4
TCP Options
The TCP options are optional values in TCP header and of variable length. TCP options are present at the end of the header and are multiple of 8bits in length.
22 There are two kinds of options based on their length. • Single octet option • Options with option-kind and option-length with option data. The initial TCP RFC 793 [9] defines three kinds of options, which are No Operation, End of Option List and Maximum segment size. Several other options are defined in the later TCP extension RFCs for adding support for new extensions to TCP. Most of the options are used in SYN segments and some are also in data segments. The support for an option is negotiated in SYN. The Header length field of the TCP header is 4 bit-sized field and it gives the length of header filed in 32-bit words. Since its only 4 bits the size of TCP header is limited to 60 bytes. The Header has fixed size of 20 bytes in absence of TCP options, and there is only 40 bytes room for TCP options that makes it challenging to add new options in order to implement the new extensions to the TCP. However there have been numerous proposals in order to overcome this problem, one such proposal is still in the draft phase. It proposes the extended TCP data offset option - TCP EDO option [41]. The TCP options structure is defined in RFC 793 [9]. The first byte of the option is option-kind field and the second byte is length of the option.The optionkind number is allocated by IANA. In order to use TCP options for experimental purposes there are two kinds of TCP options (253,254). This is defined in the RFC 6694 [40]. This RFC defines how to process and use the experimental options with legacy systems. Some of the commonly used options are as follows, Maximum Segment Size Option This is one of the most commonly used option, this is used to define the maximum segment size that will be used during the connection betweed two hosts. This options is used during the three way handshake mechanism by SYN and SYN/ACK segments. The length of MSS option is 4 bytes. Window Scale Option The TCP window scale options helps in expanding the TCP window size to 32 bits from 16 bits as it uses scale factor to carry this 32 bit value in the 16 bit window field of the TCP header. The window scale option can be sent in SYN segment to indicate that TCP is prepared to do both send and receive window scaling and communicate the scale factor to be applied to its receive window. The window scale option is 3 bytes long. Timestamp TCP Option The TCP timestamp option is used to measure the round -trip delivery times for various segments through out the connection life time
23 in order to adjust the various threshold values for its timers. The timestamp option must be sent during the SYN in order enable its ussage during the connection life time. The TCP timestamp option is 10bytes in length and carries two four-byte timestamp fields TSVal (Timestamp value field) and TSecr (Timestamp Echo reply field). TSVal contains the current value of timestamp clock of the TCP and TSecr is valid only when ACK is set, it echos a timestamp value that was sent by remote TCP in TSVal field of the timestamp option. SACK Option Selective Acknowledgements was introduced in RFC 1072 [9], this will solve the problem of traditional acknowledgments in TCP and makes it more robust. The problem with the plain acknowledgements is that it indicates the number of bytes till where it has received. There is no way to indicate in plain acknowledgements that it has received out of order data, that is it has received bytes through x1 to y1 while is still waiting for data through x to y, here x1>x. This makes sender to retransmit the data that is already received by the receiver. SACK solves this problem with plain acknwoledgements using SACK option. Inorder to use SACK, SACK permited option should be negotiated during SYN phase. SACK option is variable length and contains the extended acknowledgement information from the receiver to sender. SACK option contains the information about the noncontagious blocks of data that have been received by the receiver. The length of SACK options with n blocks will be 8*n+2, so if 40 bytes are availabe for options then it can have only 4 blocks of data. The timestamp option is always used with SACK option and this takes additional 10 bytes and because of this maximum blocks allowed in SACK will be 3 [35].
4 4.1
Content Aware TCP (CATCP) Introduction
CATCP (Content Aware TCP) is a new approach to content centric networking. CATCP is designed based on the concept of labeling the content with the unique data labels for each TCP flows along with the routers that are capable of caching packets, thus creating the pervasive content caching and distribution network.
CATCP Architecture overview CATCP system comprises modifications to the TCP at the sender’s side for makeing it content aware and the packet level caching functionality that will be added to the routers in the system. The CATCP system architecture is as shown in the figure 4.
Figure 4: CATCP Architecture
The CATCP sender adds TCP option to the segments header; this is done to identify the application layer content. We call this new TCP option as content
25 label TCP option. The receiver remains unaltered and uses the normal TCP for its operation. The packet caches inspect these labels added and it uses to maintain the packet level caches of the labeled content. These segment caches are then used to serve the content in the TCP connections by intercepting the TCP acknowledgements with the content request option and transmitting data from their caches in response. The content request option is added to acknowledgements by the packet caches and delivered to the original sender so as to keep track of transmission progress and to update the transmission window accordingly. The packet caches prevents the retransmission of same packete by updating the content request option. This will indicate the upstream caches that it has sent the data. The detailed CATCP operation, sender and cache operations are explained in the following sections.
4.2
CATCP Basic Operation
CATCP uses the normal end-to-end transport connection and the TCP end-toend signaling happens as per the standard TCP operation, both the end points perform the SYN/ACK three-way handshake for establishing the connection and FIN/ACK handshakes while closing the connection. The sender also receives all the acknowledgements thus the sender is aware of all the interactions and able to trace the transmission progress. The sender labels each data segment packets according to the data as specified by the application. The labeling is done using the new content label TCP option. The sender has to make sure that packet boundaries match the content label so that the cached packets can be reusable across the connections. Routers are designed to cache these labeled packets and reuse it across the TCP connections. Routers may cache all the labeled packets or subset of these packets using the label as the key for cached content. The data packet received by the receiver lead to acknowledgement sent by the receiver. The acknowledgements are exchanged end-to-end but the CATCP router will add a content request option to the acknowledgements when they are processed. If the router cache contains the labeled packets already and also contains the fitting data then the router triggers the transmission of packets from the router cache. This option is used to co-ordinate the data transmission from the router caches. This also helps in preventing the transfer of duplicate packets from the upstream router caches. This way we reduce the data transmission times and the amount of
26 traffic at the senders end. The sender is ultimately responsible for the reliability of the connection and data transmission. Sender will transmit the packets that are not cached in any of the router caches and also retransmit the packets that are lost end-to-end. Caches can operate as stateful or stateless, with the majority expected to be stateless. The stateless caches operation is simple as it just looks up for the content in its cache and sends it on behalf of the sender using the content request option in acknowledgements. If the data segment is found in its cache then it transmits it otherwise it does nothing to the acknowledgement. Stateful cache maintain the state information so as to track the TCP connection that contains the labeled content, so they map the TCP acknowledgements numbers to the content labels and offsets. Stateful caches can also lookup for the next transmission packet from it cache and transmit it on behalf of the original sender. Stateful caches are also responsible for adding the content request option to TCP acknowledgements that pass upstream. Caches upstream of a controlling node can be stateless, so it is desirable that either the receiver or the first hop router on the reverse path back to the source act as the controlling node. Also, note that there can be only one controlling node (whether a receiver or controlling cache) on each reverse path from receiver to sender. Figure 4 illustrates the scenario where the first hop router is acting as a stateful cache and controlling node i.e., a controlling node is responsible for adding content request option, and the receiver is sending unmodified TCP acknowledgments.
Figure 5: CATCP Operation
27 Figure 5 shows the CATCP operation with an example. In this example receiver A is fetching a HTTP resource. While fetching the HTTP resource the client would initiate TCP three-way handshake to establish the connection first and then it sends the HTTP GET request to the server to fetch the data. The server would accept the connection and request to send the response with headers and data, which is unlabeled. Then the server sends the response data by labeling it with the content label TCP option. The content label can be changed in middle of the connection if the requested resource changes. The upstream routers will cache the labeled packets and the unlabeled packets will not be cached. The figure illustrates the phases of cacheable content and non-cacheable content. The grey areas indicate its the cacheable content and the white areas indicate its non-cacheable content. In the figure 5 the small white circle at the cache indicates that flow state is initialized for the first packet with newly labeled content label in a flow, black circles indicates that the labeled packets are being cached. Figure 5 shows how CATCP benefits the receiver B, in this receiver B makes the GET request for the content that is already cached in the router cache. The white circle indicates the flow table is initialized and when the router processes the acknowledgements for that flow it transmits the next data segments from the cache and forwards the acknowledgements to the sender. The figure 2 also shows that all the control packets during the connection establishment (three-way handshake) and the connection closing messages (SYN/ACK/FIN) travel end-to-end.
4.3
CATCP Sender Operation
In order to implement the CATCP to the standard TCP sender it requires very minimal changes to it. The basic TCP operation remains unchanged, the difference occurs only when the application specifies content-label option. When the application specifies content label option, the sender includes this content label option in the headers of the data segments before transmission and also the sender will be in consistent segmentation mode, where in sender tries to achieve consistent segmentation. Sender also processes the incoming acknowledgments slightly differently then the standard operation. (The sender operation and design is out of scope with this work, the section provides just basic details about its operation and implementation)
28
Figure 6: Content Label Option 4.3.1
Content Labelling
The figure 6 shows the Content label option. Sender inserts this content label option to each data segment before transmission. The content label option identifies the application content segment, the content label option contains the offset field which indicates the part of the application data being transmitted. content offset is the offset in terms of bytes from the begning of the application data.The caches store these data segments based on the content label and content offset, this section 5 discusses the complete cache implementation or CATCP. The TCP Socket API is modified in order to provide the APIs for the application to choose content label. APIs are also provided to set the initial offset, if no offset is specified then its assumed to be zero. The content label option will be added to all the data segments before transmission until the application specifies the end of transmission of that content asociated with the content label, application can also change the content label and offset during the transmission if necessary. The addition of Content label header option will not affect the operation of receiving application. The receiving application is unaware of this header option and therefore unaware of the content labels and also whether the origin of the data segments, which can be segment cache or the sender. 4.3.2
Acknowledgement Processing
The CATCP enabled sender is capable of processing the acknowledgements with content request option. The content request option is showed in the figure 7. If the next sequence number field in the content request option is greater then the next
29
Figure 7: Content Request Option sequence number to be transmitted by the sender, then next sequence number to be sent is updated based on the content request option. This happens because of the intermediate segment caches on the transmission path has transmitted data on behalf of the sender, hence CATCP sender should not send the data that has been already served by the intermediate segment caches. The congestion control mechanism is based on the CS (CanSend) value in the content request option. This field indicates the number of packets that sender has to send; this field takes in account the number of packets that are sent by intermediate segment caches. If the intermediate caches send the data segments, then the CS field can be reduced to 0 and sender need not send any packets at all even if congestion window allows to send. If the sender receives three consecutive duplicate ACKs, or if the retransmission timeout occurs, then the sender behaves normal and it transmits the first unacknowledged segment. The sender maintains the segment boundaries when retransmitting the data to improve the cache performance. The estimation of RTT is worse in CATCP, because RTT samples calculated for the packets that are send by a cache are always lesser than the RTT at TCP seder. 4.3.3
Segmentation
Segmentation plays very important role in the efficient operation of CATCP. Consistent segment size for different connections is essential for the CATCP segment caches to be useful. If the segment sizes or boundaries vary between the connection which are delivering the same content, then the labeled content requests will miss the cached data from the CATCP router segment caches, therefore the sender must segment the application data according to the pre negotiated size and also the sender
30 should ensure to apply consistent segmentation to multiple flows transporting the same application content. Inconsistent segmentation is inefficient, but does not cause misbehavior of CATCP or malformed data. This is an important property because ensuring consistent segmentation is, in general, impossible with TCP. Even though the requirement of consistent segmentation is not a perfect fit with the traditional TCPs semantics of not preserving packet boundaries, it is possible to introduce an API method to request a specific segment size to be used, where possible, across different connections using labeled data, or configure a default segment size to be used with CATCP.
5
Content Aware TCP Router Modelling
5.1
CATCP Router Operation:
In this section we present the detailed design of the CATCP router and its operations. CATCP router can be configured to be controlling nodes or segment caches to handle the CATCP cache related operations, we present the details about CATCP router operations, stateful and stateless cache operations, cache operations such as insertion and retrieval of data segments. 5.1.1
Controlling Nodes
A controlling node is a main entity in CATCP architecture. Controlling nodes monitors the ACKs for content request option. It processes normal TCP ACK and appends Content Request option if needed. The controlling node is logically separate entity from the segment cache but can co-exist with segment caches. The controlling node functionality can be added to a TCP receiver also. The functioning of segment cache is based on the Content request option, and hence this has to be added before the ACK reaches segment caches, and hence the controlling node must be close to the receiver. The controller has to maintain per-flow information state, this way it has enough information to process the incoming ACKs. The controlling node maintains the flow specific information in a data structure called flow table. The flow table contains following data for each active TCP connection. • A four-tuple identification for the flow - Source and Destination IP address and port numbers. • Content Label - Content label of the current TCP Connection flow. • Content Offset - The TCP sequence number of the currently transmitted data segment. • Content Next - The next transmitted content byte in the connection, relative to the beginning of the content in transmission. • Congestion control state
32 The flow table is initialized when a TCP SYN packet with CATCP enabled option arrives. It creates new flow table entry using the source and destination IP address and port numbers. When a TCP data segment with Content Label option arrives at the controller and if the controller has its flow state initialized, then the controller stores the currently transmitted content label if its different from the earlier stored content label. The controller also stores (or verifies) the TCP sequence number at the start of the content to the flow table (Content Offset). Content Offset is calculated by subtracting the Offset field at the Content Label option (Option Offset) from the TCP sequence number in the current segment. This information is needed to build correct Content Request options for TCP acknowledgments for the same TCP flow. If Option Offset + TCP Length (the length of TCP segment payload) is higher than Content Next in the local flow table, the controller sets Content Next to Option Offset + TCP Length. Note that for a correctly working connection, the difference between offset and TCP sequence number should not change during the transmission of the content. 5.1.2
Segment Caches
A CATCP stateless segment cache only processes the TCP segments that contain a content label option, and to acknowledgments that include a content request TCP option. When the segment cache receives a packet containing content label option, it simply stores the TCP payload in the cache, with the content label and content offset used as the key to lookup for the content for the cache. When a segment cache receives a TCP acknowledgment with a content request option, a stateless cache first checks if the CS value in the option. If the field is zero, the cache simply ignores the option and passes the acknowledgment towards the TCP sender. If the CS value is positive, the cache uses the content label and the next sequence field in the option to check if it has the next segment in its own cache. The segment cache is not allowed to send segments out of order, so it only responds to the acknowledgment if it has the next segment. Segment cache are allowed to send more that one segment from its cache depening on the value of CS field in content request option. If the segment cache finds the segment in its cache, then the segment cache constructs a TCP header for sending the found segment to the receiver. It has all the necessary information in the incoming acknowledgment: the four-tuple can just be reversed, and the correct TCP sequence number is in the content request option. The segment cache sets the acknowledgment flag and sequence number. With this information, the segment will be a valid segment at the receiver.
33 If the segment cache sent data in response to an acknowledgment, it modifies the content request option in that acknowledgment, before sending it further upstream towards the sender. The cache increases the next sequence field in the content request option based on the amount of data it sent, so that the field points to the first unsent content sequence. The cache also reduces the value of CS by the number of segments it transmitted in response to the acknowledgment. This ensures that no more segments are transmitted than what was decided by the controlling node’s congestion control algorithm. If the segment cache or flow table becomes full, the cache must decide how to manage the available resources. segment caches implement simple cache replacement algorithms such as least recently used or least frequently used which we presented in section 2.3.2. Having segments from the same CATCP connection scattered over large number of different caches may increase the likelihood of reordering because the propagation delays for cached segments will then differ. Therefore, caching decisions, and decisions to remove data from the cache should be made on larger blocks of data rather than per-segment, to increase the probability that a cache would contain larger consecutive blocks of data and, consequently, the likelihood of reordering could be reduced. 5.1.3
Cache Operations
This section explains the different cache operations in CATCP in detail. We are going to present the cache operations such as Intiatlization and Updating flow, Packet Insertion and Retreival from the cache. Flow Intialization In CATCP controlling nodes are reponsible for maintain the per-flow information state in order to process incoming ACKs as discussed in the section 5.1.1, The state inofmration per-flow is maintained in the data structure called flow table. When a packet with CATCP content label option arrives on the controlling node, If its the first packet with the give content label in a TCP flow, The controlling node stores four tuple identifying the flow along with current content label in the flow table. The controlling node also stores the packet’s TCP sequence number to be able to determine the content offset in subsequent TCP segments and acknowledgements. The controlling node also initializes the next content sequence field with the content sequence that would follow the current TCP segment. and the last content acknowledgment field to 0. If the content label changes, i.e., transmission of a new content object starts, the content label for the flow is set accordingly,
34 and the sequence number and acknowledgment fields are re-initialized.
Figure 8: CATCP Router priming/updating for a flow
Packet Caching In CATCP packet are cached in segment caches, segment caches is a logical entitiy and can be co-located with controling nodes. When a packet comes to with CATCP content label option it will be cached by the segment caches. The caching hapens as shown in the figure 9.
Figure 9: CATCP Packet Insertion (caching)
Packet Retreival Figure 10 shows the packet retreival procedure in CATCP. Packet retreival happens when an acknowledegment comes to the router and the if there is a matching four tuple information in its flow table or with the CATCP content request option. If the matching four-tuple is not found in the flow table then the packet is forwarded without any action. If the four-tuple matches the flow
35 table entry and the CATCP content request option is not present then the router performs the following operations. The controlling node updates the lastack received based on the acknowledgement number in the packet header and it caclulates new congestion window as discussed in the section 6.3.4. Then it calculates the packets-allowed which is CanSend value. If the CanSend is positive value then the router uses content label and next sequence to determint the packet to transmit from its cache. If it find the packet in its cache then it builds a new packet using the information in the recent acknowledgment and in the flow table to build the TCP and IP headers, with the CATCP content label option to assist the downstream routers. The router uses the IP address and port of the original sender as the source address. The router then decrements CanSend by one and updates nextseq based on the highest sequence number transmitted . This procedure is then repeated from, until CanSend reduces to 0, or the next packet cannot be found in the cache.
Figure 10: CATCP Packet Retrieval When an CATCP router receives an acknowledgment that was previously processed by a downstream CATCP router, and therefore has the CATCP content request option, it follows the above procedure with the following small exceptions, before evaluating what data to send, the router updates the nextseq field based on the information from the arriving CATCP content request option, if the incoming value is larger than currently stored. The router makes use of CanSend parameter from the CATCP content request option together with the receive window to determine how many packets can be sent from the local cache. This leads to conservative behavior: the local transmission rate never exceeds a smaller congestion window on a downstream router. When an incoming acknowledgement contains CATCP con-
36 tent request option, the router can only send data from the point indicated by the nextseq field in the option, in other words, the router that first inserted the CATCP content request option has the control over which packets are sent. Otherwise multiple stateful CATCP router might be sending same packets in parallel. If a router sends data packets in response to a packet with CATCP content request option, it reduces the CanSend field in the option by the number of packets sent, and updates the nextseq field accordingly, before passing the acknowledgment towards the TCP sender. Building the TCP and IP headers based on an incoming acknowledgment and the information in flow table is fairly straight-forward. Choosing the value for receiver’s advertised window is a bit more problematic because the router cannot know the buffer state at the end host. Since flow state gets established by a labeled data packet, the router remembers the last value seen from the sender and uses it when creating data packets. If an CATCP content request option is present in a packet, a router knows that there is another downstream router that is CATCP aware and is tracking the flow state for the TCP connection. This allows for the router to drop its own flow state, and send cached packets just based on information in incoming acknowledgments. This requires that a valid TCP sequence number is also carried with the acknowledgments, so that the router is able to compose a valid TCP segment that hits the expected receive window.
5.2
Receiver Operation
Legacy receivers can operate with CATCP and does no need any changes. What is important from an CATCP perspective is that they ignore unknown TCP options and just process the data contained in the packet. The legacy receivers carry out their normal operation, and may implement different flavors of TCP: they may acknowledge every or every other packet, continuously update the receive window, possibly applying window scaling, and use different TCP options, such as timestamps or selective acknowledgments. However, the CATCP sender may choose to disable some of these options during the initial negotiation, to save in the precious TCP option space also needed for CATCP to operate. TCP receiver implementations may be sensitive to significant packet reordering and may perform other sanity checks before accepting data. Therefore, CATCP is designed to maintain ordered segment transmission as much as possible.
37
6
Simulations and Result Evaluation
We have implemented the CATCP router in NS-3 and the sender side TCP changes are implemented in the Linux Kernel 2.6.26 that is the latest version of Linux supported by Network Simulation Cradle. We have also implemented the sender in Linux kernel version 3.0.9 for the actual kernel implementation. The sender implementation is out scope for this thesis and in this section we discuss more about the NS-3 implementation of CATCP router, we also present the CATCP implementation for NS-Click. This section also presents the various simulation scenarios and results to evaluate the operations of CATCP.
6.1
Network Simulator 3 (NS-3)
NS-3 [2] is an open source discrete event simulator mainly used in network research and education to simulate the Internet based systems. The NS-3 is the follow-up project of the popular NS-2 [1] simulator. Unlike NS-2, NS-3 is written entirely in C++. User code, Protocols and Scenarios are written in C++. NS-3 is popular in research of Internet based systems because, • NS-3 models true IP stack with multiple devices and IP addresses on every node. • Event based sockets API • Packets include serialized bytes of data along with tags and metadata for easy extension and tracing. • It supports animation of network simulations. • Tracing, logging and computing statistics on the simulation object is supported. The NS-3 simulation architecture looks just like IP architecture stack as shown in the figure 11.
38
Figure 11: NS-3 Architecture The primary simulation objects in NS-3 related to sending and receiving packets is depicted in the above architecture figure 11 are, Node Node object is the main component of NS-3 and it is a base class. It may or may not have mobility and other traits. Node class in NS-3 contains a list of Net devices and a list of applications. NS-3. We can create our own node implementation by extending the node class and NS-3 provides few node implementations too such as InternetNode etc. NetDevice and Channel NetDevice represents physical interface on the node for example Ethernet Interface, etc. Channel is closely coupled with NetDevices. The packets passing in outbound direction from NetDevice call the Send() which forwards the packet and the incoming packets will call the registered callback receiveCallback. Packets will be handed over to higher layer after NetDevice does the processing. Packet NS-3 Packet objects contain a buffer of bytes: protocol headers and trailers are serialized in this buffer of bytes using user provided serialization and deserialization routines. The content of this byte buffer is expected to match bit-for-bit the content of a real packet on a real network implementing the protocol of interest. Fragmentation and defragmentation is possible since we have a buffer of real bytes, we can split it in multiple fragments and re-assemble these fragments. Memory management of Packet objects is entirely automatic and extremely efficient, memory for
39 the application-level payload can be modeled by a virtual buffer of zero-filled bytes for which memory is never allocated unless explicitly requested by the user or unless the packet is fragmented. Header related operations such as copying, adding, and removing headers or trailers to a packet have been optimized to be virtually free through a technique known as Copy On Write. Sockets and Applications Applications are user-defined processes that generate traffic to send across the networks to be simulated. NS-3 provides a framework for developing different types of applications that have different traffic patterns. The Application base class allows one to define new traffic generation patterns via inheritance from this class. Then one simply creates the application and associates it with a node, and the application will send traffic down the protocol stack. The way that applications on a node communicate with the node’s protocol stack is via sockets.
Figure 12: Send Packet Processing The socket attempts to mimic the standard BSD socket API. The major differ-
40 ence in the implementation is that while BSD socket calls are synchronous the ns-3 socket API calls return immediately. The following figure 12 show the send and receive packet-processing chain of events in case of InternetNode.
6.2
Network Simulation Cradle
The Network Simulation Cradle (NSC) is a framework that allows real world TCP/IP network stacks to be used inside a network simulator. NSC was original developed for NS-2 and the support for NS-3 is now available. The main reason why NSC was developed is to produce the simulation results closer to the real world networks. The current version of Linux kernel that is supported by NSC with NS-3 is 2.6.26. The NS-3 integration of NSC is depicted in the figure below.
6.3 6.3.1
Basic Simulation and Result Basic Behavior
This simulation to test the basic behavior is simple and it follows the scenario with 2-15 receivers sharing 3Mbps bottleneck link with 10ms delay for 625 KB transfer. We have done this simulation in two different ways based on the starting time of flow transfer. In the first scenario the flows start at 1-second interval, which is the ideal scenario and in the second all the transfer flows start at the same time. In case of first scenario the packets for the first flow are transmitted by the TCP sender and they will get stored in the CATCP cache. The following flows that start in subsequent one second intervals will benefit from cached packets and this results in fewer packet transmission from the sender. This is represented in the figure 13. In case of the second scenario the packets transmission for all the flows starts at the same time and the results shows that CATCP is less effective as shown in the figure 14. The reasons for this will be explained in the following subsections. 6.3.2
Timing Issues with Simultaneous flows
In CATCP the TCP acknowledgment triggers the transmission of new segments from the cache only if those segments are stored in the cache because of their presence in the earlier flows. The TCP flows that are starting at same time or slightly later that the first flow may not benefit from the CATCP caching. Consider a scenario where two senders are transmitting same data nearly at same time, in this scenario
●
●
●
●
●
●
●
●
●
●
●
●
●
normal CATCP
100
300
●
●
0
Packets sent / receiver
500
41
2
4
6
8
10
12
14
Number of receivers
●
●
●
●
●
●
●
●
●
●
●
●
●
normal CATCP
100
300
●
●
0
Packets sent / receiver
500
Figure 13: Mean number of packets transmitted per flow (starts with 1sec Interaval)
2
4
6
8
10
12
14
Number of receivers
Figure 14: Mean number of packets transmitted per flow (simultaneous) when ACK for the second flow arrives at the cache the next packet from the first flow is not yet available and thus needs to be transmitted by the original sender but not from the cache. If these two flows continues in the same pace then both senders end up transmitting most of the data despite of the availability of the CATCP.
42 Figure 13 illustrates the timing and synchronization problem with two CATCP flows for the same content that start one second apart. The sender transmits the first flow because the data has not yet been cached. The second flow benefits from the cached segments and the receiver receive data at higher rate due to short roundtrip time and fast connection between the CATCP cache and the receiver. Before the end of the transmission, the second flow has caught up the first one, and the flows proceed at synchronized rate until the end of the transmission, suffering from the synchronization problem described above. 6.3.3
Congestion
A naive implementation of segment cache would send either one or two packets for every incoming TCP acknowledgment. Sending one packet would effectively allow only one or few packets to be in flight at a time, it depends on the initial congestion window at the sender. This would be very ineffective use of the available network capacity. Sending two packets for every incoming acknowledgment would be similar to TCP slow start. This in turn, unavoidably would congest the downstream, if the outgoing flow is long enough. Therefore some reactive rate control algorithm is needed at the segment cache, such as the scheme adapted from TCP’s congestion avoidance that we will describe in the improvements section. 6.3.4
Improvements to CATCP
This section describes enhancements implemented on CATCP segment cache in order to overcome the limitations discussed in the earlier section. Avoiding Duplicate Packets The timing issue discussed in the earlier section can be resolved by monitoring the packet flow. If the packet flow has recently sent a packet and has an outstanding acknowledgement, then delaying the packets in subsequent flows carrying the same packets so that the caches can be primed. This helps the subsequent flows to be served from the content caches. We call this mitigation as CATCP-Nagle as its similar to TCP’s Nagle algorithm. One of the limitation of the CATCP-Nagle algorithm is the RTT measurement, the round-trip time between the cache and the receiver is often significantly shorter than the roundtrip time between the sender and the receiver, the later flows that can be served by the cache may eventually ”catch up” the first flow, in which case the cache again does not have new data to transmit for the other flows. Content Nagle cannot speed up the transmission of the flow, but reduces the number of redundant packets.
43 The CATCP-Nagle at the sender is a way to address the problems with flow synchronization. The problem with flow synchronization can be mitigated in other ways too at the CATCP cache. We call this as Delayed ACK forwarding strategy. A cache could delay forwarding of the acknowledgments of subsequent flows by at most roughly one RTT, in hopes of receiving the next packet from the initial flow in the meantime. If the next packet arrives while holding the acknowledgment, it will be sent in addition to the original receiver to the receiver(s) that had acknowledgments requesting the same content sequence on hold. After this the delayed acknowledgments can be passed on the sender. The maximum time for delaying acknowledgments should be bounded with timer to enough short value so that it does not cause a retransmission timeout at the sender. This approach could be seen as a short-term subscription for the next packet, similar to some proposed content-centric architectures, and can be expected to be more efficient than CATCP-Nagle at the sender, for the price of requiring some additional implementation complexity at the cache. This way CATCP can approach the efficiency of multicast communication without requiring IP multicast support: There are separate TCP flows to each receiver, but in ideal case the sender needs to send a data packet only once regardless of the number of receivers, if just there is a downstream cache replicating the data. Congestion Control In CATCP controlling cache we have implemented a basic congestion control algorithm to follow TCP friendly behavior on packet losses. Our algorithm is a simplified version of TCP congestion avoidance: for each flow, the controlling cache maintains a congestion window (cwnd) that determines how many packets can be in flight at a time between the cache and the receiver. The controlling cache also maintains the number of unacknowledged packets (flightsize) between the cache and the receiver, that it compares against the congestion window. For incoming acknowledgment the cache calculates packets allowed = min(max(0, cwnd - flightsize), 2) to determine the maximum number of packets that can be sent out. After sending the data, the cache decrements the actual number of packets sent from packets-allowed, and places the result in the CanSend field of outgoing content request option in the TCP acknowledgment. If the CanSend field is positive, upstream stateless caches or the CATCP sender can send subsequent data if available. The congestion window is initialized to three packets in the beginning of the connection, and each incoming acknowledgment that advances the window increases the window by cwnd = cwnd + 1/cwnd , i.e., implementing the standard
44 window increment in TCP congestion avoidance. If there are three consecutive duplicate acknowledgments, the congestion window is reduced to flightsize/2. This is done only once per transmission window. Our simplified congestion avoidance algorithm does not maintain timers nor implements TCP’s slow start, but we believe it to be sufficiently close to normal TCP’s friendly behavior. Even though the above algorithm is quite simple and conservative, it turns out to perform quite well, as illustrated in the following sections.
6.4 6.4.1
Simulation Results Simulation Scenarios and Simulation Parameters
The CATCP behavior is demonstrated using three sets of simulations in this section. The first simulation focuses on the effects of load on a shared bottleneck link on CATCP performance. In the second simulation we study the effect of CATCP on the other flows that are using normal TCP. In the third and final simulations we investigate the effect of caching a portion of TCP segments in a single flow in order to investigate the effect of variable round-trip times on CATCP transfers. In our analysis we use two simulation topologies, for the initial validation we use simple bottleneck topology. In this topology the senders are connected to the receivers via a 3 Mbps bottleneck link with 10ms transmission delay and there is a CATCP segment cache at each end of the bottleneck link. The second topology is used to analyze CATCP on a larger scale. It consists of 1-7 network segments, each segment with 1-7 hosts receiving data. This results up to 49 receivers. The data source is connected to the gateway using 3Mbps bottleneck link with 20ms transmission delay. The other network segments use a 100 Mbps Ethernet links. All our tests analyze three different variants of CATCP they are, • Basic CATCP Operation • CATCP Nagle • CATCP Delayed Ack We compare the performance of the above three variants to that of the regular Linux TCP implementation. All our simulations use CATCP and Linux CATCP implemented in NS-3.9 and network simulation cradle.
45 6.4.2
Effect of Network Load on a Shared Link
In order to evaluate the CATCP effect of network load on the shared link we perform this evaluation under varying load. We use 1-49 receivers fetching data from the single sender. The sender is sharing the common bottleneck link as described in the previous section. 625 KB data transfer flows will be starting at random times within a one second window. This will be like simultaneous clients downloading popular content over Internet. The test is repeated several times and the average of the results are shown in the figure. The figure 15 shows the number of segments transmitted by the normal TCP and various variants of CATCP. With the normal TCP the total number of segments transmitted grows linearly with the number of receivers where as in the CATCP flows, the number of segments transmitted grows sub linearly. In this case CATCP clearly shows that it can support more number of receivers with only modest increase in the number of transmitted segments. This demonstrates that segment caching works as desired to reduce the load for near simultaneous flows. The figure 15 also shows that the Delayed-Ack variant of CATCP is effective at avoiding near-simultaneous transmissions of the same data, and will generate slightly fewer segments than the other CATCP variants. The differences between the CATCP variants discussed in the earlier section are highlighted in Figure 16. This shows the number of segments lost at the bottleneck link between the sender and the first router. This figure also shows that Delayed-Ack variant of CATCP is more effective in avoiding the packet losses the Nagle variant; both beat basic CATCP and standard TCP. Using segment caches is seen to avoid unnecessary retransmission of data segments. Figure 17 shows the impact of the choice of CATCP variant on the average flow completion time for a 625 KB transfer. With 49 receivers, the last normal TCP flows were completed 108 seconds after they were started, because of the heavy congestion on the bottleneck link, where as CATCP flows take about 10 seconds to complete. 6.4.3
Effect of Congestion Control
We illustrate the effect of congestion control in the segment cache, described in earlier, on the bottleneck link load. To increase the stress on the links downstream from segment caches, for these tests we downgraded the bandwidth of Ethernet links to 10 Mbps, and reduced the window of flow starting times to 200 ms. with these parameters, we start to observe congestion also with CATCP, unless the congestion control algorithm is implemented at the segment caches. Figure 18 shows the mean
46
20000
●
●
normal CATCP CATCP−Nagle CATCP−DelAck
● ●
● ● ● ●
10000
Packets
15000
●
● ● ● ● ●
5000
● ● ● ● ● ● ● ● ● ● ●
0
●
0
10
20
30
40
50
Number of receivers
Figure 15: Effect of Network Load on a Shared Link (Segements Transmitted) ˜ completion times with the naA¯ve rate control variant of CATCP that sends at most two packets out from the segment caches for each incoming acknowledgment that advances the window. The graph shows that under high load the performance starts to deteriorate in this case. On the other hand, as Figure 19 shows, adding congestion avoidance to segment caches helps to avoid this effect, causing CATCP to behave steadily with all its variants. These results along with load evaluation results demonstrate that CATCP is highly effective at reducing load on a shared link subject to near simultaneous flows, leading to reduced download completion times. This protocol-independent ability to scale under load has potential importance for dealing with flash crowd effects and delivery of popular live content. 6.4.4
Effect on Regular TCP cross traffic
We analyze the effect of CATCP on regular TCP traffic transmitted at the same time. For this we use simulation scenario 1 described in earlier section, with up to 15 receivers sharing the bottleneck link. Receivers are tested with each of the CATCP
4000
47
normal CATCP CATCP−Nagle CATCP−DelAck
●
●
2000
● ●
● ●
1000
Packet losses
3000
●
● ● ●
●
● ●
●
●
●
0
● ● ● ● ● ● ● ● ● ●
0
10
20
30
40
50
Number of receivers
Figure 16: Effect of Network Load on a Shared Link (Segments Lost) variants, and with regular TCP. In addition, three regular TCP flows provide cross traffic. All flows start simultaneously. Figure 20 shows the completion times of the cross traffic TCP flows. When all flows use regular TCP, the completion times increase with the number of flows. On the other hand, when other flows use CATCP, also the regular flows perform well, nearly unaffected by the number of CATCP flows. 6.4.5
Effect of caching performance
When a segment cache has limited capacity, cache misses must be serviced from upstream caches or the CATCP sender. This leads to variation in the round-trip time, and potential reordering, which is known to be harmful for TCP. In this section, we evaluate how partial caching affects CATCP performance. To do this, we vary the probability that packets are cached from 100 percent down to 0 percent, and simulate how this affects the sender behavior. In this test, we assume a topology of 1-5 intermediate segment caches between sender and receiver, connected with 3 Mbps links having 10 ms propagation delay. We assume that an
48
50
●
●
normal CATCP CATCP−Nagle CATCP−DelAck
● ● ●
30
● ● ● ● ● ●
20
Completion time (s)
40
●
●
● ● ● ●
10
● ●
●
● ●
●
●
0
●
0
10
20
30
40
50
Number of receivers
Figure 17: Effect of Load on a Shared Link (Completion Time) initial flow has primed the caches, and illustrate the performance of a subsequent flow. 21 shows the effect of this change. In this figure, the horizontal axis shows the probability with which a cache stores an incoming packet. The dotted horizontal line marks the number of packets sent when the caching probability is set to 0 percent, i.e., when nothing is cached and all data flows end-to-end from the CATCP sender to the receiver. Figure 21 shows the effect of varying the number of consecutive segments that are cached. In the first set of tests, the caching decision is made separately for each segment (state len = 1); in the other tests it is made once every N segments, causing longer consecutive blocks of data to appear in cache. The longer consecutive blocks can be expected to lead to more stable TCP behavior, and this expectation is supported by the simulation results. Figure 22 shows the effect of number of caches on the packets that need to be transmitted by the TCP sender. As one might expect, a topology with more caches between sender and receiver reduces the load from TCP sender, irrespective of the fraction of packets cached.
49
●
50
● ●
normal CATCP CATCP−Nagle CATCP−DelAck
40 30
● ● ● ●
●
●
● ●
20
●
●
●
10
Completion time (s)
●
●
●
●
●
●
●
●
●
●
0
●
0
10
20
30
40
50
Number of receivers
50
Figure 18: Mean flow completion time without congestion control
●
40 30
● ● ●
●
● ●
20
● ●
● ●
●
10
Completion time (s)
●
normal CATCP CATCP−Nagle CATCP−DelAck
●
●
●
●
●
●
●
0
●
●
●
●
0
10
20
30
40
50
Number of receivers
Figure 19: Mean flow completion time with congestion control Figure 23 compares the number of segments received for varying caching probabilities. We observe that some duplicates are received when the fraction of packets cached is less than 100 percent. Packet reordering due to the varying RTT between receiver and the different caches causes this, which triggers duplicate acknowledgments and occasional unnecessary retransmissions at the TCP sender. This problem
30
●
normal CATCP CATCP−Nagle CATCP−DelAck
● ●
●
●
●
20
●
●
●
●
●
10
●
● ● ●
0
Completion time / receiver
40
50
2
4
6
8
10
12
14
Number of receivers
Figure 20: Mean flow completion time (TCP and CATCP) gets worse with more caches, i.e., more potential sources of reordering, but is not serious with high cache hit rates.
6.5
Experimental Results
In order to demonstrate the feasibility of a CATCP segment cache implmentation and the interoperability with the unmodified receivers we have implemented a controling node with segment cache. This CATCP bridge performs the layer 2 forwarding of Eternet frames between any number of interfaces using static level 3 routing table. This experiment mainly focuses on the functionality and does not do any peroformance optimizations. The testbed experiments were run by my thesis instructor and we are using this results in thesis as its very useful and relevant in this context. The testbed setup of CATCP bridge is written in C, runs on Linux. It makes use of packet sockets to capture and forward the packets and to send cached packets. It supports delayed ACK forwarding and a simple version of congestion control using cwin = 1. Internally, catcp-bridge tracks objects (resources), flows, and packets,
51
●
●
●
●
100 150 200
●
●
● ●
●
0
●
●
50
Packets sent
● ●
State len: 1 State len: 5 State len: 10 State len: 15
●
1.0
0.8
0.6
0.4
0.2
0.0
Caching probability
100 150 200
● ●
● ●
● ●
● ● ● ●
0
●
●
●
50
Packets sent
Figure 21: Effects of Cache Probability on packets transmitted for different state length
1 cache 2 caches 3 caches 4 caches 5 caches
●
1.0
0.8
0.6
0.4
0.2
0.0
Caching probability
Figure 22: Effects of Cache Probability on packets transmitted for different number of packet caches with a fixed pool of memory for each allocated at startup. The data structures allow implementing diverse purging policies; we use LRU for objects, packets, and flows at present. The catcp-bridge also supoprts a passthrough mode (CATCP
●
●
●
●
●
●
●
●
● ● ●
●
150
250
● ●
0 50
Packets received
350
52
1.0
0.8
0.6
0.4
0.2
1 cache 2 caches 3 caches 4 caches 5 caches 0.0
Caching probability
Figure 23: Effects of Cache Probability on packets received from cache for different number of packet caches operation disabled), with optional configurable packet delays. As a CATCP server, we use a modified open source web server, lighttpd v1.4.18. We assume static, browser independent, objects and use the first 8 bytes of an MD5 hash over the request URI as the content label. The chunk-based write queue of lighttpd makes it easy to add identifiable labels at the right positions into the data stream, and initiate the corresponding control commands accordingly. We only label responses with content larger than 8 kB as per our above observations. To support accessing resources on arbitrary web servers on the Internet, we also built a small proxy, cahttp, that adds labels around content fetched from the web (mainly used for proof-of-concept). Our experimental testbed comprises four Dell R410 rackmount servers (catcp[1-4]) each with six gigabit Ethernet interfaces, running Ubuntu Linux with a 2.6.35 kernel. We run six catcp-bridge instances on these boxes configured via a VLAN switch as shown in Figure 24 This allows us to create topologies with individual nodes, or with chains and trees of segment caches. Node catcp-1 serves as the client, and runs standard TCP receivers. Node catcp-4 hosts a virtual box, named catcpserver, running Linux with our CATCP extensions; it serves as the CATCP sender and runs lighttpd and cahttp. We provision lighttpd with a local data base of 1,000 files, their sizes between 1 kB and 256 kB following a Zipf distribution, binned to 4, 8, 16, ... kB. We also run the catcp-proxy on the virtual box to access arbitrary
53
catcp-‐ server (VM)
lighEpd
0
cahEp 4
1
IE
US
SG
Amazon
BR
2
catcp-‐bridge F
catcp-‐4
1
catcp-‐3
catcp-‐1
5
Internet
3
1
3
catcp-‐bridge D
catcp-‐bridge E
2
catcp-‐2
Linux NAT
4
0
2
4
0
catcp-‐bridge A
catcp-‐bridge B
catcp-‐bridge C
1
3
5
1
3
5
wget A1…n
wget B1…n
5
Home
2
wget C1…n wget E1…n
n Ethernet Interface ethn
Figure 24: Experimental lab setup. web servers and label their resources. Interface 4 of the catcp-server has four IP addresses so that simple host routes on the clients, paired with routing entries for all six bridges, are sufficient to direct traffic across the different paths indicated in the figure. Host routes are also configured to reach selected hosts in the Internet and the Amazon EC2 cloud via a NAT running on node catcp-3. With our testbed setup we did following tests to check the CATCP in various scenarios such as Interoperability, with perfect caching and bulk resource retreival. The following subsections talks more about these scenarios. 6.5.1
Interoperability
To validate the basic functionality and interoperability, we connect an Internet router to the VLAN connecting two interfaces of nodes catcp-3 and catcp-4. We issue requests from web browsers on different mobile devices to retrieve web pages and documents stored on the lighttpd server via catcp-bridge F. These experiments confirm that our use of TCP options does not impact interoperability across the operating systems we tried: MacOS X , Debian and Ubuntu Linux, Microsoft Windows
54
1.4 1.2
Uplink Downlink
ACKs Server data
Cached data
1 0.8 0.6 0.4 0.2 0 Plain TCP CATCP no delay 10ms delay
200ms delay
Normalized share of different packets
Data volume relative to TCP
2012-01-24-lab-0s-20rcv-64KB-10ms-packets.log.data
Transport Protocol Variant (TCP vs. CATCP)
Figure 25: Experimental Results with 20 receivers, 64 KB, 10ms one-way delay 7. The catcp-bridge complements the data provided by the server, sender segments from its cache to the clients as appropriate. 6.5.2
Perfect caching
We performed several experiments to understand the maximum performance that can be achieved when retrieving a given resource in practice. These experiments comprised a single catcp-bridge instance, through which a number of clients connect to three different types of target. The targets, each running our modified lighttpd, were: 1) the catcp-server, accessed via bridges A, D, and F, with bridges D and F in pass-through mode, bridge F also adding a one-way delay of either 0, 10, or 100 ms, files retrieved using wget Ai. We run a series of ten measurements each target, retrieving resources of 64 KB and 256 KB in size using plain TCP, CATCP without delayed ACKs, and CATCP with 10ms and 200ms ACK delays. We run 1, 5, 10, 20, and 50 clients started either in parallel, or with 1 s intervals between each pair. We use tcpdump to log packets at the interfaces towards the server (uplink) and towards the client(s) (downlink) of the appropriate bridge. Figure 25, 26 and 27 shows selected results of these measurements for all clients started simultaneously.7 We largely find that our simulation results hold in practice. The downlink sees an increase in the total data volume with caching compared to TCP, which is natural
55
1.4 1.2
Uplink Downlink
ACKs Server data
Cached data
1 0.8 0.6 0.4 0.2 0 Plain TCP CATCP no delay 10ms delay
200ms delay
Normalized share of different packets
Data volume relative to TCP
2012-01-24-lab-0s-10rcv-256KB-0ms-packets.log.data
Transport Protocol Variant (TCP vs. CATCP)
Figure 26: Experimental Results with 10 receivers, 256 KB, 0ms one-way delay since a few packets starting with the second content segment, are sent by both the sender and the cache, and are also ACKed twice. The uplink load, on the other hand, can be significantly reduced. Figures 25 and 26 confirm the expected behavior for ACK delays. With increasing delays, the segment cache can effectively realize multicasting; the figures show that the ACK delay needs should be larger than the RTT to the server to become effective, for which 10 ms in 25 is insufficient. Moreover, these figures hint that the number of data packets that need to be sent by the server in the best case (a: 19% and b: 14%) is not far from the optimum of 15.6% and 12.5%, respectively. The results for 256 KB downloads roughly match what one would expect as improvement over the 64 KB variants: the fraction of segments served by the cache grows. We note one particular exception, though: for 50 clients, the caching performance may degrade with increasing RTT and ACK delay if the total packet storage in the segment cache (shared between ACKs and data packets) is limited and ACKs to be queued start evicting data packets. With 10 ms ACK delay, the savings of delaying and the loss due to eviction cancel out, but for 200 ms delay too many packets are dropped. For a shared cache it is thus advisable to forward ACKs rather than dropping data segments in order to queue the former.
56
1.4 1.2
Uplink Downlink
ACKs Server data
Cached data
1 0.8 0.6 0.4 0.2 0 Plain TCP CATCP no delay 10ms delay
200ms delay
Normalized share of different packets
Data volume relative to TCP
2012-01-24-lab-0s-50rcv-256KB-10ms-packets.log.data
Transport Protocol Variant (TCP vs. CATCP)
Figure 27: Experimental Results with 50 receivers, 256 KB, 10ms one-way delay 6.5.3
Bulk Resource Retrieval
Finally, we use a tree topology to validate the interaction of multiple caches. Thia scenario demonstrates our focus on short-term caching (of partial content) to support multicast-style delivery, we are primarily interested in the system behavior under diverse load. We use ten parallel instances of wget for each outgoing interface of the client machine (1, 2, 3, 5), referred to as wget A, B, C, and E. In our first set of experiments, we instantiate the wget instances in 1 s intervals. For each instance, we randomly choose 100 out of the 1,000 resources available, following a Zipf popularity distribution for successive retrieval. We measure the load incurred on the upstream interface of each catcp-bridge and on all four upstream interfaces of the client machine using tcpdump. With TCP, the data volume from the server is about 45 MB for each of the 10 runs. We carry out the experiments with all catcp-bridges configured to support state for 500 flows, 500 resources, and cache memory for 10,000 packets. We use an ACK delay of 10ms. We do not expect a high cache hit rate, since only some 140 of the 4,000 resources qualify for caching by being larger than 8kB and requested at least twice. Rather, the aim is to demonstrate correct operation of the segment caches. We find that the CATCP caching mechanics work flawlessly in this setup: the caches complement
57 each other, and we see cached responses originating from all catcp-bridges: about 30% of the cached responses originate from caches running on catcp-2 (A, B, C) and -4 (F), 40% are served by catcp-3 (D, E). Overall, however, only 1.8 MB of data (some 12,000 packets) come from the caches, yielding a net traffic reduction of about 3% (this accounts for the systematic duplicates). When experimenting with smaller resource sets or more synchronized receivers, we obtain the expected larger gain. We also confirm that a client reloading the same resource retrieves all but the first data packet from a cache (plus the systematic duplicates). Overall, these results show that our CATCP segment cache implementation performs as expected.
58
7
Discussion and Conclusion
We have described the arctecture and operations of the CATCP based networks in the previous sections and in this section we are discussing about the various issues that are yet to be solved in realted to the CATCP functionalities.
7.1
Segmentation:
CATCP implements a simple cache and sends the packet as they are stored in the cache, based on incoming acknowledgments and content requests. The downside of this approach is, that in practice the maximum TCP segment sizes may differ between connections, and TCP implementations may re-segment the data also for other reasons. If cache only sends segments that are an exact match to what the receiver expects, it could not reuse the data for connections that apply different MSS, or end up having different segment boundaries for the same data for some other reason. A simple improvement for the case when segment boundaries don’t match would be to send all packets from the cache that cover some part of the requested segment range. In this case the receiver would receive packets that contain partially redundant data to what was received earlier. A correctly working TCP implementation should be able to handle such packets without a problem, even though it is not an ideal design to deliver packets with partially useless payloads. A more advanced method could implement cache logic that does not assume packet-based operation at all, but rather stores and processes the data as a continuous byte stream in the same way as TCP does at the end hosts. With such a design segmentation becomes a non-issue, but more advanced memory management algorithms are required at caches.
7.2
Content label namespace:
CATCP uses content labels to identify the tcp segments uniquely, it also uses the sequence number for addressing the segments. The TCP options is limited to its size and the content label is trade-off between the available option space, and the collisions of the unrelated labels. We chose the content label legth to be 8 bytes in order to provide leave space for other TCP options such as selective acknowledgement options, etc. With a total option length of 15 bytes (or 19 bytes for the Content Request), it is also possible to maintain bidirectional cached traffic so that the same TCP packet can contain both Content Request and Content label options.
59 The likelihood of collision could be reduced by including the sender IP address in the content matching algorithms at caches, but this may create other limitations. To allow for longer labels, sender and controlling nodes could be modified to ensure that a labeled data segment does not carry a content request, too, splitting the packet in two if needed. Then 160-bit SHA-1 hashes could be used for labeling. Some proposals [29]. advocate the use of self-certifying labels for their security properties. Because the application chooses the label, it could also construct a self-certifying label based on a public key of the owner of content, or a hash over the content. It is not desirable to use per-packet self-certifying labels, however, because the content request logic is based on continuous sequence number space.
7.3
Cache pollution and DoS attacks:
CATCP is very vulnerable to cache pollution and DoS attacks if it uses simple content label namespace, attackers can use popular content label and maliciously create false content resulting in polluting the cache, this results in serving wrong polluted content from cache. CATCP at its current stats does not use self certified labels. Using self certified labels can prevent this as self-certifying identifiers allow caches to check if the content is indeed associated with the name. This can also be prevented by taking certain measures, One possible mitigation to this threat is that a cache remembers the source address when a content label arrives for the first time, and only stores packets for that content label if they arrive from the same source. Paired with ingress filtering at the ISPs this could reduce this threat significantly.
7.4
Middleboxes:
Middleboxes such as NAT’s, firewalls, traffic normalisers are common in the modern networks. Middleboxes often restrict the protocols and packet formats that can traverse the network. Studies found that unknown TCP options do not notably increase the failure rate of TCP connection setup [20, 31]; this is confirmed by a recent study of SYN packets and data segments [23]. Our experiments using servers in a home network behind an ISP-supplied NAT, and also servers in the Amazon cloud confirm this. Hence, we believe that using TCP options for CATCP is not problematic for deployment. Use of NAT or TCP port rewriting, does not stop CATCP working, because the cache logic is based solely on content labels, and the four-tuple in TCP header is only used locally. If a middlebox changes the TCP sequence number, the use of content requests with stateless caches
60 would be compromised. Stateful caches would be unaffected, as they infer sequence numbers locally. Middleboxes may rewrite the TCP segment boundaries; this is problematic for our segment level caching, as it relies on consistent segmentation, but it does not make CATCP unoperational, and senders are still able to operate normally, at worst such middleboxes lower the cache hit rate
7.5
Asymmetric Routing:
CATCP relies on data packets from the source priming the controlling node that a flow has cachable content. Controller state is instantiated when the first ACK arrives. The controlling node, and all upstream nodes, can then respond to ACKs with previously cached content. This logic makes an implicit (albeit not very strong) assumption on path symmetry: for the protocol to work, segments and ACKs need to pass through the same controller. We believe this is not a serious limitation as controlling nodes are likely close to (or part of) the receiver, where path diversity is limited. Since CATCP supports caching across TCP connections, cached segments may originate from any other sender-receiver pair, and only retransmissions within a single CATCP connection would suffer from path asymmetry upstream of the controlling node. Similarly, route changes do not break ongoing CATCP connections, although they will, of course, disrupt caching and reduce transmission efficiency until any caches on the new route are primed.
7.6
Conclusion:
Content centric applications generate the majority of the traffic in the Internet today. They are supported by a mixture of adhoc and application specific engineering solutions, but there is no unified and application neutral framework for pervasive content caching and dissemination. Content Aware TCP (CATCP), a TCP enhancement can enable short term content caching, to support packet reuse across transport connections. Such reuse is intended to be useful for both synchronous and timeshifted content replication. The motivation behind CATCP came from the data-oriented and content-centric networking architectures, such as DONA [29], PSIRP [28, 42], and CCN [26], and the thought that a useful, general purpose, content caching and distribution infrastructure could be designed to fit within the current Internet architecture. To some extent, CATCP could be viewed a probabilistic variant of redundancy elimination in which repeated transmission of the same data over a single link is avoided using
61 by fingerprinting the contents of packets or data streams, caching contents, and replacing repeated content by small tokens that can be removed to restore the original data downstream of a bottleneck [38]. We have proposed CATCP, an incrementally deployable approach to introducing application independent, transport layer, content aware caching into the Internet. CATCP runs with existing receiver implementations, and requires only minimal modifications to senders (peers or servers). we have shown that CATCP is feasible to implement and has the potential to achieve its goals, especially server side and network load reduction.
62
References [1] The Network Simulator NS-2. http://www.isi.edu/nsnam/ns/. [2] The Network Simulator NS-3. https://www.nsnam.org/. [3] B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman. A survey of information-centric networking. Communications Magazine, IEEE, 50(7):26–36, July 2012. [4] M. Allman, V. Paxson, and E. Blanton. TCP Congestion Control. RFC 5681, September 2009. [5] B. Quinn K. Almeroth. Ip multicast applications:challenges and solutions, September 2001. RFC 3170. [6] K.C. Almeroth. The evolution of multicast: from the mbone to interdomain multicast to internet2 deployment. Network, IEEE, 14(1):10–20, Jan 2000. [7] A. Ayadi, P. Maille, and D. Ros. Improving distributed tcp caching for wireless sensor networks. In Ad Hoc Networking Workshop (Med-Hoc-Net), 2010 The 9th IFIP Annual Mediterranean, pages 1–6, June 2010. [8] Hari Balakrishnan, Srinivasan Seshan, Elan Amir, and Randy H. Katz. Improving tcp/ip performance over wireless networks. In Proceedings of the 1st Annual International Conference on Mobile Computing and Networking, MobiCom ’95, pages 2–11, New York, NY, USA, 1995. ACM. [9] V. Jacobson R. Braden. Tcp extensions for long-delay paths, October 1988. RFC 1072. [10] Lawrence S. Brakmo, Sean W. O’Malley, and Larry L. Peterson. Tcp vegas: New techniques for congestion detection and avoidance. In Proceedings of the Conference on Communications Architectures, Protocols and Applications, SIGCOMM ’94, pages 24–35, New York, NY, USA, 1994. ACM. [11] V. Cerf and R.E. Kahn. A protocol for packet network intercommunication. Communications, IEEE Transactions on, 22(5):637–648, May 1974. [12] Kenjiro Cho, Kensuke Fukuda, Hiroshi Esaki, and Akira Kato. Observing slow crustal movement in residential user traffic. In Proceedings of the 2008 ACM
63 CoNEXT Conference, CoNEXT ’08, pages 12:1–12:12, New York, NY, USA, 2008. ACM. [13] V. Cerf Y. Dalal and C. Sunshine. Specification of internet transmission control program, 12 1974. RFC 675. [14] D. Waitzman C. Partridge S. Deering. Distance vector multicast routing protocol, November 1988. RFC 1075. [15] S.E. Deering. Host extensions for ip multicasting, August 1989. RFC 1112. [16] Stephen Deering, Deborah Estrin, Dino Farinacci, Van Jacobson, Ching-Gung Liu, and Liming Wei. An architecture for wide-area multicast routing. In Proceedings of the Conference on Communications Architectures, Protocols and Applications, SIGCOMM ’94, pages 126–135, New York, NY, USA, 1994. ACM. [17] C. Diot, B.N. Levine, B. Lyles, H. Kassem, and D. Balensiefen. Deployment issues for the ip multicast service and architecture. Network, IEEE, 14(1):78–88, Jan 2000. [18] W. Fenner. Internet group management protocol, version 2, November 1997. RFC 2236. [19] Nikos Fotiou, Dirk Trossen, and GeorgeC. Polyzos. Illustrating a publishsubscribe internet architecture. Telecommunication Systems, 51(4):233–245, 2012. [20] Saikat Guha and Paul Francis. Characterization and measurement of tcp traversal through nats and firewalls. In Proceedings of the 5th ACM SIGCOMM Conference on Internet Measurement, IMC ’05, pages 18–18, Berkeley, CA, USA, 2005. USENIX Association. [21] Sangtae Ha, Injong Rhee, and Lisong Xu. Cubic: A new tcp-friendly high-speed tcp variant. SIGOPS Oper. Syst. Rev., 42(5):64–74, July 2008. [22] S. Floyd T. Henderson and A. Gurtov. The newreno modification to tcps fast recovery algorithm, 2004. RFC 3782. [23] Michio Honda, Yoshifumi Nishida, Costin Raiciu, Adam Greenhalgh, Mark Handley, and Hideyuki Tokuda. Is it still possible to extend tcp? In Proceedings of the 2011 ACM SIGCOMM Conference on Internet Measurement Conference, IMC ’11, pages 181–194, New York, NY, USA, 2011. ACM.
64 [24] V. Jacobson. Congestion avoidance and control. In Symposium Proceedings on Communications Architectures and Protocols, SIGCOMM ’88, pages 314–329, New York, NY, USA, 1988. ACM. [25] V. Jacobson. A new way to look at networking, August 2006. Google Tech Talk. [26] V. Jacobson et al. Networking Named Content. In Proc. CoNEXT, December 2009. [27] J.Nagle. Congestion control in ip/tcp internetworks, 1 1984. RFC 896. [28] P. Jokela et al. LIPSIN: Line Speed Publish/Subscribe Inter-Networking. In Proc. SIGCOMM, 2009. [29] T. Koponen et al. A Data-Oriented (and Beyond) Network Architecture. In Proc. SIGCOMM, 2007. [30] B. Fenner M. Handley H. Holbrook I. Kouvelas. Protocol independent multicast - sparse mode (pim-sm):protocol specification (revised), August 2006. RFC4601. [31] Alberto Medina, Mark Allman, and Sally Floyd. Measuring the evolution of transport protocols in the internet. SIGCOMM Comput. Commun. Rev., 35(2):37–52, April 2005. [32] Prasanna Padmanabhan, Le Gruenwald, Anita Vallur, and Mohammed Atiquzzaman. A survey of data replication techniques for mobile ad hoc network databases. The VLDB Journal, 17(5):1143–1164, August 2008. [33] J. Postel. Transmission control protocol, 9 1981. RFC 793. [34] R. Fielding M. Nottingham J. Reschke. Hypertext transfer protocol (http/1.1): Caching, June 2014. RFC 7234. [35] M. Mathis J. Mahdavi S. Floyd A. Romanow. Tcp selective acknowledgment options, October 1996. RFC 2018. [36] P. Sarolahti, J. Ott, and J. Kangasharju. Locations vs. identities in internet content: Applying information-centric principles in today’s networks. Communications Magazine, IEEE, 50(12):54–59, December 2012.
65 [37] Pasi Sarolahti, J¨org Ott, Karthik Budigere, and Colin Perkins. Poor man’s content centric networking (with tcp), aalto university publication series science + technology, 5/2011, 2011. [38] Neil T. Spring and David Wetherall. A protocol-independent technique for eliminating redundant network traffic. In Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, SIGCOMM ’00, pages 87–95, New York, NY, USA, 2000. ACM. [39] W. Stevens. Tcp slow start, congestion avoidance, fast retransmit, and fast recovery algorithms, 1 1997. RFC 2001. [40] J. Touch. Shared use of experimental tcp options, 2013. RFC 6693. [41] J. Touch. Tcp extended data offset option ieee draft, 2015. draft-touch-tcpmtcp-edo-03.txt. [42] D. Trossen, M. S¨arel¨a, and K. Sollins. Arguments for an information-centric internetworking architecture. SIGCOMM CCR, 40(2), 2010. [43] Jia Wang. A survey of web caching schemes for the internet. SIGCOMM Comput. Commun. Rev., 29(5):36–46, October 1999. [44] Lisong Xu, K. Harfoush, and Injong Rhee. Binary increase congestion control (bic) for fast long-distance networks. In INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, volume 4, pages 2514–2524 vol.4, March 2004. [45] G. Xylomenos, C.N. Ververidis, V.A. Siris, N. Fotiou, C. Tsilopoulos, X. Vasilakos, K.V. Katsaros, and G.C. Polyzos. A survey of information-centric networking research. Communications Surveys Tutorials, IEEE, 16(2):1024–1049, Second 2014.
