mobile tranport layer
DESCRIPTION
unit 5 of Mca Mobile computing studentsTRANSCRIPT
1Mobile Communications, ETB018, BTH
❒❒ Mobile transport layerMobile transport layer❍ “how to support mobility in Transport-layer”❍ apps relies on transport-layer protocols (TCP, UDP,…)
• apps-addresses (ports)• reliable end-to-end trans. (error detection, retransmission,…) • flow-,seq.-, congestion control,…
❍ (Mobile network-layer only provides address/routing mechanisms: “how to find/route packets to mobile node”)
❒❒ SubjectsSubjects❍ Standard TCP❍ TCP enhancements
• Indirect TCP• Snooping TCP• Mobile TCP
❍ Additional enhancements• Fast retransmission/recovery• Transmission freezing, Transaction TCP,…
❍ TCP in 2.5/3G
Part 8: Mobile transport layerPart 8: Mobile transport layer
End-to-end
Internet
Transport layer
Network layer (IP)
appl.appl.appl.
(ports)
Apps multiplex./ demultiplex
2Mobile Communications, ETB018, BTH
TCPTCP--protocol: Basic mechanismsprotocol: Basic mechanisms❒❒ TCP TCP (Transmission control protocol)(Transmission control protocol)
❍ used by several common apps/protocols • Web/HTTP, file transfer/FTP, mail/SMTP,…
❍ state-full protocol• com.-parties exchange info prior to data-transfer • negotiation/set-up procedure (“handshaking”)
– resource reservation, window parameters, seq.-numbers,…❍ stream-oriented
• byte-streams (from apps) divided into distinct TCP-segments ❍ “network friendly”
• mechanisms to slow down senders transfer-rate if network congested
❍ reliable, in-order delivery• CRC, ACKs, retransmission,…(errors, loss,…)• seq.-numbers (duplication control, in-order segments)
❍ TCP in mobile environments (= problems ?!)• most mechanisms assumes fixed/wired networks, stations,…
TCP: Internet’s connection-oriented transport service, offering reliable, in-order, byte-stream data-transfer to apps
3Mobile Communications, ETB018, BTH
TCPTCP--protocol: Congestion controlprotocol: Congestion control❒❒ CongestionCongestion
❍ main cause for packet-losses in fixed/wired networks• (rather than trans.-errors, bugs in switch-soft/hardware,..)
❍ network exposed for more traffic/packets than it can manage • routers may handle short periods of overload (buffering) • long periods often result in buffer-overflow (= packet loss)
❍ upon congestion, sending stations must reduce their transfer-rates• allowing network to recover (routers)
❒❒ TCP congestion controlTCP congestion control❍ sender-TCP detects congestion via missing ACKs (…timeout)
• earlier sent TCP-segment lost (no ACK delivered), ACK lost, or both segment/ACK lost
• (interpreted as congestion by TCP) ❍ TCP initiates slow-start
• stations reduce their transfer-rates (drastically) • co-operation imperative to prevent Internet from collapse
– (several millions of end-stations attached !?)
4Mobile Communications, ETB018, BTH
TCPTCP--protocol: Congestion controlprotocol: Congestion control❒❒ Slow start algorithmSlow start algorithm
❍ sender calculates Congestion-window for receiver• # unAcked segments a sender may have outstanding before
receiving ACK (initial size: 1 segment)
❍ on receiving ACKs, sender increase Cong.-window (exponentially)• Ex: 1 -> 2 -> 4 -> 8 -> 16 ->…
❍ …up to Congestion-threshold (increase turns linear) • Ex: 32 -> 33 -> 34 -> 35 ->…
❍ linear increase continues until:• TCP timeouts (missing ACK) • or receive multiple ACKs
for same segment • (following segment(s) missing)
❍ TCP responds by setting:• Cong.-window = 1 segment• Cong.-threshold = ½ * current value
– (half duration of exp.-increase)
t
(congestion detected)
exp.-increase
linear-increase
congestion threshold
congestion threshold
congestion window size
5Mobile Communications, ETB018, BTH
TCPTCP--protocol: Early enhancementsprotocol: Early enhancements❒❒ Fast retransmit/fast recoveryFast retransmit/fast recovery
❍ enhancements to improve TCP efficiency • avoid repeated slow-start and reduction of Cong.-threshold
❍ on reception of multiple ACKs for same segment, sender concludes: • receiver got all segments up to ACKed segment• receiver stills receives further segments
– (transmission of multiple ACKs for same segment is triggered by other segments arriving out-of-sequence)
❍ sender assumes segment lost due to trans.-errors (not congestion)• no slow-start or reduce of Cong.-threshold
❍ sender retransmit missing segment before timeout, avoiding slow-start• “Fast retransmit”
❍ sender continues with same cong.-window/threshold as earlier• “Fast recovery”
❍ (TCP implementing fast retransmit/fast recovery, only performs slow-start if retransmission-timer timeouts)
6Mobile Communications, ETB018, BTH
TCPTCP--protocol: Packetprotocol: Packet--loss loss ❒❒ PacketPacket--loss in fixed/wired networks loss in fixed/wired networks (causes)(causes)
❍ network congestion (main cause)• temp. overload in one/several node(s) in network path
❍ transmission errors: relative low BER (< 10-9, fiber optics)• (switch hardware/software, links, …pretty reliable)
❒❒ PacketPacket--loss in mobile/wireless network loss in mobile/wireless network (causes)(causes)❍ transmission errors (relative high)
• (BER might be > 10-3, channel impairments)❍ handovers (unsuccessful, delayed)
• Ex: during FA-switch (Mobile IP: FAold -> FAnew) • FAold lacks buffer-space or forwarding-capabilities during switch• (soft handover -> major improvement)
❍ blocking/shadowingtemp. disconnection of radio-channel (movement: user/obstacle)
❍ congestion • overcrowded cells, overloaded HAs, FAs, routers,… • (nodes in both radio-access + fixed infrastructure network)
7Mobile Communications, ETB018, BTH
TCPTCP--protocol: Mobilityprotocol: Mobility❒❒ Standard TCP in mobile/wireless environmentsStandard TCP in mobile/wireless environments
❍ TCP always concludes congestion on missing ACKs• justified in fixed/wired network• …devastating for mobile/wireless networks ?!
❍ slow-start (+ reduction of Cong.-threshold) under wrong assumptions • increased delay and decreasing performance in
already “slow” (radio) connection❍ main problem (standard TCP)
• can’t distinguish between packet losses causes• “narrow-minded” ?!
❍ TCP designed for fixed/wired networks • doing a great job keeping Internet up-and-running• (never “familiarized” with mobile/wireless properties)
❒❒ TCP mobility enhancements TCP mobility enhancements (requirements)(requirements)❍ compatible with standard TCP (huge installation base)❍ not jeopardize TCP’s congestion-control (fixed/wired networks)
8Mobile Communications, ETB018, BTH
TCP enhancements: Indirect TCP TCP enhancements: Indirect TCP ❒❒ Indirect TCP Indirect TCP (I(I--TCP)TCP)
❍ TCP-connection (end-to-end) is segmented into 2 parts• fixed part: fixed host <-> access point (standard TCP)• wireless part: mobile host <-> access point (stand./enhanced TCP)
❍ access point (FA) terminates both TCP-connections• “com.-partner” to both fixed/mobile host• (FA = MN from CN’s perspective,…vice versa)
❍ FA receives, acknowledges, buffers, forwards incoming packets • (on be half of MN, CN)
❍
❍ FA and MN performs “local retransmission” on wireless link• increases overall performance• prevents MN/CN to timeout
mobile host (MN)
access point (FA) Internet
TCP (wireless) TCP (standard)
fixed host (CN)
9Mobile Communications, ETB018, BTH
TCP enhancements: Indirect TCPTCP enhancements: Indirect TCP❒❒ II--TCP: PacketTCP: Packet--delivery delivery
TCPTCP
MN FA CN
packet
ACKpacket
packet
packet
ACK
ACK
ACK
t
10Mobile Communications, ETB018, BTH
TCP enhancements: Indirect TCP TCP enhancements: Indirect TCP ❒❒ ProsPros
❍ no modifications to standard-TCP (fixed part)• minor modifications to TCP (wireless part)• (no influence on TCP behavior in fixed network)
❍ isolate wireless link• segmentation into 2 distinct connections prevents packet-losses
in wireless network to propagate into fixed network• ACKs, retransmissions,… (handled locally)
❍ short delay (MN <-> FA) easily determined for optimizing timeout• (speed up local retransmissions)
❍ optimization in wireless part (header compression, security,…)
❒❒ ConsCons❍ loss of end-to-end semantics (foundation of TCP)
• CN, MN receiving ACKs, only means FA received packets • FA crashes -> 2 loose-ends TCP-connections
❍ FA-handovers (socket/state-switch, buffering, latency, …)❍ security (end-to-end encryption, FA must be a trusted part)
11Mobile Communications, ETB018, BTH
TCP enhancements: Snooping TCPTCP enhancements: Snooping TCP❒❒ Snooping TCPSnooping TCP
❍ buffer packets close to MN to enable fast local retransmission• with no impact on TCP’s “end-to-end” semantics
❍ FA monitors, snoops, buffers packets going in both direction• performs local retransmission upon packet-loss (missing ACKs)
❍ CN -> MN: FA snoops (and buffers) all packets in packet-flow• (packets buffered until snooping of associated ACKs from MN)• packet-loss detected via timeout or duplicated ACKs (from MN)• FA performs local retransmission (prevent CN-timeout)
❍ MN -> CN: FA snoops/scans packets (seq.-number gaps = packet-loss)• if gap detected: FA sends NACK to MN, triggering fast local
retransmission of packet (reordering by TCP in CN)
Internet
buffering of data
end-to-end TCP-connection
local retrans.fixed host
(CN)
Access point (FA)mobile
host (MN)
snooping of ACKs
12Mobile Communications, ETB018, BTH
TCP enhancements: Snooping TCPTCP enhancements: Snooping TCP
(OBS!: slow-start with cumulative ACKs)
MNFACNpacket
ACK
t
packet
ACK
packet
packetACK
ACK
packet packet
timeout (FA) or duplicated ACKs (MN)
fast local retrans.
MN FA CN
ACK
t
packetpacket
ACK
(gap detected)
fast local retrans.
packetpacket
packetpacket
packetpacket
packetpacketNACK
packetpacket
ACKACK
end-to-end TCP-connection end-to-end TCP-connection(packet flow: CN -> MN) (packet flow: MN -> CN)
❒❒ Snooping TCP:Snooping TCP: PacketPacket--delivery delivery
13Mobile Communications, ETB018, BTH
TCP enhancements: Snooping TCPTCP enhancements: Snooping TCP❒❒ ProsPros
❍ TCP’s end-to-end connection/semantics intact (no segmentation)• if FA crashes, standard TCP-connection still exist (CN <-> MN)• (only lacks benefits of snoop + local retrans.)
❍ CN don’t need to be modified (TCP compatible !)• enhancement implemented in FA (some modific. in MN,…NACKs)
❍ no “state-handover” required between FAs (roaming)• packets buffered in FAold are not forwarded to FAnew• relies on CN timeout/retransmission (standard-TCP)
❍ HO between snoop-TCP supported FA and non-supported FA• (…falls back on standard-TCP)
❒❒ ConsCons❍ don’t isolate wireless link (trans.-errors may propagate to CN)
• if to long until FA retransmits successfully, CN timeouts• (FA’s timeout-value to big, long period of “bad” link,…)
❍ enhancements of MN required (…NACKs)❍ security (end-to-end encrypt. -> snoop seq.-number impossible)
14Mobile Communications, ETB018, BTH
TCP: DisconnectionsTCP: Disconnections❒❒ Disconnections Disconnections
❍ common in mobile/wireless networks• Ex: MN temp. loose radio-connection to base • (shadowing/blocking, interference, bad coverage,…)
❍ TCP’s reaction on temp. disconnections: timeout -> retransmission• (implied that disconnect. cause packet-loss)
❍❍ StandardStandard--TCPTCP• retransmission timer (retrans.-interval) doubled for
each unsuccessful retrans.-attempt (up to max. 1 min)• if connection returns, receiver may have to wait up to 1 min
before receiving retransmission (+ slow-start triggered)❍❍ II--TCPTCP
• FA must buffer more and more packets depending on duration of disconnection (-> buffer overflow)
❍❍ Snooping TCPSnooping TCP• MN unable to return ACKs (CN reacts according to standard-TCP)• if CN’s Cong.-window is large at time of disconnect (many
outstanding unACKed-packets), FA’s buffers may overflow,
15Mobile Communications, ETB018, BTH
TCP enhancements: Mobile TCP TCP enhancements: Mobile TCP ❒❒ Mobile TCP Mobile TCP (M(M--TCP)TCP)
❍ focus on lengthy/frequent disconnections❍ goals: prevent triggering of slow-start + reduction of Cong.-threshold
• (on packet-loss due to temp. disconnections)• (+ preserve “end-to-end” semantics and support FA-handovers)
❍ M-TCP segments TCP-connection into 2 parts❍ standard-TCP: CN <-> SH (Supervisory host…~FA)
• SH only forwards packets (no buffering or local retrans.)❍ optimized TCP: SH <-> MN (TCP without slow-start)
• (Bandwidth manager: prevent congestion, “hogging” in wireless)
❍ SH monitors all packets to MN + ACKs returning from MN❍ if no ACK for some time: SH assumes MN disconnected
• SH chokes sender (CN) by setting sender-window = 0 • CN set in “persistent-mode” (performs no timeout/retrans.)
❍ …later, SH (old or new) detects MN-connection again • SH re-opens sender-window to old value • (CN continues to send at same rate as earlier)
16Mobile Communications, ETB018, BTH
TCP enhancements: Mobile TCPTCP enhancements: Mobile TCP❒❒ ProsPros
❍ TCP “end-to-end” connection/semantics intact• SH only performs regular packet monitoring/forwarding
during periods of non-disconnection• SH prevents useless retransmissions, unnecessary slow-starts,…
(during disconnection) by temp. choking sender
❍ simplified handover (between SHs)• no buffering of packets in SH -> no buffers to forward to new SH • lost packets is retransmitted to new SH (using standard-TCP)
❒❒ ConsCons❍ don’t fully isolate wireless link
• only handles packet-losses caused by disconnections • trans.-errors will propagate into network and to CN• (SH don’t provide buffering-/retrans. features)
❍ optimized TCP in wireless part• requires modification to MN’s protocol software• Bandwidth manager (new network entity)
17Mobile Communications, ETB018, BTH
TCP enhancements: Fast retransmit/recoverTCP enhancements: Fast retransmit/recover❒❒ Fast retransmission/recoveryFast retransmission/recovery
❍ early enhancement for preventing slow-start to trigger on losses not caused by congestion
• receiver sends duplicated ACKs to sender • sender responds by (fast) retransmit lost packet(s)
• (using current Cong.-window, threshold,…)❍ focus on handovers (MN moving to new FA)
• HOs introduce delays (…timeouts + slow-start in MN/CN)❍ after MN registered at new FA, MN sends duplicated ACKs to CN
• (forcing CN to enter fast retransmit/recovery mode)
❍ CN retransmits all unACKed packets• (preventing itself from trigger slow-start)
❒❒ ProsPros❍ simple solution (only require modifications to MN)
❒❒ ConsCons❍ only focus on problems regarding HO (not trans.-errors, disconnect,…)❍ efficiency (CN may retransmits packets already delivered)
18Mobile Communications, ETB018, BTH
TCP enhancements: Transmission freezingTCP enhancements: Transmission freezing❒❒ Transmission/timeout freezingTransmission/timeout freezing
❍ focus on long periods of interruptions/disconnections (radio-channel)• Ex: delayed HOs, enter overcrowded cell, long period of
interference, blocking/shadowing,…• (packet-loss + TCP-timeout/disconnect)
❍ uses MAC-protocol’s “early knowledge” about radio-channel problems to inform TCP about causes for packet-loss
• (prevents TCP from assume congestion -> timeout/disconnect)
❍ if MAC (MN, FA) detects radio-disconnection it informs TCP• TCP temp. freezes transmission (+ current Cong.-window, timers)• FA also needs mechanisms to inform CN
– (prevent slow-start, timeout, disconnect)❍ later, MAC detects connectivity again, it informs TCP to resume
❒❒ Pros Pros ❍ improves TCP performance (+ support “end-to-end” encryption)
❒❒ ConsCons❍ lots of modification required in software/protocol of MN, FA, CN
19Mobile Communications, ETB018, BTH
TCP enhancements: Selective retransmissionTCP enhancements: Selective retransmission❒❒ Standard TCP retransmission schema (GoStandard TCP retransmission schema (Go--backback--n)n)
❍ TCP acknowledge in-order packets, using cumulative ACKs• single ACK confirms reception of all packets up to certain packet
❍ if packet-loss, TCP retransmits all unACKed packets in buffer• (lost packet + all outstanding packets)• inefficient to retransmit of already successfully delivered packets
❒❒ Selective retransmission Selective retransmission (selective(selective--repeat)repeat)❍ more efficient retransmission schema❍ single ACK for each packet (not “bulks” of packets)❍ if packet-loss, TCP only retransmits that “selected” packet
• (…saving scarce bandwidth) ❒❒ Pros Pros
❍ improves performance in low-capacity links (≈≈≈≈ wireless links) ❒❒ ConsCons
❍ requires modifications in both sender/receiver protocol-software• additional buffer space, sorting-algorithms,…• (CPU performance, power consumption,…)
20Mobile Communications, ETB018, BTH
TCP enhancements: TransactionTCP enhancements: Transaction--TCPTCP❒❒ TransactionTransaction--oriented TCPoriented TCP
❍ focus on bursty and sparse short-msgs transmissions for apps requiring TCP’s reliability features
❍ standard TCP’s 3 phases: setup -> data transfer -> release• connection setup/release, both use “3-way handshake” • min. 7-8 msgs for sending single data-msg• acceptable for long sessions
in fixed networks• inefficient for short msgs/sessions
in wireless networks❍ T-TCP combines setup-/release msgs
with actual data-transfer• reduce # msgs to min. 3
❒❒ Pros Pros ❍ improves performance (overhead-reduction)
❒❒ ConsCons❍ huge modifications in both sender/receiver software
connectionsetup
data-transmission
connectionrelease
MN CNTCP SYN
TCP SYN/ACKTCP ACK
data msgsACK
TCP FIN
TCP FIN/ACK
TCP ACK
TCP SYN/dataMN CN
TCP ACK/FIN
TCP ACK
21Mobile Communications, ETB018, BTH
TCP enhancements: ComparisonTCP enhancements: Comparison
Approach Mechanism Advantages DisadvantagesIndirect TCP splits TCP connection
into two connectionsisolation of wirelesslink, simple
loss of TCP semantics,higher latency athandover
Snooping TCP “snoops” data andacknowledgements, localretransmission
transparent for end-to-end connection, MACintegration possible
problematic withencryption, bad isolationof wireless link
M-TCP splits TCP connection,chokes sender viawindow size
Maintains end-to-endsemantics, handleslong term and frequentdisconnections
Bad isolation of wirelesslink, processingoverhead due tobandwidth management
Fast retransmit/fast recovery
avoids slow-start afterroaming
simple and efficient mixed layers, nottransparent
Transmission/time-out freezing
freezes TCP state atdisconnect, resumesafter reconnection
independent of contentor encryption, works forlonger interrupts
changes in TCPrequired, MACdependant
Selectiveretransmission
retransmit only lost data very efficient slightly more complexreceiver software, morebuffer needed
Transactionoriented TCP
combine connectionsetup/release and datatransmission
Efficient for certainapplications
changes in TCPrequired, not transparent
22Mobile Communications, ETB018, BTH
TCP for 2.5/3G networksTCP for 2.5/3G networks❒❒ Internet draft Internet draft ((InamuraInamura, 2002), 2002)
❍ profile for optimization of TCP in 2.5G/3G networks• GSM/GPRS, UMTS, cdma 2000,…• (profile already used in I-mode, WAP 2.0,…)
❒❒ 2.5G/3G characteristics 2.5G/3G characteristics (TCP-tuning “point-of-view”)❍ asymmetric (low) bitrates
• 2.5G: 10-20 Kbps (uplink), 20-50 Kbps (downlink)• 3G (initial): 64 Kbps (uplink), 115-384 Kbps (downlink)
❍ latency/delay (high)• coding delay (error correct/detect, voice-coding, interleave,
encryption, compression.,…)• access delay (initial setup, reservation, authentication, HO,…)
❍ jitter/delay variations (high)• temp. shadow/block, interference, packet-switching,…
❍ packet-loss (high)• trans.-errors, HO-failures, congested nodes/cells,…• (link-level retransmission: ARQ improves performance)
23Mobile Communications, ETB018, BTH
TCP for 2.5/3G mobile networksTCP for 2.5/3G mobile networks❒❒ TCP adaptation for 2.5/3G TCP adaptation for 2.5/3G ((InamuraInamura, 2002), 2002)
❍ large windows• large initial sender-window (2-4 packets) would increase overall
performance (especially for short sessions/few packets)❍ large MTU (Message transfer unit)
• larger MTUs -> faster increase of cong.-window (byte-counted)• (segmentation still performed by link-layer, radio-blocks)
❍ selective ACKs• selective-retransmission of lost packets
❍ Explicit congestion notification (ECN)• on receiving packet that experience congestion, receiver informs
sender by setting flag in next data/ACK (…similar to ATM)❍ Timestamp
• included in packets for more accurate calculation/predict of RTT• RTT (Round-trip-time) used by TCP to set timer/timeout values
❍ no header compression• results in bad performance in presence of packet-loss • (strong correlation between consecutive packets)