ISSN 0798 1015

Vol. 39 (Number 39) Year 2018 • Page 9

Evaluate the performance of voice codecs for IPv6 over an IPv6to4 tunnel mechanism

Evaluar el rendimiento de los códecs de voz para IPv6 a través de un mecanismo de túnel IPv6to4

Jorge E. HERRERA Rubio 1; Carmen TRUJILLO Leal 2

Received: 04/04/2018 • Approved: 19/06/2018

Content

1. Introduction

2. Methodology

3. Results

4. Conclusions

Bibliographic references

1. Introduction

The trend of next-generation networks will be supported in the IPv6 protocol for its advantages such as: security, quality of service, mobility, encryption, autoconfiguration and performance, this will be possible with the use of transition mechanisms over the IPv4 protocol while native applications for IPv6 are being developed, some transition mechanisms can generate overload problems in the IP datagrams by the fragmentation process.

Due to the versatility of IPv6 in the handling of headers of size of 40 bytes it is possible to improve the speed in the routing and the switching of the packages (Mercado, Taffernaberry, & Piccolella, 2010)  which makes it much more efficient than IPv4 . Situation that can be studied with applications supported in Internet Protocol (IP), as it is the case of: Voice over Internet Protocol (VoIP), Internet Protocol Television (IPTV), mobile Internet, videoconference and online games (Ángel & Domínguez, 2014).

It is important to evaluate the performance of the IPv6 stack and compare it with the IPv4 stack in order to quantify the User Datagram Protocol (UDP) IPv6 performance, remembering that in IPv6 fragmentation is maintained in the network layer. Therefore, fragmentation is done by the sender before sending UDP packets. That is, intermediate devices such as routers cannot fragment a packet in IPv6, because they generate delays in switching and routing due to the excessive use of clock cycles of the processors of the equipment (Burjiz K. Soorty, 2014), to understand the process of coexistence between the IPv4 and IPv6 protocols, are used the transition mechanism 6to4 on dual stack by means of a tunnel that forward the IPv6 packet  over the IPv4 network (Sathu & Shah, 2012), this mechanism was designed to encapsulate datagrams in the IPv4 header.

The traffic generation tools allow to evaluate the performance of the test network with more real experiments, which for the case study is used the Distributed Internet Traffic Generator (D-ITG) (Srivastava et al., 2014), this platform generates: patterns defined by Inter Interference Time (IDT) between packets, packets size probability distributions (PS), Round Trip Time (RTT), packet loss, jitter and performance (Mosavi, Farabi, & Karami, 2015). The traffic is generated by an ITGSend order in the transmitter and in the receiver the packets are received by an ITGRecv order through a log file where the information is stored.

The document was divided into sections: in section two some related works and state of the art are detailed, section three presents the experimental configuration, section four explains the methodology, section five is the interpretation of the results and  the last one corresponds to the conclusions.

1.1. Background of the investigation

Previous research papers show the differences in the performance of the IPv4 and IPv6 protocols, as in the case of (Shiwani, Purohit, & Hemrajani, 2011), who carried out tests about the size of the packets, bandwidth, segment size, size of the buffer and size of the Maximum Transfer Unit (MTU) in packet routing and commutation.

RFC3142 (Hagino J., Yamamoto, 2001) of the Internet Society's network working group describes an IPv6 retransmission translator (TRT) to IPv4, which allows hosts only exchange IPv6 traffic (TCP,  UDP) with IPv4 hosts, in order to optimize resources within the same network and allow migration from IPv4 to IPv6. In the same way, (Shiwani et al., 2011) consider the effect of network performance analysis for networks based on IPv4 and IPv6 and empirically evaluate measurements related to performance, delay and instability .

Another case of the evaluation of UDP-IPv6 is the study of modern operating systems  (Burjiz K. Soorty, 2014) to determine the parameters of quality of service (QoS) through IPv6 networks. However, due to the increased overload in IPv6 and its interaction with the operating system hosting this communication protocol can generate network performance problems, in this case (Davies, 2012), worked on a dual stack demonstrated that the performance decreases with respect to the average size of the global package and the MTU, considering that the amount of traffic carried and the processing capacity of the routers and computers active hardware in the network are affected.

Through the use of network traffic generators (Iperf, Netperf, D-ITG and IP Traffic) is possible to emulate traffic and VoIP in test environments that guarantee reliable experiments, it is confirmed (Kolahi, Narayan, Nguyen, & Sunarto, 2011) and (Barayuga & Yu, 2015), where the sizes of the payload and datagrams are varied to monitor the performance of the network. In the same way (Mosavi et al., 2015)  proposes a method to determine the optimal input variables by applying genetic algorithms to check the effectiveness of the traffic generator D-ITG (Botta, Donato, Dainotti, Avallone, & Pescap, 2013)  and the time cost of the variables that affect the performance of IPv4 and IPv6 networks. Also (AAvallone, S., Esposito, M., Pescapé, A., Romano, S., & Ventre, 2002) use the Mtools tool to analyze the performance of the network through the measurement of the unidirectional delay and the round trip time of the packets that traverse the network (Fitzpatrick, Murphy, Atiquzzaman, & Murphy, 2009).

The authors (Suarez, Salcedo, Carmona, Ramirez, & Serna, 2016) show the results of laboratory experiments to determine the effects on Jitter over VoIP when the IPv6 tunnel is used in IPv4. In addition, (Kolahi, Soorty, Chand, & Qu, 2010) compare the performance of an IPv4 network and IPv6 in a peer-to-peer connection with client server architecture showed the differences in bandwidth, in a similar way (Barayuga & Yu, 2015) propose in the Philippines that IPv6 and NAT64 networks offered better performance against the NAT44 network in almost all metrics in the UDP mode test, as well (Zhou, X., Jacobsson, M., Uijterwaal, H., and Mieghem, 2010) perform the comparison of delay and loss performance over time between IPv6 and IPv4 and verify that the main reason for the worst performance comes from IPv6 over IPv4 tunnels instead of native IPv6 paths.

In the study of the most efficient codecs for the transport of VoIP in IPv6 networks is taken as reference the study of (Sathu & Shah, 2012)  who experiment with different networks using the IPv6to4 tunneling mechanism analyzing the parameters of delay, instability and performance (Singh, Singh, Singh, & Khan, 2014). Also, recommendations such as  (ITU-T G.711, 2000) allows to analyze the situation of the use of Voice Activity Detection / Discontinuous Transmission / Comfort Noise Generation (VAD / DTX / CNG) that can significantly reduce the speed of transmission of packets.

The recommendations (G.723.1, 2006) and (G.729, 2012) are also considered as the bases of the study of the structures of operation, understanding and coding of voice signals. On the other hand,  (Frederick, 2003) studies the real-time transport protocol (RTP) to diagnose the functions of the end-to-end network transport protocol for applications that transmit data in real time, such as: audio, video or data.

1.2. Experimental configuration

The configuration is based on three routers with hardware characteristics CRS125-24G-1S-IN, RB2011UiAS-IN and RB2011HinD with operating system RouterOS (see Fig.1), a point-to-point connection is established, at one end the server generates the traffic of voice and at the other end the client performs the capture and processing through the double stack mechanism with the 6to4 tunnel technique for the IPv6 connection, over a LAN -WAN- LAN network.

Fig. 1
Test scenario

The implementation with static addressing for IPv6 on the 6to4 tunnel begins, the captures are obtained from the generation and variation of the size of the datagrams for VoIP traffic, both for IPv4 and IPv6 for each of the codecs G.711.1, G.711.2 , G.723.1, G.729.2 and G.729.3 used in the processing of voice calls with a duration of one minute.

The metrics to be considered with UDP are: average delay, average delay variation (jitter), delay deviation, average bandwidth and average packet speed (Barayuga & Yu, 2015). The tests are executed using 100 Mbps point-to-point links with routing jumps on three routers as shown in Fig. 1. The UDP protocol allows for agile sending of datagrams without the need for verification and checking, making it much faster and efficient (Kolahi et al., 2010).

The generation of voice traffic is emulated by means of software D-ITG (Distributed Internet Traffic Generator) platform able to accurately replicate the work load of current Internet applications (Botta et al., 2013), which is a Metrics tool for the analysis of: delays, jitter, packet loss and datagrams, it applies statistical random models for the size of the packet (PS) and the time of departure time (IDT) (Mosavi et al., 2015), allowing to significantly emulate the behavior of the respective voice codecs used in the investigation.

To perform the study of the Dual Stack transition mechanism, the MTU control of the static tunnel with a value between 1280 and 1480 bytes is executed (Gilligan, 2005), by the following procedure:

2.1. Configuration of active equipment

The operating system of each of the equipment is configured with the IPv6 protocol, the hardware and the tunnel services in the physical interfaces. Then, physical connectivity tests and the corresponding routing are executed from the server machine with the client. After the 6to4 tunnel is configured in each one of the routers that allow inter-operation in the different network segments in the following way: a) create the exit tunnel interface, b) create the default route for the LAN interface and WAN, c) associate the client of the tunnel interface and d) add the IPv6 address of the computer interface in the LAN.

2.2. Software installation and parameters

The process of installing the D-ITG consists of decompressing the program, compiling and debugging in C ++ language of the libraries that enable the IPv6 protocol to be recognized by the operating system on both the server and the client, this generator of traffic is classified as maximum performance (Rodriguez, 2015), because it allows testing end-to-end network updates with voice traffic generated in real time to check quality of service (QoS) parameters.

The default values ​​used in D-ITG are: the payload size is 512 bytes, the protocol is UDP, the default packet rate is 1000 packets per second, the one-way time delay (RTT) parameter is unidirectional (Kolahi et al., 2011), however the necessary changes were made to characterize the type of traffic desired according to: the amount of generated packages (for example:> Itgsend -a 2002: a02: 14 :: 102: 14 -rp 9030 -m RTTM -z 10000 -t 60000 -T UDP -l 729_3.log -x ipv6a.log VoIP -x G.729.3 -VAD and the size of the datagram (for example:> Itgsend -a 2002: a02: 14 :: 102: 14 -rp 9030 -m RTTM -c 128 -t 60000 -T UDP -l 729_3.log -x ipv6a.log VoIP -x G.729.3 -VAD.

2.3. Traffic generation

The D-ITG automatically places the server in listening mode through a free port or a particular port is configured to ensure the establishment of the link. The VoIP call traffic processing and the corresponding send response to the server are performed on the client computer, using the command:> Itgrecv.

The capture process is performed with the generation of test calls lasting 60 seconds, first by varying the amount of datagrams to be generated from the server for five codecs in particular with the IPv6 protocol and then varying the size of each datagram with IPv6, after, the previous process is repeated in a similar way using the IPv4 protocol. The data obtained from the server is the result of the use of the "Itgsend" command that generates VoIP traffic in a bidirectional way on each of the codecs undergoing testing, the capture is register in a plain text log file for the corresponding analysis.

2.4. Data capture and processing

The evaluation methodology consists in generating datagram traffic for different sizes for each of the voice codecs as mentioned above, the codec G.723.1 is taken as an example, as shown in table 1.

Table 1
Variation of the number of ipv4/ipv6 packets using the G.723 codec.

Table 1 details the number of initial packets that are generated in the server and the different parameters that will be analyzed according to the codec speed that allows to balance the average speed in the link as well as the average of received packets that are transported by the standard protocol in real time (RTP) in the sending of VoIP and this in turn assembles the information about UDP that will finally be encapsulated in a packet over the Internet protocol (IP) (Frederick, 2003).

In the case of the variation in the size of the package as seen in table II, the significant variation is determined by the parameters of: delay, jitter, standard deviation, queuing times of the calls and the processing capacity of the equipment actives that affect the route of datagrams in the network. This is because the applications that work with UDP generate datagrams smaller than the MTU of the transmission medium, in order to guarantee the availability of the voice and avoid fragmentation when it passes through the router  (Torres, Cuevas, & Jaramillo, 2006) .

Table 2
Variation of the datagram size for ipv4/ipv6 using the g.723 codec.

For the situation of the variation of the size of the packet in IPv6 (table II) there are no significant changes in the total number of bytes received, packet average and total packets, speed and bandwidth compared to IPv4, but it is quite representative reduction of delay times, jitter and standard deviation as the package size increases.

The above is the result of the ease of the dual stack transition mechanism for IPv6 encapsulation to be supported over IPv4; that although there is an overload introduced by the IP, UDP and RTP headers, the bandwidth of each codec is affected and degradation occurs in the voice packets, IPv6 considerably reduces delay times and latencies.

By analyzing the coding techniques of each of the codecs, the behavior of the parameters can be described according to each protocol, as described below. As regards the generation of packets, the standard deviation (see Fig. 2a) in the codec with the IPv4 protocol do not exceed the millisecond; however, with the codec G.711.1 there was a momentary excessive variation between 15 and 25 milliseconds which affects a jitter over 2.5 milliseconds (see Fig. 2b) while in the other codecs are below 2 milliseconds, in the case of average delay(see Fig. 2c)  the G.711.1 codec has many fluctuations; while the G.723.1 codec is the best option to perform a VoIP implementation because it has a very low average jitter.

Fig. 2
Performance of the codecs according to the average delay, average jitter and
standard deviation for IPv4 in the generation of packets

An important feature in the emulation of IPv6 traffic over IPv4 is the optimization that is made by using the algorithm that uses voice activity detection (VAD) and comfort noise generation (CNG) to reduce the use of bandwidth during the periods of silence and delays in communication (ITU-T G.711, 2000), if  Fig. 3a is observed, the statistical standard deviation in IPv6 times are smaller, ranging between 0.3 and 1.5 milliseconds, while in IPv4 they are in the order of 1 and 25 milliseconds, for IPv6 the average delays (see Fig. 3c)  are much smaller than IPv4 compared with fig. 2c in a time window between 2.4 and 3.4 milliseconds for IPv6 and in IPv4 between 3 and 6 , 5 milliseconds; mean jitter oscillates between 0.3 and 1 milliseconds for IPv6 and in IPv4 between 0.5 and 4 milliseconds (see Fig. 2b), this indicates that the 6to4 tunnel guarantees a substantial improvement in the parameters of a voice communication.

Fig. 3
Codec performance according to the average delay, average jitter
and standard deviation for IPv6 in the generation of packets.

By increasing the size of the datagrams (see Fig. 4) from 128 to 1280 bytes, it can be seen that the delay times in IPv6 as a whole of the five codec are below 4.5 milliseconds and the codec that has the lowest delay is the G.729.2; in IPv4 the times are over 4 milliseconds and the G.729.2 codec also produces less delay, this leads to packet loss, because the MTU increases its size and the delay times are not kept constant. In practice, (Zhou, X., Jacobsson, M., Uijterwaal, H., and Mieghem, 2010) the increase of the buffer is not recommended because there are limits where it combines the bandwidth, the size of the MTU and codec speed affect the optimal amount of voice packets to be received at the destination.

Fig. 4. Average delay and average jitter per packet size for IP4 and IPv6

It is also clear that the jitter is too high (fig.4) in voice links when using the IPv4 protocol and the G.711.1 codec is the worst performance, while in IPv6 the best performance codec can be the G. 723.2 with more constant times.

For the analysis of the bandwidth (table III), as a QoS parameter for VoIP, the D-ITG application considers the parameters in the same way for the IPv4 and IPv6 protocols, this varies according to the number of samples per packet (Botta et al., 2013) of the codec, the higher the coding speed the bandwidth improves and therefore he sent packets per second; in the same way, the number of bytes and datagrams is greater.

Table 3
COMPARISON OF BANDWIDTH ACCORDING TO THE CODING SPEED FOR IPV4 AND IPV6

From the previous one, it is inferred that the G.711.2 codec is simpler and has lower computation load which is the reflection in the delay in the coding process, the G.729.2 codec although it has a relatively low bandwidth in comparison with the previous one; the size of the packets is 50% and the bytes received are reduced by 19.5% when there are two samples per second for calls of 60 seconds and the delay of 120 times higher than the codec G.711.2.

In the case of the G.723.1 codec compared to the G.711.1 codec, although it optimizes bandwidth by 87.5%, the total received datagrams are significantly reduced by 74%. These estimates must guarantee audio and voice quality in IP calls because as VoIP traffic increases all QoS variables deteriorate.

According to the comparison of the two protocols, the results show that VoIP in IPv6 reduces the delay and jitter times and therefore optimizes the bandwidth in each of the codecs, a situation that does not happen with IPv4. It is also perceived that, a VoIP network is affected when the RTT parameter undergoes changes due to factors such as link latency, queue delays, network overload and bandwidth (Atary & Bremler-Barr, 2016) both in the transmitter and in the receiver.

The bandwidth (Bw) variations for the three codec types can be check, if: the total packet size (tps) is made up of the layer 2 headers with 6 bytes, the IP / UDP / RTP of 2 bytes and the load useful 20 bytes as there are 8 bits per byte and the speeds of such codec (sc) (as they are in table III) can be deduced according to equation (1) that:

         (1)

When the payload size (ps) is 20 bytes (160 bit) for codec G.723.1 and G.729.2 and 160 bytes for G.711.2; it is possible to predict the theoretical bandwidth as shown in table III; thus, the G.711.2 codec has an improvement of 30.93%, G.723.1 is 27.4% and G.729.2 is about 9.8% when estimating the number of samples of each codec in the communication, this means that the bandwidth can be efficiently optimized for this type of applications.

Examining in IPv6, very low delays predominate just as with jitter so the packet quantity is increased or the size of the datagram is changed (see table I and II), this is due to the fact that in IPv6 there is a lower limit in the MTU of 1280 bytes. That is, IPv6 does not fragment packets below this limit. To send IPv6 packets through a link with an MTU of less than 1280 bytes (IBM, 2017), the link layer must fragment and defragment the IPv6 packets with transparency, so that they can be processed over a tunnel over IPv4.

In the interpretation of the UDP metrics  is observed that the flow control and the registration of the transactions depend on the application that generates the datagrams and the processing in the transport layer, because UDP does not generate much overload on the operating system; hence, when increasing the size of the packets between 10000 bytes to 200000 bytes the total of packets sent, total bytes received and the average speed are kept constant for both IPv6 and IPv4 so that the differences are observed in the times of the delays, jitter and standard deviation.

When the size of the packets is varied from 128 bytes to 1280 bytes (including up to 2048 bytes), UDP generates datagrams smaller than the MTU of the transmission medium (Fast Ethernet) that avoids fragmentation and guarantees the availability of voice while preserving the average speed in each codec in particular, consequently the delay times and jitter are lower in the IPv6 protocol as the packets go through the network.

When analyzing the codecs together for the IPv6 protocol, the functionality represented by the G.729.2 codec in the generation of packets is determinant, because it has the lowest delay, a lower jitter and a low standard deviation of the delays with respect to the other codecs, as seen in Figure 3. In the analysis of the increase in the size of the packet the IPV6 codec that has the best response is G.729.3 with lower jitter when it is compared to the IPV4 protocol, and the response of the slower delay is also better with the G.729.2 codec as seen in figure 4, because the codec speed allows a better adjustment to the bandwidth to optimize the transmission medium, all the above is the result of the combination of bandwidth, MTU size and buffer size.

As the codec bandwidth increases, the total datagrams and packets increase, under these conditions the codec G.711.1 is the one with the lowest computational load, but the most important work of the codecs is based on the voice algorithms, which must have a high speed of compressing so that there is a good balance between quality, coding efficiency and stability in unfavorable conditions.

The process of transition to IPv6 through 6to4 tunnel has the advantage of working transparently so that IPv4 users do not perceive the encapsulation process through the double stack mechanism as a link layer model in the IP stack.

AAvallone, S., Esposito, M., Pescapé, A., Romano, S., & Ventre, G. (2002). Mtools : a one-way-delay and round-trip-time meter. ITEM - Laboratorio Nazionale CINI per l’Informatica E La Telematica Multimediali Via. Retrieved from https://www.cisco.com/c/es_mx/support/docs/voice/voice-quality/7934-bwidth-consume.html

Ángel, F. M., & Domínguez, J. F. C. (2014). Implementation of Ipv6 Services at the Autonomous University of Guerrero, México. Vínculos, 10(2), 393–400. Retrieved from http://revistas.udistrital.edu.co/ojs/index.php/vinculos/article/view/6563

Atary, A., & Bremler-Barr, A. (2016). Efficient Round-Trip Time monitoring in OpenFlow networks. Proceedings - IEEE INFOCOM, 2016–July. https://doi.org/10.1109/INFOCOM.2016.7524501

Barayuga, V. J. D., & Yu, W. E. S. (2015). Packet level TCP performance of NAT44, NAT64 and IPv6 using iperf in the context of IPv6 migration. 2015 5th International Conference on IT Convergence and Security, ICITCS 2015 - Proceedings, 4–9. https://doi.org/10.1109/ICITCS.2015.7293006

Botta, A., Donato, W. De, Dainotti, A., Avallone, S., & Pescap, A. (2013). D-ITG 2.8.1 Manual, 1–35.

Burjiz K. Soorty, N. I. S. (2014). UDP-IPv6 Performance in Peer-to-Peer Gigabit Ethernet using Modern Windows and Linux Systems. International Journal of Computer and Information Technology, 3(3), 496–502.

Davies, J. (2012). Understanding IPv6. (Pearson, Ed.) (Third Edit). United States of America: Copyright © 2012 by Microsoft Corporation,95-120.

Fitzpatrick, J., Murphy, S., Atiquzzaman, M., & Murphy, J. (2009). Using cross-layer metrics to improve the performance of end-to-end handover mechanisms. Computer Communications. https://doi.org/10.1016/j.comcom.2009.06.005

Frederick, R. (2003). RFC-Request for Comments: 3550. Network Working Group H. Schulzrinne,Columbia University, 1–104.

G.723.1, I.-T. (2006). UIT-T G.723.1 Equipos terminales digitales – Codificación de señales analógicas mediante métodos diferentes de la MIC.

G.729, I.-T. (2012). ITU-T G.729 Digital terminal equipments – Coding of voice and audio signals.

Gilligan, R. (2005). Basic Transition Mechanisms for IPv6 Hosts and Routers. Basic Transition Mechanisms for IPv6 Hosts and Routers, 1–27.

Hagino J., Yamamoto, K. (2001). An IPv6-to-IPv4 Transport Relay Translator Status. Copyright (C) The Internet Society (2001). All Rights Reserved, Network Working Group.

IBM. (2017). https://www.ibm.com/support/knowledgecenter/es/ssw_ibm_i_72/. Retrieved August 26, 2017, from https://www.youtube.com/watch?v=sG77U1xhBKk

ITU-T G.711. (2000). ITU-T G.711 use in packet-based multimedia communication systems.Appendix II: A comfort noise payload definition for. Appendix IITELECOMMUNICATION STANDARDIZATION SECTOR OF ITU.

Kolahi, S. S., Narayan, S., Nguyen, D. D. T., & Sunarto, Y. (2011). Performance monitoring of various network traffic generators. Proceedings - 2011 UKSim 13th International Conference on Modelling and Simulation, UKSim 2011, 501–506. https://doi.org/10.1109/UKSIM.2011.102

Kolahi, S. S., Soorty, B. K., Chand, N., & Qu, Z. (2010). Performance comparison of IPv4 and IPv6 in peer-peer and client server local area networks. 2010 10th IEEE International Conference on Computer and Information Technology (CIT 2010), 41–45.

Mercado, G., Taffernaberry, C., & Piccolella, A. D. (2010). Design and simulation of the implementation of IPv6 protocol transition technologies and procedures in INTRANETS using an IPv6 test bed. Universidad de Mendoza.

Mosavi, M. R., Farabi, F., & Karami, S. (2015). Optimal choice of random variables in D-ITG traffic generating tool using evolutionary algorithms. Iranian Journal of Electrical and Electronic Engineering, 11(2), 101–108.

Rodriguez, M. (2015). Evaluation of tools for traffic generation scenarios. Universidad Politecnica de Madrid. Retrieved from http://www.dit.upm.es/~posgrado/doc/TFM/TFMs2014-2015/TFM_Elena_Rodriguez_Mata_2015.pdf

Sathu, H., & Shah, M. A. (2012). Performance Monitoring of VoIP with Multiple Codecs Using IPv4 and IPv6to4 Tunnelling Mechanism on Windows and Linux, 2(3), 2–6.

Shiwani, S., Purohit, G., & Hemrajani, N. (2011). Performance Analysis of IPv4 v/s IPv6 in Virtual Environment using UBUNTU. And Networks CSI-COMNET-2011, Vol Comnet- …. Retrieved from https://scholar.google.com/scholar?hl=es&q=Performance+Analysis+of+IPv4+v%2Fs+IPv6+in+Virtual+Environment+Using+UBUNTU&btnG=&lr=

Singh, H. P., Singh, S., Singh, J., & Khan, S. A. (2014). VoIP: State of art for global connectivity - A critical review. Journal of Network and Computer Applications, 37(1), 365–379. https://doi.org/10.1016/j.jnca.2013.02.026

Srivastava, S., Anmulwar, S., Sapkal, A. M., Batra, T., Gupta, A. K., & Kumar, V. (2014). Comparative study of various traffic generator tools. 2014 Recent Advances in Engineering and Computational Sciences, RAECS 2014, 6–8. https://doi.org/10.1109/RAECS.2014.6799557

Suarez, J., Salcedo, M., Carmona, C., Ramirez, J., & Serna, G. (2016). Effects of IPv6-IPv4 tunnel in Jitter of Voice over IPv6, measured in laboratory and over the National Research and Education Network of Colombia “rENATA.” IEEE Latin America Transactions, 14(3), 1380–1386. https://doi.org/10.1109/TLA.2016.7459624

Torres, R., Cuevas, S., & Jaramillo, B. (2006). Comparación de la eficiencia en la transmisión de tráfico de videoconferencia de los protocolos IPv4 e IPv6. Boletín de La Red Iris, (78–79), 101–105. https://doi.org/1139-207X

Zhou, X., Jacobsson, M., Uijterwaal, H., and Mieghem, P. (2010). IPv6 delay and loss performance evolution. International Journal of Communication Systems, 23(5), 633–652. https://doi.org/10.1002/dac

1. Engineering Department, research group GIBUP and GITENT University of Pamplona, jherrera@unipamplona.edu.co , Pamplona-Colombia. Teacher Researcher School of Architecture and Engineering University of Pamplona, GIBUP/GITENT groups, REDCOMSIS seed research coordinator. I have been employed by Colombia Telecommunications (Telecom) for 17 years. Project engineer in telecommunications

2. Faculty of Occupational Health Administration University Uniminuto, ctrujillole@uniminuto.edu.co , Cúcuta- Colombia. Teaching Researcher. Studied PhD in progress Bicentenary University of Aragua (Venezuela).Participant in the macroproject of research in "Communication and education" of the Universidad Francisco de Paula Santander