Conceptual Design

This section describes the conceptual design of Cooperative Internet Accesssystem. Coopera-tive Internet Accessrequires the extension of existing applications, but no change in the operat-ing system or in any part of the networkoperat-ing subsystem.

The dotted boxes of Figure 4.10 show the elementary building blocks of an application. The element retrieval or exchangeis the communication subsystem of an application that is in charge of sending and receiving of data to and from peers/servers in the Internet via the access-link.

Data that is sent or received by the application passes through theelement buffer, which passes

Chapter 4. Conceptual System Design 66

prediction download request queue measurements throughput

local element redistribution local

peers in local context

Via 3G to/from peers/servers in Internet

app.

controller process Via SL to/from Via SL to/from

element retrieval or exchange

elem.

buffer

Figure 4.10: General Node Architecture

over or receives data from the local application. Thelocal applicationis the actual processing entity in the application (e. g. the rendering engine of a web browser).

For Cooperative Internet Access, the application is extended with the bold line boxes elements shown in Figure 4.10 to add the required Cooperative Internet Accessfunctionality. The left hand-side of the node architecture belongs to the data plane of Cooperative Internet Access, i. e., where the actual information elements are handled. The right hand side of the node archi-tecture belongs to the control plane, i. e., the building blocks are required to operate Cooperative Internet Access.

The local element redistribution module interconnects the participating Cooperative Internet Accessnodes for their local information element exchange (Cooperative Internet Accessdata plane) via the sharing-link. The information elements are read from or written to the element buffer of the local application instance, depending on whether they are being sent or received from the node.

The control plane of Cooperative Internet Accessare the building blocks on the right hand side in Figure 4.10. These blocks are added to the node and interact with the actual applications and also with the networking stack of the host operating system. Thethroughput measurements module is constantly collecting passive measurements about the achievable throughput on the access-link in the upload direction (i. e., from the node to the Internet) and in the download direction (i. e., from the Internet to the node). Those throughput measurements are reported to the download prediction module where they are processed and reported to the controller

Chapter 4. Conceptual System Design 67

process. Therequest queuemodule stores all requests for information elements that have to be made by the node and it controls theelement retrieval or exchangemodule. Therequest queue module reports also the current requests to thedownload predictionmodule. Therequest queue module receives its information from the controller process. The controller process is shown as being outside the node, as a meta process, as the controller itself can be either on a different node, if there is a single centralized controller, or it can be distributed amongst all participating nodes. The controller process is logically separated from the general node architecture.

The following sections describe the modules in detail.

4.3.1 Throughput Measurements

Cooperative Internet Accessaims at overcoming the limitations of particular links in a cooper-ative way with other nodes. The first step to understand if a link is resource constrained is to measure the achievable throughput of the linkΘi(t).

The achievable throughput is measured for the uplink and the downlink traffic at a fixed common sampling frequency f_s. The measurements samples are stored for a limited time period, i. e., a moving window lasting from now toδ seconds in the past, as only a recent history of the link’s throughput is of interest for the system. The maximum measured throughput in theΘˆ_inow

δ is also recorded, as well as, the nominal link bitrate ˆB_`. Θˆ_inow

δ can actually lower than ˆB_`, as the access-link itself may not be the limiting factor, but a bottleneck link down the path in the network.

The module additionally collects the current link status, i. e., if the link is up or down. A link is reported as up, if the link layer indicates the link to be up and if there is network layer configuration of that link (including support for the network layer, such as name resolution services). The network layer information may include an IP address, default route, DNS servers.

The measurement module can trigger a short test sequence to see if the link is properly working (e. g., sending of ICMP messages).

The throughput measurement module connects to the download prediction module and reports all measured parameters (Θ_i(t), link up or down,Bˆ_inow

δ , and ˆB_`).

4.3.2 Request Queue

Typically, applications do not consider when to up or download their information elements via the Internet. They typically assign the elements to the element retrieval or exchange module and wait for the completion. For Cooperative Internet Accesstheelement retrieval or exchange moduleis augmented with therequest queue. The request queue determines which information element will be retrieved via the access-link with what priority. The request queue module instructs theelement retrieval or exchange moduleto work on a specific information element.

The request queue is a priority queue, meaning that elements at the queue’s head are handled with the highest priority. The queue is controlled by the controller process. The controller

Chapter 4. Conceptual System Design 68

process controls which information element requests will be stored in the request queue or if the queue entries need to be changed. The dimensioning of the request queue’s size depends on the used application is defined in the respective section.

The request queue module is connected to the download prediction module. The queue module reports the current queue entries (i. e., which information elements are queued) and the size of the information elements to be handled.

4.3.3 Download Prediction

The download prediction module combines the information received from the throughput mea-surements module and the request queue module. The download prediction has to judge when the current ongoing upload and/or download will be finished and when the other elements in the queue will be finished.

This module uses the measurement results from the measurement module to compute the prob-abilistic metrics outlined in Section 4.2.5. These metrics are used to predict the future devel-opment of the achievable throughput and in this way to estimate the completion time of each information element entry in the request queue. For each information element request, the pre-diction lists the estimated completion time and the probability that this completion time will reached. A predictor may list multiple completion times with varying probability values for a single information element request. A predictor may also give a general guidance about the ex-pected achievable throughput for an interval and the probability that this estimation will occur.

The Cooperative Internet Accessconcept does not enforce the usage of a single, standardized download prediction algorithm between all nodes. In fact, each node can deploy and use its own algorithms. It is only required that the output of the algorithm is interoperable with the output of all other algorithms, i. e., the output must fit to the metrics described in Section4.2.5.

4.3.4 Local Element Redistribution

The element buffer, containing the information elements for the local application, is filled by information elements retrieved via the access-link (via the element retrieval or exchange mod-ule), and via the sharing-link with information elements from other local Cooperative Internet Accessnodes. The local element redistribution module connects to the other local Cooperative Internet Accessnodes and takes care that the information elements retrieved by the node itself are sent to the other nodes in need of the information element or retrieved from other nodes.

The local element redistribution keeps also track about all locally participating peers, i. e., the group membership management.

4.3.5 Controller Process

The earlier sections described the modules that are needed on any participating node, but left out the controller process. The controller process is the focus point of the system, where all

in-Chapter 4. Conceptual System Design 69

formation from the peers is collected and processed, the scheduling of the information elements is performed, and from where the request queues of the local nodes are maintained.

The controller keeps a list of access-links and the nodes offering these access-links. There may be more access-links than nodes, as a single node can offer multiple access-links. The controller does not consider nodes in its computations, but uses the access-link as working unit.

The functional tasks of the controller process are:

situation management Using Cooperative Internet Accessmay not be useful in every situa-tion, as nodes are mobile, connecting to the Internet at different times with changing access-links/types. For instance, when the node is connected to a ADSL line, it may not beneficially to use Cooperative Internet Access, as the line will be very likely not resource constrained. The usage of Cooperative Internet Accessin that situation will cause a not needed overhead. Therefore, it is necessary for the system to detect the situation. Second, the system should detect which of the links is used as access-link and which other links, if any, can be used as sharing-link.

group management Cooperative Internet Accessnodes that want to participate need to decide in thesituation managementif they are going to participate in the system. A node that is participating in Cooperative Internet Access, announces its presence to the system, what resource it wants to access (e. g., which video channel), and the link resources the node can commit (e. g., number of access-links and type of link). The controller collects this information and monitors the presence of the nodes throughout their participation. Nodes that want to leave to the system also announce this or the controller will notice that they have left when checking the peers for their liveliness.

link measurements The controller process collects the measurement results of the links from the download predictor. The measurements are stored and used by theinformation ele-ment scheduler.

information element requests The controller process collects the requests for information el-ements from the various participating nodes and uses this for the information element scheduler. This step can be be implicit, if the peers have a pre-defined set of information elements to be handled which are known a priory to the controller process (e. g., number of chunks in file-sharing). Nodes can add a priority value to the information elements, indicating their preference for handling.

status of information elements The controller process collects the status of the information elements assigned to the request queues on the nodes.

information element scheduler The main task of the controller process is to coordinate the handling of information elements with the local Cooperative Internet Accessnodes. The controller takes the list of information element requests and computes how these elements can be handled according to their priority with the current set of links. The elements are ranked according their priority and matched against the reported achievable bandwidth (and probability) of the links, to schedule the information element requests to a link or a set of links. The matching process depends on the used application. Section 5 and Section6discuss 2 applications and the resulting scheduling algorithms.

Chapter 4. Conceptual System Design 70

element assignment The controller process collects assigns after the information elements, after theinformation element scheduler, to the request queue’s of the local nodes.

The functional elements described above can be grouped into:

overall system control The overall system control comprises all elements that are not specific for an application, such as situation management, link measurements and group manage-ment.

application specific system control The functional elements information element requests, sta-tus of information elements, information element scheduler, and chunk assignment are specific for each application that uses Cooperative Internet Access.

This differentiation leads to the separation between an overall system control that is application independent and a controller instance per application used. The application specific controller instance is required as the semantics of each application is different in terms of types of informa-tion elements, priority of handling of informainforma-tion elements, dependencies between informainforma-tion elements, and time constraints.