Background: In the recent years, the focus of research has shifted to Quality of Experience(QoE) to maintain the user satisfaction levels and fulfill their expectations of the serviceoffered. Numerous work has been established in finding the relationship between the networklayer and QoE. But, it is fact that the transport layer is much closer to the end-user than thenetwork layer in the TCP/IP communication protocol suite. Thus, any changes in the degreeof satisfaction or degree of annoyance are directly reflected onto transport layer than on thenetwork layer. So, it becomes more significant to study the behavior of user satisfaction inrelation to transport layer than the network layer. Objectives: This research is to relate the behavior of TCP to QoE. The main considerations tobridge the gap between them are: (a) Analyzing the effects of using different versions of TCPon server and client side, (b) Monitoring and analyzing the intensity of TCP traffic in thereverse direction and (c) Investigating TCP control flags from client to server. Methods: QoE related parameters used in this research are: (a) Quality of video i.e., MOS, (b)Degree of disturbance caused by initial delay, (c) Degree of disturbance caused by jerkinessand (d) Degree of disturbance caused by freezes. Effects of network impairments like delay,jitter and packet loss are considered in this research. NetEm is used as the traffic emulationsoftware to shape the traffic. The packet capture analysis of traffic exchange is implementedusing tcpdump. Results and Conclusions: The aim of this research is to provide a passive-estimation methodto assess the user perceived performance. The results of this research provide valuablecontribution to service providers/operators to note the early warning signals from TCP reversetraffic to evaluate the decrease of user satisfaction level and try to cope or/and recover fromimpairments in the network. This research also provides a scope for future researchers toinvestigate other protocols both in transport and application layers.

No description available.

International Telemetering Conference Proceedings / October 20-23, 2003 / Riviera Hotel and Convention Center, Las Vegas, Nevada / The Western Aeronautical Test Range (WATR) operates the ground stations for research vehicles operating at the NASA Dryden Flight Research Center (DFRC). Recently, the WATR implemented a new system for distributing Time, Space, and Position Information (TSPI) data. The previous system for processing this data was built on archaic hardware that is no longer supported, running legacy software with no upgrade path. The purpose of the Radar Information Processing System (RIPS) is to provide the ability to acquire TSPI data from a variety of sources and process the data for subsequent distribution to other destinations located at the various DFRC facilities. RIPS is built of commercial, off the shelf (COTS) hardware installed in Personal Computers (PC). Data is transported between these computers on a Gigabit Ethernet network. The software was developed using C++ with a modular, object-oriented design approach.

ITC/USA 2011 Conference Proceedings / The Forty-Seventh Annual International Telemetering Conference and Technical Exhibition / October 24-27, 2011 / Bally's Las Vegas, Las Vegas, Nevada / On the surface, network-based telemetry systems would appear to be simple, stateless, information collecting entities. Unfortunately, the reality of networking technologies brings a hierarchy of control loops into the system setup. At the top level, the command and status collection data loop that users manipulate the system with is a feedback loop. The commands themselves are transmitted across the network through competing streams of data, which are guided and controlled by Transmission Control Protocol (TCP) mechanisms. TCP mechanisms themselves have control loops in order to avoid congestion, provide reliability, and generally optimize flow. These TCP streams flowing across a network fabric compete at choke points, such as network switches, routers, and wireless telemetry links - all of which are also guided by control loops. This paper discusses the hierarchy of control loops present in a TmNS, provides an analysis of how these loops interact, and describes key points to be considered for telemetry systems.

TCP is a widely used protocol for web traffic. However, TCP€™s connection setup and congestion response can impact web page load times, leading to higher page load times for users. In order to address this issue, Google came out with QUIC (Quick UDP Internet Connections), a UDP-based protocol that runs in the application layer. While already deployed, QUIC is not well-studied, particularly QUIC€™s congestion response as compared to TCP€™s congestion response which is critical for stability of the Internet and flow fairness. To study QUIC€™s congestion response we conduct three sets of experiments on a wired testbed. One set of our experiments focused on QUIC and TCP throughput under added delay, another set compared QUIC and TCP throughput under added packet loss, and the third set had QUIC and TCP flows share a bottleneck link to study the fairness between TCP and QUIC flows. Our results show that with random packet loss QUIC delivers higher throughput compared to TCP. However, when sharing the same link, QUIC can be unfair to TCP. With an increase in the number of competing TCP flows, a QUIC flow takes a greater share of the available link capacity compared to TCP flows.

Yuen Ka-nang. / Thesis (M.Phil.)--Chinese University of Hong Kong, 2001. / Includes bibliographical references (leaves 133-135). / Abstracts in English and Chinese. / Abstract --- p.i / Acknowledgement --- p.iii / Chapter 1. --- INTRODUCTION --- p.1 / Chapter 1.1. --- Background --- p.1 / Chapter 1.2. --- Objectives --- p.1 / Chapter 1.3. --- Overview of Thesis --- p.2 / Chapter 2. --- NETWORK ASPECT OF THE VOIP TECHNOLOGY --- p.3 / Chapter 2.1. --- VoIP Overview --- p.3 / Chapter 2.2. --- Elements in VoIP --- p.3 / Chapter 2.2.1. --- Call Setup --- p.3 / Chapter 2.2.2. --- Media Capture/Playback --- p.4 / Chapter 2.2.3. --- Media Encoding/Decoding --- p.4 / Chapter 2.2.4. --- Media Transportation --- p.5 / Chapter 2.3. --- Performance Factors Affecting VoIP --- p.6 / Chapter 2.3.1. --- Network Bandwidth --- p.6 / Chapter 2.3.2. --- Latency --- p.6 / Chapter 2.3.3. --- Packet Loss --- p.7 / Chapter 2.3.4. --- Voice Quality --- p.7 / Chapter 2.3.5. --- Quality of Service (QoS) --- p.7 / Chapter 2.4. --- Different Requirements of Intranet VoIP and Internet VoIP --- p.8 / Chapter 2.4.1. --- Packet Loss/Delay/Jitter --- p.8 / Chapter 2.4.2. --- Interoperability --- p.9 / Chapter 2.4.3. --- Available Bandwidth --- p.9 / Chapter 2.4.4. --- Security Requirement --- p.10 / Chapter 2.5. --- Some Feasibility Investigations --- p.10 / Chapter 2.5.1. --- Bandwidth Calculation --- p.10 / Chapter 2.5.2. --- Simulation --- p.12 / Chapter 2.5.3. --- Conclusion --- p.17 / Chapter 2.5.4. --- Simulation Restrictions --- p.17 / Chapter 3. --- SOFTWARE ASPECT OF THE VOIP TECHNOLOGY --- p.19 / Chapter 3.1. --- VoIP Client in JMF --- p.19 / Chapter 3.1.1. --- Architecture --- p.20 / Chapter 3.1.2. --- Incoming Voice Stream Handling --- p.23 / Chapter 3.1.3. --- Outgoing Voice Stream Handling --- p.23 / Chapter 3.1.4. --- Relation between Incoming/Outgoing Voice Stream Handling --- p.23 / Chapter 3.1.5. --- Areas for Further Improvement --- p.25 / Chapter 3.2. --- Capture/Playback Enhanced VoIP Client --- p.26 / Chapter 3.2.1. --- Architecture --- p.27 / Chapter 3.2.2. --- Native Voice Playback Mechanism --- p.29 / Chapter 3.2.3. --- Native Voice Capturing Mechanism --- p.31 / Chapter 3.3. --- Win32 C++ VoIP Client --- p.31 / Chapter 3.3.1. --- Objectives --- p.32 / Chapter 3.3.2. --- Architecture --- p.33 / Chapter 3.3.3. --- Problems and Solutions in Implementation --- p.37 / Chapter 3.4. --- Win32 DirectSound C++ VoIP Client --- p.38 / Chapter 3.4.1. --- Architecture --- p.39 / Chapter 3.4.2. --- DirectSound Voice Playback Mechanism --- p.40 / Chapter 3.4.3. --- DirectSound Voice Capturing Mechanism --- p.44 / Chapter 3.5. --- Testing VoIP Clients --- p.45 / Chapter 3.5.1. --- Setup of Experiment --- p.45 / Chapter 3.5.2. --- Experiment Results --- p.47 / Chapter 3.5.3. --- Experiment Conclusion --- p.48 / Chapter 3.6. --- Real-time Voice Stream Mixing Server --- p.48 / Chapter 3.6.1. --- Structure Overview --- p.48 / Chapter 3.6.2. --- Experiment --- p.53 / Chapter 3.6.3. --- Conclusion --- p.54 / Chapter 4. --- EXPERIMENTAL STUDIES --- p.55 / Chapter 4.1. --- Pure IP-side VoIP-based Call Center ´ؤ VoIP in Education --- p.55 / Chapter 4.1.1. --- Architecture --- p.55 / Chapter 4.1.2. --- Client Structure --- p.56 / Chapter 4.1.3. --- Client Applet User Interface --- p.58 / Chapter 4.1.4. --- Observations --- p.63 / Chapter 4.2. --- A Simple PBX Experiment --- p.63 / Chapter 4.2.1. --- Structural Overview --- p.63 / Chapter 4.2.2. --- PSTN Gateway Server Program --- p.64 / Chapter 4.2.3. --- Problems and Solutions in Implementation --- p.66 / Chapter 4.2.4. --- Experiment 1 --- p.66 / Chapter 4.2.5. --- Experiment 2 --- p.68 / Chapter 5. --- A COMPREHENSIVE VOIP PROJECT 一 GRADUATE SECOND PHONE (GSP) --- p.72 / Chapter 5.1. --- Overview --- p.72 / Chapter 5.1.1. --- Background --- p.72 / Chapter 5.1.2. --- Architecture --- p.76 / Chapter 5.1.3. --- Technologies Used --- p.78 / Chapter 5.1.4. --- Major Functions --- p.80 / Chapter 5.2. --- Client --- p.84 / Chapter 5.2.1. --- Structure Overview --- p.85 / Chapter 5.2.2. --- Connection Procedure --- p.89 / Chapter 5.2.3. --- User Interface --- p.91 / Chapter 5.2.4. --- Observations --- p.92 / Chapter 5.3. --- Gateway --- p.94 / Chapter 5.3.1. --- Structure Overview --- p.94 / Chapter 5.3.2. --- Connection Procedure --- p.97 / Chapter 5.3.3. --- Caller ID Simulator --- p.97 / Chapter 5.3.4. --- Observations --- p.98 / Chapter 5.4. --- Server --- p.101 / Chapter 5.4.1. --- Structure Overview --- p.101 / Chapter 5.5. --- Details of Major Functions --- p.103 / Chapter 5.5.1. --- Secure Local Voice Message Box --- p.104 / Chapter 5.5.2. --- Call Distribution --- p.106 / Chapter 5.5.3. --- Call Forward --- p.112 / Chapter 5.5.4. --- Call Transfer --- p.115 / Chapter 5.6. --- Experiments --- p.116 / Chapter 5.6.1. --- Secure Local Voice Message Box --- p.117 / Chapter 5.6.2. --- Call Distribution --- p.118 / Chapter 5.6.3. --- Call Forward --- p.121 / Chapter 5.6.4. --- Call Transfer --- p.122 / Chapter 5.6.5. --- Dial Out --- p.124 / Chapter 5.7. --- Observations --- p.125 / Chapter 5.8. --- Outlook --- p.126 / Chapter 5.9. --- Alternatives --- p.127 / Chapter 5.9.1. --- Netmeeting --- p.127 / Chapter 5.9.2. --- OpenH323 --- p.128 / Chapter 6. --- CONCLUSIONS --- p.129 / Bibliography --- p.133

Tese de mestr.. Engenharia Electrotécnica e de Computadores. Faculdade de Engenharia. Universidade do Porto. 1998

Tese de doutoramento. Engenharia Electrotécnica e de Computadores. Faculdade de Engenharia. Universidade do Porto. 2008

Magíster en Ingeniería de Redes de Comunicaciones / Transmission Control Protocol (TCP) es un protocolo de transporte cuyo rendimiento depende del algoritmo de control de congestión empleado, el cual modifica el comportamiento de la ventana de congestión, la cual es la cantidad de paquetes que es posible enviar antes de ser reconocidos. Al emplear TCP tradicional, al comenzar una transmisión, la ventana de congestión enviada tiene un crecimiento determinado por un slow-start (inicio lento), y continúa con una fase de evitación de congestión que emplea un algoritmo AIMD: incremento aditivo de 1 paquete por cada ventana reconocida y un decremento multiplicativo medio que reduce la ventana enviada a la mitad de su valor cuando se produce una congestión. Cuando una congestión es producida por timeout (tiempo de espera agotado), la ventana de congestión es reducida a 1, y luego se realiza un slow-start y continúa con la etapa evitación de la congestión. General Additive Increase-Multiplicative Decrease (GAIMD) es una variante de TCP, que modifica el comportamiento del incremento aditivo en un valor de α paquetes por cada ventana enviada reconocida y un decremento β que mutliplica el valor de la ventana enviada, cuando se produce una congestión. GAIMD es amistoso cuando se establecen los valores de α=0.31 y β=0.875, y desprecia timeouts producidos para el cálculo de su rendimiento, el cuál teóricamente es mayor que el rendimiento en TCP tradicional. Ethernet Services Transport Protocol (ESTP) es un protocolo de transporte diseñado para transmisiones sobre redes Ethernet que modifica sólo el decremento multiplicativo (β) de TCP tradicional, sin embargo β tiene un valor variable, el cual se comporta de acuerdo a la cantidad de paquetes transmitidos entre dos pérdidas (δ). Para el cálculo de β, ESTP emplea una función con un componente exponencial cuya variable principal es δ. Para la evaluación del rendimiento de ESTP y las otras variantes de TCP que emplean un algoritmo AIMD se requiere que cada protocolo sea implementado en el código fuente del sistema operativo y el empleo de herramientas de generación de tráfico como iPerf, herramientas de captura de información de la transmisión como lo son tshark y tcpprobe, utilidades para establecer reglas en el tráfico como netem e iptables, y de software que interprete la información capturada y grafique el comportamiento de la ventana de congestión y rendimiento de la transmisión. Haciendo uso de las herramientas y software mencionados, se diseña y construye un banco de pruebas que permita evaluar el rendimiento de los protocolos de transporte, con el objetivo de contrastar y mejorar el comportamiento de los mismos.

The Internet has become one of the most widely used forms of communication available. Many applications used on the Internet require the user to interact constantly with the network. For example web browsing where the user will expect the browser to respond quickly, to finish loading pages quickly and to do all of this at an equal level for all users. The network's performance is dependant on the protocols it uses and how the resources of the network are distributed. This is why TCP (Transmission Control Protocol) is one of the most important protocols, because it controls the amount of data entering the network and provides reliability to most interactive applications. The thesis starts by introducing a basic TCP model which is later extended to model the effects of burstiness produced by TCP. Burstiness can cause a routers buffer to unnecessarily overflow. These overflows cause TCP connections to under-utilise link bandwidth because of unnecessary packet retransmissions. A model to define a quantitative measure of both burstiness and throughput of a system of TCP connections is introduced. The model gives insight into how the TCP protocol causes burstiness and can be used to find scenarios where burstiness is decreased. This helps to improve the utilization of links by reducing the burstiness of protocols. An important performance metric for interactive traffic is user perceived delay, the delay that an end user would encounter when using an application. An example of user perceived delay is the time a user waits before a HTML web page starts loading. The retransmission delays are the most important type of delay for interactive traffic because they are usually very large. A dynamic priority RED Queue (DPRQ) is introduced which changes the priority of the queues based on the goodput (throughput of succesfully transmitted packets) threshold of the interactive traffic. Using dynamic priority allows packet loss to be reduced by up to eight times for interactive traffic, which intern reduces retransmission delay. Fairness measures how equally network resources are allocated amongst different connections. When a link with TCP connections is overloaded each connection on the link will reduce its throughput to allow all the connections to have approximately equal load. This does not take into account that other links may be under utilized. The fairness issue is addressed by introducing Multipath TCP (MATCP) which allows path selection to occur at the TCP layer. This allows each unique flow to take a different path, instead of all the flows of one source using the same path. Using MATCP, a finer grain of load-balancing can be achieved and the complexity and state required in the network is greatly reduced. Two analytic models are provided in chapters three and four, which investigate slow start and TCP burstiness. In chapter five the DPRQ queue is introduced to reduce user perceived delay. An analytic model of the DPRQ is provided and verified through experimental simulation. In chapter six an analytic model of Multipath TCP is provided, which is also verified by simulation.