Per Hurtig

Enhancing SCTP loss recovery: An experimental evaluation of early retransmit

To reduce cost and provide more flexible services, telecommunication operators are currently replacing traditional circuit-switched telephony networks with packet-switched IP networks. To support the stringent requirements of telephony signaling (SS7), the SIGTRAN working group of the IETF specified the transport protocol SCTP. SCTP was developed to overcome a number of problems that follow from using TCP for signaling transport. However, the design of SCTP was to a great extent still based on TCP, and some problems related to signaling transport were inherited. For example, the loss recovery mechanisms in SCTP are almost identical to those of TCP. This is a problem as signaling traffic has stringent requirements on timely message delivery. TCP was not designed to meet stringent requirements on timely message delivery, and therefore the loss recovery was not optimized for it. To optimize SCTPs loss recovery for signaling traffic, we consider the loss recovery enhancement early retransmit. To make early retransmit even better suited for signaling traffic we propose a packet-based version, which was also recently included in the early retransmit specification. By experimentally evaluating this algorithm, we show that the packet-based early retransmit algorithm, in some cases, can reduce SCTPs loss recovery time by 62%.

NEAT: A Platform- and Protocol-Independent Internet Transport API

The sockets API has become the standard way that applications access the transport services offered by the IP stack. This article presents NEAT, a user space library that can provide an alternate transport API. NEAT allows applications to request the service they need using a new design that is agnostic to the specific choice of transport protocol underneath. This not only allows applications to take advantage of common protocol machinery, but also eases introduction of new network mechanisms and transport protocols. The article describes the components of the NEAT library and illustrates the important benefits that can be gained from this new approach. NEAT is a software platform for developing advanced network applications that was designed in accordance with the standardization efforts on transport services in the IETF, but its features exceed the envisioned functionality of a TAPS system.

On the Cost of Using Happy Eyeballs for Transport Protocol Selection

Concerns have been raised in the past several years that introducing new transport protocols on the Internet has become increasingly difficult, not least because there is no agreed-upon way for a source end host to find out if a transport protocol is supported all the way to a destination peer. A solution to a similar problem---finding out support for IPv6---has been proposed and is currently being deployed: the Happy Eyeballs (HE) mechanism. HE has also been proposed as an efficient way for an application to select an appropriate transport protocol. Still, there are few, if any, performance evaluations of transport HE. This paper demonstrates that transport HE could indeed be a feasible solution to the transport support problem. The paper evaluates HE between TCP and SCTP using TLS encrypted and unencrypted traffic, and shows that although there is indeed a cost in terms of CPU load to introduce HE, the cost is relatively small, especially in comparison with the cost of using TLS encryption. Moreover, our results suggest that HE has a marginal impact on memory usage. Finally, by introducing caching of previous connection attempts, the additional cost of transport HE could be significantly reduced.

Improved Loss Detection for Signaling Traffic in SCTP

The Stream Control Transmission Protocol (SCTP) was designed by the IETF as a viable solution for transportation of signaling traffic within IP-based networks. Signaling traffic is different from ordinary TCP bulk traffic in many ways. One example is that the requirement of timely delivery usually is much stricter. However, the management of the SCTP retransmission timer is not optimally designed considering this requirement. Basically, the management algorithm, unnecessarily, extends the time needed for loss detection. This paper presents a new management algorithm that is able to maintain a correct state of the retransmission timer, which eliminates this particular problem. In addition, the paper also compares the performance of the two management algorithms in an emulated signaling environment, using the lksctp implementation of SCTP. The results show that the proposed algorithm is able to provide significant reductions in loss recovery time. In some cases, the time needed to recover from packet loss is reduced with as much as 43%.

De-Ossifying the Internet Transport Layer: A Survey and Future Perspectives

It is widely recognized that the Internet transport layer has become ossified, where further evolution has become hard or even impossible. This is a direct consequence of the ubiquitous deployment of middleboxes that hamper the deployment of new transports, aggravated further by the limited flexibility of the application programming interface (API) typically presented to applications. To tackle this problem, a wide range of solutions have been proposed in the literature, each aiming to address a particular aspect. Yet, no single proposal has emerged that is able to enable evolution of the transport layer. In this paper, after an overview of the main issues and reasons for transport-layer ossification, we survey proposed solutions and discuss their potential and limitations. The survey is divided into five parts, each covering a set of point solutions for a different facet of the problem space: 1) designing middlebox-proof transports; 2) signaling for facilitating middlebox traversal; 3) enhancing the API between the applications and the transport layer; 4) discovering and exploiting end-to-end capabilities; and 5) enabling user-space protocol stacks. Based on this analysis, we then identify further development needs toward an overall solution. We argue that the development of a comprehensive transport layer framework, able to facilitate the integration and cooperation of specialized solutions in an application-independent and flexible way, is a necessary step toward making the Internet transport architecture truly evolvable. To this end, we identify the requirements for such a framework and provide insights for its development.

Towards a flexible Internet transport layer architecture

There is a growing concern that the Internet transport layer has become less adaptive to the requirements of new applications, and that further evolution has become very difficult. This is because a fundamental assumption no longer holds: it can no longer be assumed that the transport layer is only in the scope of end-hosts. The success of TCP and UDP and the ubiquity of middleboxes have led to ossification of both the network infrastructure and the API presented to applications. This has led to the development of workarounds and point solutions that fail to cover many facets of the problem. To address this issue, this paper identifies requirements for a new transport layer and then proposes a conceptual architecture that we argue is both flexible and evolvable. This new architecture requires that applications interface to the transport at a higher abstraction level, where an application can express communication preferences via a new richer API. Protocol machinery can use this information to decide which of the available transport protocols is used. By placing the protocol machinery in the transport layer, the new architecture can allow for new protocols to be deployed and enable evolution of the transport layer.

Impact of multi-path routing on TCP performance

Routing packets over multiple disjoint paths towards a destination can increase network utilization by load-balancing the traffic over the network. The drawback of load-balancing is that different paths might have different delay properties, causing packets to be reordered. This can reduce TCP performance significantly, as reordering is interpreted as a sign of congestion. Packet reordering can be avoided by letting the network layer route strictly on flow-level. This will, however, also limit the ability to achieve optimal network throughput. There are also several proposals that try to mitigate the effects of reordering at the transport layer. In this paper, we perform an initial evaluation of such TCP reordering mitigations in multi-radio multi-channel wireless mesh networks when using multi-path routing. We evaluate two TCP reordering mitigation techniques implemented in the Linux kernel. The transport layer mitigations are compared using different multi-path routing strategies. Our findings show that, in general, flow-level routing gives the best TCP performance and that transport layer reordering mitigations only marginally can improve performance.

Enhanced metric caching for short TCP flows

Internet-based applications that require low latency are becoming more common. Such applications typically generate traffic consisting of short, or bursty, TCP flows. As TCP, instead, is designed to optimize the throughput of long bulk flows there is an apparent mismatch. To overcome this, a lot of research has recently focused on optimizing TCP for short flows as well. In this paper, we identify a performance problem for short flows caused by the metric caching conducted by the TCP control block interdependence mechanisms. Using this metric caching, a single packet loss can potentially ruin the performance for all future flows to the same destination by making them start in congestion avoidance instead of slow-start. To solve this, we propose an enhanced selective caching mechanism for short flows. To illustrate the usefulness of our approach, we implement it in both Linux and FreeBSD and experimentally evaluate it in a real test-bed. The experiments show that the selective caching approach is able to reduce the average transmission time of short flows by up to 40%.

Flent: The FLExible Network Tester

Running network performance experiments on real systems is essential for a complete understanding of protocols and systems connected to the internet. However, the process of running experiments can be tedious and error-prone. In particular, ensuring reproducibility across different systems is difficult, and comparing different test runs from an experiment can be non-trivial. In this paper, we present a tool, called Flent, designed to make experimental evaluations of networks more reliable and easier to perform. Flent works by composing well-known benchmarking tools to, e.g., run tests consisting of several bulk data flows combined with simultaneous latency measurements. Tests are specified in source code, and several common tests are included with the tool. In addition, Flent contains features to automate test runs, collect relevant metadata and interactively plot and explore datasets. We showcase Flents capabilities by performing a set of experiments evaluating the new BBR congestion control algorithm, using Flents capabilities to reproduce experiments both in a controlled testbed and across the public internet. Our evaluation reveals several interesting features of BBRs performance.

Emulating opportunistic networks with KauNet triggers

In opportunistic networks, the availability of an end-to-end path is no longer required. Instead opportunistic networks may take advantage of temporary connectivity opportunities. Opportunistic networks present a demanding environment for network emulation as the traditional emulation setup, where application/transport endpoints only send and receive packets from the network following a black box approach, is no longer applicable. Opportunistic networking protocols and applications additionally need to react to the dynamics of the underlying network beyond what is conveyed through the exchange of packets. In order to support IP-level emulation evaluations of applications and protocols that react to lower layer events, we have proposed the use of emulation triggers. Emulation triggers can emulate arbitrary cross-layer feedback and can be synchronized with other emulation effects. After introducing the design and implementation of triggers in the KauNet emulator, we describe the integration of triggers with the DTN2 reference implementation and illustrate how the functionality can be used to emulate a classical DTN data-mule scenario.