Contents

1. Issues in TCP over wireless
   
   
2. Solution Design Issues
   
   
3. A Fundamental Question
   
   
4. Other Design Alternatives
   
   
5. The Snoop Protocol
   
   
6. Remarks
   
   
7. Reading

1. Issues in TCP over wireless

TCP functionalities:

• Provides reliable, in-order delivery of packets to applications.
  
  
• Incorporates various congestion control and avoidance mechanisms.

TCP is tuned for wired networks in the sense that packet loss is assumed to be due to congestion only (because error rates in fixed or wired networks are negligible). This assumption fails in wireless networks as error rates in wireless networks may be an order of magnitude larger than in wired networks. Hence, when packets are dropped or corrupted on the wireless link, the congestion control mechanism on the sender kicks in and as a result (of reduction in congestion window size) the throughput decreases drastically.

Back to Top

2. Solution Design Issues

The following two questions are relevant:

• Which part of the network to implement the solution at? Sender, Receiver, wired part of the network, wireless part of the network, or an agent (as in the case of mobile IP)
  
  
• Which layer to implement the solution at? MAC layer (making wireless link more reliable using link-level ACKs) or at TCP layer (making TCP aware of wireless losses) or at the network layer

Back to Top

3. A Fundamental Question

Is TCP the appropriate protocol model for wireless networks?

A possible solution to the above problem would be to do away with TCP entirely and replace by another model for the wireless network. This may involve a gateway to connect wireless networks to the Internet.

However, it is argued that TCP is indeed the appropriate model for wireless networks too, as most software (now and also in the foreseeable future) is written for it and also TCP/IP-enabled wireless networks would integrate seamlessly into the Internet.

Back to Top

4. Other Design Alternatives

1. Split Connection: In Indirect-TCP, two TCP connections exist, one between the Fixed Host (FH) in the wired part of the network and the base station that utilizes normal TCP and another between the Mobile Host (MH) and the base station that utilizes wireless-aware TCP. This is shown in the following figure:
   

   Problems in this approach:

   1. Breaks end-to-end semantics of TCP: The base station (BS) maintains hard state and if it crashes, TCP semantics are broken.
      
      
   2. Relinking: Applications on the MH need to be relinked against the wireless-aware TCP.
      
      
   3. Software Overhead: Each packet moves through 4 TCP layers (one at sender, two at BS and one at reciever).
   
   
2. Fast Retransmit: To avoid waiting for timeouts to occur on the TCP sender, if it recieves 3 DUP-ACKs in succession, the sender just retransmits the packet wanted by the reciever. This scheme may work favourably during times of handoff i.e. when the MH leaves one cell and joins another. However, it doesn't directly deal with packet loss on the wireless links and several lost packets in the same flight may bring down TCP throughput considerably.
   
   
3. Link-Level Retransmissions: Here, the wireless link layer itself may provide reliability by using ACKs of its own. But link-level ACK timeouts may interact with TCP timeouts and the performance may degrade.

Back to Top

5. The Snoop Protocol

Consider the case when data is transferred from a sender in the wired part of the network to a reciever that uses wireless for "last-mile" connectivity. The features of the Snoop protocol are:

• We assume to have administrative control over only the base stations and the mobile hosts. Hence, a protocol that requires new or change of software on these entities only is desirable.
  
  
• Snoop is a network-layer solution that snoops on TCP traffic between the Fixed Host (FH) sender and the Mobile Host (MH) reciever at the base station. At no point in the protocol would we do anything other than dropping packets or duplicating packets (behaviour consistent with Internet network layer semantics).
  
  
• The network layer routing code (forwarding code, to be correct) at the base station is modified to add the snoop module that monitors all packets passing through the TCP connection in either direction.
  
  
• The snoop module maintains a cache of all TCP packets sent by the FH and not yet acknowledged by the MH (this will help in local retransmissions which are inexpensive in comparison with retransmissions from the FH).
  
  
• DUP-ACKs may be used to detect packet loss on the wireless link which would trigger local retransmissions. Snoop will hide packet loss on the wireless link from the FH (by suppressing DUP-ACKs from propagating to the FH if it is established that the packet loss was not due to congestion in the wired part itself).

snoop_data()

The snoop_data procedure processes and caches packets from the FH:

Case	Incoming Packet	Actions
1	New packet, in sequence (with sequence number > sequence number of last packet seen, need not be the very next sequence number)	(Normal case) 1. Add to cache 2. Forward to MH
2	Out of sequence packet that has been cached earlier	(Rare case, occurs when dropped packets cause timeouts at FH - 2 subcases arise)
		(If sequence number of this incoming packet > sequence number of last packet ACKed by MH) Packet is forwarded to MH
		(If sequence number of this incoming packet < sequence number of last packetACKed by MH) MH already recieved the packet. So, the FH must have retransmitted because ACK must have been lost in the wired part of the network. Hence BS generates and sends an ACK to FH
3	Out of sequence packet that has not been cached earlier	(The packet was lost earlier in the wired network due to congestion or was delivered out-of-order by the wired network) 1. Mark as congestion (sender retransmission) 2. Forward to MH

snoop_ack()

The snoop_ack procedure processes ACKs coming from the MH and triggers local retransmissions from the base station to MH whenever appropriate:

Case	Incoming Acknowledgement	Actions
1	New ACK	(Normal case) 1. Free appropriate buffers in cache 2. Forward to FH
2	DUP-ACK	(Same sequence number as of last ACK seen so far - 3 subcases arise)
		(For a packet not in cache or marked as sender retransmission in cache) Both these reasons require DUP-ACK to be propagated to FH (pop quiz: why?)
		(First (unexpected) DUP-ACK for any packet in cache) 1. Local retransmission with high priority - see paper for implementation details 2. Calculate max number of (expected) further DUP-ACKs 3. And, of course, suppress the DUP-ACK
		(Further (expected) DUP-ACKs) Are suppressed
3	Spurious ACK (neither new ACK nor DUP-ACK)	(Improbable case) Just discard

Back to Top

6. Remarks

1. To deal with the case when MH is data transfer sender and FH is the reciever:
   • Enable SACK processing on MH
     
     
   • BS generates SACKs to request retransmission from MH of any packets lost on the wireless link
   
   
2. Snoop requires the BS to read TCP segment data (sequence numbers in the header). If IPsec is used (with a security association between the FH and the MH), the TCP payload would be encrypted and so the BS will not be able to read the TCP headers.
   
   
3. Link layer solutions are achievable in many cases.

Back to Top

7. Reading

[BSA95] Hari Balakrishnan, Srinivasan Seshan, Elan Amir, Randy H. Katz, Improving TCP/IP Performance over Wireless Networks, ACM Mobicom, Nov 1995.

Back to Top