Prof. Dr.-Ing Jochen H.

Schiller
Inst. of Computer Science
Freie Universität Berlin
Germany

Mobile Communications
Chapter 9: Mobile Transport Layer

Motivation, TCP-mechanisms
Classical approaches (Indirect TCP, Snooping TCP, Mobile TCP)
PEPs in general
Additional optimizations (Fast retransmit/recovery, Transmission freezing, Selective
retransmission, Transaction oriented TCP)
TCP for 2.5G/3G wireless

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.1

Transport Layer

E.g. HTTP (used by web services) typically uses TCP

Client Server
- Reliable transport between client and server required TCP SYN

TCP TCP SYN/ACK Connection

- Steam oriented, not transaction oriented setup
- Network friendly: time-out TCP ACK
 congestion
 slow down transmission HTTP request
Data
HTTP response transmission
Well known – TCP guesses quite often wrong in wireless and
mobile networks
- Packet loss due to transmission errors >15 s
- Packet loss due to change of network no data
GPRS: 500ms! Connection
Result release
- Severe performance degradation

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.2

Motivation I
Transport protocols typically designed for
- Fixed end-systems
- Fixed, wired networks

Research activities
- Performance
- Congestion control
- Efficient retransmissions

TCP congestion control

- packet loss in fixed networks typically due to (temporary) overload situations
- router have to discard packets as soon as the buffers are full
- TCP recognizes congestion only indirect via missing acknowledgements, retransmissions unwise, they would
only contribute to the congestion and make it even worse
- slow-start algorithm as reaction

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.3

Motivation II
TCP slow-start algorithm
- sender calculates a congestion window for a receiver
- start with a congestion window size equal to one segment
- exponential increase of the congestion window up to the congestion threshold, then linear increase
- missing acknowledgement causes the reduction of the congestion threshold to one half of the current
congestion window
- congestion window starts again with one segment

TCP fast retransmit/fast recovery

- TCP sends an acknowledgement only after receiving a packet
- if a sender receives several 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, continue with current congestion window (do not use slow-start)

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.4

Influences of mobility on TCP-mechanisms
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 can degrade severely

- however, TCP cannot be changed fundamentally due to the large base of installation in the fixed network, TCP
for mobility has to remain compatible
- the basic TCP mechanisms keep the whole Internet together

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.5

Early approach: Snooping TCP I
“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

local retransmission correspondent

foreign host
agent
„wired“ Internet

snooping of ACKs buffering of data

mobile
host
end-to-end TCP connection

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.9

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

Problems
- snooping TCP does not isolate the wireless link as good as I-TCP
- snooping might be useless depending on encryption schemes

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.10

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, 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

Advantage
- simple changes result in significant higher performance

Disadvantage
- further mix of IP and TCP, no transparent approach

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.12

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 multiplexing 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

Advantage
- scheme is independent of data

Disadvantage
- TCP on mobile host has to be changed, mechanism depends on MAC layer

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.13

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

Advantage
- much higher efficiency

“Disadvantage”
- more complex software in a receiver, more buffer needed at the receiver
- Might be a problem in really tiny devices…

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.14

Comparison of different approaches for a “mobile” TCP
Approach Mechanism Advantages Disadvantages
Indirect TCP splits TCP connection isolation of wireless
loss of TCP semantics,
into two connections link, simple higher latency at
handover
Snooping TCP “snoops” data and transparent for end-to- problematic with
acknowledgements, local end connection, MAC encryption, bad isolation
retransmission integration possible of wireless link
M-TCP splits TCP connection, Maintains end-to-end Bad isolation of wireless
chokes sender via semantics, handles link, processing
window size long term and frequent overhead due to
disconnections bandwidth management
Fast retransmit/ avoids slow-start after simple and efficient mixed layers, not
fast recovery roaming transparent
Transmission/ freezes TCP state at independent of content changes in TCP
time-out freezing disconnect, resumes or encryption, works for required, MAC
after reconnection longer interrupts dependant
Selective retransmit only lost data very efficient slightly more complex
retransmission receiver software, more
buffer needed
Transaction combine connection Efficient for certain changes in TCP
oriented TCP setup/release and data applications required, not transparent
transmission

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.16

TCP Improvements I
0.93 * MSS
Initial research work BW ≤
- Indirect TCP, Snoop TCP, M-TCP, T/TCP, RTT * p
SACK, Transmission/time-out freezing, … • max. TCP BandWidth
• Max. Segment Size
TCP over 2.5/3G wireless networks • Round Trip Time
• loss probability
- Fine tuning of TCP, RFC3481 – best current practice (BCP 71, 2003)
- Learn to live with sometimes
- 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 channels
- High latency, high jitter, packet loss
- Suggestions
- Large (initial) sending windows, large maximum transfer unit, selective acknowledgement, explicit congestion
notification, time stamp, no header compression
- Widespread use in adapted protocol stacks
- “Historical”: i-mode running over FOMA, WAP 2.0 (“TCP with wireless profile”)

Alternative congestion control algorithms

- TCP Vegas (cong. control with focus on packet delay, rather than packet loss)
- TCP Westwood plus (use ACK stream for better setting cong. control), (New) Veno, Santa Cruz, …
Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.17
TCP Improvements II
Performance enhancing proxies (PEP, RFC 3135) Mobile system
- Transport layer
- Local retransmissions and acknowledgements wireless
- Additionally on the application layer
- Content filtering, compression, picture downscaling PEP
- E.g., Internet/WAP gateways
- Web service gateways?
- Big problem: breaks end-to-end semantics
- Disables use of IP security
- Choose between PEP and security! Internet

More open issues

- RFC 3150 / BCP 48 (slow links)
- Recommends header compression, no timestamp
Comm. partner
- RFC 3155 / BCP 50 (links with errors)
- States that explicit congestion notification cannot be used
- In contrast to 2.5G/3G recommendations!

Prof. Dr.-Ing. Jochen H. Schiller www.jochenschiller.de MC - 2018 9.18