The main issues why TCP doesn't work well in wireless links are listed as follows,
- packet loss is considered as network congestion, lossy link isn't implemented in a separate packet header
- high round-trip time (RTT)
But in order to achieve interoperability between wireless and LANs, it is still beneficial to use the same TCP stack. Some error assumptions can be made on wireless links. For example, in poor GSM connections, timeouts should be rather common if running on TCP, but real world simulations show otherwise because the delay pattern is more of jitter in packet arrivals, resulting in higher values of TCP retransmit timer.
Several models are suggested so that researchers can simulate more accurately,
- Error losses and corruption: dropping packets probabilistically on a time-based loss, or by per-packet, or per-bit
- Delay variation: by suspending data transmission.
- Packet reordering: swapping two packets in the queue at a given time
- On-demand resource allocation: giving and additional delay when packets arrive at queue
- Bandwidth variation: changing bandwidth. e.g. CDMA2000 0.02-20s / 9.6~163Kbps.
- Asymmetry in bandwidth and latency: configuring uplink/downlink with different parameters for bandwidth and latency.
- Queue: WLAN, drop-tail; satellite, RED. (large buffer causes high queuing delay and poor loss recovery; small low link utilization and frequent packet drops)
Comment: This paper provides abundant background knowledge of wireless network and ways of simulating the iffy link environment. It is also very interesting to know that handovers happen once per minute while driving in a urban area.
No comments:
Post a Comment