1. Introduction
The large increase in the number of users and the new multimedia services over the Internet (e.g. videoconferencing, video surveillance, VoIP, online games or P2P-TV) generates a significant amount of network traffic [1, 2]. Moreover, the expectation of future growth in the use of multimedia applications indicates that this tendency will increase in future years. The heterogeneous characteristics of different Internet access technologies, together with user demands, make it necessary to take into account the Quality of Service (QoS) that they offer, especially when the accesses have to support real-time applications and multimedia services.
At the same time, the traffic generated by each service depends on the nature of the information carried and its size, so some applications generate bursts of traffic (e.g. video surveillance) when a lot of information has to be sent in a short time. These bursts may congest network devices if the amount of packets to be transmitted is significant with respect to the buffer size. On the other hand, some applications work to generate smooth traffic [3], with the aim of providing a certain QoS level and better user experience while not being detrimental for the network, at the cost of an increment in the processing capacity. The size of the packets generated by these applications may vary between different Internet services: while some of them (e.g. VoIP) generate small packets of a few tens of bytes, others (e.g. videoconferencing and video surveillance) use large packets. By contrast, the buffer size and the available bandwidth for supporting both services are the same, so congestion problems may appear in certain access links.
In this situation, the size of the router buffer is an important design parameter when planning a network. The reason is that there is a relationship between router buffer size and link utilization, since an excessive amount of memory would generate a significant latency when the buffer is full (this phenomenon is also known as bufferbloat). On the other hand, a very small buffer size will increase packet loss during periods of congestion. As a consequence, the influence of the buffer should be considered when trying to improve link utilization. Many studies related to buffer size issues have been published in recent years, but they are mainly focused on backbone routers and TCP flows [4] and not on buffer behaviour.
There are various techniques for improving link utilization, but most of them are focused on bandwidth saving. Nevertheless, bandwidth is not the only parameter to take into account. The buffer size and its behaviour are of primary importance when studying network traffic because the buffer is used as a traffic regulator mechanism, which may modify some parameters such as delay or jitter, and may also drop packets. As a consequence, the influence of the buffer is important in order to reduce packet loss and to offer a better user experience, especially when multimedia flows are being transmitted.
The paper is organized as follows. Section 2 reviews buffer dimensioning and discusses the influence of the buffer in different real-time services. This highlights the need of taking the buffer behaviour into account when planning a network. Section 3 describes the specific congestion problems addressed in this paper when increasing bandwidth in a local network, or combining multimedia and bursty traffic. Section 4 reports the experimental results. Two different scenarios have been deployed in order to analyze the problem statement and obtain some QoS parameters. The paper ends with the conclusions.
2. Related Work
2.1 Buffer Dimensioning
Buffers are mainly used to reduce packet loss by absorbing transient bursts of traffic when routers cannot forward them at a specific moment. This problem occurs because the router may have different input and output rates, and this produces a bottleneck in the network leading to packet loss. Buffers are instrumental in keeping output links fully utilized during congestion times.
With respect to buffer dimensioning, the commonly accepted rule of thumb is using BDP (Bandwidth Delay Product) [5] to obtain the buffer size needed at a router's output interface. This rule was proposed in 1994 [6] and it is given by B = C * RTT, where B is the buffer size, RTT is the average round-trip time and C the capacity of the router's network interface. It was experimentally obtained using at most 8 TCP flows on a 40 Mbps core link, so there is no recommendation for sizing buffers when there is a significant number of TCP flows with different RTTs.
In [7], the authors proposed a reduced buffer size by dividing BDP by the square root of the number of TCP flows present: B = C * RTT/√N. This new approximation assumes that the number of TCP flows is large enough so as to consider them as asynchronous and independent from each other. This model was called small buffer [8].
In [9] the use of even smaller buffers called tiny buffers was suggested, considering a size of some tens of packets. However, the use of this model may present a packet discard probability of 10% - 20%. The model was obtained on the basis of there been no bursty traffic.
However, some real-time IP flows present a traffic pattern consisting of bursts of high amounts of packets during short intervals. This happens with video surveillance and video streaming. This traffic profile may produce some uncertainty in buffer sizing, since a small buffer will increase packet loss but a big one will excessively delay real-time packets. In [10] and [4], combined TCP and UDP traffic flows were tested in very small buffers using non-bursty traffic, and an anomalous region was found where the probability of loss of UDP packets grows when the buffer size increases.
It has also been observed in the literature that the buffer size can be measured in different ways. For example, in [11] the routers of two manufacturers are compared. One gives the information in packets whereas the other measures it in milliseconds, which is equivalent to bytes. As a consequence, the knowledge of the buffer behaviour is an interesting parameter which cannot be avoided when trying to improve link utilization.
2.2 Influence of the Buffer on Different Services
Many scientific publications considering the influence of the buffer on different services and applications show how QoS is affected by the buffer behaviour, which is mainly determined by its size and policy. In these cases, knowing the technical and functional characteristics of this device is important. This knowledge can be useful for applications and services in order to make decisions on the way traffic is generated. In addition, packet management techniques can be applied, e.g. multiplexing a number of small packets into a big one or fragmentation, according to circumstances of each case [12].
The use of QoS characteristics based on objective network parameters (e.g. jitter, packet loss, etc.) is a suitable method for studying the influence of the buffer on multimedia traffic. In addition, subjective quality evaluation can be used to determine the users' perception of certain services. The ITU-T E-Model [13, 14] proposes a procedure for calculating the Mean Opinion Score (MOS), which is useful for network planning. Other authors [15] have developed a similar model, based on delay and jitter, for measuring the quality of online games.
The influence of the buffer on VoIP was studied in [12], where three different router buffer policies (dedicated, big and time-limited) were tested, using two multiplexing schemes. The router buffer policies caused different packet loss behaviour, and also modified the voice quality measured by means of R-factor. In the same paper, a multiplexing method for VoIP flows was studied, in which the bandwidth used was reduced by increasing the packet size. The authors show that the router buffer affects packet loss, depending on its implementation and size. In this case the native VoIP traffic showed a good behaviour when using a small buffer measured in bytes, since small packets have less probability of being discarded than big ones.
In [16] the authors presented a simulation study of the influence of a multiplexing method on the parameters that define the subjective quality of online games, mainly delay, jitter and packet loss. The results show that small buffers present better characteristics for maintaining delay and jitter at appropriate levels, at the cost of increasing packet loss. In addition, buffers whose size is measured in packets also increase the loss rate.
Many access network devices are designed for bulk data transfers [17], typical of e-mail, web browsing or FTP services. However, the same routers may experience problems for managing the traffic of other applications which generate high rates of small packets (e.g. P2P video streaming, online games, etc.). In this case, there may be bottlenecks in their processing capacity if they have to send too many packets per second [18]. In a P2P video environment, these high rates of small packets [19] may penalize the video packets and consequently peer behaviour within a P2P structure will not be as expected.
3. Problem statement
When network congestion problems arise in a SME scenario, a common practice is to increase the bandwidth of the local network. For this reason, many companies periodically upgrade their internal network devices (e.g. switching from 10 to 100 Mbps). Although this can be seen as the most thorough solution for the problem, other questions should be taken into account, since congestion is not only caused by bandwidth scarcity. Some problems can also be caused by network device implementations. As we will see below, in certain cases an increase may result in a worse network response, thus the network improvement may lead to a degradation in quality.
The reason for this phenomenon is related to the buffer filling rate. As we can see in Fig. 1, the time required to reach buffer overflow is related to the filling rate, given by the input and output rates [20]. Let Rin and Rout be the input and output rates of the buffer, respectively. We define Rfill as the rate in which the buffer fills when Rin is higher than Rout(Rfill = Rin - Rout). So, if Rout remains the same and Rin is switched from 10 to 100 Mbps, then the buffer filling rate (Rfill) will be higher in a 100 Mbps network. For this reason, the buffer may reach overflow more quickly in a 100 Mbps than in a 100 Mbps network.
Fig. 1.Principal characteristics of buffers.
When bursty traffic is generated in the network, a quick buffer filling rate may cause packet loss at certain moments, even if the average link utilization is low. This may happen when the burst length is almost equivalent to the buffer size. The buffer will easily reach overflow when it has some packets in the queue at the moment a burst arrives. This can also occur when the length of the burst is bigger than the buffer size. Although some applications generate smooth traffic, aggregate Internet traffic shows a bursty behaviour at all time scales [21]. In order to avoid this problem, some applications include smoothing features [3], which are able to modify the profile of the traffic generated.
All in all, the relationship between the speeds of the Internet access and the local network, and the relationship between buffer size and burst length are in fact important parameters which cannot be neglected when planning a network. In the next section, we describe a number of tests with the aim of illustrating this phenomenon. In some cases the combination of certain buffer sizes with bursty applications may cause buffer congestion and consequently QoS problems.
4. Tests and results
In this section, two scenarios are proposed in order to analyze the effect of the buffer size in the presence of bursty traffic, and the possible implications for the traffic of other applications. We will focus on a typical SME environment with one Internet access link, in which VoIP shares the network with the rest of the services. Real applications are used in order to obtain the traffic traces to be employed in the tests, so no traffic models have been required. Different buffer sizes have been chosen according to the results obtained in the various works cited above and the real sizes of commercial network devices (e.g. Linksys WAP54G) [20]. The results are obtained by means of packet to packet traffic analysis with the NS-2 tool.
4.1 Network Scenarios
Two scenarios are used for the tests. In the first one (shown in Fig. 2, a), a number of video surveillance communications share the same Internet access. The main aim of the test is to determine the packet loss rate in the mixed bursty traffic for different buffer sizes, and to observe the different results when the links between the cameras and the Internet access devices are 10 or 100 Mbps. The traffic of two and three cameras is used, each one with an average bit rate of 1 Mbps. The bandwidth is limited to 3.5 Mbps, which is a reasonable uplink value for current DSL access networks. This value has been chosen in order to set the offered bandwidth to 85% of the link capacity when three cameras are present. In addition, by setting this link utilization level, we ensure that packet loss is caused by the relationship between the traffic characteristics and the behaviour of the router buffer, and not by bandwidth scarcity.
Fig. 2.Simulated scenarios.
In the second scenario (Fig. 2, b), two flows generated by the IP cameras (1 Mbps per flow), one videoconferencing session (roughly 1.5 Mbps) and two VoIP calls (24 Kbps per flow) share the link, so the total bandwidth generated is 3.5 Mbps. Two different tests have been performed: in the first one, the Internet access capacity has been set to 5 Mbps, so the average link utilization is fixed (70%) and different values of the buffer size are tested. In the second test, the buffer size of the Internet access router is fixed at 40 packets and simulations are run using different values of the access capacity, and consequently different levels of link utilization, ranging from 50 to 90%.
4.2 Real Traffic Captures
In order to deploy the tests described above, we have to use three different multimedia traffic sources: videoconferencing, video surveillance and VoIP. Thus, real traces of videoconferencing and video surveillance applications were first captured in real scenarios and then generated in NS2, using the same packet sizes and inter-packet times. A sniffer which does not degrade the performance of the applications was included at the best location for capturing [22]. VoIP traffic was generated with the NS2 CBR agent. The methodology used for the traffic capture is illustrated in Fig. 3.
Fig. 3.Real traffic capture scenarios.
For videoconferencing traces, VidyoTM architecture was used. VidyoTM incorporates Adaptive Video Layering (AVL) technology, which permits dynamic video optimization for each endpoint, leveraging on H.264 Scalable Video Coding (SVC) compression technology. The videoconference software was configured with 2 Mbps and 800 x 450 resolution while the camera captured a high motion video (a football game).
The video surveillance traffic traces were obtained (see Fig. 3, b) using a popular IP camera device (AXIS 2120). This kind of traffic is particularly bursty. Table 1 shows the relationship between the video compression level and the amount of packets per burst for two different resolutions when the bandwidth of the camera is set to 1 Mbps. For all the tests we have chosen traces with 704 x 576 resolution, and a compression of 32 Kbytes. The time between bursts is 0.278 s ± 0.06 s; the amount of packets per burst is and the packet size is 1,500 bytes.
Table 1.Amount of packets per burst depending on camera parameters
Voice traffic was generated according to the G.729 recommendation ( 20 ms for inter-packet time and 2 samples per packet), resulting in a packet size of 60 bytes.
4.3 Results
4.3.1 First Scenario
As occurs in a real scenario, flows do not start at the same time, so we have added to the simulation an initial period in which the flows start randomly. The results presented are the average values 40 tests. The 95% confidence intervals are also shown in the graphs. The simulation time is 60 s for each test.
The packet loss bursts in the buffer are not only produced by the bursty applications, but may also be caused by the overlapping of traffic from other applications. Although the traffic is roughly 57% and 85% of the available bandwidth, when using two and three cameras, respectively, the packet loss may be unacceptable, as shown in Fig. 4 (note that the Y-axes have different scales in the two sub-figures). The cause is that the overlapping of bursts coming from different cameras produces a traffic burst which may exceed the capacity of the buffer. As an example, we see the poor results when using a buffer size of 30 packets (almost 9% and 4% of packet loss). If the number of packets in a burst generated by a camera is 26, it is easy for the buffer to fill up whenever a burst arrives.
Fig. 4.Relationship between buffer size and packet loss in video surveillance traffic for different buffer sizes.
At the same time, another interesting phenomenon can be observed when comparing the 10 and 100 Mbps results of Fig. 4: we see that packet loss is higher when the network speed is 100 Mbps. Furthermore, there are some cases (e.g. 2 cameras and a buffer of 45 packets) in which packet loss only appears for the fastest network. Why is this happening? If the speed of the Internet connection remains the same, a 100 Mbps network will fill the buffer faster than a 100 Mbps one whenever a burst is generated by a camera. In these cases, upgrading the network speed from 10 to 100 Mbps will produce bursts of lost packets, worsening the performance of the network.
4.3.2 Second Scenario
The results for the scenario with three services sharing the network can be seen in Fig. 5. The same phenomenon mentioned above can be observed: packet loss is higher when the speed of the local network is 100 Mbps. The effect is exacerbated if the buffer is smaller. The 95% confidence intervals are also shown in the graphs.
Fig. 5.Relationship between buffer size and packet loss, for 70% link utilization.
The results presented are for the aggregate traffic of the three applications. Although not shown separately, packet loss affects all the applications, so we observe that the presence of a bursty application (video surveillance) causes packet loss for all the coexisting applications, even for those generating constant bit rate traffic (VoIP).
As expected, packet loss increases when the link utilization grows in the case of a 40 packet buffer (Fig. 6). Again, packet loss is higher for the 100 Mbps network.
Fig. 6.Relationship between link utilization and packet loss for a 40 packet buffer.
4.3.3 Quality Analysis
In this subsection we focus on the quality obtained by each of the services sharing the network. Thus, we will use the second scenario in order to consider the three kinds of flows. We will focus on the 100 Mbps case, since this network speed represents the worst case as regards packet loss. The quality analysis is based mainly on two parameters: packet loss per flow, and delay. In addition, in the case of VoIP, we also present the results using a subjective quality estimator based on these parameters, using different values for the network delay. Besides, we have considered buffer overflow as the only cause of packet loss.
Packet Loss per Flow: Two different groups of tests have been performed: first, a fixed link utilization is considered in the scenario, and second, a fixed buffer size. Fig. 7 presents the results of packet loss per flow using a fixed utilization of the link (70%). The 95% confidence intervals are also shown in the graphs. The main cause of packet loss bursts is the presence of a bursty application (video surveillance) which causes buffer overflow and degrades the quality of all the coexisting applications. It can be observed that packet loss decreases when the buffer size is increased (Fig. 7, a), because bigger buffers can better absorb the bursts produced by the traffic mix. However, videoconferencing and VoIP obtain better results due to their less bursty profile. On the other hand, in Fig. 7, b it can be seen that the packet loss distribution is not the same for all the tested buffers. Small buffers exacerbate the problem caused by video surveillance traffic (the most bursty), increasing the rate of lost packets corresponding to this service.
Fig. 7.Packet loss when link utilization is 70% for different buffer size.
The results using a buffer of 40 packets are shown in Fig. 8. In this chart we represent on the X axis the average link utilization according to the bandwidth generated by the applications. As expected, packet loss increases when the link utilization grows. Again, the packet loss distribution is not the same for the different tests (Fig. 8, b), although the differences are not significant. We can thus see that buffer size has a stronger influence on packet loss distribution per flow. The loss percentage greater for videoconferencing and VoIP than video surveillance traffic.
Fig. 8.Packet loss when buffer size is 40 packets for different values of link utilization.
Packet loss histogram: In the previous subsection we have presented the average results, and we have been able to obtain small values of the confidence intervals. However, it is necessary to describe the packet loss distribution between the communications established in the different tests, since the lost packets may not be uniformly distributed between them. While packets are not lost in certain tests, in others some flows present a high packet loss rate, because in some cases the flow overlapping is bigger. As a result, in the same network, one communication can obtain very good quality whereas others present significantly worse values. The main cause of this effect is the random distribution of overlaps between bursts.
In order to measure this phenomenon, we have selected a scenario with a 70% link utilization and a buffer size of 40 packets, and the same applications described above. In this specific scenario, tests were repeated 200 times to better observe the effect of the overlapping flows cited above, and its relationship with packet loss. The results are presented by a histogram corresponding to each service in Fig. 9, in which the X axis shows the packet loss percentage and the Y axis represents the percentage of iterations in which that packet loss value has been obtained. Note that the X axis values are different for each of the considered services.
Fig. 9.Packet loss histogram for different multimedia flows with a buffer size of 40 packets and 70% link utilization.
In the case of VoIP (Fig. 9, a), the chart shows that almost 80% of the calls present a packet loss value smaller than 0.75%. Packet loss increases up to 3% or more in 0.5% of the cases (equivalent to 20 calls) in which the QoS will be significantly degraded. This confirms that there is a percentage of calls in which the quality obtained will not be good enough for the user.
The videoconferencing service presents a similar behaviour (Fig. 9, b). The packet loss rate is low for a high percentage of the tests. Nevertheless, these losses may impair videoconferencing quality. On the other hand, the camera communication results (Fig. 9, c) show the highest packet loss level (up to 14% in some cases), which may degrade the QoS of this service.
MOS for VoIP Calls: In this subsection we analyze the effect of packet loss bursts on the subjective quality of VoIP, a real-time service with very strict delay and packet loss requirements. In this case, we have used the results from the VoIP Packet loss histogram analyzed above. In order to estimate the subjective quality which would be obtained for each call, we have calculated the R-Factor according to [14] with the following equation:
where delaytotal is the one-way delay and H(x) is a step function. Thus, if the delay is under 177.3 ms, then it does not affect the Rfactor. However, if it exceeds this value, then the Rfactor will be significantly decreased. This responds to the phenomenon cited in [14]: “For one-way delay less than 177 msec, conversations occur naturally, whereas at delay in excess of 177 msec conversations begin to strain and breakdown; often degenerating into simplex communications at high delay values.”
Next, we obtain the MOS from the R factor, using the conversion cited in the same paper. The total delay we have considered includes the delay caused by the router buffer and the network; in addition, a de-jitter buffer has been included in order to absorb the delay variations generated by the router buffer, so the router and the de-jitter buffers compensate each other.
Six different values for the network delays have been used ( 20, 40, 60, 100, 120 and 140 ms) which produce a total delay of 116, 136, 156, 196, 216 and 236 ms, respectively. The results are presented by a histogram (Fig. 10) of the MOS obtained for each test. For the lowest three values of network delay (20, 40 and 60 ms), the figure shows a significant amount of calls with a medium quality according to the ITU-T E-Model [13, 14]. This would represent a bad result for VoIP users, since this scenario would be expected to provide the best quality in all cases. In addition, the tail at the left shows a few calls with an unacceptable quality level. On the other hand, for the three highest network delay values (100, 120 and 140 ms), in which the total delay exceeds the 177 ms threshold, a worse behaviour can be observed in the chart. The increase in the network delay produces a significant reduction in subjective quality, resulting in low quality results in some cases.
Fig. 10.MOS histogram with different one-way network delays, a buffer size of 40 packets and 70% link utilization.
5. Conclusion
This paper has studied packet loss caused by the router buffer in the presence of applications generating bursty traffic, and its influence on VoIP subjective quality. Different tests have been deployed in two scenarios using real traces of three multimedia applications, with different values of link utilization.
The buffer size has been identified as a critical parameter for network planning in these environments. The reason is that the relationship between the buffer size and the number of packets in a traffic burst generated by the applications has to be consistent in order to allocate all the packets, and to avoid packet being discarded owing to buffer overflow. In addition, the relationship between the internal network speed and that of the Internet access determines the buffer filling rate, which may produce packet loss when large bursts of packets are sent from the local network to the Internet.
Different tests have shown that the presence of bursty applications in the internal network may produce packet loss which, surprisingly, may grow with the internal network speed. Tests using different applications, access speeds and buffer sizes have been deployed. In all the tests, packet loss was higher for 100 Mbps than for 10 Mbps.
It has been observed that the bursty traffic generated by some applications affects other services sharing the same link. In order to show the effect of the bursty nature of the traffic of these applications, we have measured the MOS of concurrent VoIP calls. The results show that VoIP calls are only able to obtain a medium quality, failing to reach better results even when the link utilization is 70%. Since the cause of this problem is the bursty nature of many applications, techniques able to smooth traffic are seen as an advantage.
On the other hand, multimedia applications are becoming popular in mobile environments where resources are limited (e.g., processing capacity, power consumption and memory). In these scenarios, the problems highlighted in the present study could affect the QoS of different services, particularly if we take into account that the characteristics of the link may change due to mobility (e.g., handoff or roaming). For this reason, in a future work we plan to analyze buffer size in mobile environments when multimedia and bursty traffic are present.
참고문헌
- Gao Huang, Meng Ye and Long Cheng, "Modeling system performance in MMORPG," in Proc. of Global Telecommunications Conference Workshops, GlobeCom Workshops 2004. IEEE, pp. 512-518, 29 Nov.-3 Dec. 2004.
- S. Fleck and W. Strasser, "Smart Camera Based Monitoring System and Its Application to Assisted Living," Proceedings of the IEEE , vol. 96, no. 10, pp. 1698-1714, Oct. 2008. https://doi.org/10.1109/JPROC.2008.928765
- Ahmad Vakili and Jean-Charles Gregorie, "QoE Management for Video Conferencing Applications," Computer Networks, vol. 57, no. 7, pp. 1726-1738, 2013. https://doi.org/10.1016/j.comnet.2013.03.002
- Arun Vishwanath, Vijay Sivaraman and Marina Thottan, "Perspectives on router buffer sizing: recent results and open problems," SIGCOMM Comput. Commun. vol. 39, no. 2, pp. 34-39, March 2009. https://doi.org/10.1145/1517480.1517487
- A. Vishwanath, V. Sivaraman and G.N. Rouskas, "Considerations for Sizing Buffers in Optical Packet Switched Networks," INFOCOM 2009, IEEE, pp. 1323-1331, 19-25, April 2009.
- Curtis Villamizar and Cheng Song, "High performance TCP in ANSNET," SIGCOMM Comput. Commun, vol. 24, no. 5, pp. 45-60, October 1994.
- Guido Appenzeller, Isaac Keslassy, and Nick McKeown, "Sizing router buffers," In Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications (SIGCOMM '04), vol. 34, no. 4, August 2004.
- Neda Beheshti, Yashar Ganjali, Monia Ghobadi, Nick McKeown, and Geoff Salmon, "Experimental study of router buffer sizing," in Proc. of Proceedings of the 8th ACM SIGCOMM conference on Internet measurement (IMC '08), pp. 197-210, New York, NY, USA, 2008.
- Mihaela Enachescu, Yashar Ganjali, Ashish Goel, Nick McKeown, and Tim Roughgarden, "Part III: routers with very small buffers," SIGCOMM Comput. Commun., vol. 35, no. 3, pp. 83-90, July 2005.
- A. Vishwanath and V. Sivaraman, "Routers With Very Small Buffers: Anomalous Loss Performance for Mixed Real-Time and TCP Traffic," in Proc. of Quality of Service, 2008, IWQoS 2008, 16th International Workshop on , pp.80,89, 2-4 June 2008.
- Joel Sommers, Paul Barford, Albert Greenberg and Walter Willinger, "An SLA perspective on the router buffer sizing problem," SIGMETRICS Perform. Eval., vol. 35, no. 4, pp. 40-51, March 2008. https://doi.org/10.1145/1364644.1364645
- Jose Saldana, Julian Fernandez-Navajas, Jose Ruiz-Mas, Jenifer Murillo, Eduardo Viruete Navarro and Jose I. Aznar, "Evaluating the influence of multiplexing schemes and buffer implementation on perceived VoIP conversation quality," Computer Networks, vol. 56, no. 7, pp. 1893-1919, May 2012. https://doi.org/10.1016/j.comnet.2012.02.004
- Jan A. Bergstra and C.A. Middelburg, "G. 107: The E-Model, a computational model for use in transmission planning," ITU-T Recommendation, 2003.
- R. G. Cole and J. H. Rosenbluth, "Voice over IP performance monitoring," SIGCOMM Comput. Commun, vol. 31, no. 2, pp. 9-24, April 2001. https://doi.org/10.1145/505666.505669
- A. F. Wattimena, R. E. Kooij, J. M. van Vugt, and O. K. Ahmed, "Predicting the perceived quality of a first person shooter: the Quake IV G-model," in Proc. of Proceedings of 5th ACM SIGCOMM workshop on Network and system support for games (NetGames '06), New York, NY, USA 2006.
- J. Saldana, J. Fernandez-Navajas, J. Ruiz-Mas, E. Viruete Navarro, L. Casadesus, "Influence of online games traffic multiplexing and router buffer on subjective quality," in Proc. of Consumer Communications and Networking Conference (CCNC), 2012 IEEE, pp.462,466, 14-17 Jan. 2012.
- Siyu Tang, Yue Lu, Javier Martin Hernandez, Fernando A. Kuipers and Piet Van Mieghem, "Topology Dynamics in a P2PTV Network," Lecture Notes in Computer Science, vol. 5550, pp. 326-337, 2009.
- Wu-chang Feng, Francis Chang, Wu-chi Feng and Jonathan Walpole, "Provisioning on-line games: a traffic analysis of a busy counter-strike server," in Proc. of Proceedings of the 2nd ACM SIGCOMM Workshop on Internet measurment (IMW '02), pp. 151-156, New York, NY, USA, 2002.
- B. Fallica, Lu Yue, F. Kuipers, R. Kooij, P. Van Mieghem, "On the Quality of Experience of SopCast," in Proc. of Next Generation Mobile Applications, Services and Technologies, 2008, NGMAST '08, The Second International Conference on, pp. 501-506, 16-19 Sept. 2008.
- L. Sequeira, J. Fernandez-Navajas, J. Saldana, L. Casadesus, "Empirically characterizing the buffer behaviour of real devices," in Proc. of Performance Evaluation of Computer and Telecommunication Systems (SPECTS), 2012 International Symposium on, pp.1,6, 8-11 July 2012.
- Hao Jiang and Constantinos Dovrolis. "Why is the internet traffic bursty in short time scales?," in Proc. of Proceedings of the 2005 ACM SIGMETRICS international conference on Measurement and modeling of computer systems (SIGMETRICS '05), pp. 241-252, New York, NY, USA, 2005.
- L. Zabala, A. Ferro, A. Pineda, "Modelling packet capturing in a traffic monitoring system based on Linux," in Proc. of Performance Evaluation of Computer and Telecommunication Systems (SPECTS), 2012 International Symposium on , pp.1-6, 8-11 July 2012.