Consumer driven Adaptive Rate Control for Real-time Video Streaming in CCN/NDN
Takahiro YONEDA, Ryota OHNISHI,Eiichi MURAMOTO(Presenter),R&D Division, Panasonic CorporationJeff Burke, UCLA
Paper will be to appear in IEICE (conditional acceptance) Contact: [email protected]
R&D Division2
Table of Contents• Focused requirements and target applications• Function of PIT, CS in CCN/NDN (background
knowledge)• 2 types of RTT variation
– Source change, congestion
• Proposed method– Receiver driven, focusing on RTT fairness
• Simulation result– Single bottleneck (basic), multiple-RTT
• Implementation• Conclusion
Requirement for the Real-time Adaptive Rate Controlling
• Target: Live real-time streaming like conferencing
Live Buffer time tolerant
Archiving video (Library)
Security Camera (airport, street,,,)
CDN of video (VoD, youtube, etc)
Security Camera (real-time tracking)Video conferencing (interactive talk)
CDN of Live video (Live sports, etc)
Low delay deliveryless than 200ms for example
Sneaker network(production)
Example of the target application• Security camera, Real-time tracking• Multiple user access to the different sources
Some content ( at certain bit-rate) might be cached on router
criminal
Assumption for the target application
• Data (frame data) is divided into a plurality of data chunk• Each data chunk has sequential number (in its name)
Ex. NDNvideo
Sequential number
Background knowledge: CCN/NDN, CS and PIT
Fig: Presentation at Panasonic “Named Data Networking(NDN)”, Jeff Burke, June 2013
2
R&D Division7
(1) RTT variation by source change (unexpected)
P Router1
Publisher node
Router2 Router3
Consumer nodesC1 C2 C3
Hits PIT
Hits Content Store
(a)
Router0
P Router1 Router2 Router3
C1 C2 C3
(b)
Router0
P Router1 Router2 Router3
C1 C2 C3
(c)
Router0
Hits Content Store
Hits Content Store
Hits PIT
Interest packetData packet
Hits PIT
R&D Division8
(2) RTT increase by congestion , by queuing delay
other traffic
Link buffer
Router
If input rate is over the output link speed incoming packets are stacked in the link buffer, so that network delay of each packet is increase.
audio/video data packets
Link buffer
Queuing delay increasing
R&D Division9
Problem scope
• Consumer-driven , (no router support)• Network bandwidth estimation based on RTT variation &
packet loss• Control Interest sending rate according to the bandwidth
estimation• Select video stream bit-rate according to the bandwidth
estimation• Considering 2 types of RTT variation (unexpected or
congestion)
Points
Targets• Keep low latency transmission & available best throughput• Maintain RTT fairness (self fairness + RTT fairness)
R&D Division10
Related works (1)
• AIMD based transport mechanism [1-3]– Low throughputs in large RTT environment– Easy to increase queuing delay
• Live video distribution [4,5]– fixed sliding window might be assumed? – No adaptability for network bandwidth variation
Consumer-driven approach
[1] Giovanna Carofiglio, et al. Icp: Design and evaluation of an interest control protocol forcontent-centric networking. INFOCOM NOMEN Workshop, 2012.
[2] Stefano Salsano, et al. Transport-layer issues in information centric networks. ACMSIGCOMM ICN Workshop, 2012.
[3] Somaya Arianfar, et al. Contug: A receiver-driven transport protocol for content centricnetworks. IEEE ICNP, 2010
[4] Ciancaglini V., et al. CCN-TV: A Data-centric Approach to Real-Time Video Services.Advanced Information Networking and Applications Workshops. 2013.
[5] Derek Kulinski, and Jeff Burke. NDNVideo: Random-access Live and Pre-recorded Streamingusing NDN. In Technical Report http://named-data.net/techreport/TR007-streaming.pdf
R&D Division11
Related works (2)
• Hop-by-hop Interest flow sharping mechanism [6]– Problem of deployment
Router support approach
[6] Giovanna Carofiglio, et al. Joint hop by hop and receiver-driven interest control protocol forcontent-centric networks. ACM SIGCOMM ICN Workshop, 2012.
Proposed method
• AvgRTT≦ (RTTmin + jitter_offset) or Consecutive AvgRTT decrease
• Consecutive AvgRTT increase or Packet loss
1. Measure RTT on receiving each Data packet
2. Calculate average RTT in each short period
3. Control Interest sending rate in each short period
AvgRTT : Average RTT in each short periodRTTmin : Minimum RTTpps : Number of sending Interest packet per second
prevprevnow ppsppspps /
prevprevnow ppsppspps
(α≧1)
(0＜β＜1)
Receiver driven
R&D Division13
Distinguish consecutive RTT change and unexpected one
0
10
20
30
40
50
60
70
80
90
0 50 100 150
Aver
age
RTT
[ms]
Time [ms]
P
Consecutive RTT increase or packet loss⇒ Judge to be congested
⇒ Decrease Interest rate
Single RTT increase⇒ Judge to be changed location
of content cash⇒ Keep Interest rate
Consecutive RTT decrease/Stable RTT⇒ Judge to be stable
⇒ Increase Interest rate
PtPtt ppsppspps /Increase Interest rate
PtPtt ppsppspps Decrease Interest rate tppsx
sInterval
Interest sending interval pptt Number of Interest packet
in one second
P Constant period of estimation
s Content chunk size [byte]
x Pre-defined constant value
Average RTT calculation in each period
R&D Division14
Simulation with ndnSIM (ns-3)
BWPn-R1 1Gbps
D Pn-R1 1ms
BWR2-Cn 1Gbps
D R2-Cn 1ms
Queue Droptail
Queue Size 50pkt
P1
Router1 Router2
Pn Cn
C1Bottleneck Link
P2 C2
Publisher nodes Consumer nodes
Link bandwidth=BWlink Link delay=Dlink
• Basic evaluation• on single bottleneck link
• Assumption• Each consumer node requests content with sequential numbering
in the Content Name for each Interest packet• Each consumer node has determined the Content Name to fetch
through other means• Each publisher node provides single video stream with variable
bit-rate
R&D Division15
Basic simulation results (1-1)
0
2000
4000
6000
8000
10000
12000
0 10 20 30 40 50 60
Estim
ate
Rat
e[kb
ps]
Time [sec]
C1
(n=1, BWR1-R2=10Mbps, DR1-R2=8ms)
Evaluation of bandwidth efficiency & transmission latency on the single bottleneck link
0
5
10
15
20
25
30
35
40
0 10 20 30 40 50 60
Aver
age
RTT
[ms]
Time [sec]
C1
0
500
1000
1500
2000
2500
3000
3500
0 10 20 30 40 50 60
Estim
ate
Rat
e[kb
ps]
Time [sec]
C1
C2
C3
C4
0
10
20
30
40
50
60
0 10 20 30 40 50 60
Aver
age
RTT
[ms]
Time [sec]
C1C2C3C4
(n=4, BWR1-R2=10Mbps, DR1-R2=8ms)
R&D Division16
Comparison vs. AIMD
(n=1, BWR1-R2=10Mbps, DR1-R2=3-148ms)
Proposed method: - The throughput is more stable in various RTT - Lower delay (especially in short RTT)
0102030405060708090
100
10 20 100 200 300
[%]
Minimum network delay (both-way) [ms]
Network bandwidth efficiency
ProposalAIMD
0
5
10
15
20
25
30
10 20 100 200 300
[ms]
Minimum network delay (both-way) [ms]
Average increase of transmission latency
ProposalAIMD
AIMD (Additive Increase/Multiplicative Decrease)Decrease when packet loss, (duplicated ACK or time-out)
R&D Division17
Evaluation of RTT fairnessProposed method - each consumer gains almost same throughput
AIMD- shorter RTT consumers gain more
(n=32, BWR1-R2=100Mbps, DR1-R2=8ms)
(DelayR2-Cn=5*n+1 ms)(DelayR2-Cn=1 ms)
00.10.20.30.40.50.60.70.80.91
0
5
10
15
20
25
30
35
0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 6.5 7 7.5 8 8.5 9
Cum
ulat
ive
rela
tive
frequ
ency
Num
ber
of n
odes
Average throughput [Mbps]
Number of node（Proposal）
Number of Node（AIMD）
Cumulative relative frequency（Proposal）
Cumulative relative frequency（AIMD）
00.10.20.30.40.50.60.70.80.91
0
5
10
15
20
25
30
35
0.5 1 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 6.5 7 7.5 8 8.5 9
Cum
ulat
ive
rela
tive
freq
uenc
y
Num
ber
of n
odes
Average throughput [Mbps]
Number of node（Proposal）
Number of Node（AIMD）
Cumulative relative frequency（Proposal）
Cumulative relative frequency（AIMD）
R&D Division18
Evaluation of RTT fairness on the multi-bottleneck link topology
Case1BWR0-R1=100Mbps
Case2BWR0-R1=100MbpsBWR16-R17=50Mbps
Case3BWR0-R1=100MbpsBWR16-R17=25Mbps
00.5
11.5
22.5
33.5
44.5
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31
Aver
age
thro
ughp
uts
[kbp
]
Cn
Case1Case2Case3
Router0
Publisher node
Router1
Consumer nodes
C1
Router n
CnPn
P2
P1
Link bandwidth=BWlinkLink delay=Dlink
Router16
C16
Router17
C17
(n=32, Dall link=5ms)
Proposed method - adapt to the narrowest bottleneck and fairly share the bandwidth
R&D Division19
Feasibility for the implementation
• NDN-based live and pre-recorded video streaming (made by UCLA )
• random access to key frames using a time-code based namespace
• On-the-fly archival of live streams; identical playback approach for pre-recorded video
On NDNvideo
R&D Division20
Implementation on NDNvideo (2)
00.050.10.150.20.250.30.350.40.450.5
0
500
1000
1500
2000
2500
3000
3500
4000
0 10 20 30 40 50 60 70 80 90 100
Network bandwidthEstemate RateAverage RTT
Estim
ate
Rat
e [k
bps]
Ave
rage
RTT
[se
c]
Time [sec]
Feasible to be implemented in the real-world application(confirm the basic behavior of our implementation on NDNvideo)
Conclusion• Focus on the Live real-time video streaming• RTT fairness would be important
– because it would be unexpectedly changed by source change in NDN/CCN
• Proposed method– Receiver driven (no router support)– Periodically (re-)compute PPS (not per RTT) – Use Short period average RTT (not EMWA)
• Simulation result– lower delay, more RTT-fair compared to AIMD
• Implemented on NDNvideo to show the feasibility • Future work
– Implementation on NDNRTC with UCLA– Supporting multi-source, multi-interface scenario
