NDN-RTC是一个关于实时视频会议的NDN-based library。它旨在利用NDN网络的内容中心转发机制、数据签名安全机制、caching、请求聚合机制。RTC表示Real-Time Communication。
1. INTRODUCTION
聚合（aggregation）：多个相同的interest请求一个内容，它们会在router处聚合，避免给producer和网络带来过重负担。
实时会议这类low-latency应用程序提出的设计，目前还没有大规模可用的原型或ICN相关的参考文献。
例：如何通过各个caching获得最新数据，而不是每次都依靠consumer-producer之间的联络（会影响扩展性:scaling的潜能），同时还能保持low latency：这是一个挑战。
NDN-RTC提供publishing audio/video stream、在low latency下获取这些流的的基本功能，并作了初步的评估。
NDN-RTC基于NDN Common Client Library [16]，兼并（leverage）了WebRTC，将它的audio pipeline和video codec进行了合并。
2. OBJECTIVES
初步目标：实现NDN上low-latency的audio/video communication，完成一个可用的多方的实时会议应用程序，并测试通过。同时，也期望通过各个caching获得最新数据，而不是每次都依靠consumer-producer之间的联络；以此来维护扩展性。（把上文又重复了一遍）
对IP网络上，low-latency的audio/video会议来说，目前的解决方案缺少dedicated aggregation units（IP网络是端到端，无法把不同用户的重复的interest聚合成一个），扩展性很差。当producer和consumer人数较多时会体现出来。
本文暂时不讨论拥塞（congestion）控制的问题。
在NDN网络上，其他的应用程序也在传播data，是否还能持续进行实时内容的publishing、以及在low-latency下获取最新内容？
要做到的五点：
1. Adaptive bitrate.库和命名空间要能给consumer提供多个可选的比特率，任其自由选择;并为以后自适应做准备（lay the groundwork for）。
2. Multi-party conferencing.可以同时Publishing and fetching多个流。
3. Passive consumer & cacheability. 允许主动produce、被动consume和cache而不经过节点显式同意，为以后扩展出高的consumer-producer比做准备；目前没有实现
- Data verification.NDN的数据签名机制，确保数据认证。
5. Encryption-based access control.数据加密。3. BACKGROUND AND PRIOR WORK
之前成功的先例有NDNVideo，在普通（plain-vanilla [6]）NDN上的consumer-producer比可达1000。（不分帧，音频和视频的segment大小一样：可能造成不同步）
The project focused on developing random-access pre-recorded and live video for location-based and mixed reality applications. Audio and video内容切成chunks，由命名空间按时间索引进行命名。它能满足live and pre-recorded的要求，但是达不到low-latency和会议的即时扩展性。
NDNlive（实时直播）和NDNtube（非实时的点播），有一个比data/interest更高的application data unit和相关的API。
还有的应用程序应用MPEG流，跟low-latency无关，但是对高的consumer-producer比也更有效。
最终决定在WebRTC的基础上修改，正是看中了它的audio pipeline和video codec，以及为了浏览器整合的方便。4. APPLICATION ARCHITECTURE
NDN-RTC提供producer和consumer两种功能，同时可用于一对多、多对一、多对多。
（一对多是直播、多对多而每个人都既是consumer又是producer）
（在直播中有两种方式，TCP单播，UDP组播：追求实时内容，中间过时的帧丢了也无所谓）
IP网络是sender-driven的，实时通信是receiver-driven的：producer一直按自己的节奏在storage中放入data，consumer自己取用，自己决定如何发送interest、获得的segment和buffer的管理。
cache回答interest是异步的：In this way, flow control responsibility shifts to the consumer, and scaling can be supported by network caches downstream rather than publishing infrastructure at the application level – 目前是由NDN-CCL库提供。（异步跟扩展有什么关系？？？另外所谓的application cache就是content store吗？？？）
（IP网络中的协议：RTP：传输；RTSP和RTCP：控制传输和同步；然后利用voip：双方先建立连接，再通过RTP传输）
Figure 1：Producer的流程：从media input中获得RAW 放入frame，RAW frame编码，segment并命名，签名，放入application-level cache）；consumer的流程：通过interest pipeliner发出多个interest，将返回的data segment在buffer中组合起来，解码变回RAW frame。
Figure 2：命名空间处理命名问题，error correction data，元数据（metadata）。
1.Media
NDN-RTC将一个源的media抽象成一个流。流的名字起源于相关设备信息。一个publisher可以同时产生多个流，一个流的data可以有多个比特率：名字层级上，每个流产生不同的子进程，与称为media thread的编码进程一一对应。media thread的存在可以给相同的data提供不同的画质等级。
确定了画质后就确定了frames。video frame还会分成两个命名空间：delta and key，各自单独命名（参见section 6），audio因为远未达到最大payload，只需要delta一个命名空间，而且不同的audio可以装到同一个data包中，直到装满。
对video type，Key frame的解码不依赖之前的frame，delta frame要依赖上一个key frame；key frame少了一个frame就无法解码（丢了key frame不能依赖重新传输，需要其他的补偿机制：那本文 从cache重新取得中间的key frame的意义在哪里？？？）
Delta帧相当于P帧：预测帧，只记录与上一帧的差别
Key帧相当于I帧：关键帧，记录一帧全部的数据
*补充资料：
I帧表示关键帧，你可以理解为这一帧画面的完整保留；解码时只需要本帧数据就可以完成（因为包含完整画面）
P帧表示的是这一帧跟之前的一个关键帧（或P帧）的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。（也就是差别帧，P帧没有完整画面数据，只有与前一帧的画面差别的数据）
B帧是双向差别帧，也就是B帧记录的是本帧与前后帧的差别（具体比较复杂，有4种情况），换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高，但是解码时CPU会比较累~。
从上面的解释看，我们知道I和P的解码算法比较简单，资源占用也比较少，I只要自己完成就行了，P呢，也只需要解码器把前一个画面缓存一下，遇到P时就使用之前缓存的画面就好了，如果视频流只有I和P，解码器可以不管后面的数据，边读边解码，线性前进，大家很舒服。
但网络上的电影很多都采用了B帧，因为B帧记录的是前后帧的差别，比P帧能节约更多的空间，但这样一来，文件小了，解码器就麻烦了，因为在解码时，不仅要用之前缓存的画面，还要知道下一个I或者P的画面（也就是说要预读预解码），而且，B帧不能简单地丢掉，因为B帧其实也包含了画面信息，如果简单丢掉，并用之前的画面简单重复，就会造成画面卡（其实就是丢帧了），并且由于网络上的电影为了节约空间，往往使用相当多的B帧，B帧用的多，对不支持B帧的播放器就造成更大的困扰，画面也就越卡。
MostRightChild：返回最近的key帧
命名后的frame分为分块的data和parity（校验位，forward error correction，让consumer可以recover缺的分块，这个的具体原理暂且不管吧），各个data再命名
2. Metadata（元数据）
在stream的同级还要保存一个元数据，称为session info，每1s保存一个，以便consumer弄清楚producer的命名空间结构。
另外每个包里在seg_name字段后也要保存一个元数据，这样就算consumer不是按顺序收到各个包也没有问题。它的结构：seg_name/num_seg/playback_pos/paired_seq#/num_parity
参见Figure 3：
num_seg – frame数（Figure 2中的N）
playback_pos – delta或key
paired_seq – delta t的这一位是t，代表对应上一个key t；key t的这一位是t-1,表示对应上一个delta t-1
num_parity – number of parity segments for the frame.
3. Data objects
*WebRTC含有echo cancellation。在视频会议系统中，AB两人在通话，A的声音传给B，在B处放出来，B的喇叭也会采集到这个声音，一并传回给A。如果传输的时间延迟足够大，又不做任何处理，A会听到这个自己的回声。
video的每个frame的第0个包要分的小一些，头部额外插入一个frame header；不同的audio装到同一个data包中共用一个frame header。frame header含有时间戳等内容。segment以后每个包再加上一个segment hdr，含有时间戳、interest nonce、generation delay等内容。（参见Figure 4）
interest nonce：第一次请求某个segment的nonce。
1）等于之前某个interest的值：这是对之前interest的返回，还未被cache过
2）不等于之前任何interest的值：这是对其他consumer的返回，可能被cache过
如果是情况1），监测时间戳和generation delay：
时间戳：让comsumer确定interest到达producer的时间
generation delay：producer接收到interest后publish的时间（ms级别），让consumer控制未完成（outstanding）的interest数。
4. Consumer
consumer的流程：通过interest pipeliner发出多个interest，将返回的data segment在buffer中组合起来，解码变回RAW frame。
2）fetching
generation delay本身需要短，否则时效短的interest会累积起来（这一点由producer控制）
也不该因为generation delay太短，迟钝得在publish完以后还有interest没发完：否则会增加latency（这一点由consumer控制）
设在generation time = d[gen]内发完interest 0 – M；回复了这些segment后，consumer从元数据中获得N的值，发剩下N – M个interest（若N > M），这些interest不再需要d[gen]了。又记：从接到第一个segment到全部接收到并且拼接好的时间为assemble time = d[asm]
Note that for frames that are smaller than the estimate, some Interests may go unanswered; this is currently a tradeoff made to try to keep latency low for the frame as a whole.（这里是想说协调N和M的大小关系，没有强调具体关系）
3）Buffering
处理out-of-order segment的问题，要有足够大的空间能让错乱的帧重排。参见figure 9
高低水位机制：buffer达到一定存储量的时候才允许开始播放（低水位）；buffer低于一定存储量的时候才开始存储新的内容，避免一直播放旧的内容而跟不上实时（高水位）
4）interest expression control
The interarrival delay (d[arr]) is defined as the time between receipt of successive samples by a given consumer.
可以通过元数据计算产生两个segment的间隔时间
计算间隔时间来判断是否是最新内容。参见Figure 6，如果d[arr]等于产生两个segment的间隔时间，说明不新鲜；如果d[arr]大于后者，说明新鲜。因为d[arr]太短、一请求就能回复的通常是old、已经生产好并且放进了cache的data
不能通过时间戳来判断：可以确定手上的时间戳哪个最新，但无法确定是否还有更加新的已经产出了
In-network cache还是有用的：每个用户隔一段时间，先发一堆interest，但目的是把网络中的cache都刷新而不需要返回的data内容；之后若还是返回cache的内容，也不再判定为过时信息了
NDN-RTC依靠bootstrapping mode，使a consumer first initiates data fetching and tries to exhaust cached data by changing the number of outstanding Interests.
lambda表示在当前时间应发送多少未完成的interest（参见Figure 7）
可以用两种方式来调整lambda：实际的RTT’和d[arr]
过于aggressive的机制：先发一大堆之后时间内容的interest；conversation机制：只发能确定产生了的内容；使用lambda和lambda[d]在两者之间进行调节（具体细节没太明白……）