{'fraction_non_alphanumeric': 0.034201550387596896, 'fraction_numerical': 0.007426356589147287, 'mean_word_length': 4.56138989480945, 'pattern_counts': {'":': 0, '<': 2, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 13, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
fCDN: A Flexible and Efficient CDN Infrastructure without DNS Redirection or Content Reflection

Flexible and efficient CDNs are critical to facilitate content distribution in 5G+ architectures. Current CDNs suffer from inefficient request mapping based on DNS redirection, and inefficient content distribution from origin to edge servers, through content reflection. We proposes a novel, flexible CDN architecture that removes the need for DNS-based mapping and content reflection. Instead, requests to/from the CDN are treated as service transactions in the network, which utilises a routing function embraced from emerging research in Information-Centric Networks (ICN) to route edge-to-edge transactions to the true nearest service point. The same function is utilized to establish path-based flows over a fast forwarding substrate; thereby, eliminating the need for IP routing between service points within a single domain, and potentially at peering points with other domains. We model our architecture and formulate the resource placement problem as a variance of the K-center problem. To address the problem, we propose a greedy algorithm, Swing, that balances the placement of service points between highly and poorly connected nodes. We evaluate the efficiency of our architecture in utilising the CDN and network resources through Monte Carlo simulations that explore a range of K values. Moreover, we compare the goodness of the placement solutions provided by Swing with those provided by Largest First and Closest First Algorithms. Evaluation results show the superiority of our fCDN solution in reducing the edge-to-edge path length and the required network resources.


I. INTRODUCTION
C ONTENT Distribution Networks (CDN) emerged as application overlays that provide information awareness on top of the existing IP architecture. They facilitate delivering live and on-demand multimedia content to customers, by localising content nearer to the end-user. Current CDNs require solutions such as DNS (and HTTP) redirection and content reflection to enable large scale content distribution. This is because existing network architectures strongly tie information to location, namely in the Domain Naming Service (DNS) and the routing/forwarding functions. However, DNS redirection and content reflection limit the flexibility of CDNs and increase the overlay complexity. This means that existing CDN solutions do not easily accommodate 5G+ edge architectures, which aim to reduce latency for content retrieval and improve routing efficiency to accommodate the anticipated growth in network capacity requirements. The need to address these issues is eminent in 5G+ networks, in order to support the expected shift in communications towards mobile services, where CDN is going to be pushed increasingly towards the edge.
Traditional CDNs are implemented through three intertwined overlays: the (user) mapping overlay, which directs the user request to the most appropriate CDN Point of Presence (PoP); the transport overlay, which disseminates content from the origin server(s) to the edge servers, such as for live-streaming; and, the routing overlay, used for the first two overlays. These overlays [1]- [3] are particularly visible in an Akamai [1] CDN, with the mapping overlay being responsible for assigning CDN PoPs to Local DNS (LDNS) points; and, the transport overlay facilitating edge-origin communication through application-layer multicast. This paper presents a novel CDN architecture that provides the features of these overlays while overcoming the limitations of CDNs by introducing a service routing architecture that allows greater edge integration.
Today, user mapping through request redirection is the main solution used by CDNs to provide anycast. DNS redirect relies on maintaining multiple IP addresses to a single fully qualified domain name (FQDN) and "mapping" the FQDN to one of the IP addresses, depending on the location of the IP addresses. DNS redirect is the cheapest form of the redirection, as it only depends on the DNS server location and incurs much less overhead than other forms of redirect, such as the HTTP counterpart. However, this mechanism relies on selecting a "nearest" PoP to the LDNS point, not to the client. This results in some scenarios having highly inefficient mappings; thereby, degrading the end-toend QoS while increasing load inside the network. Additionally, DNS was not designed to operate in a highly flexible manner to deliver agile service routing.
Once a user request is mapped, the transport overlay comes to bear and is particularly evident in streaming CDNs. Today, the transport overlay introduces a middle substrate of content "splitters", namely reflectors which scale up the dissemination of content from entry points (or originators) to edge servers. This is enabled through a form of application-layer multicast where a reflector acts as the splitting and replication point. Notably, the reflector substrate mainly compensates for the lack of scalable anycast/multicast support at the network layer. Therefore, it can be thought of as an expensive addition to provide a feature that ought to be natively supported by the network. This not only increases the network overall cost, by the added cost of the middle substrate of reflectors, but also results in sub-optimal routing between edge servers and origins through the use of unicast routing for traffic that could otherwise be transmitted using multicast, and through the inability of existing IP routing to adequately separate location from the service name.
This paper proposes a novel, flexible, CDN architecture for matching supply with demand, that eliminates DNS redirection and content reflection from CDN, while allowing for flexible, and highly agile, composition of anycast/multicast relationships; therefore, aiming to positively impact userlevel latency as well as network utilization. This is achieved by interpreting user requests to CDNs, as well as the transport from the origin server to CDNs, as a service transaction. We employ a novel service routing solution, directly realized over a L2 transport network. Such service routing eliminates the need for DNS and HTTP redirection, whilst utilizing an efficient, agile, L2 multicast solution for transport in the network and therefore removing the need for reflectors. In our evaluation, we focus on the efficiency gains of our proposed mapping, leaving the improvements of the transport for future work. For our realization, we utilize insights from the emerging research in Information-Centric Networking (ICN) that natively supports anycast, while path calculation and forwarding is facilitated through source-routing mechanisms that natively support multicast in the network. Whilst our realization is rooted in first deployments of real prototypes in early trials, our ideas are supported by first contributions to standardization, most prominently in the IETF. For this, we relate our ideas to that of Service Function Chaining (SFC), albeit elevating the service routing to the level of HTTP, leaving the routing decisions to a substrate similar to the one outlined in this paper. Within the SFC WG of the IETF, contributions to this effect are currently being discussed in [4]. An early realization of the service routing substrate has also been part of an ETSI Multi-access Edge Computing (MEC) proof-of-concept [5], which has showcased efficient content delivery for HTTP-level streaming as well as edge content retrieval in localized gaming.
Our contributions in this paper are threefold: 1) First, we describe the design of a novel, flexible CDN architecture, (fCDN) freed from DNS redirection and content reflection; and, instead, comprising a set of functions focused on providing content naming and CDN resource management. We present the CDN consumption and service points as edge clusters that communicate over a fast P2MP core. We describe the network function utilized in the core to provide edge-to-edge service routing and show how it can efficiently replace DNS redirection in providing anycast. 2) Second, we define the model to describe our proposed architecture and formulate the resource placement problem as a variance of the "K-center" problem. 3) Third, propose a novel greedy algorithm, namely Swing a variance of the Farthest First Travel algorithm to reduce edge-to-edge path; thereby, allowing for reducing the network requirements and end-user latency. We develop Monte Carlo simulations that explore values of K in Swing, and use that to identify a suitable parameter set that minimises the overall storage and network requirements.
The rest of this paper is structured as follows: Section II outlines the inefficiencies in mapping requests based on DNS redirection, and the userextension to DNS adopted to address these inefficiencies. Section III presents our proposal for a flexible CDN and describes how the network functions, the service routing required at the edge and the CDN functions. Section IV defines the mathematical model for placing and delivering CDN services, and Formulates the optimization problem for resource placement. Section V presents our greedy algorithm, Swing, and the reference algorithms compared against it. Section VI presents the performance evaluation of our proposed fCDN and the greedy algorithm Swing, and finally Section VII draw our conclusions.

II. RELATED WORK
Existing research shows that, in general, major CDN architectures, such as Akamai [1], [6] and Google [7], [8], are comprized of a set of overlays, particularly: the mapping, transport and routing overlays. We focus here on the mapping overlay, which relies generally on DNS redirection of requests to the nearest CDN PoP. To realise this behaviour in an operator's network, the mapping overlay assigns CDN PoPs to LDNSes; whereby, the nearest PoP(s) is assigned to each LDNS point. Notice here that nearest refers to the distance between the LDNS and the CDN PoP, not to the distance between end-users access nodes and the PoP. This means that in a scenario where a CDN PoP is located in an access node, but the LDNS point is not co-located in the same nodes, enduser requests will not be mapped to this nearest CDN PoP. Instead, end-user requests will be mapped inefficiently to remote PoPs. The severity of this issue has been quantified by [9] for public DNS resolvers; and, an extension to the DNS protocol to include the IP prefix of the client network has been proposed and deployed in major CDNs, such as that of Akamai and Google [9]. The solution of [9] only mitigates the problem, as it only provides one to one mapping between a subnet and a CDN PoP. Moreover, given the sharp increase in the size of the DNS state, the length of the IP prefix has to constrained, such that the DNS state remains manageable. A general agreement on /20 has been conveyed in [9], which translates into a subnet of up to 4094 users. While this has been a reasonably small subnet in existing networks; the push for mobile edge communications in 5G+ architectures is expected to demand considerably higher granularity.
The massive progress of CDN has paved the away for emerging research in Information-Centric Networking (ICN). ICN advocates for rethinking the design of the Internet to overcome the limitations mainly faced by CDN overlays [10], [11]. However, the ICN proposition to radically change the semantics of the communication paradigm, on a global scale, makes it considerably challenging to adopt ICN by operators; because, this requires massive update to current and legacy infrastructure. Migration approaches towards deployable ICN has been proposed in [12], [13]. The proposition of [12] is to deploy ICN on top of existing CDNs; thereby, inheriting the inefficiencies of DNS-based redirection and the suboptimal transport through reflectors, discussed in the Introduction. In contrast, [13] proposes to maintain IP services at the edge of an operator's network; while facilitating edge-to-edge communications a L2-like fabric in the core. The latter proposition paves the away for overcoming the inefficiencies of DNS redirection and content reflection, as we will show when describing our proposal in Section III. Next, we overview the proposition of [13] and describe the ideas we use from this for our proposal for flexible CDN.

A. IP-over-ICN
IP-over-ICN architecture has emerged as a feasible migration path towards ICN [13]- [15]. This is now moving from a research idea towards standardization as described in the Introduction [4], [5]. An IP-over-ICN architecture assumes an operator's network to consist of two parts: a set of IP networks at the edge; and, a Point-to-Multi-Point (P2MP) forwarding core that connects the edges. The core provides line-speed switching, and a set of network functions that facilitate matching supply with demand and create edge-to-edge paths. Those functions are: Rendezvous (RV), to provide naming, and Topology Management (TM), to provide routing [10], [16]. A programmable core with emerging technologies in Software-Defined Networking (SDN) is advantageous; provided proactive network management that does not introduce control delay. We utilise our solution in [14] to facilitate such a SND core. An IP edge is connected to the core through a Service Router (SR) that provides mapping of traditional IP-based protocols (IP, HTTP,..ect) to and from a namespace understood by the RV function. Furthermore, the SR translates the request/receive semantics into an equivalent publish/subscribe counterpart [13]. Clients requests are translated into publishing a request for a service, while a server listening for requests is translated into a subscription for requests by the bridging SR. Similarly, a server response is translated by the SR to a publication, while the client waiting for response is translated into a subscription.
The architecture above loosens the tie between information and location, as it treats an IP address, FQDN or URL as services, decoupled from the location of their actuators. Hence matching supply with demand is independent from location, where the latter's awareness is limited to the TM function to create edge-to-edge paths or multicast trees. This renders the DNS service irrelevant and not required to facilitate the communication paradigm. Furthermore, the Pub/Sub model is more aligned with the transport semantics of existing CDNs, which already uses a Pub/Sub model in the transport overlay; particularly that of streaming CDNs [6]. Forwarding in the core is enabled through fast functions (FW), such as that proposed by [17] and its variant suitable for SDN [14]. We utilise this architecture to propose our novel, flexible CDN (fCDN) solution in the following section. We show that by using the RV for matching supply with demand, we no longer need DNS redirects or DNS extension to provide mapping. Furthermore, the network is natively supporting multicast, thereby eliminating the need for content splitters.

III. FLEXIBLE CDN ARCHITECTURE
Based on the initial ideas of IP-over-ICN, described in Section II-A, the key aspect of formulating our CDN architecture is to interpret individual CDN servers as service endpoints where requests from users to CDNs, as well as from origins to CDNs, are entirely routed at the HTTP service level. The routing for the latter is realized through the ideas presented in the previous Section II-A. Following this logic, we propose a novel flexible-CDN architecture (fCDN), comprized of a set of functions providing labelling, resource monitoring/management and peering capabilities. Our proposal removes the mapping and transport overlays from CDN, and instead provides a simplified Pub/Sub mapping and transport capabilities in the network. This is achieved through a Path Computation Function (PCF), embraced from the ICN proposition described in Section II-A. We place our solution within the context of a local fCDN in an operator's network, and assume global fCDN to be a connected set of local clusters.
The proposed architecture is depicted in Figure 1(a). A network operator deploys a fastswitching, Point-to-Multi-Point (P2MP) substrate in the core; capable of performing stateless-multicast forwarding. Such a fabric may be facilitated with the Bloom Filter-based solution proposed in [17], its Bit-based variance in SDN [14], or the Bit Indexed Explicit Replication (BIER) solution [18], [19]. For the rest of this work, we will assume the solution of [14] to be the forwarding mechanism in the network core. Edge-to-edge routing in the core is facilitated through the PCF, which matches service requests (i.e., ICN publications) with service availability (i.e., ICN subscriptions), resulting in a suitable path calculation between the matching network elements, as described in [10], [13]. At the boundary of the core, SRs are presented in multiple points; connecting traditional IP-based clusters at the edge over the P2MP-core. The term "service" here refers back to the initial idea of IPover-ICN to interpret any IP-based service, such as HTTP, as a service transaction in the underlying ICN-based network. For this, each SR provides the essential feature of mapping those services to/from their respective pre-defined Information Identifiers (IIds), grouped under specific name-spaces. For our purposes of content delivery, we extend the existing mapping capability to provide aggregate content mapping and distribution in CDNs. The SR may have customisable variations to provide different features, depending on the IP edge connected to the function, be it an end-user consumption point or a service point.
For our CDN purposes, service points can be classified into: Entry Points and Edge Points. Entry points are nodes that have a stored data copy of all the content that is to be served in the network, for static content; and, have a direct link to content originators, such as broadcast studios, for live content. For the sake of simplicity, without loss of   Fig. 1. A functional and name-space views of our proposed CDN architecture. The functional view, (a), shows the central Path Computation Function (PCF) matching publications with subscription and creating source-routed multicast trees from the origin to edge service points and from edge points to consumption points of end-users generality, we refer to entry points as origins and the SR connecting an origin cluster as oSR. Edge points are service points placed closer to the enduser. They typically have constrained resources and hence only cache a subset of the static content, while fetching the rest (including live content) from origins. We refer to the SR connecting an edge service point as an edge Service Router (eSR).
The fCDN is presented as a set of functions to the network, freed from the DNS mapping and transport complexity of traditional CDN. Instead, the fCDN focuses on: defining service/managedcontent names; instrumenting the publish/subscribe behaviour of SRs in the service points, namely eSR and oSR; monitoring usage behaviour and optimising the utilization of fCDN resources; and, establishing peering relations with other fCDN clusters. We define three fCDN functions to provide these capabilities: Naming and Labelling Function (NLF): defines the size and aggregation scheme of information objects into aggregate managed objects, 'cacheable' in different service points, and provide them with Managed Object Names (MONs). This function is equivalent to the naming function in existing CDN mapping overlay. The function also disseminates service/managed-object names to the eSR and oSR and provides them with service-based publish/subscribe policies. Resource Monitoring and Management Function (RMMF): monitors consumption patterns and fCDN load, and, uses this information to manage the fCDN resources; i.e. how many service points are active in the network and the set of services/content they serve. This is essential to facilitate dynamic and temporal placement of virtual edge servers in highly dynamic networks. PCF Peering Function (PPF): manages peering policies, names distribution and path stitching between PCFs in multiple Autonomous Systems. Given that inter-domain routing is outside the scope of this work, we will give no further details here; leaving it to our future work.

A. Managed Service and Content Naming
The name-spaces to be supported in our proposed fCDN may vary for different services. Here we describe a HTTP-based name-space, focusing on HTTP-based services. We show through Figure 1(b) how the proposed fCDN architecture defines names for managed objects and their respective Pub/Sub relationships.
Managed objects are aggregate bundles of content, named and disseminated as individual objects. Such bundles may be collections of static (VoD) content, or bundles of live streams. Each managed object is given a Managed Object Name (MON); the format of which, is to be defined either by the fCDN provider or by the content provider, through agreement with the fCDN provider. This could be a wild-card URL, a 'stream identifier', and/or a service FQDN, as present in existing CDNs [6], [20]. Notably, the size of a managed object and the number of objects in a network is a fCDN design parameter, inherited from existing CDNs. This critically differentiates our proposal of naming managed objects from existing proposals to naming arbitrary objects in the Global Internet, such as [21], [22]. Our proposal allows for object naming within well-defined scalability metrics, such as the size of lookup tables and TCAMs entries. Therefore, it is generally expected to incur a much smaller (and manageable) state than that of the name space of arbitrary objects in the Global Internet. The HTTP and CDN name-spaces are illustrated in Figure 1(b), with exemplary FQDN, URL and MON. The 'http' root scope is accessible to all uSR, eSR and oSR to deliver HTTP services to end-users; while the 'cdn' root scope is dedicated to eSR and oSR only, and utilized to retrieve managed objects from origins or other edge service points. Details of the Pub/Sub interactions are described in the next section.

B. Publish/Subscribe Model
A service point, being an origin or an edge, registers a subscription under the 'http' root scope in the PCF for requests of all the FQDNs it is designated to serve to end-users. This resembles the action of a server listening for requests. The set of FQDNs to subscribe for is disseminated by the NLF of the fCDN. A service point willing to provide a cached object (a.k.a managed-object) to other service points also subscribes to the MON under the 'cdn' root scope. This resembles listening to requests of MONs, issued by other service points. When a provider point needs to respond to a request it publishes the same MON under the 'http' name-space. This publication is the response to the original request that was published under the 'cdn' root scope.

C. End-to-End Content Distribution
We describe end-to-end content distribution through a video streaming example by the mobile end-user in the network of Figure 1(a), both when content is already cached and when it is not. Figure 2 illustrates the sequence of messages exchanged between the different network functions to facilitate content delivery in this scenario. When the fCDN is started and updated, the NLF would determine the set of FQDNs/MONs to be serviced in the network, depending on the input provided by content providers. Meanwhile, the RMMF defines the number and location of service points in the network, as will be described in Section IV, and the set of FQDNs/MONs to be serviced by each point. Communication between the two functions results in a list of FQDNs/MONs to be distributed to the eSR and the oSR, by the NFL. Both the eSR and the oSR subscribes to the list of FQDNs, while only the oSR subscribe to 'cdn/MON' and only the eSR publish 'cdn/MON'. The PCF detects a match between a publication and a subscription, and provides the publisher eSR with a path to reach its 'best' oSR. To this end, the path is cached in the eSR, but the content is not necessarily requested.
A mobile end-user wishing to watch a HTTP video, would send a HTTP request request to its uSR. The latter maps the FQDN of the request to an information Id and publishes a FQDN request to the PCF, under the 'http' name-space. The PCF would then match the publication with all subscriptions from eSRs and oSRs that match the FQDN, and establish a delivery path between the uSR and the 'best' subscriber SR. In this case the best SR is the eSR closest to the end-user. The PCF supplies the path to the uSR, which uses it to forward the HTTP request to the eSR. The eSR extracts the HTTP request and passes it to its paired edge server. If the edge server has the information cached, it would respond back with the data through its eSR to the uSR and into the end-user. Contrarily, if the server does not have a cached copy, it will request the content from another server. The eSR, maps the request into a 'cdn/MON' publication. The PCF matches the 'cdn/MON' publication with existing subscription(s) to the same name and creates a delivery path from the eSR to the oSR. The PCF provides the eSR with the path, which is then used to send the MON request to the oSR. After which, the eSR subscribes for the oSR response under the 'http/MON' path. Meanwhile, the oSR receives the request and pass it to the origin server. The origin server responds back, through the oSR, with the managed-object identified by the MON. Once the edge server receives the content, it will respond to the end-user request with the video content. Figure 2 provides a detailed overview of these interactions.
When the content is VoD, the serving point may either be an origin or an edge, with a cached copy of the video; whereas, if the content is a live stream, the service point is the content originator. In the latter case, the origin is provided with a direct path to the edge service point, without the need for an intermediate reflector. Notably, the above operations are only required on the first packet, even in a chunk-based HTTP stream; whereby, requests for subsequent chunks are forwarded directly to the eSR. Using a source-routed forwarding solution such as that described in [14], [17], both the originedge, and edge-edge streaming can be multicast, as  Fig. 2. Detailed overview of exchanges between an End-User (EU) and surrogate, and between a surrogate and origin to facilitate content delivery to the customer it has been described in the previous Section III-D.

D. HTTP Unicast-to-Multicast-to-Unicast
Our architecture has a key advantage over existing HTTP streaming mechanisms [1], [6], that is the ability to spontaneously multicast the response back from the server to synchronous or quasisynchronous clients, be them end-users or edge service points. This advantage is critical in providing scalable content dissemination over the network. It provides a more flexible and dynamic substitution to the transport overlay of existing CDNs, using a network of reflectors. The improvement in flexibility and dynamicity in our solution stems from the ability to change the shape and size of the multicast tree, without having to adhere to predefined 'splitting' points; and, therefore, not having to address bottleneck challenges on the 'splitting' points. Moreover, unlike existing CDNs [6], [23], our solution not only supports multicast between the origin and the edge service point; but, also between a service point and user consumption point (i.e. end-users uSR pair). For a large number of users, our solution allows for scalable delivery of HTTP services using substantially less network capacity.
Following Figure 2, when a group of quasisynchronous end-users request new content (e.g. HTTP chunk), the uSR would only issue one publication to the PCF. The uSR then forwards a subscription to the HTTP response to the eSR, on behalf of each of the end-users. If these subscriptions fall within a pre-defined period of time, namely the catchment interval, the eSR would formulate a multicast group of one uSR and issue a single response back, using the unicast forwarding identifier -from eSR to uSR -provided by the PCF. If, supposedly, another uSR issues a subscription to the eSR response within the same catchment interval, then in this case, the eSR extends the multicast group to two uSRs and uses the two unicast forwarding identifiers to create a single multicast identifier, following the mechanism of [17] or [14]. The latter is used to multicast the response to the uSR.
Notably, in both of the cases above, the eSR passes only the first request to the server, while suppressing subsequent requests within the catchment interval; thereby, the server receives a single request; for which, it issues a single response. Intuitively, this reduces the load on the server by the number of requests falling within the catchment period. Similarly, when two or more eSRs subscribe to the content of the same MON within the catchment interval of the oSR, the latter would create a multicast group of the eSRs and publish a single, multicast, response back to them all. Moreover, while endusers are quasi-synchronous, edge service points can be orchestrated to subscribe for MON content within a predefined period; thereby, engineering the size of multicast groups according to the target capacity saving. Our analytical formulation in Section IV provides a formal definition of the average size and number of multicast groups and the relationship between that and the catchment interval and the total transmission period of content.
In an ideal scenario, content would be cached in every node. However, given constrained link, storage and processing capacities in current and future networks, optimized resource utilization and service delivery is critical to enable the expected growth in 5+G networks. Similar to [24], we assume a fCDN/operator collaboration to provide an accurate optimization of resources by the RMMF, depending on the conditions of the CDN and the operator's networks. Our collaboration comes in the form of exchanged CDN/network statistics between the RMMF and the PCF. Next we model our proposed CDN network and formulate the optimization problem facing the resource management overlay.

IV. MODEL AND PROBLEM FORMULATION
Here, we model our proposed fCDN architecture and formulate the optimization problem of dimensioning network and storage capacities. Notice that in our fCDN architecture, the publish/subscribe paradigm is carried out in both the request and response directions, with appropriate publish/subscriber roles as required by the nature of an IP transmission (publication) or reception (subscription). In the direction of requests from clients, service points act as subscribers for the request information; in contrast in the response direction service points act as publishers of the content associated with an FQDN or a MON. For the sake of simplicity and clarity, we will describe our model in relation to the response direction, where a service point assumes the role of a content publisher and the end-user or a non-cached edge service point takes the role of a content subscriber (hiding the fact that for bi-directional TCP/IP semantics the service point also acts as a subscriber when listening and the client publishes the first connection packet etc.).

A. Modelling Traffic
First, we model the overall collection of FQDNs and MONs offered by multiple content providers as a global set of ranked items I = { i, ϕ i , η i , ζ i |, i , η i , ζ i ∈ R + }, |I|= N ; where i is the information Id of the item, ϕ i is the probability of occurrence of i, η i is the network capacity required to deliver i and ζ i is the storage requirements to store/cache i. An information item i may be grouped under one of two name-spaces: either just the HTTP name-space or both the HTTP name-space and the CDN name-space, as shown in Fig III. Recall that the HTTP namespace is utilized for all HTTP communication between uSR and the e/oSR, whereas the CDN name-space is only used between eSR and oSR to fetch managed content, through their MON.
An operator's network is modelled as a directed graph G = {V, A}; having a set of vertices V , connected by a set of arcs A = { u, v | u, v ∈ V, u = v}. Each v ∈ V has a pre-defined storage and network capacities. The storage capacity is constrained by the amount of storage resources a CDN provider is willing to place on site of v. It can be defined as C = {c v ∈ R + | ∀v ∈ V }. The network capacity of a vertex, v ∈ V , is here defined as the total network capacity on all outgoing edges from the vertex to its neighbours where the link capacity on an outgoing edge is b u,v . We define the neighbourhood of u ∈ V as a subset V u = {v| v ∈ V, v = u, u, v ∈ A}. Thus, we define network capacity that vertex u can provide as and the overall network capacity, across all network links, as We assume a CDN provider plans to place in the network a set of origins O ⊆ V and a set of Origins, O, are large-scale data centers provided with storage and network capacities large enough to accommodate the content of all the items in the catalogue I. In contrast, edge service points, E, are nodes that are closer to the end-user and have tighter constraints on storage and network capacities than origins. The SR of all these service points behave as publishers, P = E ∪ O, of the content associated with the items in I; regardless of whether or not the content is actually stored in the server associated with the edge service point. Hence, edge points, specifically the eSR, may advertise the availability of an FQDN but they will not necessarily cache all the content associated with the FQDN. Nonetheless, provided with the information Ids of pre-defined MONs of the FQDN, an eSR may subscribe proactively to a MON, in the CDN name-space, to obtain and cache paths to the origins of the MON.
The network presents content subscribers, S ⊆ V , that are SR that are interested in advertized information. Subscribers may either be uSR, fetching content on behalf of their connected users; or, eSR, retrieving content for their edge servers that is not cached. A particular item, i, will have certain subscribers S i ∈ S that can be obtained from appropriate publishers P i ∈ P that have either cached the item or have a path to it. Notably, a single node can be both a publisher and subscriber for content. For instance a node connecting a set of end-users as well as an edge server to one (u/e)SR, belongs to both S and P . Thus often S i ∩ P i = ∅. In fact, in an ideal scenario, where all content items are cached locally, S i ≡ P i , ∀i ∈ I. However, given the significant operational and technical costs for content placement and distribution, often only a subset of items is advertized and/or cached, while the rest is delivered through the network from origins. The set, D, describes publishers and subscribers mutually interested in information for the items I and is D = { i, P i , S i |S i ⊆ S, P i ⊆ P, ∀i ∈ I} For each subscriber s ∈ S i of the ith tuple in D, the PCF creates a Pub/Sub relationship, λ i,s,p with a publisher p ∈ P i , defined as The overall set of Pub/Sub relationships of the ith tuple, Λ i , is defined as the set of all Pub/Sub relationships which match each subscribers of i to a publisher of i noting that for a set of subscribers for i there may be multiple publishers such that The challenge here is to determine: 1) how many publishers P to place in the network 2) how to split P between E and O, and 3) where to place O and E, such that the maximum distance to any s ∈ S is kept to a minimum. The first challenge can be addressed by reducing the problem to a variance of the "K-center" placement problem [25]. This problem is known to be NP-hard [25], [26] such that an optimum solution cannot be found in polynomial time. Hence we will address it through greedy algorithms and show that they provide a reasonably good and fast solution.

B. Storage and Network Requirements
To address the placement problem, we first model the storage and network requirements of the items with respect to both the publishers and the network. We define the choice of storage of an item i ∈ I, with storage requirement ζ i , at a publisher p ∈ P , as This means, the storage requirement of a publisher p ∈ P can be determined as: s.t. θ(p) ≤ c p , ∀p ∈ P (6) where the constraint of (6) ensures that the total storage demand of all item published by p does not exceed the storage capacity of p.
The network capacity required to distribute i is dependent on: 1) the subset of publishers selected to deliver to the subscribers, and 2) the number of streams established to deliver the content to the subscribers. To identify the number of selected publishers, we go back to Pub/Sub relationships Λ i of (4). We define the set of Pub/Sub relationships of i satisfied by p ∈ P i as: These relationships are the basis to calculate the expected load on the server. Next, we need to define the number of streams to be issued to S i,p by p. Recall here that each s ∈ S is either performing uSR or eSR, connecting one or more IP-based (HTTP) clusters. We define M s as the total number of HTTP clients connected to a node s ∈ S; and, m s,i ≤ M s as the number of HTTP clients requesting/receiving item i. Given the unicast nature of the HTTP semantics, we assume initially that the HTTP clients are provided through individual, parallel, unicast streams, ignoring the multicast capability of the architecture until later. Consequently, for each Pub/Sub relationship λ i,p,s ∈ Λ i,p , where s has m s,i clients, the capacity required on network link u, v to satisfy λ i,p,s is For publisher p, the network outgoing capacity required to deliver all Pub/Sub relationships of i is: where the subscripts on λ i,p,s have been dropped for brevity. Recall that V p ⊆ V is the neighbourhood set of p. Now, the total outgoing capacity to deliver all tuples of Λ is s.t χ(p) ≤ B p , ∀p ∈ P (11) where constraint (11) ensures that the capacity demanded from a publisher does not exceed its network capacity.
For any u, v ∈ A, the capacity required to deliver all Pub/Sub relationships of all tuples of Λ is

C. Network Requirements: Multicast
The definition of required link capacity in (8) is applicable to existing HTTP streaming mechanisms, both for static (VoD) and live content. However, our solution provides the ability to multicast the response back to a group of clients, if their requests happen to be synchronous or quasi-synchronous within a predefined catchment interval, as described in Section III-D.
To define the size of multicast group, and the number of multicast groups, let us first define T to be the total time period required to stream a video item i ∈ I. T is a relatively short time period, in the order of 0 − 2 hours; during which, the popularity of i is invariant [27]. Let us also define τ < T as the catchment interval. The questions now are: 1) how many users fall within a catchment period (i.e. size of a group), and 2) how many catchment intervals occur during T (i.e. number of groups formed). In an orchestrated synchronization of subscriptions, these can be engineered by the service orchestrator, e.g. CDN RMMF. However, when client subscriptions are only quasi-synchronous, the catchment interval can be triggered to start by the arrival of the first subscription to the serving SR. Here, the size and number of multicast groups is directly related to the request rate.
When delivering an item i to S i , multicast can be formed in two ways: 1) multicast to multiple clients behind a single subscriber s ∈ S i , and 2) multicast to a subset of subscribers of S i . and for popular items both mechanisms will be be present. To define the size of a multicast group triggered by a single s ∈ S i , let m t s,i be an independent number of HTTP clients subscribing for i at time t and triggering the start of a τ catchment interval. Recall in Section IV-B, we defined m s,i as the number of clients connected to s ∈ S and actively subscribing for i, thus we define m t s,i as the number subscribing time t. Now, the size of the multicast group triggered by s ∈ S during a τ duration interval at p is: The definition of (14) renders the multicast group size a time-dependent function.
To estimate the average multicast group size, we refer to the average subscription rate. Since the client subscriptions are independent from each other, the number of subscriptions per catchment interval is assumed to have a Poisson distribution. Moreover, since the popularity of the item is invariant across T , the Poisson distribution is assumed homogeneous, as confirmed by the findings of [27]. Hence, the arrival rate of requests from s for item i as µ s,i (inter-arrival rate 1/µ s,i ) is µ s,i = m s,i /T and the average group size isγ p,i = µ s,i τ .
So far, we have defined the size of a multicast group triggered by a single s ∈ S i . This translates into a single multicast stream to deliver the content as opposite to an average number of unicast streams µ s,i per interval τ . Now, to define the size of a multicast group that spans a subset of subscribers of S i , we refer back to the Pub/Sub relationship Λ i,p of (7). This set of relationships results in creating a single source multicast tree, with multicast groups triggered by each s ∈ S i,p . The question here is: how many of these groups are synchronous with each other, as those can be merged into a single multicast tree from the publisher p. To answer this question, we consider the total number of clients actively independently subscribing for i during the time period T . For a large number of clients, the exponentially distributed inter-arrival time between events is small; and it gets smaller as the number of clients increase. This translates into increasing likelihood of triggering catchment intervals with smaller time gaps between them. Accordingly, the average group size is lim m s,i →∞γ This means that in a particular interval of length τ , a single multicast stream is used to deliver the content of i as opposite to an average s∈S i,p m s,i unicast streams. Next, we determine the number of catchment intervals triggered at p for the entire period of the content T . This translates into number of multicast streams that need to be accounted for in the network. First, let ω s,i be the number of catchment intervals triggered by s ∈ S i within the Pub/Sub relationship λ i,p,s and during time period T . This means that on average s divides T into intervals : Using (16) we can now describe the average number of catchment intervals,ω s,i , as a function of T :ω Now, for Λ i,p set of relationships originating from p, each s would be generating on averageω s,i , ∀s ∈ S i . For a small number of clients, the likelihood of synchronized triggering of w s,i is small. However, as the number of clients in the network increases, the likelihood of having synchronized triggering of catchment intervals increases, as the weight of the term T /µ s,i in (17) decreases, rendering the average number of multicast groups a function of T and τ . In this case the average number of multicast streams triggered at p is:ω p,i ≈ T /τ (18) Now, assuming (18), we can obtain the mean network capacity requirements on a network link u, v to satisfy the Pub/Sub relationships Λ i,p as And, the total capacity requirement on u, v as Clearly (20) is highly dependent on the choice of publisher, paths and underlying network topology.

D. Problem Statement
Given the network and communication model presented in Section IV-A; and, the storage and network capacity requirements, defined in Sections IV-B and IV-C, we define the network dimensioning problem as a multi-objective, weighted, minimization variance of the "K-center" problem:

Definition:
Let K = |P | is the number of service points a CDN provider is planning to place in a network. Goal: Find a set of origin points O ⊆ P and a set of edge points E ⊆ P , such that |E|+|O|= K, and: min ∀p ∈ P, u, v ∈ A Subject to: the storage capacity constraint of (6); the link capacity constraint of (13); the network capacity constraint of (11); and, traditional flow conservation constraints Next, we describe our proposed greedy heuristic algorithm to solve this problem. We compare it later on in our Evaluations VI against reference heuristics based on node closeness centrality or population size.
V. ALGORITHMIC SOLUTIONS The "K-center" problem is found to be NP-hard; that is, an optimal solution cannot be found in polynomial time. Consequently, here we propose a fast greedy algorithm to find a near-optimum solution of good quality and within small period of time. We first relax the constraint of (13) by assuming the network to have infinite capacity i.e. that the operator has to provide the capacity to meet the needs of the users. We then use χ( u, v ) as a dimensioning metric to estimate required network capacity, later, in the evaluation, we will compare this need under different scenarios.
Our proposed algorithm, given in Algorithm 1, is a variance of the Farthest-First Traversal (FFT), namely Swing. Swing objectives is to minimize the distance between a service point and the farthest consumption point. To achieve this objective, the algorithm attempts to spread the service points as wide as possible in the graph, between highly connected nodes and furtherest nodes from the graph center. The difference here is that the node selected next may not necessarily be the farthest node from the current one, but it is the opposite on the scale of connectivity in the graph. The algorithm takes as input: the network graph, K the number of selections and the V × V Distance matrix, ∆. Here, Distance refers to the minimum cost path between a source and a sink nodes; where cost may be represented by various metrics, such as the hop count.
First, Swing builds up two sets of candidates for selection: the primary set Φ and the backup, secondary, set Φ . Each element in the sets is a vertexdistance pair, κ, δ , the distance part of each pair allows for evaluating the "goodness" of the vertex part of the pair; whereby, shorter distance translates into higher goodness. To compose the sets, Swing iterates over all vertices of the graph, steps 8-14; for each vertex u, calculates the connectedness of its neighbourhood set V u . Connectedness here is defined as the sum of all distances from the neighbour v ∈ V u to all other vertices. The neighbour with the best connectedness, i.e. minimum total sum of paths length, is added to the primary set Φ, whilst all other neighbours in V u are added to the backup set Φ . Once the sets of candidates are complete, Swing will make K selections of service points from the primary set, then from the backup set if needed, i.e. when K ≥ |Φ|. When selecting from a candidate set, steps 16-21 or steps 22-29, Swing either chooses a candidate with the best connectedness Φ[δ min ] , if k has an odd value in the range; or, it will select a candidate with the worst connectedness Φ[δ max ], if k has an even value in the range. Once a candidate is selected i.e. added to the selected set Ψ, it is removed from the candidacy sets and subsequent selection will be made from the remainder of the sets. The performance of the solutions provided by swing is highly dependent on the topology of the graph. Here, we highlight this dependency and parametrise common behaviour of the algorithm.

A. Reference Algorithms
We compare the performance of Swing against two reference greedy algorithms, namely Largest First selection (Pop) in Algorithm 2 and Closest First selection (Cls) in Algorithm 3. Pop calculates for each vertex v ∈ V the ratio of the population of the node to the total population in the network, ρ v . It then uses ρ in a probability based selection function SELECT . This means the K vertices with largest population have the highest likelihood of selection. On the other hand, Cls calculates the relative closeness centrality of each vertex to the total centrality of all the vertices in the graph, ρ. It uses ρ as the selection probability in the function SELECT . That is, the K most connected nodes have the highest probability of selection.
Next, we evaluate the performance of our proposed architecture and compare it to that of tradi-Algorithm 1 Swing(G(V, A), K, ∆) for all v ∈ V u do 10: ensure set uniqueness 16: if K < |Φ| then 17: for all k ∈ 1 . . . K do 18: end for 22: else 23: Ψ ← VTX(Φ) 24: K ← |Ψ|+1 25: for all k ∈ K . . . K do 26: 27: end for 29: end if 30: return Ψ tional CDN with DNS redirection. We Also compare our algorithm Swing against the reference algorithms and show its advantages and disadvantages in various scenarios. Moreover, we explore the parameters space and use that to determine best range of K for both origin and edge service points.

VI. EVALUATION
Here, we analyse the performance of our proposed architecture with respect to the dimensioning parameters and quantify the savings in network Algorithm 2 P op(G(V, A), U, K) ← SELECT(f rom = V, size = K, probability = δ) 6: return Ψ resources and improvements in edge-to-edge communications. This is reflected in three parameters: path length, network capacity and storage capacity. Furthermore, we analyse the network capacity gain when delivering through multicast as opposite to unicast in fCDN. We also analyse the performance variability of the placement algorithms within the space of parameters. As described in Section IV, our dimensioning problem can be reduced into a multiobjective variance of the K-center problem, which is known to be NP hard. We do not optimise primarily for K, but rather explore the parameter space to identify the number of origins and service points that would minimize the joint storage and network requirements. Moreover, we explore the space of catchment intervals for different video lengths and quantify benefits of different catchment intervals for different video lengths.

A. Evaluation Model
We model our proposed architecture analytically over a realistic network graph from the Internet Topology Zoo [28], namely Geant 2012 G(V = 37, A = 116). We use a synthetically generated content catalogue of 1000 items having a Zipf popularity distribution of exponent 0.8, following the range of accepted fits for content popularity distribution [27], [29]. Each item is characterized by: 1) probability of occurrence, drawn from the Zipfian popularity distribution, 2) bitrate value, randomly selected from the range {20, 40, 60} Mb/s, and 3) a storage volume randomly selected from the range {20, 40, 60} MB. The ranges of bit-rates are selected within the common range of bit-rate to support different HD/UHD video formats [30]. Moreover, the popularity distribution is invariant across all nodes in the network.
To model the subscription rate, we first estimate the network population using the global LandScan population database [31], combined with a standard Voronoi tessellation model associating each potential user to the nearest network node. We consider on average 40% of the population of each node are active users; triggering subscriptions for content in the catalogue. The number of subscriptions per item, in each node, is drawn from the probability of occurrence of the item.
The publication model considers K = K o + K e incremental number of publishers in the network, split between origin K o = {2, 4, 6, 8} and edge K e = {2, 4, 6, 8} service points. Origin and edge points are placed at different nodes in the network; where the nodes are selected by one of the selection algorithms, i.e. Swing, PoP or Cls. Origins do not have constraint on their storage capacity, hence they are able to cache all the items. Edge points are constrained in storage capacity, where they only cache a subset of the items, while retrieve the rest from origins. To identify which items will be cached in each edge point, we first reverse engineer equation (5) by estimating first the total storage capacity of p, then use a probability-based pseudo random caching policy; whereby, items of higher popularity have a higher likelihood to be selected for caching. The storage capacity can be constrained following different considerations. Here, we assume the capacity placed in each edge point to be relative to the capacity that may be placed in the node with largest population, should it be selected by the optimization algorithm. We base this assumption on the fact that the node with largest population is the node that would require the largest set of items to be cached; thus smaller nodes would require storage resources relative to that of the largest node. To model traditional CDNs we further introduce an incremental range of LDNS points, K d = {2, 4, 6, 8}; the placement of which, is provided by the selection algorithms described in Section V. Notably, the set of nodes selected to provide LDNS may overlap with the set of publishers. We discuss through the results the importance of this overlap for current CDNs and some of the inefficiencies that may occur if it is not maintained.
Within the model above, we run 50 tests of randomized publications and subscriptions for: CDN with DNS redirection, fCDN when delivery is unicast, fCDN when delivery is multicast. Routing is facilitated through Dijkstra's shortest path algorithm, where path length is measured in hopcount. Notably, given the deterministic nature of Swing, only subscriptions are random in each tests. fCDN is modelled for a set of video length values T = {900, 1800, 2700, 3600} seconds, and a set of catchment intervals τ = {0.1, 1, 10} seconds. Next, we present our results observed when modifying different parameters.

1) Path Length:
Here, we analyse the path length from three perspectives: the converged range of path lengths in CDN and how it compares to fCDN, variations in this convergence for CDN in response to varying the number and position of LDNS points, and the performance of the placement algorithms. Figures VI-B1 and VI-B1 shows the empirical cumulative distribution function of all the paths in the CDN with DNS reduction and in fCDN respectively. Due to complexity constraints we show IP path length for the minimum and maximum number of LDNSes, {2, 8}. The results show that when the number of LDNS points is small, 2, approximately 5% of the paths has a zero-length. Those reflect localized demands, where the node has a service point (origin or edge). The highest path length is 15 hops and approximately 90% − 92% of the paths are 4 hops or less. Notably, increasing the number of service points alone, i.e. without a comparable increase in the number of LDNS points, does not introduce a noticeable decrease in the path length. It is only when the number of LDNS points increases, 8, that a reduction is witnessed. In this case, between 10% and 20% of paths are of zero length, whereas the maximum path length varies between 14 and 16 hops depending on K o number of origins. Convergence varies as well; when K o number of origins is 2 the variation between the different algorithms is distinguishable. Nonetheless, proximately 90% of paths are of 3 hops. When K o = {6, 8}, around 87%-88% of the paths are of 2 hops. This behaviour is purely due to the inefficiency in mapping requests based on DNS redirection, where the service point is selected closest to the LDNS but not necessarily closer to the consumption point. This means a node might have a service point placed at its site and has a cached copy of the item of interest, but if the LDNS is remotely located and adjacent to a farther service point, requests of the node will be mapped to the remote service point rather than itself. This leads to a rigid constraint on co-locating LDNS points with edge or origin service points when dimensioning a CDN network, , to avoid inefficient request mapping.
In contrast, we observe in Figure VI-B1 that path lengths in our proposed fCDN are considerably shorter that their counterpart in traditional CDN. For a small number of origins K o = 2, 20% to 30% of paths are of length zero; for larger K o = 8, 30% to 40% of paths are of length zero. This indicates around 2−4 fold increase in the number of localized demands due to accurate request mapping. Maximum path lengths also show a considerable reduction from 14 hops in best case to 10−12, when K o = {6, 8}. Moreover, when the number of service points is small, K o = 2 and K e = 2, approximately 90% of paths are of 2-3 hops. As the values of K o and K e increases to 8 each, more than 95% of paths reduces to 2 hops. Notably, when comparing the algorithms behaviour, we observe that Swing facilitates significantly shorter paths compared to Pop or Cls. On the left hand side of Figure VI-B1, When Swing is used to place services, approximately 99% of paths are of 3 hops with the longest path being of 7 hops as apposite to 13 and 14 hops by Pop and Cls respectively. On the right hand side of the same figure, approximately 99% of paths associated with Swing are of 2 hops with maximum path length between 5 and 15, depending on K e number of surrogates. Similarly, in Figure VI shows the required backhaul capacity to accommodate a total theoretical demand of 70 Gb/s, in both CDN and fCDN respectively. For CDN with DNS redirection, the backhaul capacity is directly tied to the number of LDNSes placed in the network. For a small number of DNSes, K d = 2, tuning the other K o and K e has negligible impact on the required backhaul capacity; however, as K d increases, the impact of increasing K e and K o increases. In all cases the average required backhaul is approximately between 100 and 200 Gb/s, making 1 − 2 folds of the demand.
In contrast, the backhaul capacity of fCDN is highly dependent on the number of service points K e and K o . Figure VI-B2 shows the backhaul capacity required in fCDN for the two dissemination modes: unicast and multicast. For the latter, we assume a fixed video length of 900 seconds and we vary the catchment interval in the period {0.1, 1, 10}. For a small number of edge points, K e = 2, the backhaul capacity required for unicast is approximately 115 Gb/s, averaged for all algorithms, i.e. 2 folds of the demand. However, as the number of origins increases to K o = 8, the backhaul capacity drops to ≈ 65 Gb/s that is lower than the offered demand of 70 Gb/s. Similar reduction is observed when fixing the number of origins to K o = 2 and increasing K e gradually from 2 to 8 where the backhaul traffic drops from ≈ 115 Gb/s to ≈ 70 Gb/s. This reduction in backhaul traffic is a result of localising substantial portion of the offered demand, due to accurate request mapping to the nearest service point. Backhaul traffic can further be reduced when delivery is multicast, depending on the catchment interval τ that can be achieved. When τ = 0.1 second, an approximately 15% reduction in backhaul traffic is observed; and, when τ = 1 second, the reduction ratio increases to ≈ 50%. Notably, as the catchment interval increases, the difference in performance between the algorithms decreases. Notice that a catchment interval of 10 seconds is unrealistic as it introduces substantial delay to the down time and affects the users' perceived Quality of Experience (QoE). Nonetheless, we include this value to give an indication for the further improvements that can be achieved with realistic 1 ≤ τ ≤ 10 values.
Notably, the results also show that the difference in capacity requirements is small when K e = 2 and K o = 8 as opposite to the combination of K e = 8 and K o = 2. This indicates that given a number of publishers K = K e + K o , increasing the caching points as opposite to increasing the advertising points, with the content not cached, does not largely affect the backhaul capacity. This translates into possible savings in the storage capacity, without added cost on the network, as we will see later in Section VI-B4.
3) Multicast Gain: Here, we analyse the network capacity gain when delivering content over multicast q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q LDNSes:  trees. We show how the multicast gain is affected by the catchment interval and the video length, as described in (18). The multicast gain has been evaluated for catchment intervals τ ∈ {0.1, 1, 10} for an average video length T = 900 seconds. For a catchment interval of 0.1second, the multicast gain is ≈ 1.25; whereas, for τ = 1 second the gain is between 1.4 and 1.8. The results here are aligned with the approximately 2 fold reduction in backhaul capacity, when the catchment interval is 1 second. Higher gains can be realized with higher τ When considering different video lengths T ∈ {1800, 2700, 3600} seconds. The results indicates that the average backhaul capacity and gain maintains similar profile to that of 900 seconds. However, for a fixed τ , videos of higher length will offer smaller capacity gain. This is expected as the average number of subscriptions decreases for longer videos, given the homogeneous Poisson distribution, described in Section IV.

4) Storage Capacity:
Here, we analyse the storage capacity required in the network when increasing the number of edge points K e for a fixed number of origins K o ; and, when increasing K o for a fixed K e . We illustrate this by calculating the theoretical total volume of all items; that is, the total volume if all items are stored in all selected nodes, i.e. K = K o . We then compare the ratio of volume of all items that have been cached and advertized with the ratio of volume that has been advertized, but not been cached. Figure 5 illustrates the storage requirements for K e ∈ {2, 4, 6, 8} and K o ∈ {2, 4, 6, 8}. For a small number of edge points K e = 2 and large number of origins K o = 8, only 25% of the total volume is cached. In contras, when K e = 8, K o = 2, approximately 60% of the volume is advertized but not cached, while only ≈ 40% of the volume is cached. When comparing this result with that of Figure VI-B2 for backhaul capacity, we find that the difference in cached vs. not cached does not have a significant impact on the backhaul traffic, as long as the content is advertized by all nodes. This means, advertising the availability of content without necessarily caching it is sufficient enough to localise the offered demand. This is because edge points retrieve content from the origins always through orchestrated multicast, which reduces the amount of backhaul traffic to substantially small values.
From the results presented so far, we can draw two general views: first, increasing content visibility through larger number of edge points that advertise the content but not cache it, while dimensioning a low number of origins, allows for reducing both storage and backhaul capacity requirements, while accommodating the offered load. Second, backhaul capacity can further be reduced and capacity gain can be obtained, when delivering over multicast trees rather than unicast paths. The gain in backhaul capacity due to multicast is subject to the variation of the catchment interval, τ . A significant 50% reduction can be achieved, when setting τ = 1 second.  Here, we proposed a novel and flexible CDN (fCDN) architecture that eliminates two of the major inefficiencies in existing CDNs, namely the suboptimal request mapping due to DNS redirection and the suboptimal routing by the transport overlay. Instead, our proposed fCDN facilitates anycast request mapping and multicast routing directly in the network, through a Publish/Subscribe matching function embraced from emerging research in ICN. Furthermore, to facilitate service placement, we formulated the problem of service placement as a variance of the K-center problem; and, proposed a novel greedy algorithm,named Swing, to solve it. We evaluated the performance of our architecture, and the proposed algorithm, with respect to request mapping using synthetically generated demands over realistic network topology. Our evaluation results showed that increasing the number of advertising edge points, for a fixed number of origins is preferable over increasing the number of origins for a fixed number of edges.