Patent Application
20170054627
The field of this invention is that of Information Centric Networking (ICN).
More particularly, the invention relates to an ICN router.
Information Centric Networking (ICN), is an alternative approach to the architecture of computer networks. Its founding principle is that a communication network should allow a user to focus on the needed data, rather than having to reference a specific, physical location where that data is to be retrieved from. This stems from the fact that the vast majority of current Internet usage (90%) consists of data being disseminated from a source to a number of users.
ICN has introduced a new networking model, where the communication is centered on named-data rather than host address. Indeed, in ICN every data packet is identified, addressed and retrieved by its unique name instead of its physical location.
Among the several ICN architectures that have been proposed in recent years, the best known example is represented by the Content Centric Networking (CCN), also known as Named Data Networking (NDN). While ICN architectures generally differ in a number of choices (e.g., flat vs hierarchical naming strategy, routing and forwarding strategies, granularity of minimum addressable entity, etc.), they however generally have common points—such as featuring caching functionalities as primitive in the architecture. Since a common terminology that encompasses all ICN proposals is currently missing, in this context we adopt the CCN lingo for the sake of clarity, but we point out that our approach is applicable to a greater extent.
Thus, in ICN all network nodes (routers) potentially store a content (which is split in “chunks”, i.e. elementary fragments of data with a given size, in other words “blocks”) that they forward to serve future requests for the same content. Therefore, it is possible to equip network nodes with enhanced storage capabilities such as caches/buffer memories. Indeed, storage resources can be used to maintain temporary content replicas spread through the network for a period of time ranging from minutes to hours or days. The availability of different replicas depends on several factors, such as content popularity, cache replacement policies, and is impacted by the request forwarding policy. The term “request forwarding policy” refers here broadly and as non-limitative, to ways/rules to manage the forwarding of a content request within a network comprising nodes. In fact, request forwarding policy plays an important role in providing better end-users performance (ex: data delivery time) and reducing the amount of data transferred in a network, i.e. providing a lower network load.
In practice, the success of ICN architectures depends on their ability to provide large caches, able to process data traffic at line speed. It has been pointed out that these two requirements tradeoff: due to technological limits of currently available memory technologies, state-of-the-art sizes to about 10 GB the largest cache size that can sustain over 10 Gbps speeds.
Notably, two main performance aspects need to be considered for ICN caches. First (i), ICN routers perform lookup on the content names, in order to decide whether an interest can be satisfied locally by cached content, or whether it needs to be forwarded. In case of a match, (ii) the lookup returns a pointer to the memory region storing the content itself, that needs to be transferred to assemble a response packet.
Operation (i) requires to move small amount of data, and its main performance indicator is thus the memory access latency. In order to sustain line rate operations, the memory index must be accessed at a frequency that in the worst case matches the throughput of the maximum sustainable data rate. In other words, assume that the aggregate router data rate is R, that data chunks have size Sc (generally a few kB), then the maximum number of chunks that can be transferred in the time unit is R/Sc, that also upperbounds the number of accesses to the index, so that taccess ≦1 R/Sc.
Operation (ii), instead, depends on the chunk size, and can be either driven by access latency (in case of small chunks) or by the external data rate, i.e. the sustainable throughput when reading random memory blocks
In the document “A reality check for content centric networking”, by D. Perino and M. Varvello (in ACM SIGCOMM ICN workshop, 2011), a state-of-the-art core ICN router is designed to support 8×40 Gbps interfaces serving SC=1500B chunks, stored on a 10 GB DRAM (“Dynamic Random Access Memory”) cache implementing sequential access and LRU replacement policy, indexed on a 100 MB SRAM (“Static Random Access Memory”) chip by employing H=40 bits long content names hashes.
However such a memory size appears insignificant with respect the digital data consumed worldwide, and ICN success is conditioned to the feasibility of large content stores. As such, it would be desirable to include technologies such as SSD “Solid State Drive” (or even HDD “Hard-Disk Drive”) to scale up the cache size up to some TB. Even if the document “A reality check for content centric networking” proposes an edge router design where a 1 TB SSD cache is indexed by a 10 GB DRAM chip, such design is not usable for core ICN routers, as the high memory access latency of SSD (at least 30 μs) bottlenecks operations (i) and (ii) on the memory: a maximum (and insufficient) speed of 0.5 Gbps is reported.
Therefore, there is a need for a simple yet inexpensive and effective architecture that scales up ICN caches to multi-Terabyte size while maintaining multi-Gbps line-speed operation.
For these purposes, the present invention provides an ICN router, comprising a first cache layer and a second cache layer, the first cache layer comprising a first content memory and the second cache layer comprising a second content memory the second content memory having a higher capacity but a slower access speed than the first content memory, the router being configured so that the first cache layer is adapted to fetch data from second cache layer when the router is requested to output said data,
Taking advantage of correlation among chunks, the present ICN router uses request arrivals in the ICN data plane as predictors of requests for subsequent chunks. A number of chunks are then proactively moved from the large but slow second content memory (e.g., SSD) to the swap area of the fast but small first content memory (e.g., DRAM). Additionally, by batching memory transfer operations over multiple chunks, occurs a transition from an operational point where SSD is dominated by memory access time, to an operational point where SSD external data rate is the bottleneck—gaining over an order of magnitude in terms of sustainable data rates. Finally, the system may be further optimize to yield low startup latency (e.g., for video streaming) by storing the first chunk of a large portion of the catalog directly in the fast first content memory (trading with swap area).
Preferred but non limiting features of the present invention are as follow:
the first cache layer further comprises a first index memory indexing blocks of the first content memory, and the second cache layer further comprises a second index memory indexing blocks of the second content memory;
the first content memory has a higher capacity but a slower access speed than the first index memory, and the second content memory has a higher capacity but a slower access speed than the second index memory;
the ICN router further comprising a third cache layer comprising a mass memory having a higher capacity but a slower access speed than the second content memory, the router being configured so that the second cache layer is adapted to fetch data from third cache layer when the router is requested to output said data;
the first content memory further comprising a start-of-video area wherein is stored at least the first block of a plurality of contents stored in the second content memory;
the contents having at least their first block stored in the start-of-video area are the contents of the second content memory which are the likeliest to be requested.
In a second aspect, the invention provides a method for accessing content at an ICN router, characterized in that it comprises steps of:
Preferred but non limiting features of the present invention are as follow:
the step (a) further comprises searching for a first block of the requested content in a start-of-video area of the first content memory;
at least the first block of the requested content is stored in the start-of-video area the step (b) simultaneously comprising sequentially serving in response to the request blocks of the requested content which are stored in a start-of-video area;
the requested content is a video to be played, the method comprising a step (d) of, when receiving at the router a request for pausing the serving of the video, further sequentially serving at least one block at the first block size, and when receiving at the router a request for resuming the serving of the video, performing again steps (b) and (c) from the last block served.
According to a third and a fourth step, the invention provides a computer program product, comprising code instructions for executing a method for accessing content at an ICN router according to the second aspect of the invention; and. a computer-readable medium, on which is stored a computer program product comprising code instructions for executing a method for accessing content at an ICN router according to the second aspect of the invention.
The above and other objects, features and advantages of this invention will be apparent in the following detailed description of an illustrative embodiment thereof, which is to be read in connection with the accompanying drawings wherein:
Referring to
From
Hence, it may be argued that a system design moving SSD bottleneck from memory access time to external transfer rate could possibly gain over an order of magnitude in terms of the sustainable rate (up to 40×-48×). Additionally, given large SSD size, favorable performance in terms of caching should be expected as well.
Referring to the
The router 1 comprising a first cache layer L1 and a second cache layer L2, the first cache layer L1 comprising a first content memory 11 and the second cache layer L2 comprising a second content memory 21, the second content memory 21 having a higher capacity but a slower access speed than the first content memory 11.
The router 1 is configured so that the first cache layer L1 is adapted to fetch data from second cache layer L2 when the router 1 is requested to output said data. In other words, the system is organized as a hierarchy of caches: a (multi-Terabyte) L2 cache masked behind a small L1 cache able to operate at (multi-Gbps) line rate. The idea is that L1 should contain chunks of ongoing videos for fast service in the data plane. Conversely, L2 is large but slow, so it can store a significant portion of the catalog, that it needs however to opportunely prefetch to L1.
To this end, the first content memory 11 presents a first block size and the second content memory 21 presents a second block size, the second block size being higher that the first block size (and in particular being a multiple of the first block size). Optimal block sizes will be given later.
The first content memory 11 comprises a “swap area” 110 through which the first content memory 11 is connected to the second content memory 21. The swap area 110 is adapted for individually serving blocks at the first block size as parts of blocks at the second size fetched from the second content memory 21. Blocks at the second size are thus treated by the swap area 110 as a batch of blocks at the first size.
In other words, the swap area 110 is adapted for outputting at the first block size data fetched from the second content memory 21 at the second block size. For example, if the first block size is 4 kB and the second block size is 64 kB, the swap area 110 converts a 64 kB-block from the second content memory 21 into sixteen 4 kB-blocks of the first content memory 11. In ICN, objects are split in multiple named chunks, so that a request for a named chunk can be used as predictor of subsequent requests for other chunks belonging to the same object. This suggests to proactively trigger prefetching operations, operating over batches of chunks, so as to sustain high transfer throughput at L2. More precisely, the first size can be chosen as the chunk size, and therefore a block at the second size is a batch of consecutive chunks
Thus, the first (small but fast) cache L1 serves small blocks individually, whereas multiple small blocks are moved from the second (large but slow) cache L2 to the swap area 110 of the first content memory 11. This circumvent latency problems in accessing small blocks in the second cache L2, whereby accessing larger blocks (storing a batch of multiple small blocks) implies achieving high memory transfer rates while avoiding per-block latency penalty at the same time.
To sum up, providing the L1 with batches of chunks allows the L1 to serves theses chunks one by one at maximum speed, further circumventing the L2 performance limitations when chunks are treated individually by operating on batches of chunks at L2.
In a preferred embodiment using current storage technologies of
As already explained, the chunk size (i.e. the first block size) is the minimum data object granularity. Small chunk sizes are preferable (e.g., to avoid paying a padding penalty for a myriad of small objects). Clearly, as the chunk size determines the frequency of all system operations, a larger chunk size is also beneficial as it relaxes the system complexity. Currently ongoing effort already employs larger chunk sizes of about 4 kB, so that we consider chunk sizes between 2 kB and 20 kB, preferably 10 kB, to be a reasonable compromise. Yet, efficient memory transfers require larger read/write size, so that it is necessary to batch B chunks in order to achieve a batch size that allows sustaining high external data rates. As SSD achieves 20-24 Gbps in random read of 64-128 KB from
Thus, the router 1 is designed so that the L2 external data rate is the bottleneck. It is also to be noticed that the PCIe bus supports IO data rates up to 64 Gbps, so that it is possible to use multiple parallel SSD for an additional gain.
Advantageously, the first cache layer L1 further comprises a first index memory 12 indexing blocks of the first content memory 11, and the second cache layer L2 further comprises a second index memory 22 indexing blocks of the second content memory 21. Cache indexes are accessed at each name lookup in the data-plane: whenever an interest packet hits the router, if the name is present in the index, the index contains the memory location of the corresponding named data in the storage memory.
Thus, at each level caches are organized into a classical (index, storage) pair. It is wishable for the first index memory 12 to be faster than the first content memory 11, and similarly for the second index memory 22 to be faster than the first content memory 21. At the same time, since memory indexes only have to store pointers to locations in the content memory where objects are located, it follows that indexes memories 12 and 22 are of much smaller size with respect to content memories 11 and 21 respectively.
Consequently, in the preferred embodiment of the present ICN router (as represented in
Currently available off-the-shelf technologies allows a first index memory 12 with a capacity comprised between 20 MB and 200 MB (preferably about 100 MB), and a second index memory 22 with a capacity comprised between 2 GB and 20 GB (preferably about 10 GB).
As represented in
This L3 could be useful for increasing the size of L2 in an inexpensive way. A third bloc size (superior to the second block size) may be used for the mass memory 31. This would also require to manage part of the second content memory 21 as a second swap area 210 that temporarily stores content of the mass memory 31, and which is adapted for individually serving blocks at the second block size as parts of blocks at the third size fetched from the mass memory 21.
The ICN architecture is particularly useful when requested contents are videos. Nowadays Internet streaming is dominated by portals such as YouTube, Kankan, Hulu, etc. In terms of networking, video traffic can be specified by the (average) streaming rate that the network needs to sustain in order to avoid stutter in the playback.
The streaming rate depends, on the one hand, on technological limitations of the physical display, and, on the other hand, on the availability of content encoded at that resolution. Despite physical resolution steadily increases (e.g., 4 K displays were recently shown), such extremely high definition content is not readily available in the consumer market.
As such, most of the freely available Internet content is generally streamed at a much lower rate. For instance, the default video resolution of popular free services such as YouTube is 640×360, is encoded with H264 at a median rate of 500 Kbps, according to measurements. Even popular paying services such as Netflix, offer only a minor part of their content at HD (1280×720, 5 Mbps) or FHD quality (1920×1080, 7 Mbps). Consequently, the size of an average streamed video is between 10 MB (low quality) and 100 MB (high quality), i.e. between 1,000 and 10,000 chunks.
The present ICN router 1 propose to further optimize for ICN specificities by providing in the first content memory a start-of-video (SoV) area 111 wherein is stored at least the first block of a plurality of contents stored in the second content memory 21. More precisely, the contents having at least their first block stored in the start-of-view area 111 are the contents of the second content memory 21 which are the likeliest to be requested, i.e. the popular videos. Each of the swap area 110, the SoV area 111 and the second content memory 21 may be managed according to a Least Recently Used (LRU) replacement policy.
For a catalog size of 500,000,000 videos following an assigned popularity law (usually Zipf), a subset of around 500,000 videos would constitutes 65% of requests. Thus, having the first chunk of these 500,000 videos stored into the start-of-video area 111 would allow any request for one of these videos to be instantaneously treated by serving this first chunk to the requesting user, while initiating transfer from the L2 to the L1 of the rest of the video through the swap area 110.
Observe that: (i) SoV 111 relates to properties of the catalog, whereas Swap size reflects the maximum number of active flows; (ii) Swap area 110 must be sufficiently large to guarantee that prefetched chunks are not evicted before a time lapse equal to the watching time of a batch (i.e., 1.6 s when streaming rate=500 Kbps, and 160 ms when streaming rate=5 Mbps).
Considering for simplicity an equal partitioning of the first content memory 11 between SoV area 111 and Swap area 110, with a size of 10 GB, both areas are 5GB worth of cache space. So the SoV area 111 could keep the first chunk for 500,000 videos (at a first block size of 10 kB), while the Swap area 110 allows for 50,000 concurrent flows (at a second block size of 100 kB), thus, potentially sustaining up to 20-24 Gbps of aggregate streaming.
It is to be noticed that these figures refer to the case in which all remaining chunks requested by users are retrieved from the L2 cache, and thus temporarily placed in the Swap area 110. This is, indeed, the worst case for the Swap sizing.
We emphasize that, considering an average video size of 10 MB, about 5 TB of second content memory 21 would be needed to keep the top 500,000 videos of the nowadays YouTube catalog.
Since we expect caching performance to be mainly driven by L2 size, when routers operate at a data rate slower than 20-24 Gbps, it also makes sense to consider a smaller L1 DRAM cache 11, as this translates into cost reduction (mainly as L1 SRAM index 12 shrinks) that could compensate, if not entirely cover, the additional SSD cost. For example, 1 GB of Swap area 110 would correspond to the minimum size needed to sustain a data rate of 4-4.5 Gbps. A 1 GB of SoV area 111, instead, would be able to store initial chunks for 100,000 top videos, responsible for over 58% of the requests.
Let us denote with ci the i-th chunk of object m in a catalog comprising M movies. Consider all chunks to have equal size Sc, for example 10 kB (possibly using padding for, e.g., the last chunk of an object). Requests for the first chunk c1 of the object m can be assumed to be independent of previous chunk requests, whereas requests for subsequent chunks ci (i>1) of the same object are highly correlated in time: in the case of video, it can be loosely assumed chunks to be separated by a gap related to the streaming rate.
Whenever an interest for the first chunk c1 hits the ICN router 1, a lookup( ) is issued to the first content memory 11 first: in case of a hit in the SoV area 111 (i) a frame containing c1 data is assembled and returned via send( ); (ii) the system signals the second content memory 21 to prefetch( ) a batch of B consecutive chunks (i.e. a block of the second block size) to the Swap area 110 (and the first index memory 12 is updated accordingly).
Therefore, video chunks move from L2 to L1 and update the L1 index 12 before the corresponding requests effectively hits the cache.
In case of a L1 miss for c1 (i.e. the first chunk is not present in the SoV area 111), content search continues both (i) in the L2 within the ICN router 1 via a lookdown( ) (in the second index memory 22) and/or (ii) in the router vicinity via interest forward( ). Operations (i)-(ii) can be performed in parallel (to optimize user delay) or in sequence (to save network traffic). Sequential operations trigger network traffic only in case of a L2 miss, but add in this case a delay proportional to the lookdown( ) time in the L2 index 12. Parallel operations avoid this delay but possibly generate unnecessary network traffic in the case of a L2 hit.
Parallel operations are preferable as they lead to better user experience, and since the overhead is limited to the first chunk of an object (according to the example values, 10 KB of a 10 MB video corresponds to a 0.1% overhead). Moreover, parallel operations can also simplify system implementation, as this avoids the need to maintain timers (for retransmission over the alternative path) and any further state.
Pushing the decoupling of L1 and L2 further, in principle it would be more efficient to let the SoV area 111 and the second content memory 21 store completely disjoint chunk sets. Otherwise stated, from caching purposes, it would be useless to store a redundant copy of the first chunk in both L1 and L2, since the latter will never be used.
However, as the second content memory 11 is much larger than the first content memory 11 and especially persistent, this slight redundancy allows the system to easily recover after a failure, and promptly re-initialize the SoV area 111 by transferring the first chunk of the most popular objects.
After having consumed the first chunk, the user will start requesting subsequent chunks. Due to prefetching, chunks c2 . . . cB are now to be found in the first content memory 11, so that whenever a request for chunk cB+1 arrives, the system can proactively lookdown for cB+1 . . . c2B. In CCN terms, since the last portion of a chunk name represents the chunk sequence number, this is easy to do since upon reception of chunk ck the lookdown( ) decision requires checking a simple modulus division k % B=B−1.
This behavior holds as long as the user does not jump ahead in time, breaking the sequential view mode. While we expect sequential behavior to be vastly predominant, still we recognize that users increasingly depend on added value-services such as advanced VCR functionalities allowing them to pause, rewind or fast-forward, possibly generating non-sequential chunk request patterns.
Additional system optimization, while non-necessary for the correct operation, can provide benefits by pushing a moderate complexity to the edge of the ICN network:
According to a second aspect, the invention proposes a method for accessing content at an ICN router 1.
The method starts with a step (a) of receiving at the router 1 a request for a content at least partially stored in a second content memory 21 of second cache layer L2 of the router 1, the second content memory 21 presenting a second block size. This step (a) further comprises searching for a first block of the requested content in a start-of-video area 111 of the first content memory 11, which is likely to contain it if the content is a popular video.
In a second step (b), if the first block has been found in the SoV area 111, it is served in response to the request. Simultaneously, as explained blocks at the second block size of data of said requested content are fetched from the second content memory 21 at a swap area 110 of a first content memory 11 of a first cache layer L1 of the router 1, the first content memory 11 presenting a first block size. As already explained, if a block at the first size is a chunk, a block at the second size is a batch of chunks.
For each fetched block at the second block size, the chunks which this block comprises are individually and sequentially serving, in response to the request, in a step (c).
Finally, a new block at the second block size is prefetched from the second content memory and copied to the swap area of the first content memory upon reception of a content request for the penultimate chunk of the batch (i.e., chunk of index k satistiying k % B=B−1).
When the content id a video, may be performed the “optimization” previously detailed. The method may thus comprise a step (d) of, when receiving at the router 1 a request for pausing the serving of the video (i.e. the user “pauses” the playing of the video), further sequentially serving at least one block at the first block size (so as to store extra chunks locally in the playout buffer of the user), and when receiving at the router 1 a request for resuming the serving of the video, performing steps (b) and (c) from the last block served (i.e. resuming fetching of batches of chunks from the second content memory 21). As the chunks stored in the user's buffer are
| Number | Date | Country | Kind |
|---|---|---|---|
| 14305639.8 | Apr 2014 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2015/059396 | 4/29/2015 | WO | 00 |
