Project topics and materials
Get Complete Project Material File(s) Now! »
Live video streaming
In the case of live video streaming, the source is producing the media while the user asks for it. The main goal is therefore to minimize the latency between the two while providing a smooth quality of experience to the user. Albeit DAS techniques can provide a good user’s quality of experience, the minimum latency they can achieve is bounded by the segment granularity: a segment must first be fully encoded before being available for download. To achieve low-latency streaming, several real-time streaming protocols were developed, such as RTMP and RTP. Real-Time Messaging Protocol (RTMP) is a protocol that was initially a pro- prietary protocol, but was partially released in [105]. It was developed by Macromedia (now owned by Adobe) for streaming multimedia content over the Internet. RTMP is a TCP-based protocol that establishes persistent connections between Flash players and servers. it splits multimedia streams into fragments of size dy- namically negotiated between the two parties. Real-time Transport Protocol (RTP) [126] is a protocol that provides end-to- end real-time data (e.g., audio, video) delivery services in a push-based fashion. Typically, RTP runs on top of UDP, but it can be used on top of other underlying transport or network protocols. If the underlying protocol is supporting multicast, then RTP also supports multicast distribution. Its primary goal is to support web- conferencing (audio and/or video) and to do so, it had to accommodate to the different media formats available and therefore, a payload type identification is
provided in the RTP header to indicate to the receiver the encoded format of the data carried in this RTP packet. Furthermore, as a receiver may receive multimedia contents from several sources, a synchronization source (SSRC) identifier is present in the RTP header to uniquely identify the media source of this packet. The RTP header also presents a sequence number, that is incremented by one for each RTP packet sent, for the receiver to detect packet loss and packet reordering. RTP is only designed to transport media data, and thus relies on session establishment protocols, such as SIP (Session Initiation protocol), RTSP (Real-Time Streaming Protocol), or SDP (Session Description Protocol).
Bandwidth estimation granularity
Figures 3.9-(a) and 3.9-(b) present the impact of bandwidth estimation on the DAS performance by contrasting a coarse-grained throughput estimation against a fine-grained one. Specifically, in Figure 3.9-(a), each video segment constitues a bandwidth sample, while a sample in Figure 3.9-(b) results from averaging estim- ates over 50 NDN packets, as also proposed in [138]. As a consequence, the number of available samples in the NDN case can grow up to two orders of magnitude more with respect to the TCP segment-based estimate (recall Figure 3.2), thus resulting in valuable extra information that can be used to implement a more timely and refined estimate of the available bandwidth.
While we are aware that more sophisticated approaches would be possible (e.g., packet-pair for capacity [70], train or chirps for available bandwidth [99, 47, 116], possibly in band with the data transfer [102]), our main interest here is not to quantitatively assess a specific mechanism, but to point out qualitative properties that can be expected from this building block. Furthermore, provided the availability of the complex aforementioned techniques for the TCP case, the resulting estimate would, however, be available only at the server side, requiring out-of-band protocols to signal it to DAS clients (differently from the NDN case).
When comparing Figure 3.9-(a) to Figure 3.9-(b), we notice that the instant- aneous bandwidth variations are better tracked by a fine-grained estimate, which allows DAS clients to better exploit the available capacity. However, a more re- sponsive adaptation logic might result in an increased aggressiveness, as shown by AdapTech and BOLA, where the number of quality switches increases, if it is not smoothed by the strategy itself, as shown by the conservative version of PANDA, which takes advantage of the finer-grained estimate by increasing the selected video quality (with respect to the TCP/IP case) without any side effect. It is also worth noticing that while a fine-grained bandwidth estimate allows to a better use of the available capacity and thus downloading at a higher rate, the buffer level is lower with respect to the TCP/IP case and can, in some cases, lead to rebuffering events, for instance when using PANDA with a vanilla NDN network
stack (without WLDR). Therefore, we are not advocating to indiscriminately use fine-grained bandwidth estimates (e.g., see the increase in quality shifts in some cases), we consider more accurate techniques to estimate the available bandwidth as a useful building block when coupled to, for example, in-network load balance, where the availability of multiple (independent) channels can be exploited to either increase the selected video quality, or guarantee the same quality if some of them experience bad conditions: in these cases, being able to closely track channel evol- ution would allow to fully benefit from the aggregate capacity.
Access technology and emulation technique
In order to confirm the findings discussed in the previous sections in more real- istic conditions, we now contrast DAS performance gathered via emulated channel models (Wi-Fi and LTE) against those collected using real traces. In particular, we use both 3G 4 and 4G 5 real traces, available at [117, 136]. For the emulated cases, we set the distance between the client and the Wi-Fi access point to 60m, resulting in a downstream capacity of approximately 6Mbps, while the distance between the client and the LTE base station is set to 1200m, thus offering a down- stream capacity of approximately 18Mbps. We remark that if, on the one hand, emulated models have the benefits of yielding arbitrarily long stochastic processes – which ensure statistical relevance of the experiments over multiple independent repetitions, real traces, on the other hand, represent samples of finite length, but of real conditions – without requiring complex calibrations.
Table of contents :
Abstract
Résumé
Remerciements
1 General Introduction
1.1 Video streaming to shape future networks
1.2 ICN: a promising architecture
1.3 Thesis statement
1.4 List of contributions
2 Background
2.1 Video Delivery
2.1.1 Video on Demand
2.1.2 Live video streaming
2.2 MPEG-DASH
2.2.1 General
2.2.2 Adaptation logics
2.3 Information-Centric Networking
2.3.1 Named Data
2.3.2 Name-based routing
2.3.3 ICN features
2.3.4 ICN architectures
3 Assessing ICNbenefits invideodelivery
3.1 Introduction
3.2 Methodology
3.2.1 Adaptation logics used
3.2.2 Architecture
3.2.3 Scenario description
3.3 Calibration Results
3.3.1 Adaptation logic behaviour
3.3.2 Sensitivity analysis
3.3.3 Multi-client scenarios
3.4 Experimental Results
3.4.1 In-network loss recovery
3.4.2 Bandwidth estimation granularity
3.4.3 Access technology and emulation technique
3.4.4 In-network load-balancing
3.4.5 Summary
3.5 Conclusion
4 Network-Assistance invideodelivery
4.1 Introduction
4.2 Related Work
4.2.1 Single element network assistance
4.2.2 Multi-element network assistance
4.3 To Cache or not to Cache?
4.3.1 Design space
4.3.2 Results at a glance
4.4 Network-aware DASH proposal
4.4.1 NA2: Network-Aware AdapTech
4.5 Evaluation
4.5.1 Sensitivity analysis
4.5.2 Comparison with Network-blind baseline
4.6 Conclusion
5 Assessing ICNbenefits inReal-TimeStreaming
5.1 Introduction
5.1.1 DAS real-time communication
5.1.2 WebRTC
5.2 Related work
5.3 Hybrid ICN Background
5.3.1 Naming
5.3.2 Forwarding
5.3.3 Consumer/Producer socket API
5.4 Review of WebRTC architectures
5.5 hICN-RTC Architecture
5.6 Realtime Information Centric Transport Protocol
5.6.1 RICTP Producer socket
5.6.2 RICTP Consumer Socket
5.7 Evaluation
5.7.1 Implementation and Experimental Settings
5.7.2 RICTP benchmarking
5.7.3 hICN-RTC Scalability
5.8 Conclusion
6 Conclusion
Appendices
A Tools used in our experiments
A.1 vICN
A.2 The CICN suite
A.3 Videos used
B Viper
C Small guide forDASHexperiments
D Small guide to network-assisted DASH experiments
D.1 Extreme cases
D.2 Network assistance
D.3 Extra information
E Résumé de la thèse en français
