Angaben zur Quelle [Bearbeiten]
| Autor | Mayutan Arumaithurai, Kadangode K. Ramakrishnan and Toru Hasegawa |
| Titel | Information‐Centric Networking: The Case for an Energy‐Efficient Future Internet Architecture |
| Zeitschrift | Green Communications: Principles, Concepts and Practice |
| Herausgeber | Konstantinos Samdanis (Editor), Peter Rost (Editor), Andreas Maeder (Editor), Michela Meo (Editor), Christos Verikoukis (Editor) |
| Ort | Chichester, UK |
| Verlag | John Wiley and Sons, Ltd |
| Jahr | 2015 |
| Seiten | 361-376 |
| Fragmente | 3 |
| [1.] Analyse:My/Fragment 004 28 - Diskussion Zuletzt bearbeitet: 2018-08-23 19:24:50 Klgn | Arumaithurai 2015, Fragment, KeineWertung, My, SMWFragment, Schutzlevel, Unfertig |
|
|
|
| Untersuchte Arbeit: Seite: 004, Zeilen: 28 |
Quelle: Arumaithurai_2015 Seite(n): 02, Zeilen: 27-30 |
|---|---|
| Peer-to-peer (P2P) is a prime example of a content centric approach where users interested
in a particular content, attempt to obtain it from other peers. Popular Peer-to-Peer (P2P) services such as BitTorrent make use of a tracker server to store the mapping between available content and which of the peers have it. A peer interested in a particular content contacts |
Peer-to-peer is a prime example of a content-centric approach where users interested in a par-
ticular content attempt to obtain it from other peers. Popular peer-to-peer services such as BitTorrent make use of a Tracker Server to store the mapping between available content and which of the peers have it. A peer interested in a particular content contacts |
|
|
| [2.] Analyse:My/Fragment 005 01 - Diskussion Zuletzt bearbeitet: 2018-08-23 19:21:44 Klgn | Arumaithurai 2015, Fragment, KeineWertung, My, SMWFragment, Schutzlevel, Unfertig |
|
|
|
| Untersuchte Arbeit: Seite: 005, Zeilen: 01 |
Quelle: Arumaithurai_2015 Seite(n): 2,3,4, Zeilen: 30-36,10-35,7-13 |
|---|---|
| a tracker server and obtains a list of peers that are serving that particular content. The advantage
of P2P solutions is that the peers that are downloading a particular content can also choose to serve that content thereby increasing the number of sources for a particular content. P2P solutions thus provide users a wide range of options from where one could obtain the content. P2P services also facilitate the possibility for a requester of content to obtain it from multiple sources simultaneously. Why they are not completely effective as a content-centric alternative? The disadvantage of a P2P based solution is that it is not topology aware and therefore proximity in terms of hops in the P2P topology does not in reality mean that they are close to each other in the routing topology. For instance, three peers that appear close to each other on the P2P topology could in fact be world apart with one of them being in the US, another in Europe and another in Japan. Therefore, in terms of the actual distance the content has to traverse, it might have to traverse a larger number of hops thereby increasing energy consumption. To overcome the problem of topology unawareness, solutions such as Application Layer Transport Optimization (ALTO) [6] have been proposed. The ALTO servers are envisioned to have information about the network topology and other factors and therefore support the clients in the peer selection process. The ALTO based solution looks promising, but cannot operate at small time scales since the updates it receives are usually averaged over larger time scales. Furthermore, the effectiveness of the ALTO solution depends on the level and accuracy of the information it obtains from the various network operators. 1.2.1.2 Content Delivery Network (CDN) Content Delivery Networks (CDNs) are a distributed network of large storehouses for content and support the redistribution of content. The goal of a CDN is to serve content to end-users with high availability and high performance. CDNs help users to obtain their content faster and reduce the load on the original source of content as well as on the network. CDNs are in fact a group of servers present in data-centers that cache and serve content such as downloadable files (movies, software, documents), web-objects (images,scripts, text), location specific advertisements and other static content. They are also used by content providers to serve live-streaming and video on demand. CDNs were usually deployed in backbone networks, but recently, network operators have been deploying smaller scale CDNs closer to the edge to optimize traffic in their network as well as to provide content providers an alternative CDN service. Why they are not completely effective as a content-centric alternative? CDNs are application layer solutions and therefore the client will have to establish connection to the content provider (e.g. HTTP), in order to receive a list of content and the corresponding CDN cache server where the content can be obtained from. Therefore, content providers might need to have their servers available for initial connection establishment and depend on CDNs to increase efficiency. Moreover, CDN based solutions can be sub-optimal since the CDN source has to be decided prior to the actual data transfer. A web server might |
Tracker Server
and obtains a list of peers that are serving that particular content. The advantage of peer-to-peer solutions is that the peers that are downloading a particular content can also choose to serve that content, thereby increasing the number of sources for a particular content. Peer-to-peer solutions thus provide users a wide range of options from where one could obtain the content. Peer-to-peer services also facilitate the possibility for a requester of content to obtain it from multiple sources simultaneously. Why They are not Completely Effective as a Content-Centric Alternative? The disadvantage of a peer-to-peer-based solution is that it is not topology aware and, therefore, proximity in terms of hops in the peer-to-peer topology does not in reality mean that they are close to each other in the routing topology. For instance, three peers that appear close to each other on the peer-to-peer topology could in fact be world apart with one of them being in the United States, another in Europe, and another in Japan. Therefore, in terms of the actual distance the content has to traverse, it might have to traverse a larger number of hops, thereby increasing energy consumption. To overcome the problem of topology unawareness, solutions such as Application Layer Transport Optimization (ALTO) [6] have been proposed. The ALTO servers are envisioned to have information about the network topology and other factors and, therefore, support the clients in the peer selection process. The ALTO-based solution looks promising, but cannot operate at small timescales because the updates it receives are usually averaged over larger timescales. Furthermore, the effectiveness of the ALTO solution depends on the level and accuracy of the information it obtains from the various network operators. 19.2.2 Content Delivery Network (CDN) Content Delivery Networks or Content Distribution Networks (CDNs) are a distributed network of large storehouses for content and support the redistribution of content. The goal of a CDN is to serve content to end users with high availability and high performance. CDNs help users to obtain their content faster and reduce the load on the original source of content as well as on the network. CDNs are in fact a group of servers present in data-centers that cache and serve content such as downloadable files (movies, software, documents), web-objects (images,scripts, text), location-specific advertisements, and other static content. They are also used by content providers to serve live-streaming and video on demand. CDNs were usually deployed in backbone networks, but recently, network operators have been deploying smaller scale CDNs closer to the edge to optimize traffic in their network as well as to provide content providers an alternative CDN service. 19.2.2.2 Why They are not Completely Effective as a Content-Centric Alternative? CDNs are application layer solutions, and, therefore, the client will have to establish connection to the content provider (e.g. HTTP), in order to receive a list of content and the corresponding CDN cache server where the content can be obtained from. Therefore, content providers might need to have their servers available for initial connection establishment and depend on CDNs to increase efficiency. Moreover, CDN-based solutions can be suboptimal because the CDN source has to be decided prior to the actual data transfer. A web server might |
|
|
| [3.] Analyse:My/Fragment 006 01 - Diskussion Zuletzt bearbeitet: 2018-08-23 19:25:18 Klgn | Arumaithurai 2015, Fragment, KeineWertung, My, SMWFragment, Schutzlevel, Unfertig |
|
|
|
| Untersuchte Arbeit: Seite: 006, Zeilen: 01 |
Quelle: Arumaithurai_2015 Seite(n): 4,5,6, Zeilen: 14-27,32-35;7-9;01-11 |
|---|---|
| place data in a CDN and request users to go there, but a CDN server close to the user might
not be used since the web server did not store content there. Dynamically deciding which content to cache in which CDN server is not straightforward. In the case of mobile nodes, this could result in larger inefficiency since a Uniform Resource Identifier (URI) that has been resolved earlier to a particular CDN might not be the optimal one once a node moves and since no URI resolution is involved after movement, the non optimal CDN is being used which could be a larger number of hops away. 1.2.1.3 Domain Name Systems (DNS) DNS is another example of a content centricity approach. The DNS stores mapping between a Uniform Resource Identifier (URI) and the IP address where the content can be obtained. For instance, a user searching for “Google.com” can be redirected to any of the Google servers based on how the DNS is configured. The configuration could be such that the load is balanced or the request is redirected to the server closest to where the request was made. When an end user moves, he can renew his DNS request to receive from a server close to him. Why they are not completely effective as a content-centric alternative? Nevertheless, the problem with DNS is that, it is performed at the beginning and is rarely updated during the session. This is also referred to as early-binding. Moreover, DNS updates are not possible in shorter time frames and makes sense only for big content providers. 1.2.2 Exisiting/ongoing work on ICN based solutions 1.2.2.1 Named Data Networking (NDN) Named Data Networking (NDN) [7, 8], originally known as Content Centric Networking (CCN)1 [3] is a popular ICN protocol where content/information is looked up and delivered according to its name without knowing the identity and location of the sender. NDN uses two packet types, Interest and Data. A consumer queries for named content by sending an Interest packet; a provider in turn responds with a Data packet. NDN requires a new forwarding engine instead of IP, which contains the Forwarding Information Base (FIB), Content Store (buffer memory which caches content) and Pending Interest Table (PIT). FIB is used to forward Interest packets toward potential source(s) of matching data. PIT keeps track of ‘bread crumbs’ of Interest (i.e., to support reverse-path forwarding), which the Data packets follow to reach the original requester(s). If multiple Interest packets arrive for the same data from multiple end-nodes, they will be aggregated in the PIT and served when the data arrives. The Content Store maintains a cache of the data in order to satisfy potential future requests for that data. |
place data in a CDN and request users to go there, but a CDN server close to the user might
not be used because the web server did not store content there. Dynamically deciding which content to cache in which CDN server is not straightforward. In the case of mobile nodes, this could result in larger inefficiency because a Uniform Resource Identifier (URI) that has been resolved earlier to a particular CDN might not be the optimal one once a node moves and because no URI resolution is involved after movement, the nonoptimal CDN is being used, which could be a larger number of hops away. 19.2.3 Domain Name Systems (DNS) DNS is another example of a content-centricity approach. The DNS stores mapping between a URL and the IP address where the content can be obtained. For instance, a user searching for “Google.com” can be redirected to any of the Google servers based on how the DNS is configured. The configuration could be such that the load is balanced or the request is redirected to the server closest to where the request was made. When an end user moves, he can renew his DNS request to receive a server close to him. 19.2.3.2 Why They are not Completely Effective as a Content-Centric Alternative? Nevertheless, the problem with DNS is that, it is performed at the beginning and is rarely updated during the session. Moreover, DNS updates are not possible in shorter time frames and make sense only for big content providers. 19.4.1 Named Data Networking (NDN) Named Data Networking (NDN)1 [3], originally known as Content-Centric Networking (CCN) [2], is a popular ICN protocol where content/information is looked up and delivered according to its name without knowing the identity and location of the sender. NDN uses two packet types, Interest and Data. A consumer queries for named content by sending an Interest packet; a provider in turn responds with a Data packet. NDN requires a new forwarding engine instead of IP, which contains the Forwarding Information Base (FIB), Content Store (buffer memory which caches content), and Pending Interest Table (PIT). FIB is used to forward Interest packets toward potential source(s) of matching data. PIT keeps track of bread crumbs of Interest (i.e., to support reverse-path forwarding), which the Data packets follow to reach the original requester(s). If multiple Interest packets arrive for the same data from multiple end-nodes, they will be aggregated in the PIT and served when the data arrives. The Content Store maintains a cache of the data in order to satisfy potential future requests for that data. |
|
|