ISBN: 0-471-41405 -0
Download (direct link):
The solution, IP version 6 (IPv6), was developed in order to ensure that IP would not become a limiting factor for the spread of the Internet. With IPv6, 128 bits are used for the IP address instead of 32 bits (see Figure 6.2). Consequently, there will be a theoretical limit of 3 40 x 101038 Internet hosts (or plenty of billions of addresses per person on Earth). In addition to solving the problem of the lack of IP addresses, IPv6 also provides enhanced security features and more control over the routes that packets take.
IPv6 has been in the works for a long time now, but adaptation is slow in the industry. We expect, however, that the mobile Internet will be one of the main drivers for a wider acceptance of IPv6.
While IPv4 still exists, static IP addresses are likely to come at a premium. Most wireless networks will enable the user to connect either to an Internet Service Provider (ISP) that the wireless operator provides or to an external ISP (through a RADIUS/DIAMETER server). Anyway, we do not recommend
IP version 4
IP version 6
Figure 6.2 IP address sizes for version 4 and version 6.
designing an application that requires static or public IP addresses, because not many users will be able to obtain one of those addresses.
Transmission Control Protocol (TCP)
As a transport-layer protocol, TCP also ensures that data for which IP finds a destination host will be propagated to the right application. FTP and HTTP applications might be running on that same host, and the TCP port number indicates which is the target application. TCP also ensures that packets (TCP really sends and receives segments, but here we use the word packet at all times for simplicity) of data are delivered reliably and in order. As we saw previously, these requirements are crucial because IP does not guarantee anything; rather, it merely provides a means to get the packets routed correctly. Packets that have traveled different routes in order to get to same destination need to be assembled in the right order, and TCP performs this task. Delivering the packets reliably means that lost packets are detected and retransmitted. Finally, TCP provides flow control functionality, which makes sure that the sender and receiver agree on a suitable speed of data delivery. Covering the loss of packets and the maintenance of flow control are the two features that affect wireless performance the most. In addition, applications developers who want to get the most from this versatile protocol should understand the setup process of a TCP session.
Establishing a TCP Session
TCP is a connection-oriented protocol, which means that a session has to be initiated before data can be exchanged and that each TCP session can only exist between two hosts. The typical example is a user who wants to download a Web page with his or her Web browser. Clicking a hyperlink starts a TCP session between the user’s client computer and the Web server that hosts the page. As the user goes to another site, a new TCP session is created between that server and the client. Each TCP session is initiated by a three-way handshake,
where the initiating party (let’s call him or her the sender) sends a synchronization (SYN) packet to the other party (here, we call it the destination). This packet holds information about the session that is to be established, such as the packet sequence number, the proposed maximum packet size, and the proposed rate of transmission. The rate of transmission is identified by a sending window size (in other words, how big a part of the sending buffer can be sent at the same time). The receiving party then responds with similar parameters that consequently describe its parameters and buffer sizes. As a final step, the sending party acknowledges that it received the responding SYN by sending another SYN packet. We show the entire sequence in Figure 6.3.
So, every time you establish a TCP session, you exchange three packets. This is not a serious problem on the Internet, because the latencies (delays between the sender and the receiver) are low (200ms to 300ms most of the time). In a
Figure 6.3 TCP three -way handshake.
wireless system, however, latencies will (at times) be in the range of seconds. Think of what the consequences are on a TCP network that has a round-trip time (RTT) of two seconds, because each transaction between the sender and the receiver needs packets to go back and forth a number of times. RTT refers to the time that it takes for a packet to travel to the recipient and back. If you have to use TCP, be aware of this factor and always count on a delay that is measured in seconds when establishing a new TCP session.
In addition, there is a parameter called Initial Retransmission Timeout (IRTO) that specifies the time that a sender will wait for the first sent packet to return before assuming that the other party will not respond. The Internet Engineering Task Force (IETF) recommends this parameter to be set to three seconds, but many servers on the Internet have cut that down to a few hundreds of milliseconds. Why? Well, if you are on a fast connection and are accessing a server, you do not have to wait that long before abandoning the connection if it is unreasonably slow or even down. Obviously, an RTT of two seconds (not uncommon on loaded wireless networks) here would cause considerable problems, because the sender will give up the wait for the initial packets even before they have traveled halfway.