CDN Interconnection Framework as A Way to Improve E-Learning in Zimbabwe

CDN Interconnection Framework as A Way to Improve E-Learning in Zimbabwe

Spencer T. J. Chigananda

MTech in Cloud Computing Candidate School of Information Science and Technology

Department of Information Technology Harare Institute of Technology, Zimbabwe

Abstract:- The Covid pandemic has changed how the way society conducts business or education. There is need to minimize human contact due to the nature of the pandemic. This thesis has identified the lack of eLearning access in rural Zimbabwe. There is a huge cost attached to the access of eLearning material and there is need for the challenge to be addressed. Thankfully, Cloud computing offers solutions to address a cost-effective manner to deliver content to users irrespective of geographical region. This thesis looks at harnessing the power of content delivery network interconnection (CDN interconnection) and its surrounding technologies to come up with a solution for allowing cheap educational content delivery in rural Zimbabwe through interconnection of the Government of Zimbabwe ICT service providers.

Keywords: Content Delivery Interconnection (CDN Interconnection) ; eLearning; Government of Zimbabwe ICT service provider

1. INTRODUCTION

   The thesis topic is about creating a CDN interconnection framework for internet service providers and the public data centers to provide social services to remote parts of the country. The social service to be addressed is eLearning or online education. The thesis will look at related work already done and address the technical gap for application in a third world country like Zimbabwe.

2. STATEMENT OF PROBLEM

   At least 60% of the Zimbabwean population lives in rural areas. The rural folk struggle to access mobile data as it is expensive. In addition, higher internet speeds are accessed in urban areas compared to rural areas. The rural folk typically access the mobile network using 2G and 3G networks. This presents an opportunity to create a technology that addresses this challenge. This translates to challenges in accessing eLearning resources for rural children. Internet service providers seek to harness cloud

   David Fadaraliki

   Senior Lecturer, Cloud Computing School of Information Science and Technology

   Department of Information Technology Harare Institute of Technology, Zimbabwe

   computing technologies to deliver content cheaply to users to provide social benefits.

3. REVIEW OF LITERATURE

   Content Delivery Network interconnection was first defined in a problem statement drafted by the Internet Engineering Task Force (IETF) in September 2012. According to request for comment (RFC) 6707 by Niven- Jenkins et al, CDN interconnection is a protocol that has numerous benefits as an emerging technology. Niven- Jenkins et al mention the drastic increase of video and multimedia content on the internet and how content delivery networks (CDNs) can be used to store what they term as cacheable content. The RFC by the IETF spells out the scope of CDNI Interconnection, CDNI interfaces, and possible application areas of CDN interconnection. Some of the benefits include reduced delivery cost, improved quality of experience for users, and increased robustness of delivery [1]. The RFC clearly defines the use cases of CDN interconnection which can be extended by any researcher. The RFC lists the four interfaces which are required to interconnect any pair of CDNs and that constitute the problem space of CDN interconnection. These four interfaces are CDNI control interface, CDNI request routing interface, CDNI metadata interface, and CDNI logging interface [1]. A research gap emanates from the development of these four interfaces and how they can be modified to address the problem statement as defined in the proposal.

   CDN Background

   RFC 3040 outlines the architecture, features and components of CDN. In essence, CDNs are used to provide large scale content delivery of diverse types of content. According to Niven-Jenkins et al, the goal is to deliver content to an end user regardless of that end users location or the network they are attached to in a cost-effective and

   efficient manner. The authors also spell out three possible business arrangements for end-to-end content delivery that possibly involve a relationship with a Content Service Provider and/or an authoritative CDN provider (the term defined below as according to Niven-Jenkins et al).

   CDNI Terminology

   The RFC by Niven-Jenkins et al lists important terminology for any researcher to understand the CDN interconnection framework or protocol (quoted directly from the authors):

   Authoritative CDN: A CDN that has a direct relationship with a CSP for the distribution and delivery of that CSPs content by the Authoritative CDN or by Downstream CDNs of the Authoritative CDN [1].

   CDN Interconnection (CDNI): A relationship between a pair of CDNs that enables one CDN to provide content delivery services on behalf of another CDN. A CDN Interconnection may be wholly or partially realized through a set of interfaces over which a pair of CDNs communicate with each other in order to achieve the delivery of content to User Agents by Surrogates in one CDN (the Downstream CDN) on behalf of another CDN (the Upstream CDN) [1].

   CDN Provider: The service provider who operates a CDN and offers a service of content delivery, typically used by a Content Service Provider or another CDN Provider. Note that a given entity may operate in more than one role. For example, a company may simultaneously operate as a Content Service Provider, a Network Service Provider, and a CDN Provider [1].

   CDNI Metadata: The subset of Content Distribution Metadata that has an inter-CDN scope. For example, CDNI Metadata may include geo-blocking information (i.e., information defining geographical areas where the content is to be made available or blocked), availability windows (i.e., information defining time windows during which the content is to be made available or blocked) and access control mechanisms to be enforced (e.g., URI signature validation). CDNI Metadata may also include information about desired distribution policy (e.g., pre-positioned vs dynamic acquisition) and about where/how a CDN can acquire the content [1].

   Content: Any form of digital data. One important form of Content with additional constraints on distribution and delivery is continuous media (i.e., where there is a timing relationship between source and sink) [1].

   Content Distribution Metadata: The subset of Content Metadata that is relevant to the distribution of the content. This is the metadata required by a CDN in order to enable and control content distribution and delivery by the CDN. In a CDN Interconnection environment, some of the Content Distribution Metadata may have an intra-CDN scope (and

   therefore need not be communicated between CDNs), while some of the Content Distribution Metadata may have an inter-CDN scope (and therefore needs to be communicated between CDNs) [1].

   Content Distribution Network (CDN) / Content Delivery Network (CDN): Network infrastructure in which the network elements cooperate at Layers 4 through 7 for more effective delivery of Content to User Agents. Typically, a CDN consists of a Request Routing system, a Distribution system (that includes a set of Surrogates), a Logging system, and a CDN Control system [1].

   Content Service: The service offered by a Content Service Provider. The Content Service encompasses the complete service, which may be wider than just providing access to items of Content; e.g., the Content Service alsoincludes any middleware, key distribution, program guide, etc. that may not require any direct interaction with the CDN, or CDNs, involved in the distribution and delivery of the content [1].

   Content Service Provider (CSP): Provides a Content Service to End Users (which they access via a User Agent). A CSP may own the Content made available as part of the Content Service or may license content rights from another party [1].

   Control system: The function within a CDN responsible for bootstrapping and controlling the other components of the CDN as well as for handling interactions with external systems (e.g., handling delivery service creation/update/removal requests, or specific service provisioning requests) [1].

   Delivery: The function within CDN Surrogates responsible for delivering a piece of content to the User Agent. For example, delivery may be based on HTTP progressive download or HTTP adaptive streaming [1].

   Distribution system: The function within a CDN responsible for distributing Content Distribution Metadata as well as the Content itself inside the CDN (e.g., down to the Surrogates) [1].

   Downstream CDN: For a given End User request, the CDN (within a pair of directly interconnected CDNs) to which the request is redirected by the other CDN (the Upstream CDN). Note that in the case of successive redirections (e.g., CDN1-->CDN2-->CDN3), a given CDN (e.g., CDN2) may act as the Downstream CDN for a redirection (e.g., CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection of the same request (e.g., CDN2-->CDN3) [1].

   Dynamic CDNI Metadata acquisition: In the context of CDN Interconnection, dynamic CDNI Metadata acquisition means that a Downstream CDN acquires CDNI Metadata for

   content from the Upstream CDN at some point in time after a request for that content is delegated to the Downstream CDN by an Upstream CDN (and that specific CDNI Metadata is not yet available in the Downstream CDN) [1].

   Dynamic content acquisition: Dynamic content acquisition is where a CDN acquires content from the content source in response to an End User requesting that content from the CDN. In the context of CDN Interconnection, dynamic acquisition means that a Downstream CDN acquires the content from content sources (including Upstream CDNs) at some point in time after a request for that content is delegated to the Downstream CDN by an Upstream CDN [1].

   End User (EU): The real user of the system, typically a human but maybe some combination of hardware and/or software emulating a human (e.g., for automated quality monitoring etc.) [1].

   Logging system: The function within a CDN responsible for collecting the measurement and recording of distribution and delivery activities. The information recorded by the Logging system may be used for various purposes, including charging (e.g., of the CSP), analytics, and monitoring [1].

   Metadata: Metadata in general is data about data [1]. Network Service Provider (NSP): Provides network-

   based connectivity/services to End Users [1].

   Over-the-top (OTT): A service, e.g., content delivery using a CDN, operated by a different operator than the NSP to which the users of that service are attached [1].

   Pre-positioned CDNI Metadata acquisition: In the context of CDN Interconnection, CDNI Metadata pre- positioning is where the Downstream CDN acquires CDNI Metadata for content prior to, or independently of, any End User requesting that content from the Downstream CDN [1].

   Pre-positioned content acquisition: Content pre- positioning is where a CDN acquires content from the content source prior to, or independently of, any End User requesting that content from the CDN. In the context of CDN Interconnection, the Upstream CDN instructs the Downstream CDN to acquire the content from content sources (including Upstream CDNs) in advance of, or independently of, any End User requesting it [1].

   Request Routing system: The function within a CDN responsible for receiving a Content Request from a User Agent, obtaining, and maintaining necessary information about a set of candidate Surrogates or candidate CDNs, and for selecting and redirecting the user to the appropriate Surrogate or CDN. To enable CDN Interconnection, the

   Request Routing system must also be capable of handling User Agent Content Requests passed to it by another CDN [1].

   Surrogate: A device/function (often called a cache) that interacts with other elements of the CDN for the control and distribution of Content within the CDN and interacts with User Agents for the delivery of the Content. Typically, Surrogates will cache requested content so that they can directly deliver the same content in response to requests from multiple User Agents (and their End Users), avoiding the need for the content to transit multiple times through the network core (i.e., from the content origin to the Surrogate) [1].

   Upstream CDN: For a given End User request, the CDN (within a pair of directly interconnected CDNs) that redirects the request to the other CDN [1].

   User Agent (UA): Software (or a combination of hardware and software) through which the End User interacts with a Content Service. The User Agent will communicate with a Content Service for the selection of content and one or more CDNs for the delivery of the Content. Such communication is not restricted to HTTP and may be via a variety of protocols. Examples of User Agents (non-exhaustive) are browsers, Set Top Boxes (STBs), dedicated content applications (e.g., media players), etc [1].

   CDNI Interfaces

   Niven-Jenkins et al in RFC 6707 also briefly discuss each of the Content Delivery Network Interconnection (CDNI) interfaces and their purpose. These interfaces are CDNI Control Interface, CDNI Request Routing Interface, CDNI Metadata Interface, and the CDNI Logging Interface. It is important to note that the four CDNI interfaces are all control plane interfaces operating at layer 7 of the OSI network model [1]. In addition, the expectation from the authors is that the CDNI interfaces will be defined on top of existing session, transport, and network protocols. Niven- Jenkins et al stress that although a new application protocol could be designed specifically for CDNI, it is unnecessary and it is therefore recommended that existing application protocols be reused or leveraged (e. g. HTTP, XMPP) to realize the CDNI interfaces.

   The CDNI control interface allows the CDNI control system in interconnected CDNs to communicate [1]. The CDNI control interface may support bootstrapping of other CDNI interfaces, allow configuration of other CDNI interfaces, allow the downstream CDN to communicate static information among many other features. This interface is the least well-defined of the other interfaces and presents a research gap.

   The CDN Request Routing interface allows the Request Routing systems in the interconnected CDNs to communicate to ensure that an End User request can be

   (re)directed from an Upstream CDN to a surrogate in the Downstream CDN, in particular where selection responsibilities may be split across CDNs. [1].

   The CDNI metadata interface allows the Distribution system in interconnected CDNs to communicate to ensure that CDNI metadata can be exchanged across CDNs.

   The CDNI logging interface allows the logging in interconnected CDNs to communicate relevant activity logs in order to allow log consuming applications to operate in a multi-CDN environment [1].

   Fig. 1 Illustration of CDNI interfaces [1]

   CDN Federation

   CDN Federation is another term used interchangeably with CDN Interconnection. It has a close meaning to CDN Interconnection and refers to the close collaboration of CDN providers to move content across their shared user base. The concept emphasizes the need for CDNs to be interconnected so as to increase efficiency.

   Scope of the CDNI Specification

   The IETF working group responsible for standardizing the CDN interconnection protocol in the FC specify the scope of the CDNI protocol specification. This helps researchers understand which aspects of the specification are in scope to develop the protocol. It is important to understand the scope of the specification and the following paragraphs give a brief outlay of the scope of the IETF specification.

   According to Niven-Jenkins et al, the interface between the Content Service Provider and the Authoritative CDN is not in the scope of the specification. This means the two entities are free to choose the kind of interface or protocol to make use of in connecting.

   The streaming protocols to be used between the delivering CDN surrogate and the User agent are also not in the scope of the specification.

   The request interface that is used between the user agent and the request routing system of a given CDN are also not in the scope of the specification.

   Most importantly, the content acquisition between CDNs (that is, the data plane interface for actual delivery of a piece of content from one CDN to the other) is not the goal of the IETF specification for CDN interconnection. The expectation is to use existing protocols such as HTTP or protocols that have already been defined in other forums that deal with content acquisition [1].

   Application of CDNI and possible use cases CDNI Design Principles and Considerations

   A publication titled Design Principles of an Operator- Owned Highly Distributed Content Delivery Network by Stella Spagna et al guides researchers on design principles to apply on implementing CDN interconnection. According to Spagna et al, mobile operators are experiencing a tremendous increase in data traffic due to the growing popularity of bandwidth-intensive video services [2]. This paper discusses how to design for bandwidth intensive traffic. The paper provides design principles for network embedded operator CDNs related to cache server placement, content outsourcing, replica placement, and request routing. The paper discusses about the current cache server placement strategies and request routing logic. An example of cache server placement is minimum k-center problem models the cache server problem as a center placement problem. There is also discussion on the content outsourcing approaches being used. For example, Akamai uses a non- cooperative pull-based approach. The tradeoffs of each approach are discussed, and these tradeoffs are also posing research gaps on creating much better content outsourcing approaches. Spagna et al outline the design goals of CDN interconnection as network tailored cache placement strategies, balanced replica placement algorithms, network aware request routing algorithms, and mobile network operator owned CDN architectures [2].

   CDNI experiments conducted and proof of concepts done Nam and Park in the paper titled Analyzing the Effectiveness of Content Delivery Network Interconnection of 3G Cellular Traffic advocate the use of CDN interconnection as an emerging technology to adopt. They state that the goal of a telecommunications operated CDN is to create local caches that can potentially cut down the interdomain traffic crossing the Internet Exchange Point (IXP) by absorbing content delivery needs of the content providers that are outside of the ISP [3]. The paper also suggests CDN interconnection implementation as a new source of telco revenue. Below is an illustration the CDNI

   redirection protocol according to Nam and Park:

   Figure 2 Illustration of CDNI redirection protocol according to Nam and Park [3]

   Nam and Park outline the benefits of CDNI to ISPs, content providers, and to the end user [3]. Below is a summary of the benefits.

   Benefits to ISP:

   CDNI allows the sharing of resources of the collaborating peer CDNs so as to extend service coverage [3]. CDNI also reduces IXP traffic as mentioned earlier. From the perspective of the upstream CDN, CDNI extends the service coverage to outside of its own region.

   Benefits to Content Provider:

   CDN Interconnection lowers the cost of the CDN service [3]. In addition, CDNI allows a small content provider to make a contract with a regional CDN that participates in CDNI and benefits from the lower cost of global CDN service [3].

   Benefits to End Users:

   Users have access to content that is originally served outside of the users Internet service provider [3]. CDNI makes content location local to the users (think of community clouds or CDNs) and the regional telecommunications CDN can even dynamically optimize the delivery path of content considering the users location and network load or network performance metrics.

   Nam and Park analyzed the HTTP traffic at one of the largest cellular internet service providers in South Korea. The authors logged all HTTP request and response pairs that pass one of three 10 Gbps core network links just below a 3G GPRS support node (GGSN) in Seoul for a period of one week. They made use of a high-performance deep flow inspection system called Monbot. This system produced three types of log data in real time: TCP flow statistics, HTTP request/response statistics, and SHA-1 hashes of content chunks (hashed to maintain user data privacy).

   The cellular network in experiment at the time had 12.5 million subscribers at the time of the paper publication and the measurement point chosen by the authors covered half of the regions served by the ISP in South Korea [3].

   7.7 billion HTTP requests were logged during the measurement period (totaling 75% of downlink traffic) [3].

   The obtained dataset was used to determine the incoming traffic that crosses the IXP based on the server IP address [3]. A Geo-IP database, Maxmind, was used to map a server- side IP address to its hosting ISP and country. The results of the experiment were outlined as the benefits and overheads of CDN interconnection in real world 3G traffic [3].

   Results of the experiment:

   CDNI offers the benefit of bandwidth savings for an ISP. As much as 16.2% IXP bandwidth savings [3]. However, the experiment showed that CDNI has a request routing overhead as CDNI works by redirecting the request to a downstream CDN, which adds one HTTP redirection delay to the user.

   Binder et al in their paper titled Practical Experience with CDN Interconnection discuss CDNI architecture and implementations done to test functionality. The authors state that CDNs are the most scalable way of distributing content today and with the advent of CDN interconnection, even smaller operators can achieve a global footprint [4]. However, Binder et al mention that the cost of CDN interconnection is added latency to the network (an issue raised by Nam and Park in their paper). This is because requests have to traverse multiple autonomous networks [4].

   Binder et al give an overview of CDN Interconnection. There is emphasis to increase CDN performance by interconnecting them. This approach keeps unchanged existing infrastructure and can improve infrastructure utility. The authors mention in the paper the advantages that CDN interconnection can provide in improving CDN services: geographical extension, inter-affiliates interconnection ( a situation where a large CDN provider has numerous subsidiaries and each of them operates their own CDN), ability for ISP to handle third-party content, overload handling and traffic dimensioning (CDNs may interconnect to increase their effective capacity), and failure tolerance of content delivery resources (CDNI can redirect traffic from a faulty CDN to another fully functional CDN and hence keep the whole network serving customers.

   Binder et al give a typical scenario of content acquiring over CDNI with the use of an architectural diagram show below:

   Figure 3 Example of content acquiring over CDNI according to Binder et al [4]

   Binder et al state that the basic use case of interconnection is that the authoritative or upstream CDN provider is used by the content service provider for content delivery. This CDN provider could contain or more downstream CDN providers and th authoritative CDN provider has the ability to delegate content serving on it.

   The paper by Binder et al also discusses CDNI design and the design issues to consider when trying to implement CDN interconnection. The advice the authors give in considering a CDNI design is to ensure the design does not change the existing network topology and makes use of existing autonomous networks to minimize the cost of implementation. Binder et al further suggest to make use of the existing CDN web services to connect to the CDN. This allows CDNI to make API calls to the CDN to extract data as well as allow CDN operations. The authors also provide the basic lifecycle of the CDNI content acquiring architecture.

   Binders et al in their paper conducted an experiment to test the CDNI concept. Their experiment involved the creation of three CDN domains. One of the domains was made up of a CDN simulator. One of the CDN domains was of South Korea Telecom. The goal was to investigate the benefits of CDN interconnection in a real environment. The experiment showed an improvement in the end user experience.

   Yonghwan Bang et al in a paper titled CDN Interconnection Service Trial: Implementation and Analysis describe a CDNI gateway model as the ideal way of implementing CDN interconnection in ISPs. The authors design and implement a CDNI system based on the CDNI gateway model that is standard capable and platform independent to realize all the CDNI system requirements.

   Bang et al developed their CDNI system at Korea Advanced Institute of Science and Technology (KAIST) and conducted a CDNI trial service comprising of three major South Korean ISPs, a cable network provider, and a content service provider (CSP). The three major ISPs and the cable network provider collaborated to build four content delivery networks and the content service provider became the publisher of the trial service.

   Architecture of CDNI Gateway

   Bang et al describe the architecture of the CDNI gateway that they designed and implemented. The gateway model provides standard CDNI compliance as well as interface compatibility with legacy CDN systems. Their architecture primarily consists of two parts: a CDNI module and a CDNI adaptation interface. The CDNI module consists of a CDNI interface and a CDNI database. The function of the CDN adaptation interface is to provide communication between a CDNI module and legacy CDN systems. This is the component that provides backward compatibility for the CDNI system with legacy CDN. The CDNI database stores

   required information for CDNI among CDNs. Bang et al implemented their own HTTP and DNS servers to optimize the CDNI system. In their design the DNS server would enable parallel processing for user content requests. Below is a table that summarizes the functions of the CDNI adaptation interface in a CDNI system:

   Table 1 Functions of the CDNI adaptation interface in a CDNI gateway [5]

   Category	Function	Description
   Administration	RUN	Request to CDNI gateway to run CDNI module.
   	INIT	Send CDN information to CDNI gateway and request to initialize.
   	STOP	Request to CDNI gateway to stop CDNI service.
   Database Configuration	ADD	Request to CDNI gateway to add information.
   	UPDATE	Request to CDNI gateway to update information.
   	REMOVE	Request to CDNI gateway to remove information.
   Get Information	GET_CDmD	Request to CDNI gateway to get content distribution metadata.
   	GET_LOG	Request to CDNI gateway to get other CDNs (dCDN) CDNI log data.

   Bang et al describe the operations for a CDN interconnection in a CDNI gateway and state that in a CDNI system, the content delivery service is operated through an upstream CDN (uCDN) and downstream CDN (dCDN). The relationship between uCDN and dCDN can be one-to-many or many-to-many. The authors have an illustration of the operation:

   Figure 4 Service scenario of a CDNI system [5]

   Bang et al make an important note that is it crucial to prevent looping and flooding to provide a reliable CDNI service. Looping and flooding prevention can be provided by utilizing combined information of a CDN provider ID list and a maximum number of allowed redirections hop count.

   Results of CDNI Trial Service:

   As mentioned earlier, the trial service by Bang et al involved three ISPs, a cable network operator, a content service provider, and KAIST. The CDN interconnections used a redirection policy of proximity-first for each content request, and the CDNI gateway design was capable of both HTTP and DNS redirection. To determine the traffic reduction due to CDNI, there was need to monitor and analyze the IX link. However, since it was not possible for the researchers to monitor a commercial IX link due to the sensitivity, the researchers employed the Korean Advanced Research Network (KOREN) to take the role of an IX link instead of using an actual commercial IX link [5]. In this case, all service traffic generated by surrogates is delivered over an actual commercial network while the inter-CDN traffic that corresponds to IX link traffic is delivered through the KOREN links [5].

   The trial service was offered to 170 users, with 100 active users [5]. A total of 121 contents with a total volume of 9.6GB were in place for service. [5] For a six-day service period, 2612 content requests were generated, and a total volume of 50.5GB of content services were delivered [5].

   In conclusion, this trial service saw a traffic reduction of 43% on the IX link [5]. This is a significant reduction in bandwidth for any telecommunications operator making CDNI implementation worthwhile. The CDNI gateway model is one of the most feasible practical solutions to implement CDNI and enhance network capabilities.

   Figure 5 KAIST CDNI trial service network and content information [5]

4. CONCLUSION

   CDN Interconnection is a technology that can be used to create community CDNs or clouds if fused with cloud computing concepts. CDNI already offers ISPs reduced bandwidth costs and hence over the top services such as eLearning can be created on top of CDNI infrastructure to offer more services to end users. The literature review also shows a huge research gap in the CDNI control interface design which any researcher can look to improve.

5. FUTURE WORK

Machine learning can be incorporated in the CDNI framework especially on the request routing aspect to create an adaptive CDNI gateway model. Future researchers can investigate how this can be achieved. Future researchers can also mine network traffic metadata to come up with models to help CDNI framework flow of information.

REFERENCES