【NDN基础】Information-Centric Networking: A Natural Design for Social Network Applications 全文翻译

Information-Centric Networking: A Natural Design for Social Network Applications

信息中心网络：社交网络应用程序的自然设计

 

Bertrand Mathieu,Patrick Truong, Wei You, and Jean-François Peltier

Orange Labs

 

摘要

      现在，几百万人使用在线社交网络应用程序，比如Twitter，Facebook，Google+。这种应用程序提供端用户在因特网上容易地共享内容的自由。与OSN的扩展同时，一个新的网络范式出现，信息中心网络方法，该方法的焦点是用户期望获得的内容，而不是提供该内容的服务器：一个基于内容的方法，而不是一个以主机为中心的方法。我们观察ICN的概念，，更精确的是本文中的CCN解决方案（代表内容中心网络，基于兴趣包-数据包消息），并观察OSN行为（在Twitter案例中用户订阅的被另一个用户发布的内容，或者在Facebook中朋友从其他朋友接收内容的概念）。我们主张CCN范式完美地适应OSN应用程序行为，并能够帮助保存网络负载。在本文中，我们描述拥有CCN解决方案的OSN应用程序怎样运行，并描述对于Twitter用例来说，我们执行的评估强调相较于当前典型的基于IP的交付和基于CDN的解决方案，使用这样的CCN方法的优势。依赖于CCN节点位置和缓存效率，网络负载可以明显减少，获得内容的响应时间可以加快60%。

 

1   引言

       这些年，社交网络成为一个增长的趋势，几百万人每天通过在线社交网站，比如Facebook，Twitter和YouTube（不仅仅是一个视频仓库，也可以被认为是一个社交平台）彼此交互。最近阿拉伯世界的暴动显示了这些媒体对我们每天生活的影响。社交网络正在重新定义我们使用因特网的方式，从浏览信息转移到在线消费和共享所有类型的内容，包括用户生成的内容。在社交网络中快速的病毒信息扩散，传统的端到端通信趋向于为一对多或多对多内容的传播和获取让路。内容分发因此被社交媒体用户之间的多次交互影响。然而，所有当前的内容传播变通方法，比如内容交付网络（CDN）或者点对点网络，将内容推到网络边缘来提高用户体验的质量，但是他们仍然依赖主机到主机IP原则，并不考虑为了优化内容路由或缓存而传送内容的社交语义。

      社交网络应用程序的普遍流行是众多在研究社区中研究信息中心网络（ICN）的原因之一，信息中心网络作为一个因特网体系结构新的范式，基于用户的兴趣直接路由内容。ICN聚焦于发现和交付信息（例如，用户想要的内容），而不是在主机之间维持端到端通信（例如，在哪里找到用户想要的内容）。命名方案在网络层唯一地标识内容，使得使用动态内容缓存成为可能，以便在ICN中查询内容通常路由到网络中最有效的位置。因为社交网络中的互相交换主要由如照片或者视频的内容组成（用户的发布也可以被看作内容片），我们相信ICN作为内容分发的核心原则，依据传输带宽、高可用性和最小延迟的最小需求，可以提高网络性能。

       本文如下组织。我们呈现了在线社交网络（OSN）应用程序和对于社交图的分析的相关工作，来在OSN中更好地服务用户需求。介绍ICN范式之后，我们显示了ICN体系结构怎样增加内容分发的性能来在OSN应用程序中处理巨大数量的用户。我们也举例说明我们对于基于Twitter的评估的讨论和Jacobson等人提出的内容中心网络（CCN）以作为ICN的实现。最后，我们总结我们的文章并概括我们的未来工作。

 

2   在线社交网络应用程序

      在这一部分，我们呈现了世界领导者OSN应用程序的主要特征（例如，Facebook和Twitter），并给出了一些图片显示网络流量的影响，最后呈现了这样内容的网络交付怎样被优化。

      社交网络源自于人类社会，包括彼此通过特定的连接，比如朋友关系、共同兴趣、文化期望、同学关系、商业贸易等相关的分组的个人或组织。随着因特网的普及，概念自然地按比例增长来互联他们计算机背后的几百万用户，以便全世界的人们可以在线一起讨论。最著名的在线社交网络服务是Facebook和Twitter，最近Google也提出了它自己的应用程序，Google+，结合并重定义了Facebook和Twitter的主要特征。

      Facebook允许用户发布他们的个人信息，以便他们可以找到其他用户共享相同的兴趣（朋友，同事等）。用户之间的交互是复杂的，包括和朋友保持联系（在用户墙上的消息发布），通过基于兴趣的组连接人们，和多媒体文档共享。社交网络也提出了大量的可选特征（被称为应用程序），比如照片和视频共享，或者简单讯息聚合订阅（RSS feed）读者，这代表一个用户Facebook页面的个性化视图集。

       社交网络Twitter是一个微博服务，允许用户发送和读取短信（叫做推文tweets）达到140个字符。用户可以订阅（或者跟随）其他用户的推文。用户推文的订阅者叫做跟随者。Twitter不仅仅是一种连接和与其他人互联的方式，但也越来越多地被用作搜索和实时共享信息。爆炸新闻经常在Twitter上第一次当场广播，由于用户的转推或评论，信息通过社交网络非常快地传播，然后通过其他通信媒介。

       现在，因特网变成一个大的内容仓库，内容的主要提供者是音乐、视频或webTV流服务。依据思科，视频代表今天流量的40%，到2015年底将达到62%。因特网使用的景观也被在线社交网络（OSN）越来越多的现象重塑，这已经导致了社交共享和网址收藏。大多数网站或移动应用程序真正集成“像”或“共享”按钮来使得用户和它们的朋友通过两个主要的社交平台共享他们观看的内容，Facebook和Twitter。最近通过ShareThis所做的研究显示web上共享的活动代表超过10%的所有因特网流量。Facebook占据社交共享的38%，相比之下，Twitter和邮件占据17%。结果，OSN代表一个新的强大的传播方式，并通过因特网寻找内容。在Web上一个重要的对内容的访问部分来自OSN。作为一个例子，或者看视频的人直接在社交网络站点上（在这种情况下，用户的视频存储在OSN存储服务器上），或者他们通过YouTube观看视频（或者另一个第三方流服务）被他们的朋友链接共享。超过150年的YouTube视频价值因此在Facebook被每日观看。

       Facebook和Twitter，作为大规模分布式应用程序，依赖于内容分发网络（CDN），以便减少他们自己服务器的负载，并加速直接访问CDN数据缓存的用户请求。为了测量用户的增长速率，一些研究最近提出对大规模社交网络图特征的深度理解来帮助CDN来优化内容分发。在文献[5]中，基于自回归预测方法，Twitter的趋势话题是分析和用作预兆来在CDN中为优化内容复制和复制品布置问题参与一些内容的流行度。从用户在OSN中联系的循环通常包括被一个地理上限制的区域限定的一个密集的连接核心事实开始，文献[6]的作者聚焦于从OSN用户交互中地理信息的提取，来在CDN中有效地缓存内容。遵从同样的动机，文献[7]提出了一个框架来在ad-hoc移动社交网络中通过提取基于时间的使用模型优化内容分发，作为用户通常在特定时间段在移动设备上的连接。

       一般而言，被OSN的出现平衡的新的内容消费应用程序的出现重定义了网络实体间的相互依赖，现在更多地依赖于内容片和它们的社交关系的语义，而不是被底层IP协议处理的物理端节点。一个可能的解决方案在生成的社交图内部高效地映射所有相关交互是使用新的范式，ICN，在过去的几年里被提出来预想因特网体系结构的重新设计，通过在网络处理的核心放置内容。Twitter作为一个用例，我们在下面的章节显示ICN方法怎样提高内容OSN中用户之间的内容交换。

 

3   信息中心网络

      这部分目标是在用CCN例子详细描述之前提出ICN方法的主要概念。

 

3.1  概念

       ICN是互联的信息片的集合，也叫做内容、信息或者数据对象，被路由的名字定位，并在高层被应用程序或服务管理。他们可以是任何类型，包括web应用程序，静态或用户生成的内容，实时的媒体流和更复杂的交互式多媒体通信等。对网络的主要关心是传播、寻找和传送信息，而不是端主机的可达性和他们之间对话的维持。

       ICN中的通信范式与IP中的范式不同。当前的IP体系结构以基于主机的会话模型为中心（例如，在内容被传送之前通信建立在两个主机之间），网络中数据的交付遵从源驱动的方法（例如，路径从发送者到接收者建立）。在ICN中，用户没有可以提供内容的主机的知识而请求内容，通信遵从接收者驱动的原则（例如，路径被接收者到提供者建立），数据遵从相反的路径。网络负责在请求的内容和内容可以被寻找的地方之间做映射（图1）。请求的内容的匹配而不是提供内容的端节点的可检索性因此在ICN中影响了通信的建立。

       为了高效，ICN的一个重要的方面是命名。内容应该以这样的方式被命名，独立于内容能够被找到的位置，这是ICN的主要目标（以分隔名字和位置）。实际上，它避免接收像“Error 404:File not found”这样的消息，像我们当服务器宕机时在HTTP中得到的（是初始化的服务器或者服务器复制内容）。ICN也包括一个网络中的本地缓存功能，以这种方式节点可以暂时缓存穿越它的内容（依赖缓存大小和替代算法），并将它们交付到请求的用户。通过该缓存机制，内容是重复的，内容交付到端用户的可能性是增加的。

       从位置解耦命名也允许ICN中移动性或者多播的本地支持。实际上，当用户移动的时候，他们连接到ICN网络中的另一个节点，但由于没有IP地址用作路由，它是透明的，与IP相对，在IP中，地址应该被改变。对于多播，只要一个用户请求了给定的内容，节点就可以缓存它，然后为同样的内容将它交付给后来的请求。它然后自然地创建一个类似多播的交付。

 

3.2  CCN的介绍：ICN解决方案的开拓者

       一个熟知的ICN网络解决方案是CCN，由Palo Alto研究中心（PARC）设计。

       在CCN中，端用户为内容发送他感兴趣的兴趣包消息。该兴趣包消息仅仅通过内容名标识。数据包消息被返回她/他以作为响应。这个匹配的数据包被相同的内容名标识。因此，传统的IP转发表，通过IP地址路由，不再适合，并应该被适合于转发数据，代替IP地址来解析内容名。在CCN中，合适的转发表命名为转发信息表（FIB），包括内容的标识符（而不是IP地址）和转发消息的出接口。实际上，因为网络不涉及任何目的地的概念，下一个节点并不涉及被IP地址标识的下一跳，而仅仅涉及出接口信息，这连接当前的节点与其邻居节点，该邻居节点可能有正确的内容或者关于怎样传播兴趣包消息到可能的源的知识。每个接口路由数据然后导致一跳接一跳的路由，并没有包的最终目的地的知识。

       待定兴趣表是在CCN节点而没有呈现在IP路由器中的新的组件。当每个CCN节点接收到一个给定内容的兴趣包，它记录该给定内容和它接收到的兴趣包的进接口，在咨询FIB表并将兴趣包转发到下一跳之前。当该CCN节点接收到响应（数据包消息匹配兴趣包消息），它通过匹配兴趣包到来并通过所有匹配的接口转发内容来在PIT中查询接口信息。转发数据包之后，内容条目从PIT中移除。如果发生多个兴趣是同样的内容，CCN节点将仅转发第一个兴趣包一次，但是记录所有的接收到这样兴趣包的接口，以便在得到响应时，转发/复制相应的数据包到所有接口。这样做，CCN网络自然地提供本地的多播功能。

       最后，CCN节点中的最后一个组件是内容缓存，这是内容的缓存。接收的数据包将被本地缓存在CS中，如果兴趣包被接收，因为内容已经缓存在CS中，CCN节点将仅从CS传送它，没有填充PIT表，也没有向上游转发兴趣包。CS越大，将能够缓存更多的内容。

       在CCN中存在几个与缓存相关的功能的研究（例如，网络中缓存的位置，缓存的有效大小，替代策略）。拥有这个特征，CCN网络能够自然地提供缓存功能，以便减少一些内容的传送时间（受欢迎内容），也减少了网络的负载。

       对于CCN网络的可扩展性，我们提出了一个层次化的命名结构，允许FIB中基于内容名的条目的汇聚。实际上，为了减少FIB的大小，条目能够基于内容提供者的名字被汇聚（例如，twitter.com或者facebook.com），或者应用程序名字前缀（例如，Twitter的话题名字），或者甚至ISP前缀。

       由于在PIT中，兴趣包和内容消息应该是精确匹配，不难想象CCN中内容的数量是非常巨大的。然而，由于一旦响应的数据包到来，PIT中的条目就被移除，PIT的大小是非常小的。此外，一些正在进行的研究工作研究怎样避免拥有拥有一个大的PIT表，并提高CCN提议的可扩展性，例如，使得PIT是分布式的，以便匹配今天的内存技术限制，或者实现基于布隆过滤器的空间有效的体系结构，以便更大地减少表的大小。

       CCN节点三个主要的功能组件在图2中描述，拥有Twitter流量的例子（我们将在下一节详细描述）：FIB找到到来的兴趣包应该被转发的合适的接口，内容缓存目的是缓存内容，PIT记录接收到的兴趣包的进接口。

 

4   信息中心社交网络

       这一节呈现了OSN应用程序怎样从ICN网络中受益来以一种有效的方式传送内容到端用户，从网络观点（减少网络负载）和端用户观点（提高获得内容的延迟）。描述该方法之后，我们执行了评估。

 

4.1  OSN的信息中心体系结构

       像之前看到的，OSN应用程序可以发送数据到很少的或很多的用户（例如，跟随者）。对Twitter，例如，发送一个tweet到1000个跟随者可以被认为是多播交付和缓存的混合。当缓存内容在路径上并且提供给请求者时，拥有这样行为的ICN网络能实际上帮助交付tweets。同样的方法可以被应用于Facebook或者Google+数据的交付（例如，新照片或者公告的更新墙，并将它发送给朋友）。

       图3扼要表示了我们考虑的三个Twitter的内容交付体系结构，显示了从客户/服务器IP网络，通过CDN网络，到CCN网络的进化。对该客户/服务器IP体系结构，端用户从服务器直接获取内容。例如，在Twitter案例中，一个端用户，在法国连接到Orange网络，将有规律地（每90s）向Twitter服务器投票，来获知最近的她/他追随的人们的推文。该IP流量然后经过几个网络，从法国的Orange接入网到本地拥有服务器的Twitter站点。为了减少网络负载并提高端用户的响应时间，服务提供者（Twitter，Facebook等）使用CDN网络。CDN的主要想法是在那些节点中拥有最受欢迎的可用内容（以基于推的方式或动态的请求），由于更靠近端用户，可以提供更短的响应时间。占优势的CDN运营者（Akamai，Limelight等）不是网络操作者，而是第三方提供者，并在网络操作者的网络之外的部署他们的CDN基础设施，以作为覆盖网。对我们的用例，来自法国一个Twitter用户的请求仍然应该穿过整个Orange网络，到被CDN提供者操作的更近的CDN节点（可能通过其他中间网络），然后返回。相较于IP，网络流量然后从CDN节点减少到Twitter服务器，但没有从端用户到CDN节点。最后的体系结构是CCN，路径上的节点可以缓存并向随后的端用户转发内容来请求相同的内容。对于受欢迎的内容，相同网络附近的几个端用户能够请求相同的内容（例如，许多Twitter用户的追随者或者公告在社交网络中的流行视频），如果内容在缓存中，CCN节点能够自己交付它。通过CCN，网络中缓存功能的优势应用于许多层，允许网络负载大量减少，从操作者的网络开始。由于CCN节点将从上游节点/服务器接收内容仅一次，并向下游所有感兴趣的实体交付它，因此直播的内容是相似的。所有的端用户不需要从原始服务器或者CDN节点获取内容。

       对于Twitter应用程序的用例来说，在当前的体系结构中，服务器对为每个用户提供唯一的标识符ID_@user是有用的。命名对该应用程序是至关重要的；因此，我们也应该高效地提供他。在我们Twitter的基于CCN的体系结构中，我们也依赖于那些中心服务器来提出命名方案，但与CCN命名一致。典型地，每个Twitter用户，被认为是CCN中的对象，用标识符/twitter/ID_@user命名（前缀twitter用于确保来自所有其他信息中心服务的名字的全局唯一）。基于用户的名字，每个来自用户的消息被命名为/twitter/ID_@user/timestampmsg，拥有一个表明消息发布日期的后缀。

       在用户得到她的/他的类似CCN的Twitter名字前缀，她/他的追随者使用该标识符来向CCN节点发送兴趣包，然后用用户的新推文获得自动更新。让我们举一个例子，像图4和图2中展示的那样。用户Patrick发送兴趣包来追随Jef，一个消息来追随Bertrand，另一个来追随Wei。我们假设端用户Patrick通过face4连接到CCN节点。如果在缓存中拥有内容，接收到兴趣包的CCN节点将首先检查它的CS。因为兴趣与Bertrand相关，它拥有内容，并将传送它到Patrick，通过face4送回内容。对于与Jef相关的兴趣，并不在CS中，CCN节点观察他的FIB表来获知将兴趣包转发到哪里：必须将其转发出face2、face1和face3.对于与Wei相关的兴趣，必须将它转发出face2.兴趣消息被节点转发（例如，与Jef和Wei相关），在PIT表中通过相关的进接口（例如，face4）显示，响应Patrick的流量到来的接口。最后，接收到请求的内容后，CCN节点将通过该接口将转发数据包返回Patrick。对于被David或Elena发布的兴趣包，希望跟随Patrick，CCN节点将它们转发出接口face4，像在FIB中指定的那样。

       基于CCN中的层次化命名，从名字前缀开始，仅仅一个完全相同的兴趣包可以被生成来请求用户随后的推文。像CCN被设计的那样，每个接收到的数据包响应一个兴趣包；因此，对于接收到的下一个消息，应用程序应该在接收到数据包后发送新的兴趣包。应用程序的职责是依据兴趣包传输定义自己的策略，以便处理更新的信息、用户移动性等等。因为CCN路由器在PIT中可能保存最初兴趣包的时间更长，另一个CCN解决方案的优势是从客户端当前90s查询的可能移除，来检查他们追随的人们推文的更新。

       这个新的CCN体系结构，拥有本地的网络内功能，有许多应用程序的优势。在CCN中拥有本地的缓存特征，用户可以写的所有的推文将额外被散布在网络中不同的缓存位置，只要她/他的追随者开始更新他们的Twitter时间线。

       通过它本地的多播性能，CCN设计也允许用户创建并管理联系人组，这是Twitter中当前缺少的功能。（与绝大多数OSN，比如Facebook或者Google+相反，Twitter当前不允许在有限的追随者圈子中发送个人推文。）

 

4.2  评估结果

       使用基于CCN的体系结构来作为推文交付，我们可以直观地想象网络负载可以依赖于给定内容追随者/朋友的数量被大量减少。我们然后执行一些评估来证明CCN交付的兴趣，相较于当前的网络体系结构（像今天被部署的），依赖于OSN应用程序用户的数量。

       在我们的模拟实验中，我们举了Twitter应用程序的例子，法国的用户连接到Orange国内网络。在我们的假设中，Twitter服务器在Orange国内网络之外。我们也考虑使用内容传递网络（CDN），该网络在每个有一个服务器，在Orange的对等点有一个服务器。相较于ICN解决方案，我们假设CDN将不会仅传送高数据量内容，比如视频和照片，像它现在被使用的那样，而不仅仅是推文。为了高效，服务器需要拥有许多内容，这防止CDN节点靠近端用户。在ICN解决方案中，社团在跟随者之间创建，跟随者在路由表中被自动处理，然而在CDN的情况下，必须通过手工或者使用一些确定的选择被提供，因此如果服务器靠近端用户，即拥有一个很差的命中率，如果他们在核心网络中，就有庞大数据库的需要，在很差的命中率和庞大的数据库需要之间做出权衡。对我们使用的两层CDN体系结构的研究，存储在美国的内容是第一层，存储在对等点的内容是第二层。到达那些节点的延迟将是一个中间值，该中间值介于在法国到达服务器的东西与在美国到达服务器的东西。对于操作者网络拓扑，我们假定一个层次化的三层网络拓扑，在CCN体系结构的每一层都有缓存设施。

       我们用来定义Twitter服务行为的参数主要取自文献[12,13]。典型地，我们为每个推文取120个字符的平均长度，用户平均每天发送0.97个推文，法国Twitter用户的数量大约三百万（在我们的评估中，客户的数量从0到五百万变化）。我们对特定的组，取追随者的数量，遵从一个与幂律分布相似的曲线（像在文献[14]中分析的那样）。对CCN行为来说，我们认为ICN可以缓存和传送100%的Twitter内容是不现实的（例如，CCN节点存储内容），因此，我们做拥有不同缓存命中率的评估，从低效率缓存系统（例如，5%的命中率）上升到高效系统（ICN缓存提供的80%的数据）。

        当前三百万法国Twitter用户每秒大约生成1250个推文。每个推文的平均字符数大约120个；因此，每秒大约存在1.2Mb由Twitter用户引入的流量。在所有的推文消息中，3%包含视频或图像链接。中等质量的视频通常以512kb/s编码。一个视频平均2min，给出大约60Mb的流量。压缩图像通常是50kb。包含视频和图像的推文通常比纯文本推文更受欢迎（例如，私有消息）。如果我们考虑这种行为，每秒1250个推文响应大约1.13Gbs/s的网络负载。如果ICN网络传送这样的流量，ICN缓存中的低命中率并不实际帮助节省带宽；但随着命中率的增长，网络中的数据容量巨大的减少。例如，50%的命中率，我们可以在网络中节省一半的流量，也就是说，大约0.55Gbs/s的网络负载（图5）。这种节省是仅仅对于一个应用程序来说的（Twitter）；它将增加相似性，因为其他应用程序以这种方式被交付。ICN解决方案帮助操作者极大地减少了国内网络和对等点的流量，也因此带来了花费。

       我们也估算图3描述的三个网络体系结构中端用户和内容提供者之间的延迟。图6显示下面用例的特定命中率的延迟：

       （1）Twitter表现出了从法国到美国的Twitter服务器测量的延迟，来获得内容。

       （2）CDN Twitter是得到内容的延迟，拥有两层的CDN，处理的请求，或者在缓存命中率的案例里，通过Twitter的另一个CDN服务器操作（例如，Akamai），或者在缓存丢失的案例里的Twitter服务器。

       （3）ICN Twitter是对于我们在法国的ICN网络中得到的延迟，成为一个在所有三层上拥有CCN节点的网络。

       ICNTwitter体系结构给出最好的结果，显示靠近客户的甚至拥有低命中率的缓存是最有效的。依赖于内容在网络树的哪里被缓存，延迟可以减少20%到60%（命中率50%）。

 

5   结束语

       像期望的那样，作为我们评估的结果，为社交网络应用程序使用ICN不仅仅对网络操作者是有利的，而且对端用户经验质量（QoE）也是有利的，由于内容更靠近端用户，并能更快速地交付。此外，源自于OSN的社会链接对网络交付效率有直接影响，并完美地符合ICN特征，比如本地类似多播的功能。

       ICN范式是一个有前途的社会网络应用程序的解决方案。在未来的工作中，我们计划在CCN解决方案的顶层开发/改写一个OSN应用程序，来更好地适应本地ICN功能，并在实际的网络上做大范围测试（例如，PlanetLab环境）来和当前的IP基础设施做比较。我们也计划在ICN网络中考虑OSN社会链接，以便优化路由和内容的交付。

 

6   参考文献

[1] V. Jacobson et al.,“Networking Named Content,” Proc. ACM CoNEXT 2009, Dec. 2009.

[2] “Cisco Visual NetworkingIndex: Forecast and Methodology, 2010–2015,” http://tinyurl.com/3p7v28.

[3] “The Law of Sharing,”http://blog.sharethis.com/2011/07/07/the-law-ofsharing/.

[4] “Youtube — Share andShare Alike: We’ve Acquired Flick,” http://youtubeglobal. blogspot.com/2011/01/share-and-share-like-weve-acquired.html.

[5] S. Agarwal and S.Agarwal, “Social Networks as Internet Barometers for Optimizing ContentDelivery Networks,” Proc. 2009 IEEE 3rd Int’l. Symp. Advanced Networks andTelecommunication Systems (ANTS), Dec. 2009.

[6] S. Scellato et al., “TrackGlobally, Deliver Locally: Improving Content Delivery Networks by TrackingGeographic Social Cascades,” Proc. WWW 2011, Mar. 2011.

[7] F. Nazir et al., “TimeCritical Content Delivery Using Predictable Patterns in Mobile SocialNetworks,” Proc. IEEE Computational Science and Engineering 2009, Aug. 2009.

[8] B. Ahlgren et al., “ASurvey of Information-Centric Networking (draft),” Information-CentricNetworking, no.

10492, 2011, available: http://drops.dagstuhl.de/opus/volltexte/2011/2941.

[9] L. Zhang et al., “NamedData Networking (NDN) Project,” Oct. 2010, available: http://www.nameddata.net/ndn-proj.pdf.

[10] I. Psaras et al.,“Modelling and Evaluation of CCNCaching Trees,” Networking 2011, ser. LectureNotes in Computer Science, vol. 6640, Springer Berlin/Heidelberg, 2011, pp. 78–91.

[11] G. Carofiglio et al.,“Modeling Data Transfer in Content Centric Networking,” Proc. 23rd Int’l.Teletrafic Congress (ITC), 2011.

[12] “Twitter Finally RevealsAll Its Secret Stats,” http://www.businessinsider.com/twitter-stats-2010-4.

[13] “State of theTwittersphere,” http://blog.hubspot.com/Portals/249/sotwitter09.pdf.

[14] M. Cha et al., “MeasuringUser Influence in Twitter: the Million Follower Fallacy,” Proc. 4th Int’l. AAAIConf. Weblogs and Social (ICWSM 10), May 2010.