The document proposes a hybrid video streaming scheme for hierarchical peer-to-peer (P2P) networks. The scheme aims to reduce server load, network load, initial waiting time, and freeze time from faults. It uses a scheduling algorithm called "pyramid broadcasting" to reduce initial waiting time. The tree construction mechanism builds P2P multicast trees based on the physical network structure to reduce server and network loads. The fault recovery mechanism allows rapid recovery from faults using only local communication to reduce freeze time. Simulation experiments showed the scheme achieved its objectives by reducing initial waiting time, freeze time, and loads on servers and peers.
Computer networks have experienced an explosive growth over the past few years and with
that growth have come severe congestion problems. For example, it is now common to see
internet gateways drop 10% of the incoming packets because of local buffer overflows.
Our investigation of some of these problems has shown that much of the cause lies in
transport protocol implementations (
not
in the protocols themselves): The ‘obvious’ ways
to implement a window-based transport protocol can result in exactly the wrong behavior
in response to network congestion. We give examples of ‘wrong’ behavior and describe
some simple algorithms that can be used to make right things happen. The algorithms are
rooted in the idea of achieving network stability by forcing the transport connection to obey
a ‘packet conservation’ principle. We show how the algorithms derive from this principle
and what effect they have on traffic over congested networks.
In October of ’86, the Internet had the first of what became a series of ‘congestion col-
lapses’. During this period, the data throughput from LBL to UC Berkeley (sites separated
by 400 yards and two IMP hops) dropped from 32 Kbps to 40 bps. We were fascinated by
this sudden factor-of-thousand drop in bandwidth and embarked on an investigation of why
things had gotten so bad. In particular, we wondered if the 4.3
BSD
(Berkeley U
NIX
)
TCP
was mis-behaving or if it could be tuned to work better under abysmal network conditions.
The answer to both of these questions was “yes”.
Transmission Control Protocol (TCP) is a fundamental protocol of the Internet Protocol Suite. TCP complements the Internet Protocol (IP), therefore it is common to refer to the internet protocol suit as TCP/IP. TCP is used for error detection, detection of packet loss or out of order delivery of data. TCP requests retransmission, rearranges data and helps with network congestion.
Several congestion control algorithms have been developed, over the last years, to improve TCP's performance over various technologies and network conditions.
The purpose of this assignment is to present TCP, network congestion, congestion algorithms and simulate different algorithms in different network conditions to measure their performance. For this assignment's needs, OPNET IT Guru Academic Edition software was used to accomplish the reproduction of projects that have been already published and gave the wanted results.
NS2 - the network simulator which is proved useful in studying the dynamic nature of communication networks. Simulation of wired as well as wireless network functions and protocols( e.g. routing algorithms, TCP, UDP ) can be done using NS2
(Slides) P2P video broadcast based on per-peer transcoding and its evaluatio...Naoki Shibata
Shibata, N., Yasumoto, K., and Mori, M.: P2P Video Broadcast based on Per-Peer Transcoding and its Evaluation on PlanetLab, Proc. of 19th IASTED Int'l. Conf. on Parallel and Distributed Computing and Systems (PDCS2007), (November 2007).
http://ito-lab.naist.jp/themes/pdffiles/071121.shibata.pdcs2007.pdf
Computer networks have experienced an explosive growth over the past few years and with
that growth have come severe congestion problems. For example, it is now common to see
internet gateways drop 10% of the incoming packets because of local buffer overflows.
Our investigation of some of these problems has shown that much of the cause lies in
transport protocol implementations (
not
in the protocols themselves): The ‘obvious’ ways
to implement a window-based transport protocol can result in exactly the wrong behavior
in response to network congestion. We give examples of ‘wrong’ behavior and describe
some simple algorithms that can be used to make right things happen. The algorithms are
rooted in the idea of achieving network stability by forcing the transport connection to obey
a ‘packet conservation’ principle. We show how the algorithms derive from this principle
and what effect they have on traffic over congested networks.
In October of ’86, the Internet had the first of what became a series of ‘congestion col-
lapses’. During this period, the data throughput from LBL to UC Berkeley (sites separated
by 400 yards and two IMP hops) dropped from 32 Kbps to 40 bps. We were fascinated by
this sudden factor-of-thousand drop in bandwidth and embarked on an investigation of why
things had gotten so bad. In particular, we wondered if the 4.3
BSD
(Berkeley U
NIX
)
TCP
was mis-behaving or if it could be tuned to work better under abysmal network conditions.
The answer to both of these questions was “yes”.
Transmission Control Protocol (TCP) is a fundamental protocol of the Internet Protocol Suite. TCP complements the Internet Protocol (IP), therefore it is common to refer to the internet protocol suit as TCP/IP. TCP is used for error detection, detection of packet loss or out of order delivery of data. TCP requests retransmission, rearranges data and helps with network congestion.
Several congestion control algorithms have been developed, over the last years, to improve TCP's performance over various technologies and network conditions.
The purpose of this assignment is to present TCP, network congestion, congestion algorithms and simulate different algorithms in different network conditions to measure their performance. For this assignment's needs, OPNET IT Guru Academic Edition software was used to accomplish the reproduction of projects that have been already published and gave the wanted results.
NS2 - the network simulator which is proved useful in studying the dynamic nature of communication networks. Simulation of wired as well as wireless network functions and protocols( e.g. routing algorithms, TCP, UDP ) can be done using NS2
(Slides) P2P video broadcast based on per-peer transcoding and its evaluatio...Naoki Shibata
Shibata, N., Yasumoto, K., and Mori, M.: P2P Video Broadcast based on Per-Peer Transcoding and its Evaluation on PlanetLab, Proc. of 19th IASTED Int'l. Conf. on Parallel and Distributed Computing and Systems (PDCS2007), (November 2007).
http://ito-lab.naist.jp/themes/pdffiles/071121.shibata.pdcs2007.pdf
Server-based and Network-assisted Solutions for Adaptive Video StreamingEswar Publications
Server-based adaptive video streaming is gaining popularity in recent years. This is because clients (client-based) and in-network devices (network or proxy-based) are not powerful enough to run state of the art adaptation algorithms, for example, traffic shaping and machine learning. When decision making is placed at the server new and exciting possibilities are obtained for next best segment selection. This work highlights server-based solutions to adaptive video streaming. It provides a taxonomy of current state of the art solutions. It then illustrates various approaches used for server-based adaptive video streaming. Advantages and disadvantages are discussed.
Network-assisted or in-network DASH solutions have certain advantages over traditional client-based approaches. It is proposed that the sharing of information would result in better network and client bandwidth estimations.
This measure would ensure better next segment selections. In this paper a novel network-assisted DASH taxonomy is proposed. It consists of cache-based, optimization, rate-quality model, and co-operative elements. Recent approaches using the elements of the taxonomy are illustrated. These approaches show the advantages of using network-assisted entities in DASH-based systems.
ROLE OF DIGITAL SIMULATION IN CONFIGURING NETWORK PARAMETERSDeepak Shankar
Selecting the right Ethernet standard and configuring all the network devices in the embedded systems accurately is an extremely hard and rigorous job. The configuration depends on the topology, workloads of the connected devices, processing overhead at the switches, and the external interfaces. Network calculus, mathematical models and analytical techniques provide worst case execution time (WCET), but their probability of activity is extremely wide. This leads to overdesign which leads to higher costs, power consumption, weight, and size. Simulating the network is the best way to measure the throughput of the entire system. Digital system simulation provides better latency and throughput accuracy, but the accuracy is still limited because it does not consider the latency associated with the network OS, cybersecurity processing and scheduling. In many cases, these factors can reduce the throughput by 20-40%.
In this paper, we will present our research on modeling the entire Ethernet network, including the workloads, network flow control, scheduling, switch hardware, and software. To substantially increase the coverage and compare topologies, we have developed a set of benchmarks that provides coverage for different combination of deterministic, rate-constrained, and best effort traffic. During the presentation, we will cover the benchmarks, the list of attributes required to accurately model the traffic, nodes, switches, and the scheduler settings. We will also look at the statistics and reports required to make the configuration decision. In addition, we will discuss how the model must be constructed to study the impact of future requirements, failures, network intrusions, and security detection schemes.
Key Takeaways:
1. Learn how to efficiently use network simulation to design Ethernet systems
2. Develop a reusable benchmark and associated statistics to test different configurations
3. The role and impact of the CDT slots, guard band, send slope, idle slope, shuffle scheduling, flow control and virtual channels
What happens when adaptive video streaming players compete in time-varying ba...Eswar Publications
Competition among adaptive video streaming players severely diminishes user-QoE. When players compete at a bottleneck link many do not obtain adequate resources. This imbalance eventually causes ill effects such as screen flickering and video stalling. There have been many attempts in recent years to overcome some of these problems. However, added to the competition at the bottleneck link there is also the possibility of varying network bandwidth which can make the situation even worse. This work focuses on such a situation. It evaluates current heuristic adaptive video players at a bottleneck link with time-varying bandwidth conditions. Experimental setup includes the TAPAS player and emulated network conditions. The results show PANDA outperforms FESTIVE, ELASTIC and the Conventional players.
LLL-CAdViSE: Live Low-Latency Cloud-based Adaptive Video Streaming Evaluation...Alpen-Adria-Universität
Live media streaming is a challenging task by itself, and when it comes to use cases that define low-latency as a must, the complexity will rise multiple times. In a typical media streaming session, the main goal can be declared as providing the highest possible Quality of Experience (QoE), which has proved to be measurable using quality models and various metrics. In a low-latency media streaming session, the requirements are to provide the lowest possible delay between the moment a frame of video is captured and the moment that the captured frame is rendered on the client screen, also known as end-to-end (E2E) latency and maintain the QoE. This paper proposes a sophisticated cloud-based and open-source testbed that facilitates evaluating a low-latency live streaming session as the primary contribution. Live Low-Latency Cloud-based Adaptive Video Streaming Evaluation (LLL-CAdViSE) framework is enabled to asses the live streaming systems running on two major HTTP Adaptive Streaming (HAS) formats, Dynamic Adaptive Streaming over HTTP (MPEG-DASH) and HTTP Live Streaming (HLS). We use Chunked Transfer Encoding (CTE) to deliver Common Media Application Format (CMAF) chunks to the media players. Our testbed generates the test content (audiovisual streams). Therefore, no test sequence is required, and the encoding parameters (e.g., encoder, bitrate, resolution, latency) are defined separately for each experiment. We have integrated the ITU-T P.1203 quality model inside our testbed. To demonstrate the flexibility and power of LLL-CAdViSE, we have presented a secondary contribution in this paper; we have conducted a set of experiments with different network traces, media players, ABR algorithms, and with various requirements (e.g., E2E latency (typical/reduced/low/ultra-low), diverse bitrate ladders, and catch-up logic) and presented the essential findings and the experimental results.
1. A Hybrid Video Streaming Scheme on Hierarchical P2P Networks * Shinsuke Suetsugu Naoki Wakamiya, Masayuki Murata Osaka University, Japan Koichi Konishi, Kunihiro Taniguchi NEC Corporation, Japan
2.
3.
4.
5.
6. Overview of Proposed Scheme Tree Server (GTS) Video Server (ORG) Scheduling Server (SS) Local Tree Server (LTS) Subnet Tree Server (STS) Normal Peer ( NP ) branch A branch C branch B subnet a subnet c subnet b Central office branch branch branch division division division
7.
8. 1. Scheduling Algorithm - pyramid broadcasting - t t playout -> video data Scheduling Server ( SS ) Video Server ( ORG ) play-rate b transmission –rate 2b distribute continuously on different channels among each segments segment slot peer 1 : 2 : 4
9. 2. Tree Construction Mechanism trees are constructed segment-by-segment and slot-by-slot
10. 2. Tree Construction Mechanism - inter-branch tree - Tree Server ( GTS ) Video Server ( ORG ) inform IP address of Video Server participation request The first participation request in this branch branch A branch C branch B Central office LTS LTS
11. 2. Tree Construction Mechanism - inter-branch tree - Tree Server ( GTS ) Video Server ( ORG ) branch A branch C branch B limitation for number of children fanout = 2 list of ancestors: video server -> LTS B recursively attempts to connect to children on failure inform IP address of one of its children Peers store informed addresses as a list of ancestors Central office
12. 2. Tree Construction Mechanism - inter-subnet tree - LTS Tree Server ( GTS ) Video Server ( ORG ) consider its fanout branch A subnet A subnet D subnet B subnet C inform IP address of LTS in this branch STS
13.
14.
15.
16. Initial Waiting Time average waiting time: 2.94 sec maximum waiting time: < 6 sec initial waiting time [sec] cumulative probability
17. Freeze Time video freezes for only 0.5 % of all thousands of peers maximum freeze time: < 1 sec freeze time [sec] cumulative probability
18.
19.
Editor's Notes
Thank you Mr. chairman. Now I’m going to discuss our research / titled Low-delay and continuous P2P video streaming on structured networks.
This presentation is organized as follows. First, I introduce the [research background] / and I describe our objective. Next, I give [an explanation of our proposal], including three items, that is, scheduling algorithm, tree construction mechanism, and fault recovery mechanism. After that, I show [some results of simulation experiments]. Finally, I conclude this presentation.
Here I introduce [the background of our research]. Video streaming is [a promising application] that has been widely distributed. In a client-server model, as shown in the left figure, the server [[has to] distribute [video data] to all clients], which causes heavy load on the server. [P2P multicast technology], however, can help [to reduce the load of the server] by [peers relaying video data to other peers], as shown in the right figure. To achieve [P2P multicast technology], it is required [to construct multicast trees] to determine how video data are distributed.
How to construct “good” distribution trees? In many other papers, they measure [characteristics of the underlying physical network], for example, delay or bandwidth. However, that requires long time and causes [heavy load on the network]. In the case [of enterprise or university networks], measurements are not required, because they have [well-organized hierarchical structures], consisting [of branches and divisions, or departments]. By assuming such structured networks, [distribution trees] can be built easily and quickly.
Therefore, we propose [a scalable scheme of video streaming distribution] for [hierarchically constructed networks] based on [the organizational structure], for example, enterprises and universities. In this proposal we try [to reduce the load of servers and networks]↑, shorten [the initial waiting time] until the video starts playing↑, and reduce [the freeze time] caused by faults.
First, I give [an overview of our proposal]. This figure is [an example of an enterprise network]. There are three servers at the central office, named scheduleing server↑, tree server↑, and video server. The scheduling server manages [the schedules of peers and servers], and determines [ when distribution trees [have to] be constructed]. The tree server [manages distribution trees] and determines how to construct them. The video server is [the root of distribution trees] and [distributes video streams to the peers]. An enterprise has some branches, whose networks we call “branch”. And each branch has some divisions, whose networks we call “subnet”. For every branch, a peer is selected as [local tree server], and [inter-branch trees] are constructed among [local tree servers]. In the same way, for every subnet, a peer is selected as [subnet tree server], and [inter-subnet trees] are constructed among [subnet tree servers]. Other peers are called Normal Peer, NP, and inter-NP trees are constructed among normal peers.
Our proposal consists of three features. One is the scheduling algorithm [for reduction of the [initial waiting time]], another is the [tree construction mechanism] for construct distribution trees quickly , the other is the [fault recovery mechanism] for [ not freezing the video streams]. I explain these three ideas in this order.
For scheduling we use [existing pyramid broadcasting]. Please take a look at this top figure. A video data [is divided into segments ]. [The duration of segments] follows [the geometric progression] for [not freezing video streams]. Next, please look at this lowers figure. Each segment is [ repeatedly broadcasted on a dedicated channel] at twice the rate of play-rate. [Each segment duration] is called a slot . At the beginning of this scheme, [◎] a peer (who wants to watch a video stream) sends a “schedule request” to the [scheduling server]. [◎] [The scheduling server] [assigns slots to the peer] so that it receives segments one-by-one [from the beginning of the stream]. [◎] The peer receives segments [as the scheduling server informs], [◎] and plays, [◎] receives and [◎] plays, [◎] receives and [◎] plays [in this order].
As the second idea, I explain [about the tree construction mechanism]. Distribution trees are constructed segment-by-segment and slot-by-slot . I assume that the blue peers receive the first segment in this blue slot, and the red peers are in this red slot. With [the scheduling algorithm], [blue and red peers] also receive the second segment [in this yellow slot]. It means that they all are included in [the tree of the segment in the yellow slot], and the tree is constructed like this. Then I explain how these trees are constructed [by choosing one tree].
I explain [about the three types of trees] depending on their hierarchy. First, I show how the inter-branch trees are constructed. [After communicating with the scheduling server], [◎] each peer sends a “participation request” to the tree server. [◎] In each branch, the first peer sending the request is assigned as a local tree server , called LTS. [◎] The tree server [informs the IP address of the video server] to the LTS. [◎] The LTS establishes connection to the video server.
I assume that an LTS in the branch C tries to connect to the video server as well. However, It causes [a concentration of the load] on the video server, so the video server has [a limitation for the number of children], called “fanout number”. If the fanout number is two , the LTS in the branch C cannot connect to [the video server] because [the video server] already has two children. In this case, [◎] the video server [informs the IP address of one of its children] to the LTS. [◎] The LTS connects to the informed address. [◎] Peers, however, also have this limitation, that is, the fanout number. If the LTS C [cannot connect to the LTS B due to the limitation], the LTS C tries to connect to a child of LTS B. This means, peers recursively [step down the tree] and they definitely succeed [in joining the tree]. [The tree server] does [ not manage this process], which help [to reduce the load of the server]. [◎] Peers record addresses [they were informed in this process] as the “ ancestor list ”. [◎] For example, the LTS C has [IP addresses of [the video server and the LTS B]]. This information is used [in the fault recovery mechanism], I will explain later. [◎] Next, I explain how the inter-subnet trees are constructed.
Inter-subnet trees can be constructed, in [ almost the same manner as the inter-branch trees]. [◎] In each subnet, the first peer sending a participation request to [the tree server] is assigned [as a subnet tree server], called STS. [◎] The STS is informed of an IP address of not the video server but the LTS in this branch, and establishes connection to the LTS. [◎] In the same manner, an inter-subnet tree [is constructed [with considering the fanout number]]. At last, I explain how the inter-subnet trees are constructed.
There are several differences [between the 1st and later segments] about [the manner of constructing inter-NP trees]. [◎] At the 1st segment, a peer sending a participation request is assigned as NP , Normal peer, [◎] and is informed of the [IP address of the STS of this subnet, and connects to it. [◎] At later segments, a client [does not access the tree server] but directly accesses [the STS of previous segment] and establishes connection. An inter-NP tree is constructed as well, considering its fanout.
As the final issue, I discuss [the fault recovery mechanism]. Faults are caused [by many kinds of reasons and occasions], for example, [a user stops playing the video] or [[network components] such as routers and links] fail. This mechanism can work [in any of these situations]. I propose two types of recovering, [one is the recovery within a subtree], the other is recovery among different trees. I explain about [only recovery within subtrees] due to the limitation of the time. [◎] When a peer leaves this tree, [◎] these two peers [try to recover from fault]. These peers have [the information about their ancestors ], [◎] so one of them can connect to its grandparents, [◎] and finishes recovering. [◎] The other peer also [tries to connect to it], [◎] but the limitation, fanout number, prevents that. [◎] This peer [is informed of its grandparents’s children], [◎] and [tries to connect to it]. [◎] Finally recovery is completed. This mechanism [can work for all types of subtrees], such as inter-branch trees, inter-subnet trees and inter-NP trees.
[Our criteria for evaluation] are [the load of servers and peers], [the initial waiting time] and [the recovery and freeze time]. In our scenario, there are [ five branches in a network] and [ five subnets in each branch]. The [peer arrival rate] is set at 30 arrivals per second. It means [that the number of peers (participating in video distribution) is 2,790 (two thousand seven hundred and ninety) on average. Every peer leaves the service [with a probability of 0.004 at every second]. It means that only 47% can receive the whole video. I introduce [some of the results] we got from our simulation experiments.
This figure shows [the distribution of initial waiting time] that a peer experiences. [The initial waiting time] is the time beginning [ when a peer sends [a schedule request] to the scheduling server] and ending [ when it starts playing the video]. We can see that [the average waiting time] is 2.94 seconds, and [the maximum waiting time] is less than six seconds.
This figure depicts [the distribution of freeze time]. The freeze time is the total time [the video play-out is interrupted]. We can see [that [only 0.5 % of peers] experience freezes] and [the maximum freeze time] is 0.98 seconds, short enough for users to tolerate.
Finally I conclude our presentation. In this talk, we proposed a scheme for video streaming. Simulation verified [that our scheme provides users] with low-delay and continuous video streaming services. However, we also found [that [the load of the servers] is still rather high and we can improve our approach [by further reducing the load]. Therefore, we need an improved mechanism to distribute [the load efficiently]. [In addition] redundant flows can exist on inter-branch networks. A new algorithm (to build bandwidth-efficient, low-cost inter-branch distribution trees) is the topic of future work.
Now the presentation is completed. Thank you for your kind attention.