foreign networks. Content-Centric Networking (CCN) [1] or. Named-Data Networking (NDN) [5] is one of the architectures proposed for ICN. The prototypes of ...
2016 13th IEEE Annual Consumer Communications & Networking Conference (CCNC)
NRTS: Content Name-based Real-time Streaming Kazuhisa Matsuzono and Hitoshi Asaeda National Institute of Information and Communications Technology (NICT), 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: {matsuzono, asaeda}@nict.go.jp
Abstract—Content-Centric Networking (CCN) or Named-Data Networking (NDN) has been proposed as an alternative to the existing Internet architecture. In this paper, we propose Content Name-based Real-time Streaming (NRTS) to enhance the basic concept and implementation of CCN in order to improve streaming quality. NRTS utilizes “symbolic interest,” which eliminates segment identification, and “content-name-based streaming,” which enables per-content (instead of per-packet) streaming and multicasting using a rate control scheme based on network conditions. NRTS is more suitable for high-performance delaysensitive real-time applications than the original CCN architecture. It avoids the generation of bursty interests and the need for complex operations such as setting the pipeline size. The results from the experiments conducted using simulations and testbeds show that NRTS attains higher throughput and scalability than the original CCN architecture.
I. I NTRODUCTION Information Centric Networking (ICN) [1], [2] has introduced innovative ideas and diverse derivative research areas, such as name-based routing and in-network caching, and reduces dependence on the resources of the origin server and foreign networks. Content-Centric Networking (CCN) [1] or Named-Data Networking (NDN) [5] is one of the architectures proposed for ICN. The prototypes of CCN and NDN, called CCNx [3] and NDN Forwarding Daemon (NFD) [5], respectively, have been developed. CCN/NDN focuses on the method of information dissemination in a network: how consumers retrieve content by name, using an “interest” packet, and how publishers provide content through a network, using “data” (called “content object”) packets. Several researchers have investigated video streaming over CCN/NDN. In [8], [9], Lederer et al. presented adaptive multimedia streaming in CCN using MPEG-DASH [6]. Video content is encoded in various video quality versions, and the content of each version is split into data segments having unique names. However, MPEG-DASH over CCN mainly focuses on services for pre-recorded video content distribution rather than delay-sensitive real-time streaming applications. The incorporation of the Real-time Transport Protocol (RTP) [11] into CCN yields a higher potential for achieving delay-sensitive high-performance streaming of content to consumers because, typically, RTP does not cause unnecessary data reception delays. In the approach that uses RTP in CCN, the consumer requests each RTP packet by sending an interest specifying the sequence number, and receives the corresponding data encapsulated in RTP [7]. However, one interest is required for each RTP packet, and hence, the number
978-1-4673-9292-1/16/$31.00 ©2016 IEEE
of interest requests increases in proportion to the bit-rate, which can cause bursty interest traffic and loss of interest and data packets. In the case of live streaming or broadcast multimedia services with high-throughput data delivery, multicaststyle communication is indispensable for the conservation of network and CPU resources. CCN natively supports multicaststyle communication; however, it is executed “per-packet” rather than “per-content”, which cannot effectively address the bursty interest issue. In this paper, we propose Content Name-based Real-time Streaming, NRTS, which enables RTP-like streaming and more suitable for high-performance real-time applications than the original CCN architecture. NRTS can 1) eliminate complex interest operations at the consumer side and adjust receiving video quality according to network conditions, 2) suppress bursty interest traffic, and 3) natively support per-content multicast-style communication. We conducted experiments to test NRTS on a local testbed and an international ICN testbed in Japan and Korea. We also conducted simulations and analyzed the results to test the adaptability and stability of NRTS in a congested network. The rest of this paper is organized as follows: In Section II, the background for our research is provided. The detailed design of NRTS is described in Section III. In Section IV, we describe the performance analysis of NRTS on a local testbed, on an ICN testbed, and through simulations. We present related work in Section V, and state our conclusions in Section VI. II. BACKGROUND AND P ROBLEM D ESCRIPTION A. Forwarding and Caching Strategy CCN advocates receiver-driven communication, in which a consumer initiates communication by sending an interest for a specific content and CCN routers forward the interest to the publisher responsible for the requested content, using name prefixes for routing. A Forwarding Information Base (FIB) is a lookup table used to determine incoming interfaces (or incoming “Faces”) for the content. Its entries consist of name prefix and incoming Face pairs. Each CCN router also maintains a Pending Interest Table (PIT), which is a lookup table containing the name prefix, and outgoing Faces used to forward received content. When a CCN router receives an interest, it examines the content to determine whether it is cached in its local Content Store (CS). If the named content is in the CS of the router, the router forwards the cached content to the Face on which it arrived. If the named content is not present in the CS of
2016 13th IEEE Annual Consumer Communications & Networking Conference (CCNC)
the router, the router searches its PIT to determine whether another interest for the same named content has already been processed. If the relevant named content is in the PIT of the router but the arrival Face is not set in its PIT, the router updates the PIT entry by adding the arrival Face as the outgoing Face and discards the interest. If the relevant named content is not in the PIT of the router, the router creates a new PIT entry and forwards the interest through the incoming Faces specified in its FIB. If no router along the path of the content to the publisher has the requested content in its cache, the interest packet will finally reach the publisher. When an interest is received, the publisher forwards the content object to its downstream router. Each CCN router along the path that receives the interest forwards the data through the outgoing Faces, stores the forwarded content in its CS if required, and deletes the corresponding PIT entry. The caching strategy of CCN should vary based on the types of contents. Real-time streaming content varies with time, and hence, outdated information is not useful in this case. Thus, in contrast with the conventional procedure, CCN routers, in general, do not cache real-time streaming content. B. Bursty Interests When a consumer sends an interest, the user specifies the complete name prefix of the requested content, and the corresponding data (i.e., the content object packet) is received from the network. CCN enables packet-level content delivery, in which the content name prefix specified in an interest indicates a unit of the transmitted packet. However, real-time streaming content changes over time, and streaming content in a given time slot is not identical to other content in a different time slot. Therefore, consumers must specify each fragment of content on receiving it, and send interests per RTP sequence number or segment number in order to obtain data. The segment number increases rapidly in proportion to the streaming bit rate, and hence, consumers receiving streaming content must send bursty interests continuously and consecutively (e.g., 1000 interests per second for a 10 Mbps stream) in order to continue receiving streaming content. A round trip can delay the reception of data, leading to potential throughput degradation, and hence, the “pipeline” approach [7], [19] solves this issue by enabling the consumer to simultaneously send multiple interests and maintain a certain number of outstanding interests. However, it is difficult to determine and adjust the optimal pipeline size in order to avoid network congestions caused by bursty interests. C. Tradeoff between Data Buffer Size and Playback Delay In order to deal with network congestion, new transport protocols with congestion control have been proposed [13], [14]. In these schemes, consumers adjust the pipeline size (i.e., the number of outstanding interests) according to a window-based Additive-Increase/Multiplicative-Decrease (AIMD) mechanism. In this mechanism, the timing for transmission of interests must be perfectly adjusted by monitoring
Fig. 1. NRTS functional modules.
the reception bandwidth to minimize playback delay. However, the transport protocol imposes highly complex interest operations on consumers and leads to longer playback delay. In the case of MPEG-DASH over CCN [8], [9], the consumer monitors the current data buffer size to determine the appropriate video quality to be requested. However, the quality adaptation mechanism is not suitable for delay-sensitive applications. The mechanism considers that a large amount of data packets are held in the buffer at the consumer side; however, it results in long playback delay. III. NRTS D ESIGN A. Functional Overview NRTS is designed to achieve the following objectives: 1) Content-name-based forwarding: Routers should be able to recognize the type of content by the content name prefix and bypass the caching procedure. 2) Bursty interest suppression: Bursty interests must be suppressed to provide consumers with consistently high quality streaming services without unnecessary network congestion. 3) Simple operation for consumer: It should not be necessary for consumers to perform complex interest operations (e.g., adjustment of the best pipeline size). 4) Stability in congested network: In congested networks, high-performance real-time streaming must enable ideal data reception by using simple and effective methods. To achieve these objectives, the following three modules are implemented in NRTS (Fig. 1): 1) PIT management to handle symbolic interest, 2) Reception controller with network condition monitor, and 3) Transmission controller with Transmission Control Table (TCT). These modules operate in conjunction with each other, as described in Algorithm 1. B. Symbolic Interest without Segment Identification In CCN, when a consumer requests streaming data, the user must specify the content name and segment number in an interest, and thus, receives a data packet per interest. The user
2016 13th IEEE Annual Consumer Communications & Networking Conference (CCNC)
Algorithm 1 NRTS routing functions 1: /* PIT Management */ 2: function Receive Interest(𝑛𝑎𝑚𝑒, 𝑓 𝑎𝑐𝑒 𝑖𝑛) 3: if 𝐶ℎ𝑒𝑐𝑘 𝑆𝑦𝑚𝑏𝑜𝑙𝑖𝑐 𝐼𝑛𝑡𝑒𝑟𝑒𝑠𝑡.𝑖𝑠𝑇 𝑟𝑢𝑒() then 4: if 𝐶ℎ𝑒𝑐𝑘 𝑅𝑎𝑡𝑒𝐶𝑜𝑛𝑡𝑟𝑜𝑙 𝑓 𝑖𝑒𝑙𝑑.𝑖𝑠𝑇 𝑟𝑢𝑒() then 5: /* Transmission Controller */ 6: TCT Entry(𝑛𝑎𝑚𝑒, 𝑓 𝑎𝑐𝑒 𝑖𝑛, 𝑠𝑝𝑒𝑐𝑖𝑓 𝑖𝑒𝑑 𝑟𝑎𝑡𝑒) 7: else 8: ContentName Based PIT Entry(𝑛𝑎𝑚𝑒, 𝑓 𝑎𝑐𝑒 𝑖𝑛); 9: LookUpFIB and Interest Sending(); 10: end if 11: else 12: Per Packet PIT Entry(𝑛𝑎𝑚𝑒, 𝑓 𝑎𝑐𝑒 𝑖𝑛); 13: LookUpFIB and Interest Sending(); 14: end if 15: function Receive Data(𝑛𝑎𝑚𝑒, 𝑓 𝑎𝑐𝑒 𝑖𝑛) 16: if 𝑀 𝑎𝑡𝑐ℎ 𝑃 𝐼𝑇 𝐸𝑛𝑡𝑟𝑦.𝑖𝑠𝑇 𝑟𝑢𝑒() then 17: if 𝑀 𝑎𝑡𝑐ℎ 𝑇 𝐶𝑇 𝐸𝑛𝑡𝑟𝑦.𝑖𝑠𝑇 𝑟𝑢𝑒() then 18: /* Transmission Controller */ 19: Check and Adjust TransmissionRate(); 20: end if 21: Data Sending(); 22: end if 23: /* Reception Controller */ 24: if 𝑀 𝑎𝑡𝑐ℎ 𝐶𝑜𝑛𝑡𝑒𝑛𝑡𝑁 𝑎𝑚𝑒 𝐵𝑎𝑠𝑒𝑑 𝑃 𝐼𝑇 𝐸𝑛𝑡𝑟𝑦.𝑖𝑠𝑇 𝑟𝑢𝑒() then 25: 𝑃𝑠𝑎𝑚𝑝𝑙𝑒 ← Calculation PLR(𝑓 𝑎𝑐𝑒 𝑖𝑛); 26: 𝑃 ← 𝛼 × 𝑃 + (1 − 𝛼) × 𝑃𝑠𝑎𝑚𝑝𝑙𝑒 ; 27: if 𝑃 ≥ 𝑃𝑡ℎ𝑟𝑒𝑠ℎ then 28: Sending SymbolicInterest for RateDown(𝑓 𝑎𝑐𝑒 𝑖𝑛); 29: else 30: Sending SymbolicInterest for RateUp(𝑓 𝑎𝑐𝑒 𝑖𝑛); 31: end if 32: end if 33: function PIT Timer Out(𝑛𝑎𝑚𝑒, 𝑓 𝑎𝑐𝑒) 34: Delete PIT Entry or FaceOnly(𝑛𝑎𝑚𝑒, 𝑓 𝑎𝑐𝑒); 35: if 𝑀 𝑎𝑡𝑐ℎ 𝑇 𝐶𝑇 𝐸𝑛𝑡𝑟𝑦.𝑖𝑠𝑇 𝑟𝑢𝑒() then 36: Delete TCT Entry or FaceOnly(𝑛𝑎𝑚𝑒, 𝑓 𝑎𝑐𝑒); 37: end if
must also adjust the manner of sending interests in order to receive streaming data in time. As described in Section II-B, this strategy results in bursty interests and a fairly complex adjustment of the manner of sending interests. In order to reduce the traffic caused by bursty interests, NRTS adopts “symbolic interest,” which indicates the content name and duration (e.g., 30 s), but does not require the segment number to be specified. Thus, in NRTS, a consumer can continually obtain data packets per interest for the specified period. A newly defined optional header in the Type-LengthValue (TLV) packet format1 is used to indicate whether the 1 In CCNx version 1.0, a TLV packet format is introduced for an interest and data packet [4], whereas we tentatively use this header option in our NRTS implementation.
interest represents a symbolic interest. In NRTS, a content name specified by the consumers does not include an RTP sequence number or a segment number; however, when a router creates the corresponding PIT entry, the name prefix combines the specific content name prefix with a flag “++” and a label “segment” (e.g., /example.com/video/video1/++segment). The router registers such a name prefix in its PIT, and considers “++segment” as a wild-card expression (i.e., replaces with the RTP sequence numbers or the segment numbers). Symbolic interests extend the “InterestLifetime” parameter stored in the PIT. The InterestLifetime parameter is already defined in CCN; however, it is used to simply extend the lifetime of a PIT entry. In NRTS, InterestLifetime is used to extend the lifetime of a PIT entry, and also to enable the NRTS router to continuously forward streaming data during the specified period (e.g., 30 s) while receiving streaming data with the relevant content name prefix. In order to continue receiving content, a consumer sends new symbolic interests well before (e.g., 3 s before) the expiry of the InterestLifetime specified in the last symbolic interest. This step is accomplished by taking into account the delay in the arrival of the new symbolic interest at the upstream router. Thus, seamless data reception is enabled by reducing the sending interval between two interests before lifetime expiration. If the first symbolic interest at the start of receiving the content is lost, the start-up delay becomes extremely long. As a simple solution to this issue, irrespective of the lifetime specified in the interest, a consumer transmits the corresponding symbolic interest a couple of times. C. PIT Management In order to handle symbolic interests, NRTS supports a content-name-based PIT entry, in addition to per-packet PIT entries. A content-name-based PIT entry maintained by each router contains the content name prefix (not including the segment number) specified in a received symbolic interest and the Face(s), such as {/example.com/video/video1/++segment, {Face0, Face2}}. In order to handle the InterestLifetime for each Face, a router preserves and updates the InterestLifetime at each Face when receiving interest messages. When the InterestLifetime of a Face has expired, the Face is removed from the PIT entry. When the InterestLifetime of all the Faces expires, the contentname-based PIT entry is removed from the PIT. By supporting a content-name-based PIT entry, NRTS routers can inherently support multicast communication. By definition, the original CCN supports multicast communication. However, the definition may lead to incorrect interpretations of multicast for real-time streaming: 1) Fundamentally, CCN routers can forward content to multiple consumers without intervention by the original publisher if the routers cache the data; or 2) When a CCN router simultaneously (i.e., at a per-packet level) receives interests for content with identical names from multiple downstream Faces, it aggregates the received requests into a single interest message and forwards
2016 13th IEEE Annual Consumer Communications & Networking Conference (CCNC)
the interest to the upstream CCN router. However, we cannot assume that real-time streaming content is always cached in routers. Further, interests sent by multiple consumers who request identical content are seldom perfectly synchronized at the segment number or the per-packet level. In NRTS, by contrast, routers can handle interests for the same streaming content without separately sending the interests upstream and receiving multiple instances of the same data. Then, the routers can maintain one-to-many PIT entries for one content name prefix and multiple downstream Faces, and can natively effect multicast-style communication. D. Reception Controller The reception controller in NRTS 1) monitors network conditions (i.e., packet loss conditions) on each Face, and 2) sends new symbolic interests to the upstream router(s) in order to control the data reception rate or video quality. The reception controller operates between neighboring routers; an upstream router receiving a symbolic interest does not forward it to a router(s) further upstream. Packet loss is detected by referring to the segment numbers of the relevant transmitted packets, RTP sequence numbers when an RTP header is encoded, or the information in the RTP header for Scalable Video Coding (SVC) [12] when SVC [16] is used for video encoding. When the reception controller detects packet loss, it samples a packet loss rate (𝑃𝑠𝑎𝑚𝑝𝑙𝑒 ) at the fixed interval. By using an exponentially weighted moving average with a smoothing factor 𝛼 (0 < 𝛼 < 1), the packet loss rate 𝑃 is calculated as follows: 𝑃 = 𝛼 × 𝑃 + (1 − 𝛼) × 𝑃𝑠𝑎𝑚𝑝𝑙𝑒 . The value of 𝛼 determines the rapidity with which 𝑃 adapts to 𝑃𝑠𝑎𝑚𝑝𝑙𝑒 . In this study, in order to avoid the adverse effects of a temporary increase in packet loss rate, we set 𝛼 to a relatively high value, 0.8, and the fixed interval time for 𝑃𝑠𝑎𝑚𝑝𝑙𝑒 to 1.0 s in this work. When 𝑃 is greater than or equal to the threshold value (𝑃𝑡ℎ𝑟𝑒𝑠ℎ ), the reception controller module sends a symbolic interest with a transmission rate for the upstream router to reduce the data transmission rate. When 𝑃 < 𝑃𝑡ℎ𝑟𝑒𝑠ℎ , the reception controller sends a symbolic interest for the upstream router to increase the transmission rate. 𝑃𝑡ℎ𝑟𝑒𝑠ℎ is set to 0.01 based on comprehensive simulation results. In order to provide instructions to upstream routers about controlling data reception rate or streaming quality, the reception controller communicates its desired reception rate or video quality parameter using a “rate control” type field in the optional header by specifying the data transmission rate in the symbolic interest. The upstream router receiving the symbolic interest changes the data transmission rate to the specified value. E. Transmission Controller In NRTS, transmission control is performed in association with a symbolic interest containing the rate control field. When an NRTS routing daemon receives a symbolic interest with a rate specification, it inserts the content name with the rate control field specified in the symbolic interest in the TCT.
Consumer 1 1Gbps, 1ms
Consumer 2 Publisher
R1 1Gbps, 1ms
R2
1Gbps, 1ms
1Gbps, 1ms 1Gbps, 1ms
Consumer 8
Fig. 2. A local testbed to measure basic streaming performance.
When the NRTS routing daemon receives data and confirms the existence of the corresponding PIT entry using the PIT management process, it also checks the TCT to determine the existence of a corresponding entry. If the corresponding TCT entry exists, the transmission controller adjusts the data transmission rate or video quality by referring to the rate type field. If a Face in the PIT entry is removed (e.g., owing to timer expiration), the corresponding Face in the TCT is removed. For real-time video streaming in NRTS, SVC [16] functions well because it enables encoders to produce a single video stream (maintained by a single PIT entry) with multiple quality layers providing progressive enhancement of the stream. A consumer can request the highest-quality video stream coded by SVC with a symbolic interest. Then, the user can adjust the quality by discarding the layered video data according to the reception condition without interaction with upstream routers. When SVC is used, the rate control field in a symbolic interest specifies the desired layer(s) to be transmitted. When a router sends a symbolic interest to increase the data reception rate, the next level layer of the video is requested. The transmission controller module changes the rate of the corresponding field in the TCT. While referring to the field in the TCT, the transmission controller module adjusts the video layers. IV. E VALUATION A. Impact of Pipeline and Block Size Setting on Streaming Performance We implemented NRTS based on CCNx 0.7.2. First, we investigated the impact of pipeline and block size settings on the streaming performance of CCN and NRTS on a local testbed (Fig. 2). A publisher transmits a live stream and eight consumers receive it. The bandwidth and one-way delay for each link were 1 Gbps and 1 ms, respectively. We implemented the streaming publisher, consumers, and the routers on Intel Core i7/3.5 GHz CPU desktop PCs running on 64-bit Linux. We used the average reception bandwidth as a performance metric. The reception bandwidth of live streaming over CCN is affected by the pipeline size, which determines the number of interest packets that the consumer can send per unit of time; therefore, we tested CCN by using various pipeline sizes. NRTS and CCN are affected by the content object size; hence, we performed the evaluation by using content object sizes of 1024 and 4096 bytes. Fig. 3(a) shows the experimental results obtained when the content object size was set to 1024 bytes. The average reception bandwidth of CCN with a pipeline size of one is approximately 4 Mbps owing to the low interest transmission
2016 13th IEEE Annual Consumer Communications & Networking Conference (CCNC)
!"
!
TABLE I AVERAGE RTT AND HTTP THROUGHPUT FROM THE PUBLISHER ( AT NICT) Site RTT (ms) HTTP throughput (Mbps) Waseda University 2.9 64.5 Keio University 2.5 125 SNU (via Keio) 73.3 9.86
# #"
"
# # "
" "
publisher
" " "
a
!
b
a
(a) Average throughput (content object size = 1024 (bytes))
Keio Univ. (JP)
!"
!
b
#
b
SNU (KR)
Fig. 4. CCN/NRTS topology created at four sites in Japan and Korea on an ICN testbed.
#"
"
a
Waseda Univ. (JP)
a
NICTT (JP)
b
# # "
" "
" " "
!
(b) Average throughput (content object size = 4096 (bytes)) Fig. 3. Average throughputs (Mbps) for a consumer requesting a 1024 and 4096 byte content object.
rate. Bursty interests cause network congestion, and some of the interest packets are not delivered upstream (and hence, the corresponding data are not delivered). This phenomenon indicates that consumers must configure pipeline size appropriately according to network conditions and the streaming data rate to be received, which can be a challenge. In contrast, NRTS always achieved desirable throughput values without requiring the pipeline size adjustment. Fig. 3(b) shows the result for a content object size of 4096 bytes. The average reception bandwidth of CCN was approximately the same as that of NRTS in all cases except the case in which the pipeline size was one. This behavior is a result of the increase in the the amount of data transmitted per request. However, increasing the content object size results in a trade-off: packet loss triggers a higher negative impact on playback quality. B. Streaming Performance of CCN and NRTS on an ICN Testbed In order to verify the scalability of NRTS, we conducted experiments on an ICN testbed [21], which employs the Linux Container (LXC) virtualization mechanism to build testbed nodes. This experiment involved multicast-style communications with eight consumers requesting the same live streaming in the testbed, as shown in Fig. 4. For reference, we investi-
gated the average Round-Trip Time (RTT) and HTTP/TCP/IP throughput of data transmission for each site measured on the same day by using the wget command from the publisher (at NICT), as shown in Table I. Instead of using a size-based pipeline to send interests, the consumers sent interests at a constant rate (i.e., a consumer could send an interest packet after the previous one without waiting to receive a new content object) in CCN. We set the content object size to 4096 bytes, with the exception of the link between Keio and Seoul National University (SNU) (where the content object size was limited to 1024 bytes owing to their network configuration). In each test, we conducted the experiments 10 times, and chose the average of the top five results. Fig. 5(a) shows the results of the experiment for CCN. When the streaming data transmission rates are greater than 15 Mbps, the average throughput of CCN cannot achieve ideal data receptions (i.e., the average throughput values of some CCN consumers reduced to values significantly lower than the streaming data transmission rate). It can be seen that, in the Waseda and SNU networks, in particular, the average throughput values were considerably low. This result can be attributed to the loss of interests and content objects for consumers in the Waseda and SNU networks owing to bursty interests. Consumers in the SNU network, which dealt with smaller content objects (1024 bytes), experienced greater loss of interest packets owing to bursty interests and greater loss of content object packets owing to higher processing costs in the router (i.e., Keio-a). However, in Fig. 5(b), NRTS consumers attained much higher average throughput values, especially at higher streaming data rates, than consumers using CCN. Thus, it can be concluded that 1) interest and content object losses were mitigated as a result of symbolic interests, and 2) multicaststyle communication effectively reduces node processing cost, and contributes to improvements in forwarding performance
2016 13th IEEE Annual Consumer Communications & Networking Conference (CCNC)
#$
0.7
0.6
Data Packet Loss Rate
#
"$
"
!$
!
0.5
NRTS CCN for the highest quality stream request CCN for the intermediate quality stream request CCN for the lowest quality stream request
0.4 0.3 0.2 0.1
$
0
!
$ ! !$ " "$
#
0
5
10
15 20 25 Time (sec.)
30
35
40
(a) Overall data loss rate
(a) Average throughput (8 consumers with CCN) 2 #$
Video Layer
#
"$
"
1
!$
!
Base layer
$ !
$ ! !$ " "$
#
Background Traffic Receiver
3Mbps layer-2 3Mbps layer-1 3Mbps base-layer
Consumer 1
Video Stream
Publisher
R1 10Mbps, 10ms
R2 10Mbps, 10ms
R3
5
10
15
20 25 Time (sec.)
30
35
40
(b) Transition of video layers recorded in the Transmission Control Table (TCT) at NRTS Router-1 (R1) Fig. 7. Simulation results for three consumers with NRTS and CCN
(b) Average throughput (8 consumers with NRTS) Fig. 5. Average throughputs (Mbps) for each of 8 consumers with CCN and NRTS, respectively. Background Traffic Sender
0
Consumer 2
10Mbps, 10ms 10Mbps, 1ms
Consumer 3
Fig. 6. CCN/NRTS simulation topology.
and proper reception of content objects for consumers. These results reveal that our proposed architecture improves scalability and facilitates efficient data reception for many consumers without the need for a complex pipeline setting. C. Streaming Performance of CCN and NRTS in a Congested Network In order to investigate the adaptability and stability of NRTS in congested networks, we performed a simulation using ndnSIM [17] with the network topology shown in Fig. 6. We assumed that the publisher sent SVC-encoded video streams of the highest quality at a rate of 9 Mbps, and that three consumers received the streams. The video stream included three video quality layers, and the bandwidth of each video layer was 3 Mbps. The bandwidth of all the intermediate links was set to 10 Mbps, with a link delay of 10 ms, except the client access link (1 ms). Background traffic was
transmitted from 10 s to 30 s at an average rate of 3 Mbps. We used four types of consumers: 1) NRTS consumers, 2) CCN consumers receiving the lowest video quality, 3) CCN consumers receiving the intermediate video quality, and 4) CCN consumers receiving the highest video quality. For CCN consumers, the sending interval of interest packets for each video quality was set based on the bit rate. Since size-based or interval-based pipeline approach suffers from bursty packet loss and widely fluctuating jitter [19], we did not use the consumer type. Fig. 7(a) shows the simulation result with respect to the overall data packet loss rate. Prior to the transmission of background traffic (after 10 s), CCN consumers who had requested intermediate quality streams and the highest quality streams observed data packet loss owing to bursty interests. The CCN consumers did not synchronize for transmission of identical interests at a per-packet level, and hence, router3 (R3) was unable to aggregate them, thus resulting in increased interest and data traffic. When background traffic transmission commenced, NRTS consumers observed a data loss rate of approximately 10% (in 11 s). However, as shown in Fig. 7(b), however, the video layers transmitted from router1 (R1) to router-2 (R2) were adjusted by the rate control mechanism, which thus contributed to the suppression of data loss. Subsequently, although NRTS consumers experienced approximately 4% data loss (in 23 s) owing to the video layer increment transmitted at R1, the adaptation scheme minimized data loss.
2016 13th IEEE Annual Consumer Communications & Networking Conference (CCNC)
V. R ELATED W ORK Voice over CCN, VoCCN [7], was introduced as a practical example that exploited the intrinsic features of CCN. The authors claimed that CCN is scalable because it does not require the inbound Session Initiation Protocol (SIP) proxies of VoIP. The Audio Conferencing Tool (ACT) [10], another proposal for real-time streaming applications over CCN, explores naming and real-time audio conferences. In a high latency network, the interest-data round trip delays the reception times of the voice data packets for VoCCN and ACT, thus rendering them unplayable or inferior in quality. In order to overcome this problem, these proposals adopted the pipeline approach, in which the data receiver maintains a certain number of outstanding interests for each voice data stream. CCN-TV [20] also adopted the pipeline approach with a fixed size, in order to handle playout delay and real-time data. However, as previously described, this approach requires all consumers to set the pipeline size appropriately according to network conditions and the rate, which is a challenge. Tsilopoulos et al. [18] proposed Persistent Interests (PIs) in order to avoid deletion of the PIT entries until users explicitly unsubscribe from a channel or the interest lifetime expires. Their motivation is identical to our objective with symbolic interest. However, a new procedure to unsubscribe from a channel introduces a complex state machine and reduces the benefit of protocol simplicity in CCN. Further, PIs does not define a mechanism to manage multiple lifetimes, such as the situation in which multiple PIs with different lifetimes for the same channel are received on a router, in order to support multicasting. NDNVideo [19] is currently being developed with the objective of completely utilizing the features of NDN [5]. The goal of this project is to design and implement software for live and on-demand video streaming, with random access (even on live sources) and no session semantics or negotiation, while enabling multiple receivers to experience synchronized multimedia. The results of NDNVideo tests indicate that the specification of a size-based or interval-based interest pipeline is not sufficiently reliable for widespread usage because loss of bursty packets and widely fluctuating jitter were often observed, stemming from network congestion triggered by the transmission method for interest messages. VI. C ONCLUSION In this paper, we proposed Content Name-based Real-time Streaming, NRTS. Symbolic interest avoids the transmission of bursty interests, and enables routers to continue forwarding data for a specified period. It results in significant reduction in the network congestion owing to bursty interests, thus overcoming the issue observed in the original CCN. NRTS supports content-name-based streaming that naturally enables multicast-style communication with a rate control scheme based on network conditions. Experimental results conducted on a local and an international ICN testbed showed that NRTS performs better than CCN, and confirmed that NRTS can achieve significantly higher throughput and scalability without
a complex pipeline setting. The results of the simulation also show that NRTS can achieve high throughput and stability even in cases with insufficient available bandwidth. In future research, we intend to design an intelligent algorithm to quickly detect an interest or data packet loss and adjust the lifetime or transmission rate according to network conditions. We also plan to implement a video quality controller, and conduct more extensive analyses of methods to adjust the video bit-rate. R EFERENCES [1] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard, “Networking Named Content,” Proc. ACM CoNEXT 2009, pp.1–12, Dec. 2009. [2] D. Trossen, M. Sarela, and K. Sollins, “Arguments for an informationcentric internetworking architecture,” SIGCOMM Comput. Commun. Rev., vol.40, no.2, pp.26–33, Apr. 2010. [3] “CCNx implementation,” available at: http://www.ccnx.org/ [4] “CCNx 1.0 Protocol Specification,” available at: http://www.ccnx.org/documentation/ [5] “Named Data Networking,” available at: http://named-data.net/ [6] T. Stockhammer, “Dynamic adaptive streaming over HTTP-design principles and standards,” Proc. ACM MMSys ’11, Feb. 2011. [7] V. Jacobson, D. Smetters, N. Briggs, M. Plass, J. Thornton, and R. Braynard, “VoCCN: Voice-over content centric networks,” Proc. ACM ReArch Workshop 2009, Dec. 2009. [8] S. Lederer, C. Mueller, C. Timmerer and H. Hellwagner, “Adaptive Multimedia Streaming in Information-Centric Networks,” IEEE Network Magazine, Vol.28, No. 6, pp. 91-96, 2014. [9] S. Lederer, C. Mueller, B. Rainer, C. Timmerer, and H. Hellwagnet, “Adaptive Streaming over Content Centric Networks in Mobile Networks using Multiple Links,” Proc. IEEE ICC, 2013, pp. 677-681. [10] Z. Zhu, S. Wang, and X. Yang, “ACT: Audio Conference Tool Over Named Data Networking,” Proc. ACM SIGCOMM ICN Workshop, Aug. 2011. [11] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” IETF RFC 3550, Jul. 2003. [12] S. Wenger, Y.K. Wang, T. Schierl and A. Eleftheriadis, “RTP Payload Format for Scalable Video Coding,” IETF RFC 6190, May 2011. [13] G. Carofiglio, M. Gallo, L. Muscariello and M. Papalini, “Multipath congestion control in content-centric networks,” Proc. IEEE ICNP 2013. [14] F. Zhang, Y. Zhang, A. Reznik, H. Liu, C. Quian and C. Xu, “A transport protocol for content-centric networking with explicit congestion control,” Proc. IEEE ICCCN, Aug. 2014. [15] H. Wu, M. Claypool, and R. Kinicki, “Adjusting forward error correction with quality scaling for streaming MPEG,” Proc. ACM NOSSDAV’05, Washington, USA, Jun. 2005. [16] H. Schwarz, D.Marpe and T. Wiegand, “Overview of the Scalable Video Coding Extension of the H.264/AVC Standard,” IEEE Trans. Circuits and Syst. for Video Tech., Vol. 17, No. 9, pp. 1103-1120, Sep. 2007. [17] A. Afanasyev, I. Moiseenko, and L. Zhang, “ndnSIM: NDN simulator for NS-3,” NDN, Technical Report NDN-0005, 2012 [18] C. Tsilopoulos and G. Xylomenos, “Supporting Diverse Traffic Types in Information Centric Networks,” Proc. ACM SIGCOMM Workshop, Aug. 2011. [19] D. Kulinski and J. Burke, “NDNVideo: Random-access Live and Prerecorded Streaming using NDN,” Technical Report NDN-0007, 2012. [20] V. Ciancaglini, G. Piro, R. Loti, L.A. Grieco and L. Liquori, “CCN-TV: A Data-centric Approach to Real-Time Video Services,” Proc. IEEE AINA Workshops, Mar. 2013. [21] H. Asaeda, R. Li, and N. Choi, “Container-based Unified Testbed for Information-Centric Networking,” IEEE Network Magazine, Vol. 28, No.6, pp.60-66, 2014.
