Mobile Tranport Layer

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


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


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 !?)


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


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)


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)


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)


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)


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


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)


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


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


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)


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,


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)


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)


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)


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


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


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


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


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)


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)

Documents

Mobile Tranport Layer