7.3 The Radio Link Challenge

Although IP and its application protocols are designed as link generic to accommodate a very wide range of data link networks, there was an implicit assumption in the designs that the network is a wired network. Now that the wireless is adopting these protocols, it is realized that the radio links have their own characteristics, which impact the performance of the IP protocols. These impacts are more significant in the case of Wireless Wide Area Networks (WWAN e.g., cellular networks) and Wireless Personal Area Network (WPAN e.g., Bluetooth), compared to the Wireless LAN (IEEE 802.11). This is because WWAN and WPAN offer more latency and limited bandwidth. In this section, we are going to discuss the challenges posed by some of the characteristics of radio links for IP.

7.3.1 Radio Link Efficiency

A radio interface is bandwidth constrained because it is bound to use limited spectrum. Although 3G networks claim to provide bit rates up to 2 Mbps, it is still a far cry from the 52.8 Mbps a very high data rate digital subscriber line (VDSL) can offer on a single twisted-pair copper loop. Similarly, bit rate of 11 Mbps in WLAN is no comparison to 1 Gbps of the gigabit Ethernet (IEEE 802.3). Therefore, it is highly desired to use the available bandwidth as efficiently as possible, so as to give the user a decent performance for IP compared to the wired world. Moreover, cellular operators pay a significant amount of their deployment costs in acquiring a spectrum. Therefore, radio link efficiency is also highly desired for cost savings.

One approach to improving efficiency for some IP protocols is to use header compression. A problem with IP is its large header overhead. This problem is more visible for those real-time applications where a packet is generated at a very fast rate and the payload size is comparable or even smaller to the header size. For example, an RTP (real-time protocol) packet carrying interactive voice conversation could have an IPv6 header of 40 bytes, a UDP header of 8 bytes, and an RTP header of 12 bytes, making the total header bytes equal to 60 bytes. The size of the payload, depending on the speech coding, could be as low as 15 to 20 bytes. In this example the header size is twice the payload size. The Robust Header Compression ROHC working group has developed [RFC 3095] header compression schemes for RTP/UDP/IP. The schemes can reduce the header size down to one or zero byte. The wireless links also need to have robust header compression for the other protocols, such as TCP and SCTP.

Bandwidth efficiency can also be improved by performing compression on IP payloads. The IP Payload Compression Protocol (IPComp) [RFC 2393] defines a framework for payload compression. The 3GPP2 network uses the PPP from the PDSN to the MS and has suggested using the PPP Compression Control Protocol [RFC 1962] for PPP payload compression. Bluetooth LAN access profile also suggests using PPP and PPP payload compression. However, if the encryption is applied to IP datagrams, the compression at a lower layer (e.g., PPP) becomes ineffective . IPComp is especially useful when encryption is applied to IP datagrams. RFC 2757 provides a good analysis of the feasibility of IP payload compression. It suggests that IP payload compression is something of a niche optimization and may not be always useful. It also says that many of the IP payloads are already compressed (images, audio, video, " zipped " files) by the applications or are already encrypted above the IP layer. These payloads will not compress further, limiting the benefit of this optimization. Also, the application-level compression can often outperform IPComp because the applications can use compression dictionaries based on knowledge of the specific data being compressed. Therefore, for payload compression the best bandwidth efficiency can be achieved if application-level compression techniques are used extensively. The challenge is to ensure that all the applications have a compression mechanism and are using them over wireless links.

7.3.2 Radio Delay and Error

Radio links are low-bit-rate links. They can transmit a block of bits, called a radio frame, which is usually much smaller than an IP packet. Therefore, IP packets are usually segmented into much smaller radio frames so they can be transported over these low-bit-rate links. The link layer usually provides queues for the IP packets and the radio frames , to help in the process of segmentation and transmission. This introduces store-and-forward delay and decreases the throughput of IP. The challenge is to reduce this store-and-forward delay to increase throughput. There are new modulation and coding schemes defined for 3G systems that can pack more bits in a radio frame and can reduce the store-and-forward delay to a certain extent. But the increased number of bits usually comes at the cost of error protection.

Another radio delay that adds to the store-and-forward delay is caused by the link-layer error recovery mechanism. The radio links have a relatively high frame loss rate; therefore, an ARQ type of mechanism is used for assured delivery. Retransmission due to the ARQ mechanism adds delay in delivering an IP packet. In addition to the delay, the link-layer ARQ has some adverse effect on applications, which have their own ARQ mechanisms, like TCP. TCP calculates the value for retransmission timeout (RTO) based on the measured end-to-end round-trip time (RTT). When the link layer retransmits radio frames of a TCP packet, link latency momentarily increases . This sudden increase in latency may cause RTO expiry, resulting in an unnecessary retransmission by TCP of a packet that the link layer is still retransmitting. Such spurious end-to-end retransmissions generate unnecessary load and reduce end-to-end throughput.

One can suggest inhibiting link-layer ARQ if the application has ARQ. But link-layer retransmissions are much more efficient than end-to-end error recovery. This is because the end-to-end path could be much longer than the wireless link. As a result, link-layer and application ARQ need to exist together. The challenge here is to establish an efficient interaction between the two layers of ARQ protocols so they will not cause any impairment on the throughput.

Errors on wireless links may result in IP packet loss, which has another implication in TCP. For TCP, a packet loss means that there is congestion in the network. This is because in the wired network, packets are usually lost due to congestion and are rarely lost because of link errors. TCP initiates congestion avoidance or slow start mechanisms; these procedures reduce throughput significantly. While there are mechanisms [RFC 3155] defined for improving TCP performance in such scenarios, the challenge is to optimize the TCP and any other protocols from the assumptions, which are invalid in the case of wireless link layer.

In the cellular world, signaling message sizes are optimized for low bandwidth, so the signaling procedures can be completed with low latency. One such example is the initial access message in GSM [GSM TS 04.08], which is only one byte long. In the IP world, there are text-based protocols, such as SIP, RTSP, and SDP, which are defined without considering bandwidth-limited links. For example, a SIP message can be as big as 2000 bytes. These messages would take a significant amount of time to transfer over the air interface, resulting in a significant delay in session establishment or feature invocation. These protocols need to be optimized for wireless links. The ROHC working group is currently looking into compressing the SIP protocol.

In summary, the challenge is to modify wireless link and/or IP to enhance performance. Wireless links have their own hard limitations, such as bandwidth, which cannot be enhanced further. Also, some enhancements may not be cost effective for commercial use. On the other hand, modifications in IP and its applications are more challenging than wireless links. IP protocols are already implemented in lot of products, and it is not possible to change all those legacy products. Moreover, IP is a layer 3 protocol and it should not be changed because of a specific layer 2 protocol requirement.

The IETF Performance Implications of Link Characteristics (PILC) working group has published documents that provide analysis of link characteristics and set the direction for further research. PILC has also suggested use of performance enhancing proxies (PEPs) for TCP (see RFC 3135 for details). PEP is defined as a function that improves the performance of Internet protocols on network paths where native performance suffers due to the characteristics of a link. So far, the PEP approach is used for TCP, but other application protocols may also like to adopt this approach. However, generalized use of PEPs is discouraged, mainly because they contravene the end-to-end principle of IP. In the long run, wireless link and IP need to be converged in a more substantial way. Future enhancements in one protocol need to be carried out while considering the requirements of the other.