Вы находитесь на странице: 1из 43

Wireless Networks and Mobile Computing (COMP


Mobile Transport

Mohammad Reza Pasandideh

Carleton University, Department of SCE , Jan 2009

OSI Model vs. TCP/IP Model
Transport Layer Challenges
TCP/IP Protocol Overview
Slow Start & congestion Avoidance
TCP fast retransmit/fast recovery
TCP sender congestion control
TCP Protocol in Wireless Medium
TCP Improvements
TCP Last-HOP Enhancements
Possible Adaptations
Split Connection (Indirect TCP)
Snooping TCP
Explicit Loss Notification (ELN)
Mobile TCP
Forced Fast retransmit/fast recovery

Link Level Retransmission
Transmission/time-out freezing
Selective retransmission
Transaction oriented TCP
Comparison of different approaches
TCP Improvements
Cross Layer solutions
Seamless Service Continuity
SCTP Protocol
Host Identity Protocol

Optimization of transport layer protocols and their performance has
big impact on data transmission
Optimization and performance improvement of transport layer
protocols, specially TCP is among highly interesting topics among
academic researches.
Several techniques have been proposed and implemented.
Traditional TCP is not suitable for wireless medium.
Joint layer optimization gains more benefits. (Cross Layer Design)
Transport Layer survivability is important issue for a reliable network .
SCTP , SHIM6 and HIP are key solutions for a redundant network.

OSI Model vs. TCP/IP Model

Transport Layer defines three main standard transport


TCP implements a reliable data-stream protocol

(connection oriented)

UDP implements an unreliable data-stream


SCTP implements some new features

-Both connection oriented and connectionless

Transport Layer Challenges

TCP is optimized for wired networks

Packet loss is mostly caused by congestions

Congestion Control and Avoidance

drastic reduction of packet rate and slow start

larger timeout intervals for retransmissions
Assumption is not valid for wireless networks
Much higher packet error rates

packet losses during handovers and disconnections

Bundled packet losses
Necessary reaction:
fast error recovery
no reduction of packet rate
Result in case of un-adapted TCP for wireless networks:
Data rates far below possible data rate

Slow error recovery(high response times)


TCP/IP Protocol Overview

Provides a reliable, in-order abstraction
Recover lost packets and detect/drop duplicates
Detect and drop corrupted packets
Full-duplex: bi-directional data flow in same connection
Flow and congestion control
Flow control: sender will not overwhelm receiver
Congestion control: sender will not overwhelm the network
Sliding window flow control
Send and receive buffers
Congestion control done via adaptive flow control window size
TCP/TP Model defined by IETF in RFC 1122
TCP tries to trade off efficiency and being a Good Network Citizen
Good Network Citizen: Judged by performance, reliability, availability[1]
Vast majority of bytes transferred on Internet today are TCP based:
Web, Mail, Peer-to-peer (Napster, Gnutella, FreeNet, KaZaa)

TCP protocol
Connection Establishment
(3-way handshake)
1) Client sends SYN with initial
sequence number ( ISN = X)
2) Server responds with its own SYN
w/seq number Y and ACK of client
ISN with X+1 (next expected byte)
3) Client ACKs server's ISN with Y+1

TCP/IP, Slow Start

Sender may not only overrun receiver,
but may also overrun intermediate routers:
No way to explicitly know router buffer occupancy,
so infer congestion from packet losses.
Assumption :losses is due to congestion,
i.e. intermediate routers have no available buffers
Sender maintains a congestion window:
Max CW size is un-acknowledged data outstanding.
Successive ACKs from receiver cause CW to grow.
How CW grows based on which of 2 phases:
Slow-start: initial phase, CW exponentially grows
Continue up to threshold
Congestion avoidance: CW steady grows

Slow Start & congestion Avoidance

TCP slow-start algorithm
Sender calculates a congestion window for a
receiver and a congestion threshold (i.e. 65535)
Start with a congestion CW=1 Segment
Exponential increase of the CW up to the
congestion threshold.
Linear increase of the CW after threshold
(Congestion avoidance)
Missing acknowledgement causes the reduction
of the congestion threshold to one half of the
current CW
CW =1 segment

Slow Start & congestion Avoidance

TCP slow-start and Congestion control algorithm
Sender calculates a
congestion window for a
receiver and a congestion
threshold (i.e. 65535)
Start with a congestion CW=1
Exponential increase of the
CW up to the congestion
Linear increase of the CW
after threshold (Congestion
Missing acknowledgement causes the reduction of the congestion
threshold to one half of the current CW (Additive increase, Multiplicative
Set CW =1 segment & Repeat

TCP fast retransmit/fast recovery

TCP fast retransmit/fast recovery
TCP sends an acknowledgement only
after receiving a packet.
If a sender receives triple
acknowledgements for the same
packet, this is due to a gap in received
packets at the receiver however, the
receiver got all packets up to the gap
and is actually receiving packets.
Therefore, packet loss is not due to
congestion. CW and congestion
threshold is set to one half of the current
CW, followed by congestion
avoidance .(Do not use slow-start)


TCP sender congestion control



TCP Sender Action


Slow Start

ACK receipt
for previously
unacked data

CongWin = CongWin + MSS,

If (CongWin > Threshold)
set state to Congestion

Resulting in a doubling of
CongWin every RTT


ACK receipt
for previously
unacked data

CongWin = CongWin+MSS *

Additive increase, resulting

in increase of CongWin by
1 MSS every RTT

SS or CA

Loss event
detected by

Threshold = CongWin/2,
CongWin = Threshold,
Set state to Congestion

Fast recovery, implementing

multiplicative decrease.
CongWin will not drop below
1 MSS.

SS or CA


Threshold = CongWin/2,
CongWin = 1 MSS,
Set state to Slow Start

Enter slow start.

TCP Tahoe

SS or CA


Increment duplicate ACK count

for segment being acked

CongWin and Threshold not


TCP Protocol in Wireless Medium

TCP on wireless works inefficiently!

On wire links, TCP assumes losses if congestion happens.

On wireless links, TCP assumes congestion if packets are

Typically wrong in wireless networks, here we often have packet
loss due to transmission errors.
Furthermore, mobility (i.e. handoff) 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.
However, TCP cannot be changed fundamentally due to the large
base of installation in the fixed network.

TCP for mobility has to remain compatible.


TCP Improvements
It is difficult to create a one size fits all TCP for lasthop wireless networks enhancements upon application

B. Sardar and D. Saha, A survey of TCP Enhancements for

last-hop wireless
networks, IEEE Comm. Surveys and Tutorials, 2006.


TCP Last-HOP Enhancements

Classification of available solutions for last-hop wireless enhancement

B. Sardar and D. Saha, A survey of TCP Enhancements for

last-hop wireless
networks, IEEE Comm. Surveys and Tutorials, 2006.


Possible Adaptations
Where in the path from sender to receiver to solve problem?
Split connection
One TCP connection from wired end to base, another from base to
wireless end
Problem solved locally
But solved at TCP layer (more semantics)
Sender and receiver together addresses problem
They address congestion loss
They should also address medium loss
Link layer addresses problem
Problem occurred in the link and thus should be solved there.


Split Connection (Indirect TCP)

Break a single TCP connection from wired end to wireless end into:
TCP connection from wired end to base station
TCP connection from base station to wireless end
The wireless connection performs all the retransmissions in response to
wireless losses.
Two TCP stacks in the base station.
Hosts in fixed part of network do not notice the characteristics of the wireless

Split Connection (Indirect TCP)

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
Simple to control, mobile TCP is used only for one hop between, e.g., a
foreign agent and mobile host.
A very fast retransmission of packets is possible, the short delay on the
mobile hop is known.
Loss of end-to-end semantics, an acknowledgement to a sender does
now not any longer mean that a receiver really got a packet, foreign
agents might crash
Higher latency possible due to buffering of data within the foreign agent
and forwarding to a new foreign agent


Snooping TCP
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


Snooping TCP (Cont)

Data transfer to the mobile host
FA buffers data until it receives ACK of the MH, FA detects packet loss
via duplicated ACKs or time-out
Fast retransmission possible, transparent for the fixed network
Data transfer from the mobile host
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 MAC layer
MAC layer often has similar mechanisms to those of TCP
thus, the MAC layer can already detect duplicated packets due to
retransmissions and discard them.
Snooping TCP does not isolate the wireless link as good as I-TCP
Snooping might be useless depending on encryption schemes

Explicit Loss Notification (ELN)

This is an end-to-end approach.
Adds an Explicit Loss Notification (ELN) option to TCP acknowledgements.
When packet dropped over wireless, Subsequent acknowledgements
indicate non-congestion related loss occurred.
Upon receiving this information with duplicate acknowledgements, the
sender may perform retransmissions without invoking the associated
congestion-control procedures.
Potential Problems with End-to-End
Un-necessary duplicate acknowledgements sent all the way to source
Un-necessary retransmissions from source to destination


Mobile TCP- Performance

Special handling of lengthy and/or frequent disconnections
M-TCP splits as I-TCP does
The mobile host must discover an interface switch or a handoff and notify the
correspondent host. Then both endpoints are aware that subsequent observed
losses of the data in transit can be attributed to mobility rather than
The sender marks the data that it is in its retransmit queue. A lost packet in this
range triggers retransmission, but not congestion control mechanism.
Upon an interface switch, the sender resets the congestion window, slow start
as though it were initiating a new connection.
maintains semantics, supports disconnection, no buffer forwarding
loss on wireless link propagated into fixed network
adapted TCP on wireless link
Not a good idea for heavy traffic.

Mobile TCP (Cont)

Movement detection & notification
When IP endpoints at MH changes, the changing its address is trapped by the
kernel device control code.
All the sockets that use the affected interface are notified, and a switch
detection routine is invoked.
MH notifies the CH via an option field in the next MTCP packet.
If operating on top of IPv6, MTCP can make use of IPv6 CH notification
mechanism instead of using a special option.
Connection management
MTCP preserves end-to-end semantics by dynamically changing end-point
address for ongoing connections.
Malicious host to hijack an ongoing TCP connection
Authorization mechanism is suggested


Forced Fast retransmit/fast

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, the
MH sends duplicated acknowledgements on purpose
This forces the fast retransmit mode at the communication partners
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
Simple changes result in significant higher performance
Further mix of IP and TCP, no transparent approach


Link Level Retransmission

Handle the problem at the link level, that is where the loss occurred. Local
retransmission instead of end-to-end retransmission
Link-level timer much smaller (~20ms)
TCP timers larger (multiples of 500 ms)
Depends on end-to-end delay
Take advantage of the smaller link-level timer; it can be used to retransmit
several times before the TCP timer goes off.
Such as HSDPA
Potential problems:
Incompatible timers cause retransmission by both parties.
Competing retransmissions by the link and transport layers
often lead to significant performance degradation.
Packets may reach TCP receiver out-of-order.


Transmission/time-out freezing
Mobile hosts can be disconnected for a longer time
No packet exchange possible, e.g., in a tunnel, disconnection due to
overloaded cells or mix with higher priority traffic
TCP disconnects after time-out completely
TCP freezing
MAC layer is often able to detect interruption in advance
MAC can inform TCP layer of upcoming loss of connection
TCP stops sending, but does now not assume a congested link
MAC layer signals again if reconnected
Scheme is independent of data
TCP on mobile host has to be changed, mechanism depends on MAC

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
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
much higher efficiency
more complex software in a receiver, more buffer needed at the receiver


Transaction oriented TCP

TCP phases
Connection setup, data transmission, connection release
Using 3-way-handshake needs 3 packets for setup and release,
Even short messages need a minimum of 7 packets!
Transaction oriented TCP
RFC1644, T-TCP, describes a TCP version to avoid this overhead
connection setup, data transfer and connection release can be combined
Only 2 or 3 packets are needed
Requires changed TCP
Mobility not longer transparent

Comparison of different approaches for a mobile



TCP Improvements
Initial research work
Indirect TCP, Snoop TCP, M-TCP, T/TCP, SACK, Transmission/time-out
TCP over 2.5/3G wireless networks
Learn to live with
Data rates: 64 kbit/s up, 115-384 kbit/s down; asymmetry: 3-6, but
also up to 1000 (broadcast systems), periodic allocation/release of
0.93 * MSS max. TCP BandWidth
RTT * p Max. Segment Size
Round Trip Time
loss probability

High latency, high jitter, packet loss

Fine tuning todays TCP, Suggestions
Large (initial) sending windows, large maximum transfer unit,
selective acknowledgement, explicit congestion notification, time
stamp, no header compression
Already in use
i-mode running over FOMA
WAP 2.0 (TCP with wireless profile)


TCP Improvements, Cross Layer

Cross-Layer approaches violate the traditional layer architecture
-> Creation of new interfaces
-> Merging of adjacent layers
-> Sharing of variables and parameters among multiple layers
Although layered architectures have served well for wired networks,
they are not suitable for wireless networks
Cross-layer design advantages
Exploits the interactions between layers
Promotes adaptability at all layers based
on information exchange between layers
Cross-layer design disadvantages
Hard to characterize the interactions
between protocols at different layers
Joint optimization across layers may
lead to complex algorithms
Potential to destroy modularity

Cross Layer solutions for TCP

Freeze TCP
To implement Freeze-TCP, the network stack needs to be aware of mobility
(at least to some extent). In essence, some cross-layer (layers of the protocol
stack) efforts and information exchange are needed. [3]
TCP_CL for IEEE 802.11 networks
By making slight modifications to the legacy IEEE 802.11 MAC and TCP
protocols, TCP-CL provides a significant improvement in the performance of
TCP in multi-hop wireless environments. [4]
TCP enhancement scheme for OFDM networks
Link recovery scheme combined with Freeze-TCP based on sub-carrier
reallocation and AMC can improve the performance of TCP greatly in OFDM
networks. [5]


Seamless Service Continuity

The 3GPP defines seamless service continuity as a transition between
two wireless networks without user intervention and with minimal service
disruptions (i.e., packet loss, etc.).
This transitioning between wireless networks is what is known as handover.
Requirements for a mobility enabled transport protocol
The transport connection continues while changing the associated IP
address (Multi-homing)
The transport connection automatically switch over to a new IP address
when the used path fails.
IP addresses can be added to or removed from the transport connection
without affecting the established association.


SCTP Protocol
SCTP (Stream Control Transport Protocol) was developed to provide higher
reliability for signaling transport over the Internet.

Key feature of SCTP is the multi-homing capability allowing immediate switchover to a alternative path when anything fails.
Automatic switch-over when a link breaks is exactly the function needed for
Dynamic establishment of new associations (adding new IP addresses ADDIP) allows unlimited mobility.


Load sharing

Policy constraints


A host or a site has several network

connections through:
- Several internet service providers (ISPs)
- Multiple network interfaces
- Multiple internet address

Multi-homing Types
Site Level

Host Level


Multi-homing Problem & Solution


Network connection dynamically changes

Dynamic changes of the IP address will disturb the live
sessions of the transport-layer protocols.
Transport Layer survivability is not supported

Solution should satisfy the following:

During the dynamic changes, the established sessions

should not be disturbed.
Sessions at transport layer should not be aware of routes
changes at the IP layer
Shim6: Site Multi-homing by IPv6 Intermediation
HIP: Host Identity Protocol

Site Multi-homing by IPv6 Intermediation (SHIM6)

Shim6 is a protocol being developed in the

Internet Engineering Task Force (IETF)
Provides a host-based solution to allow IPv6
sites to multi-home for load sharing,
redundancy, and fault tolerance.
Shim6 uses the initial IP address as an
endpoint identity at the transport layer,
and multiple locators at the IP layer to
perform multi-homing.
The protocol includes components for
securely binding locator sets together to
prevent address hijacking

Host Identity Protocol (HIP)

Host Identity Protocol (HIP)

Transport protocols are bound to IP addresses and

disconnect when an address changes.

HIP defines a new global Internet name space.

HIP uses a defined public key at the transport

layer as an endpoint identity, and multiple
locators at the IP layer to perform multi-homing.

With HIP, the transport layer operates on Host

Identities instead of using IP addresses as
endpoint names.

At the same time, the network layer uses IP


Traditional TCP is not optimized for wireless environment
Improvement is required on transport layer protocols, mainly TCP to
achieve higher performance.
End-to-End, Split connection and Link layer solutions investigated.
Versus layers joint optimization gains more benefits.
Cross Layer Design exploit dependency between stack layers to achieve
some performance gains
SCTP is a general purpose reliable transport protocol for the Internet, for
real-time and non real-time traffic.
Multi-homing is achieved by Shim6 and Hip.


1) Why TCP on wireless works inefficiently?
On wireless links, TCP assumes congestion if packets are dropped due to transmission errors.
Furthermore, mobility (i.e. handoff) itself can cause packet loss. For example if 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.

2) List three methods of TCP optimization solutions.

1)Indirect TCP
2)Snooping TCP
4) Fast retransmit/ fast recovery
6) Selective retransmission

3) Mobile-TCP
5) Transmission/ time-out freezing
7)Transaction oriented TCP

3) What is multi-homing? Explain its two famous solutions.

Multi-homing is a technique to increase the reliability of the Internet connection for an IP network.
Multi-homing is generally used to eliminate network connectivity as a potential single point of
failure. Multi-homing can be in site or host level.
Multi-homing solutions:
-Site Multi-homing by IPv6 Intermediation (Shim6) uses the initial IP address as an endpoint
identity at the transport layer, and multiple locators at the IP layer to perform multi-homing.
HIP (Host Identity Protocol) uses a defined public key at the transport layer as an endpoint .identity, and multiple locators at the IP layer to perform multi-homing

[1] Douligeris,N. and N. Serpanos, D., Network Security:
Current Status and Future Directions, John Wiley and Sons,
[2] http://www.jochenschiller.de/
Schiller,J.,Mobile Communications Chapter 9: Mobile
Transport Layer,
[3] Sardar, B. and Saha, D.,A survey of TCP enhancements
for last-hop wireless networks, IEEE Communications
Surveys & Tutorials, Vol. 8, No. 3, 3rd Quarter 2006
[4] Cheng, R. and Lin, H. A cross-layer design for TCP end-toend performance improvement in multi-hop wireless networks
Computer Communications 31 ,31453152, 2008
[5] Jun, W., Xi, F., Quan,C., Min,J., Ping,Z., A cross-layer
wireless TCP enhancement scheme in OFDM network ,
TENCON, 2006