Closing Connections

Introduction

Mobile applications often leave a connection open long after data has been transmitted and the connection is no longer required. This typically happens when a connection is not deliberately closed as part of the transmission and is terminated later when the connection times out. This is an inefficient way to close a TCP connection.

It is good practice to close a connection as soon as possible after data is transmitted, to prevent radio channels from being kept open needlessly.

The following image (figure 1) illustrates the issue of a connection that was closed inefficiently. The image shows the Trace chart in the Diagnostics tab of the AT&T Video Optimizer diagnostic tool. The Video Optimizer tool collects trace data from an application, evaluates it against recommended best practices, and generates analytical results.

Figure 1: Trace results showing the late termination of a connection.

In the "Bursts" row of this Trace chart, the bursts (in green and red) between 10 and 40 seconds on the timeline were used to transfer data. While the burst (in blue) around the 80 second mark represents a request to close the earlier connection.

Notice that the radio, represented on the "RRC States" row below the "Bursts" row, is turned back on just to close the connection. This can be seen at the 80 second mark below the narrow burst (in blue). The RRC States row also shows that the radio is not just simply turned on and off. It remains on for a set period, including time in a high energy state, then low energy, and all the related tail time (wasted energy) before it turns off.

If the connection had been closed as part of the final packet which transmitted data, the radio could have remained idle.

This Best Practice Deep Dive looks at the ways in which TCP connections can be closed. It examines the issue that occurs when connections are not deliberately closed and offers recommendations for closing connections more efficiently.

Background

During normal operation, both sides of the transmission are sending and receiving data simultaneously. Connection termination typically begins with one side signaling that it wants to close the connection, but a number of requirements are necessary to ensure that the connection is shut down gracefully.

To understand these requirements, it's important to remember two TCP flags:

• ACK — Indicates acknowledgment. All packets after the initial SYN packet sent by the client should have this flag set.
• FIN — Indicates no more data will be transmitted from the sender.

When either side of a TCP conversation is done sending data, it can send a FIN signal to close the connection. When one side receives a FIN, it must notify the application that the other side is shutting down transmission. The sending of a FIN is normally the result of the application issuing a close, which the other side acknowledges with an ACK.

Even though a TCP connection is established with a three-way handshake (SYN, SYN-ACK, ACK), it can be terminated in various ways, including the following:

1. A four-way handshake termination could begin when one side transmits a FIN packet, which the other side acknowledges with an ACK. Therefore, a typical tear-down requires a pair of FIN and ACK segments from each TCP endpoint. After both FIN/ACK exchanges are concluded, the terminating side waits for a timeout before finally closing the connection, during which time the local port is unavailable for new connections; this prevents confusion due to delayed packets being delivered during subsequent connections.
2. A three-way handshake termination could take place when one side sends a FIN and the other acknowledges with a FIN & ACK. The first side then acknowledges with an ACK.
3. A two-way handshake termination could occur when a FIN/ACK sequence is transmitted simultaneously by both sides.

No matter which of these methods is used to terminate a TCP connection, it's important to note that they all terminate the connection deliberately.

The Issue

The problem occurs when there is no deliberate effort to close the TCP connection. If the connection is not closed by design, it will likely be closed by a time-out as part of connection management.

Time-outs were created to handle error control in TCP. Servers usually have some time restriction that is activated when the connection has been idle for a given period. Once that time-out restriction has been reached, the server should gracefully close the connection. However, if a client or server does not detect the other side's close instruction promptly, it could cause unnecessary resource drain on the network.

For instance, if the final transmission carrying data does not execute a termination, then a later time-out is implemented by the server. This is a late termination. In the wireless environment, a later termination often means the radio is turned on just to close the connection. When the radio is turned on, it remains on for a set period, including time in a high energy state, then low energy, and all the related tail time before it turns off. (See figure 1 for an illustration of a late termination.)

This adds to network congestion and wastes energy, which can affect battery life.

Best Practice Recommendation

The Best Practice Recommendation is to close TCP connections quickly after your data is transmitted, to prevent leaving radio channels open. Promptly closing connections prevents you from having to open radio transmissions only for the purpose of closing a connection due to time outs. By eliminating as many of these inefficient connections as possible, you can save energy and optimize your application.

Connections can be closed in a variety of ways, but it's helpful to remember that once the last data for a given transmission is sent, and there is no more data to transmit, you can terminate the connection by transmitting the last segment with the FIN bit set to 1. The other side will then acknowledge (ACK) that communication and terminate the connection.

It's important to note that managing connections in your application involves tradeoffs. It is not always efficient to close every persistent connection quickly. There are exceptional situations where a persistent connection needs to be kept open so that it may be reused.

However, by closing connections promptly that do not need to be kept open for reuse, you can reduce energy consumption in your application.