TCP-IP NETWORKING FOR WIRELESS SYSTEMS

Integrated Communication Systems Group
Ilmenau University of Technology
TCP/IP Networking for Wireless
Systems

Content
• Internet Protocol Suite
– Link Layer: Ethernet, PPP, ARP, MAC Addressing
– Network Layer: IP, ICMP, Routing
– Transport Layer: TCP, UDP, Port Numbers, Sockets
– Application Layer: FTP, Telnet & Rlogin, HTTP, RTP
• TCP
– Basic Properties
– TCP Datagram Format
– Connection Setup and Release
– MTU and MSS
– Cumulative, Delayed and Duplicate Acknowledgements
– Sliding Window Mechanism
– Flow and Error Control
Advanced Mobile Communication Networks, Master Program 2

Internet Protocol Suite
TCP/IP = the “Internet protocol suite“ = a family of protocols for the
“Internet”
Internet guesstimates 2003:
– 800 million users (x 2 each two years), 200 million permanent hosts
Standardisation:
– ISOC: Internet Society
– IAB: Internet Architecture Board
• IETF: Internet Engineering Task Force: http://www.ietf.org
– Standards & other informations are published as RFCs:
Requests for Comments
• IRTF: Internet Research Task Force

Internet Protocol Suite
Implementations:
– De-facto standard: BSD 4.x implementations (Berkeley Software
Distribution)
– Subsequent versions come with new TCP features, e.g.
4.3 BSD Tahoe (1988): slow start, congestion avoidance, fast
retransmit
4.3 BSD Reno (1990): fast recovery
– Other TCP/IP stacks derived from BSD
– Implemented mechanisms, default parameter settings, and bugs
are different on different operating systems (e.g. versions of MS
Windows)!

TCP/IP Layer Overview
TCP/IP Layers
(OSI model*)
Tasks Protocol Examples
Application
(7)
Application specific
Telnet, rlogin, FTP, SMTP,
SNMP, HTTP, ...
Transport
(4)
End-to-end flow of data
between application
processes
TCP, UDP
Network
(3)
Routing of packets
between hosts
IP, ICMP
Link
(2)
Hardware interface
Packet transfer be-
tween network nodes
PPP, Ethernet, IEEE 802.x,
ARP
* Mapping between TCP/IP and OSI layers is not always exact.

TCP/IP Encapsulation
user data
user data
appl.
header
Application
eth
header
IP
header
application data
TCP
header
eth
trailer
Ethernet
Driver
14 20 20 4
Ethernet frame
Ethernet: 46...1500 bytes
application data
TCP
header
TCP
TCP segment
20
IP
header
application data
TCP
header
IP
IP datagram
20...65536 bytes
20
Example:
Application data
transfer using TCP

TCP/IP Basics: Link Layer
Application Layer
Transport Layer
... Network Layer
... Link Layer
User
Process
User
Process
User
Process
User
Process
TCP UDP
IPICMP
Hardware
Interface
ARP

Link Layer Protocols
Examples:
– Ethernet (encapsulation of higher layer packets is defined in RFC 894)
– PPP: Point-to-Point Protocol for serial lines (RFCs 1332, 1548)
MTU: Maximum Transfer Unit (or Max. Transmission Unit)
– Maximum IP packet size in bytes (e.g. for Ethernet: 1500, X.25 Frame Relay:
576)
Path MTU:
– Smallest MTU of any data link in the path between two hosts
– Used to avoid IP fragmentation
– TCP option: path MTU discovery (RFC 1191)
Loopback Interface:
– A client application can connect to the corresponding server application on the
same host by using the loopback IP address “localhost“ = 127.0.0.1
– Implemented at the link layer, i.e. full processing of transport and IP layers
ARP: Address Resolution Protocol (RFC 826)
– Address resolution from 32-bit IP addresses to hardware addresses (e.g. 48-
bit)

TCP/IP Basics: Network Layer
Application Layer
Transport Layer
... Network Layer
... Link Layer
User
Process
User
Process
User
Process
User
Process
TCP UDP
IPICMP
Hardware
Interface
ARP

IP: Internet Protocol
IP provides forwarding between hosts:
– Based on 32-bit IP addresses *
– Hop-by-hop using routing tables
Unreliable, connectionless datagram delivery service:
– packet loss, out-of-order delivery, duplication
IP fragmentation: used on any link with MTU < original datagram
length:
– Duplicates IP header for each fragment and sets flags for re-
assembly
– Re-assembly at the receiving host only, never in the network
RFC 791
Applications use the Domain Name Service (DNS) to convert
hostnames (e.g. “www.lucent.com“) into IP addresses
(135.112.22.95) and vice-versa
* IPv6 uses 128-bit addresses

IP Datagram Format
QoS
requirements;
rarely used
and supported
4-bit
version
8-bit type of service
16-bit identification
data
20 bytes
4-bit
header
length
16-bit total length (in bytes)
3-bit
flags
13-bit fragment offset
8-bit time to live 8-bit protocol 16-bit IP header checksum
32-bit source IP address
32-bit destination IP address
options (if any)
IP datagram
length in bytes
(limit = 65536)
- (reserved)
- don‘t fragment
- more
fragments
Unique
identifier
(counter)
Limit on the
number of
routers
(countdown)
Higher layer
identifier,
e.g.:
ICMP=1
TCP=6
UDP=17
“Real“ frag
ment offset /
8IPv4
Number
of 32-bit
words
16-bit one‘s complement sum
of the IP header only
checksum error =>
discard datagram & try to
send ICMP message

ICMP: Internet Control Message Protocol
ICMP packet consists of IP header + ICMP message
Used for queries and to communicate error messages back to the
sender, e.g.:
– “Bad IP header“
– “echo request“ (or reply)
– “host unreachable“
– Mobile IP messages
Messages are used by higher layers, e.g.:
– ping, traceroute, TCP, ... HTTP
RFC 792

TCP/IP Basics: Transport Layer
Application Layer
Transport Layer
... Network Layer
... Link Layer
User
Process
User
Process
User
Process
User
Process
TCP UDP
IPICMP
Hardware
Interface
ARP

UDP vs. TCP
UDP: User Datagram Protocol (RFC 768)
– Simple, unreliable, datagram-oriented transport of application data
blocks
TCP: Transmission Control Protocol (RFC 793 + others)
– Connection-oriented, reliable byte stream service
– Details: see section on TCP
Port numbers are used for application multiplexing:
– Unique address = IP address + port number = “socket“
– Concept of well-known ports, e.g. TCP port 21 for FTP (RFC 1340)
Popular API for TCP and UDP connections: Socket API
– “Stream sockets“ use TCP
– “Datagram sockets“ use UDP

UDP Datagram Format
16-bit source port number 16-bit destination port number
16-bit UDP length 16-bit UDP checksum
data (if any)
8 bytes
Optional 16-bit one‘s complement sum
of UDP pseudo-header (12 bytes of the
IP header) + UDP header + data
(padded to 16-bit multiple)
checksum error =>
discard datagram silently
UDP datagram
length in bytes
(redundant)
Used for
application
multiplexing
Used for
application
multiplexing

TCP/IP Basics: Selected Applications
Application
Layer
Transport Layer
... Network Layer
... Link Layer
User
Process
User
Process
User
Process
User
Process
TCP UDP
IPICMP
Hardware
Interface
ARP

FTP: File Transfer Protocol
File transfer based on TCP
TCP control connection:
– To well-known server port 21
– ASCII commands
TCP data connection
QoS requirements:
– High throughput (optimise TCP bulk data flow)
RFC 959

Telnet and Rlogin
Used for remote login based on TCP
– Rlogin (RFC 1282):
• Simple protocol designed for UNIX hosts
– Telnet (RFC 854):
• Any OS
• Option negotiation
• More flexible and better performance
Client operation principle:
– Send each keystroke to the server
– Option: TCP’s Nagle algorithm groups multiple bytes into one
segment
– Display every response from the server
QoS requirements:
– Low-RTT transport of small packets (optimise TCP interactive data
flow)
• RTT = round-trip-time (sender – receiver – sender)

HTTP: Hypertext Transfer Protocol
Transfer of webpages based on TCP:
– Webpage typically consists of an HTML (Hyper Text Markup
Language) document + various embedded objects, e.g. pictures
HTTP/1.0:
– Objects are (requested and received) serially
– For each object, a new TCP connection is established, used and
released
– Multiple connections: several TCP connections can be used in
parallel

HTTP: Hypertext Transfer Protocol
HTTP/1.1 (RFC 2068): performance improvements by
– Persistent Connections:
• TCP connections are not released after each object, but used for
the next one
– avoids TCP connection establishment and termination
– avoids slow start for each new connection
– Pipelining:
• Multiple objects can be requested in one packet
• Requested objects are sent sequentially over one TCP
connection
HTTP/2 (RFC 7540): decreased latency due to
– Parallel loading of page elements over single TCP connection
– header compression
– Server initiated data transmission (push technology)

RTP: Real-time Transport Protocol
Transfer of real-time data based on UDP
RTP:
– for media with real-time characteristics (audio/video)
– services: payload type specification, sequence numbering, timestamping,
source identification & synchronization, delivery monitoring
– no guaranteed quality of service (QoS)
RTCP (Real-time Transport Control Protocol):
– QoS monitoring & periodic feedback:
• Sender report (synchronisation, expected rates, distance)
• Receiver report (loss ratios, jitter)
Network independent: on top of unreliable, low-delay transport
service
RFC 1889
ITU-T H.225.0 Annex A => H.323 => e.g. MS Netmeeting, VoIP

Summary: Internet Protocol Suite
The TCP/IP protocol suite is a heterogenous
family of protocols for the global Internet
At the center and always used: IP
– Routing between hosts
Application data transport by
– UDP: unreliable datagram service
– TCP: reliable byte-stream service
TCP/IP stack is part of each operating system:
– Numerous different implementations and bugs exist
TCP performance is extremely important!
– TCP carries 62% of the flows, 85% of the packets,
and 96% of the bytes of Internet traffic
(http://www.cs.columbia.edu/~hgs/internet/traffic.html)
– TCP’s complex error control mechanisms are designed for wired networks
=> special problems for wireless transport

TCP (Transmission Control Protocol)
Properties
Connection-oriented, reliable byte-stream service:
– Reliability by ARQ (Automatic Repeat reQuest):
• TCP receiver sends acknowledgements (acks) back to TCP sender to
confirm delivery of received data
• Cumulative, positive acks for all contiguously received data
• Timeout-based retransmission of segments
– TCP transfers a byte stream:
• Segmentation into TCP segments, based on MTU
• Header contains byte sequence numbers
Congestion avoidance + flow control mechanism
In the following examples:
– Packet sequence numbers (instead of byte sequence numbers)
– ack i acknowledges receipt of packets through packet i (instead of
bytes)

TCP Segment Format
6 bits
reserved
16-bit source port number
data (if any)
20 bytes
4-bit
header
length
16-bit window size
16-bit TCP checksum
32-bit sequence number
options (if any)
16-bit destination port number
32-bit acknowledgment number
6-bit flags
16-bit urgent pointer
16-bit one‘s complement sum of
TCP pseudo-header (12 bytes of
the IP header) + TCP header + data
(padded to 16-bit multiple)
checksum error
=> discard datagram silently!
=> using an erroneous header is
dangerous; loss will be detected
by other mechanismsUrgent
Pointer (2 Byte):
Identifies the
number of the
first data byte
in this segment
within the byte
stream
Ack for the
reverse link:
next sequence
number that is
expected to be
received
Number of 32-
bit words
Advertised
window
size:
number of
bytes the
receiver is
willing to
accept
URG: Urgent Pointer field significant - urgent data are outstanding
ACK: Acknowledgment field significant
PSH: Push Function - push to indicate prompt transmission of
data
RST: Reset the connection
SYN: Synchronize sequence numbers
FIN: No more data from sender
TCP is full duplex:
Each segment contains an ack for the reverse link
A ”pure” ack is a segment with empty data

TCP Connection Establishment and Termination
Client Server
Segment 3: ACK
Three-way handshake
*ISN: initial sequence number
(RFC 793)
Segment 1:
SYN + ISN* +
options, e.g. MSS
Active open:
Segment 2:
SYN, ACK + ISN +
options, e.g. MSS
Passive open:
Application close
=> Segment 1: FIN
Active close:
Passive close:
=> Send EOF to
application
Segment 2: ACK;
application can still send
data
Half-close #1
Application close =>
Segment 3: FIN
Segment 4: ACK Half-close #2
=> Connection establishment & termination take at least 1 RTT

MTU and MSS: Maximum Segment Size
Client Server
Application
TCP
IP
Link Layer
Request to connect to Server
SYN, MSS=536
TCP Connection
establishment
MSS = 536
- Fixed TCP header = 20
- Fixed IP header = 20
MTU = 576 (e.g. modem)
MSS = 1460
- Fixed TCP header = 20
- Fixed IP header = 20
MTU = 1500 (e.g. ethernet)
SYN, ACK, MSS=1460
find
network
interface
MSS is optionally announced (not negotiated) by each host at TCP connection
establishment. The smaller value is used by both ends, i.e. 536 in the above example.
Note that “real“ TCP payload is smaller if TCP options are used.

Cumulative Acknowledgements
A new cumulative ack is generated only on receipt of a new in-
sequence segment
i data acki
TCP
sender
TCP
receiverRouter40 39 3738
received:
...
35
36
41 40 3839
35 373634
received:
...
35
36
37
timestep
3533 3634

Delayed Acknowledgements
Delaying acks reduces ack traffic
An ack is delayed until
– another segment is received, or
– delayed ack timer expires (200 ms typical)
40 39 3738
3533
received:
...
35
36
New ack not produced
on receipt of segment 36,
but on receipt of 37
41 40 3839
35 37
received:
...
35
36
37

Duplicate Acknowledgements 1
A dupack is generated whenever an out-of-order segment arrives at
the receiver (packet 37 gets lost)
40 39 3738
3634
received:
...
36
42 41 3940
36 36
received:
...
36
x
38
dupack
on receipt of 38
2 timesteps
packet loss

Dupacks are not delayed
Dupacks may be generated when
– a segment is lost (see previous slide), or
– a segment is delivered out-of-order:
40 39 3837
3634
41 40 3739
36 36
dupack
on receipt of 38
received:
...
36
x
38
received:
...
36
1 timestep

40 37 3839
3634
41 40 3937
36 36
dupack
34
received:
...
36
x
38
received:
...
36
42 41 3740
36 36 36
dupackdupack
received:
...
36
x
38
39
43 42 4041
36 36 39
new ackdupack
received:
...
36
37
38
39
36
dupack
Number of
dupacks
depends on
how much
out-of-order
a packet is
A series of
dupacks
allows the
sender to
guess that a
single
packet has
been lost

Window Based Flow Control 1
Sliding window protocol
Window size W is minimum of
– receiver’s advertised window - determined by available buffer
space at the receiver and signaled with each ack
– congestion window - determined by the sender, based on received
acks
TCP’s window based flow control is “self-clocking”:
– New segments are sent when outstanding segments are ack’d
2 3 4 5 6 7 8 9 10 11 131 12
Sender’s window
Acks received Not transmitted

Window Based Flow Control 2
Optimum window size:
– W = data rate * RTT = “bandwidth-delay product”
(optimum use of link capacity: “pipe is full”)
What if window size is too large?
 Queuing at intermediate routers (e.g. at wireless access point)
=> increased RTT due to queuing delays
=> potential of packet loss
What if window size is too small?
 Inefficiency: unused link capacity
38 37
3940
33
35
34
36
TCP
sender
TCP
receiverRouter
W = 8 segments (33...40)
packet
dimensions:
rate
transmit
time
size

Packet Loss Detection Based on Timeout
TCP sender starts a timer for a segment (only one segment at a time)
If ack for the timed segment is not received before timer expires,
outstanding data are assumed to be lost and retransmitted
=> go-back-N ARQ
Retransmission timeout (RTO) is calculated dynamically based on
measured RTT:
– RTO = mean RTT + 4 * mean deviation of RTT
• Mean deviation δ = average of |sample – mean| is easier to calculate than
standard deviation (and larger, i.e. more conservative)
– Large variations in the RTT increase the deviation, leading to larger RTO
– RTT is measured as a discrete variable, in multiples of a “tick”:
• 1 tick = 500 ms in many implementations
• smaller tick sizes in more recent implementations
– RTO is at least 2 clock ticks

Exponential Backoff
Double RTO on successive timeouts:
Total time until TCP gives up is up to 9 min
Rationale: allow an intermediate, congested router to recover
Problem: if ack is lost, TCP (sender) just waits for the next timeout
Segment
transmitted
Timeout occurs
before ack received,
segment retransmitted
Timeout interval doubled
T1=RTO T2 = 2 * T1

Packet Loss Detection Based on Dupacks:
Fast Retransmit Mechanism
TCP sender considers timeout as a strong indication that there is a
severe link problem
On the other hand, continuous reception of dupacks indicates that
following segments are delivered, and the link is ok
=> TCP sender assumes that a (single) packet loss has occurred if it
receives three dupacks consecutively
=> Only the (single) missing segment is retransmitted
=> selective-repeat ARQ
Note: 3 dupacks are also generated if a segment is delivered at least
3 places out-of-order
=> Fast retransmit useful only if lower layers deliver packets
“almost ordered” - otherwise, unnecessary fast retransmit

Flow Control by the Sender
Slow Start
Initially, congestion window size (cwnd) = 1 MSS
Increment cwnd by 1 MSS on each new ack
Slow start phase ends when cwnd reaches ssthresh (slow-start
threshold)
=> cwnd grows exponentially with time during slow start (in theory)
– Factor of 1.5 per RTT if every other segment is ack’d
– Factor of 2 per RTT if every segment is ack’d
– In practice: increase is slower because of network delays (see next slide)
Congestion Avoidance
On each new ack, increase cwnd by 1/cwnd segments
=> cwnd grows linearly with time during congestion avoidance (in
theory)
– 1/2 MSS per RTT if every other segment ack’d
– 1 MSS per RTT if every segment ack’d

Slow Start & Congestion Avoidance – Theory
• Theoretical assumption: after sending n segments, n acks arrive
within one RTT
• Note that Slow Start starts slowly, but speeds up quickly
0
2
4
6
8
10
12
14
0 1 2 3 4 5 6 7 8 9
Time / RTT
cwnd(segments)
Slow Start
Congestion
Avoidance
ssthresh
Receiver’s
advertised
window = 12

Slow Start – Reality (Including Network Delay)
• Taking network delay into account, “cwnd increases exponentially” turns into:
– cwnd increases sub-exponentially
– pairs of segments are sent while pipe fills
• Simple example:
– one-way delay = 1 timestep
– data rate = 1 segment/timestep
sending rate > data rate (cwnd > 2)
(timestep 4 onwards)
=> at some point in time there will
be a packet loss, causing TCP
to slow down
Time-
step Sender action cwnd
#segments
sent
#segments
outstanding
#segments
recv'd and
ack'd Receiver action
0 initial values 1 0
send segment 1 1 1
1 1 receive and ack segment 1
2 receive ack 1 2 0
send segments 2 and 3 2 2
3 1 receive and ack segment 2
4 receive ack 2 3 1 1 receive and ack segment 3

Congestion Control after Packet Loss
Packet loss detected by timeout (=> severe link problem):
Retransmit lost segments
Go back to Slow Start:
– Reduce cwnd to initial value of 1 MSS
– Set ssthresh to half of window size before packet loss:
• ssthresh = max((min(cwnd, receiver’s advertised window)/2), 2 MSS)
Packet loss detected by ≥3 dupacks (=> single packet loss, but link is ok):
Fast Retransmit single missing segment
Initiate Fast Recovery:
– Set ssthresh and cwnd to half of window size before packet loss:
• ssthresh = max((min(cwnd, receiver’s advertised window)/2), 2 MSS)
• cwnd = ssthresh + number of dupacks
– When a new ack arrives: continue with Congestion Avoidance:
• cwnd = ssthresh

Packet Loss Detected by Timeout
0
5
10
15
20
250
3
6
9
12
15
20
22
25
Time / RTT
cwnd(segments)
ssthresh = 8
ssthresh = 10
cwnd = 20
Timeout
cwnd = 1

Packet Loss Detected by ≥3 Dupacks
• After fast retransmit and fast recovery window size is reduced in half
• Multiple packet losses within one RTT can result in timeout
0
2
4
6
8
10
0 2 4 6 10 12 14
Time / RTT
cwnd(segments)
After Fast Recovery
ssthresh = 4
≥3 Dupacks
cwnd = 8
cwnd = 4

Influence of wireless transmission on TCP
• TCP assumes congestion if packets are dropped
– typically wrong in wireless networks, here we often have packet loss
due to transmission errors
– furthermore, mobility itself can cause packet loss, if e.g. a mobile
node roams from one access point (e.g. foreign agent in Mobile IP) to
another while there are still packets in transit to the wrong access
point and forwarding is not possible
• The performance of an unchanged TCP degrades severely
– however, TCP cannot be changed fundamentally due to the large
base of installations in the fixed network, TCP for mobility has to
remain compatible
– TCP on server does not know whether peers are mobile or not
– the basic TCP mechanisms keep the whole Internet together

Indirect TCP – Principle
• Indirect TCP (I-TCP) segments the connection
– no changes to the TCP protocol for hosts connected to the wired
Internet, millions of computers use (variants of) this protocol
– optimized TCP protocol for mobile hosts
– splitting of the TCP connection at, e.g., the foreign agent into 2 TCP
connections, no real end-to-end connection any longer
– hosts in the fixed part of the net do not notice the characteristics of
the wireless part
mobile host
access point
(foreign agent) „wired“ Internet
„wireless“ TCP standard TCP

Indirect TCP – Socket and state migration due to handover
mobile host
access point2
Internet
access point1
socket migration
and state transfer
A handover between access points requires the migration of the TCP sockets
and the TCP state (buffers, etc.)!

Indirect TCP – Discussion
• Advantages
– no changes in the fixed network necessary, no changes for the hosts
(TCP protocol) necessary, all current optimizations to TCP still work
– transmission errors on the wireless link do not propagate into the fixed
network
– simple to control, mobile TCP is used only for one hop between, e.g., a
foreign agent and mobile host
– therefore, a very fast retransmission of packets is possible, the short
delay on the mobile hop is known
• Disadvantages
– loss of end-to-end semantics, an acknowledgement to a sender does
now not any longer mean that a receiver really got a packet, e.g.
wireless link may drop or foreign agent might crash
– higher latency possible due to buffering of data within the foreign agent
and forwarding to a new foreign agent
– access point needs to be involved in security mechanisms (e.g. IPsec)

Snooping TCP – Principle
• „Transparent“ extension of TCP within the foreign agent
– buffering of packets sent to the mobile host
– lost packets on the wireless link (both directions!) will be retransmitted
immediately by the mobile host or foreign agent, respectively (so
called “local” retransmission)
– the foreign agent therefore “snoops” the packet flow and recognizes
acknowledgements in both directions, it also filters ACKs
– changes of TCP only within the foreign agent
„wired“ Internet
buffering of data
end-to-end TCP connection
local retransmission correspondent
hostforeign
agent
mobile
host
snooping of ACKs

Snooping TCP
• Data transfer to the mobile host (downlink)
– FA buffers data until it receives ACK from the MH
– FA detects packet loss on wireless link via timeouts (smaller timeout
value than on CN) or DUPACKs from CN (which are discarded)
– FA employs fast retransmission, transparent for the fixed network
• Data transfer from the mobile host (uplink)
– FA detects packet loss on the wireless link via sequence numbers, FA
answers directly with a NACK to the MH
– MH can now retransmit data with only a very short delay
• Integration of the link layer
– link layer often has similar mechanisms to those of TCP
• Problems
– snooping TCP does not isolate the wireless link as good as I-TCP
– snooping might be useless depending on encryption schemes, e.g.
does not work with IPsec due to encryption of IP payload (including
TCP segment number)

Mobile TCP
• Special handling of lengthy and/or frequent disconnections
• M-TCP splits control as I-TCP does
– unmodified TCP fixed network to supervisory host (SH)
– optimized TCP between SH and MH (no slow start)
• Supervisory host (SH)
– no caching, no retransmission (different from Indirect-TCP)
– monitors all packets, if disconnection detected
• set sender window size to 0
• sender automatically goes into persistent mode
– old or new SH reopens the window (set to old size)
• Advantages
– maintains semantics, supports disconnection, no buffer forwarding
• Disadvantages
– loss on wireless link propagated into fixed network (no buffering)
– adapted TCP on wireless link

Transmission/timeout freezing
• Mobile hosts can be disconnected for a longer time
– no packet exchange possible, e.g.,
 discontinued communication in a tunnel
 disconnection due to overloaded cells
 preemption by higher priority traffic (scheduling)
– TCP disconnects after time-out completely
• TCP freezing
– PHY/MAC layer is often able to detect interruption in advance
– PHY/MAC can inform TCP layer of upcoming loss of connection
– TCP stops sending, but does now not assume a congested link
– PHY/MAC layer signals again if reconnected
• Advantage: scheme is independent of data
• Disadvantage:
– TCP on mobile host has to be changed
– mechanism depends on lower layers

Forced fast retransmit/fast recovery
• Change of foreign agent often results in packet loss
– TCP reacts with slow-start although there is no congestion
• Forced fast retransmit
– as soon as the mobile host has registered with a new foreign agent
(Mobile IP), the MH sends DUPACKs on purpose
– this forces the fast retransmit mode at the communication partners
(instead of slow start)
– additionally, the TCP on the MH is forced to continue sending with the
actual window size and not to go into slow-start after registration
• Advantage
– simple changes result in significant higher performance
• Disadvantage
– focus on problems due to (fast) handover, not on temporarily poor
wireless link quality
– mix of Mobile IP and TCP, no transparent approach

Selective retransmission
• TCP acknowledgements are often cumulative
– ACK n acknowledges correct and in-sequence receipt of packets up
to n
– if single packets are missing quite often a whole packet sequence
beginning at the gap has to be retransmitted (go-back-n), thus
wasting bandwidth
• Selective retransmission as one solution
– RFC2018 allows for acknowledgements of single packets, not only
acknowledgements of in-sequence packet streams without gaps
– sender can now retransmit only the missing packets
– mechanism is supported by newer TCP implementations
• Advantage
– much higher efficiency
• Disadvantage
– more complex software in a receiver, more buffers needed at the
receiver

Comparison of different approaches for a “mobile” TCP

Summary: TCP
TCP provides a connection-oriented,
reliable byte-stream service:
– application data stream is transferred in segments based on
lower layer MTU
– receiver sends back cumulative acknowledgements (acks)
– sliding window mechanism with flow control based on
• receiver’s advertised window,
• sender’s Slow Start (timeout) and Congestion Avoidance
(3 DUPACKs) mechanisms
– Error control & packet loss detection based on
• adaptive retransmission timeout => back to Slow Start,
• duplicate acknowledgments (dupacks) => Fast Retransmit
& Fast Recovery
Pure performance over wireless due to misinterpretation of
DUPACKs and timeouts (loss instead of congestion)

References
• Jochen Schiller: Mobile Communications (German and English), Addison-Wesley,
2005 (chapter 9 provides an overview on different approaches)
• Ramjee Prasad, Marina Ruggieri: Technology Trends in Wireless Communications,
Artech House, 2003
• The bible: W. Richard Stevens, “TCP/IP Illustrated, Volume 1: The Protocols“
• Douglas E. Comer: Computernetzwerke und Internets. 3. Auflage, Pearson
Studium, Prentice Hall, 2002
• Standards (RFCs): http://www.ietf.org/
• Selected papers on TCP over wireless:
– Balakrishnan et al, “A comparison of mechanisms for improving TCP
performance over wireless links”, IEEE/ACM Transactions on Networking,
Dec. 1997
– Xylomenos et al, “TCP performance issues over wireless links”, IEEE
Communications Magazine, April 2001
– Balakrishnan et al, “How network asymmetry affects TCP”, IEEE
Communications Magazine, April 2001

TCP-IP NETWORKING FOR WIRELESS SYSTEMS

More Related Content

What's hot (20)

Similar to TCP-IP NETWORKING FOR WIRELESS SYSTEMS (20)

Recently uploaded (20)

TCP-IP NETWORKING FOR WIRELESS SYSTEMS