1 Mobile Communications, ETB018, BTH ❒ ❒ Mobile transport layer Mobile 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”) ❒ ❒ Subjects Subjects ❍ 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 layer Part 8: Mobile transport layer End-to-end Internet Transport layer Network layer (IP) appl. appl. appl. (ports) Apps multiplex./ demultiplex
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1Mobile Communications, ETB018, BTH
❒❒ Mobile transport layerMobile transport layer❍ “how to support mobility in Transport-layer”❍ apps relies on transport-layer protocols (TCP, UDP,…)
❍ 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)
❍ 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
❍ 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)
❍ 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,…)
❍ 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)
❍ 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
❍ 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
❍ requires modifications in both sender/receiver protocol-software• additional buffer space, sorting-algorithms,…• (CPU performance, power consumption,…)
❍ 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