* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Routing in Sensor Networks: Directed Diffusion and other
Point-to-Point Protocol over Ethernet wikipedia , lookup
Airborne Networking wikipedia , lookup
Wireless USB wikipedia , lookup
Distributed firewall wikipedia , lookup
Policies promoting wireless broadband in the United States wikipedia , lookup
Network tap wikipedia , lookup
Wireless security wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Multiprotocol Label Switching wikipedia , lookup
Computer network wikipedia , lookup
Asynchronous Transfer Mode wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Serial digital interface wikipedia , lookup
Wake-on-LAN wikipedia , lookup
Deep packet inspection wikipedia , lookup
UniPro protocol stack wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
TCP over Wireless Links ECE 256 Spring 2009 1 Today’s Discussions Setting up the context (recap) MAC (radios, HTP, antennas, rate/power/CS control), routing Motivating a Transport Layer The e2e argument The basics of flow control and congestion control From wireline to wireless Peek into the large gamut of research in wireless TCP Snoop, ELN, Vegas, Reno, Paris, Hollywood (just kidding !!) Performance over wireless links What’s hot now ? 2 Recall 1: PHY and MAC MAC MAC PHY PHY • Spread Spectrum radios (DS and FH) • • • • • RTS/CTS and Carrier Sensing for Hidden Terminals Directional antennas to reduce interference Rate control to extract max capacity from available SINR Power control for spatial reuse & energy savings – topology control TDMA scheduling, multi-channel use, encryption security … and many more 3 Recall 2: Network Layer Routing Routing Routing Routing Routing • The first view of the network • Coping up with (uncontrolled) user mobility -Flooding the network reactively, or proactive updation • Mobile IP, coping with handoffs, etc. • Ad hoc routing – discovery, optimal metric, maintenance, caching • Secure routing – Routes bypassing malicious nodes 4 We have a route, now what ? TCP TCP NETWORK • Transport packets quickly and reliably over this network • Network properties often unknown (or difficult to track) - Where is the congestion ? How much cross traffic ? - What is the bottleneck bandwidth ? - How much buffers at intermediate nodes ? Motivation for end to end TCP 5 The End to End Argument [Reed,Clark] “The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible.” In other words, as a middle man, don’t attempt to do it, if you cannot do it completely. Let the end point handle it completely !! Caveat: Middle-man involvment OK for performance optimization Question is: Who is the end point ? TCP ? Application layer ? Human user ? … the debate goes on 6 Some transmission methods Stop & Wait Pipelined Go Back N Selective Repeat 7 Stop-and-wait operation sender receiver first packet bit transmitted, t = 0 last packet bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK RTT ACK arrives, send next packet, t = RTT + L / R U = sender L/R RTT + L / R = .008 30.008 = 0.00027 microsec onds 8 Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-to-beacknowledged pkts range of sequence numbers must be increased buffering at sender and/or receiver Two generic forms of pipelined protocols: go-Back-N, selective repeat 9 Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives last packet bit arrives, send ACK last bit of 2nd packet arrives, send ACK last bit of 3rd packet arrives, send ACK RTT ACK arrives, send next packet, t = RTT + L / R Increase utilization by a factor of 3! U sender = 3*L/R RTT + L / R = .024 30.008 = 0.0008 microsecon ds 10 Go-Back-N Sender: k-bit seq # in pkt header “window” of up to N, consecutive unack’ed pkts allowed ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” may receive duplicate ACKs timer for each in-flight pkt timeout(n): retransmit pkt n and all higher seq # pkts in window 11 GBN in action 12 Selective Repeat receiver individually acknowledges all correctly received pkts buffers pkts, as needed, for eventual in-order delivery to upper layer sender only resends pkts for which ACK not received sender timer for each unACKed pkt sender window N consecutive seq #’s again limits seq #s of sent, unACKed pkts 13 Selective Request Makes sense to transmit only the lost packets But this is true under what assumption ? Can you say a case in which Go-BACK-N might be better 14 Selective repeat: sender, receiver windows 15 Selective repeat sender data from above : if next available seq # in window, send pkt timeout(n): resend pkt n, restart timer ACK(n) in [sendbase,sendbase+N]: mark pkt n as received if n smallest unACKed pkt, advance window base to next unACKed seq # receiver pkt n in [rcvbase, rcvbase+N-1] send ACK(n) out-of-order: buffer in-order: deliver (also deliver buffered, in-order pkts), advance window to next notyet-received pkt pkt n in [rcvbase-N,rcvbase-1] ACK(n) otherwise: ignore 16 Selective repeat in action 17 Selective repeat: dilemma Example: seq #’s: 0, 1, 2, 3 window size=3 receiver sees no difference in two scenarios! incorrectly passes duplicate data as new in (a) Q: what relationship between seq # size and window size? What if pkts go out of order 18 TCP 19 TCP Congestion Control Problem Definition How much data should I pump into the network to ensure • Intermediate router queues not filling up • Fairness achieved among multiple TCP flows Why is this problem difficult? TCP cannot have information about the network Only TCP receiver can give some feedbacks 20 The TCP Intuition Pour water Collect water 21 The Control Problem Two main components in TCP Flow Control and Congestion Control Flow Control If receiver’s bucket filling up, pour less water Congestion Control Don’t pour too much if there are leaks in intermediate pipes Regulate your flow based on how much is leaking out • Aggressive pouring calls for retransmission of lost packets • Conservative pouring lower e2e capacity Challenge: At what rate(t) should you pour ? Why ? 22 The TCP Protocol (in a nutshell) T transmits few packets, waits for ACK Called slow start R acknowledges all packet till seq #i by ACK i (optimizations possible) ACK sent out only on receiving a packet Can be Duplicate ACK if expected packet not received ACK reaches T indicator of more capacity T transmits larger burst of packets (self clocking) … so on Burst size increased until packet drops (i.e., DupACK) When T gets DupACK or waits for longer than RTO Assumes congestion reduces burst size (congestion window) 23 TCP Timeline Host B Think of a blind person trying to stand up in a low ceiling room RTT Host A Objective: Don’t bang your head, but stand up quickly time 24 After RTO timeout 25 cwnd = 20 20 15 10 ssthresh = 10 ssthresh = 8 5 25 22 20 15 12 9 6 3 0 0 Congestion window (segments) When waited for > RTO Time (round trips) 25 The TCP Protocol (in a nutshell) DupACK not necessarily indicator of congestion Can happen due to out of order (OOO) delivery of packets If 3 OOO pkts, then CW need not be cut drastically The DupACK packet retransmitted Continue with same pace of transmission as before (fast recovery) R advertizes its receiver window in ACKs Why ? If filling up, T reduces congestion window 26 Fast Recovery on 3 OOO DupACKs Window size (segments) After fast recovery 10 Receiver’s advertized window 8 6 4 2 0 0 2 4 6 8 10 12 14 Time (round trips) 27 TCP Round Trip Time and Timeout EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT Exponential weighted moving average influence of past sample decreases exponentially fast typical value: = 0.125 28 Example RTT estimation: RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350 RTT (milliseconds) 300 250 200 150 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) SampleRTT Estimated RTT 29 TCP Round Trip Time and Timeout Setting the timeout EstimtedRTT plus “safety margin” large variation in EstimatedRTT -> larger safety margin first estimate of how much SampleRTT deviates from EstimatedRTT: DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT| (typically, = 0.25) Then set timeout interval: TimeoutInterval = EstimatedRTT + 4*DevRTT 30 Several flavors of TCP: combines options / optimizations Reno, Vegas, Eifel, Westwood … Overall TCP has worked well – proven on the internet Then why study it again for wireless networks ? 31 The TCP Intuition Pour water Collect water 32 Renewed Challenge Key assumption in TCP A packet loss is indicative of network congestion Source needs to regulate flow by reducing CW Assumption closely true for wired networks BER ~ 10 -6 With wireless, errors due to fading, fluctuations Need not reduce CW in response … But, TCP is e2e CANNOT see the network Thus, TCP cannot classify the cause of loss CHALLENGE 33 The Problem Model TCP connection application application application transport transport transport network network link link link physical physical physical Wireline rxmt network wireless 34 Impact of Misclassification 2.0E+06 Sequence number (bytes) Best possible TCP with no errors (1.30 Mbps) 1.5E+06 TCP Reno (280 Kbps) 1.0E+06 5.0E+05 0.0E+00 0 10 20 30 Time (s) 40 50 60 2 MB wide-area TCP transfer over 2 Mbps WaveLAN 35 The Solution Space Much research on TCP over wireless Difficult to cover complete ground We peek into some of the key ideas Link layer mechanisms Split connection approach TCP-Aware link layer TCP-Unaware approximation of TCP-aware link layer Explicit notification Receiver-based discrimination Sender-based discrimination 36 Link Layer Mechanisms 37 Link Layer Mechanisms Forward error corrections Add redundancy in the packets to correct bit-errors TCP retransmissions can be alleviated Link layer retransmissions MAC layer ACKnowledgments Overhead only when errors occur (unlike FEC) Such mechanisms require no change in TCP Is that breaking e2e argument ?? 38 Issues with Link Layer Mechanisms Link layer cannot guarantee reliability Have to drop packets after some finite limit What is the retransmission limit (??) Retransmission can take quite long Why? Can be significant fraction of RTT TCP can timeout and retransmit the same packet again • Increasing RTO can avoid this • But that impacts TCP’s recovery from congestion Head of the line blocking Link layer has to keep retransmitting even if bad channel Blocks other streams 39 Findings Link layer retransmission good When channel errors infrequent When retransmit time << RTO When modifying TCP is not an acceptable solution 40 Split Connection Approach 41 1 TCP = ½ TCP + ½ (TCP or XXX) Per-TCP connection state TCP connection TCP connection application application transport transport transport network network network link link link physical physical physical Base Station rxmt application wireless 42 Splitting Approaches Indirect TCP [Baker97] Fixed host (FH) to base station (BS) uses TCP BS to mobile host (MH) uses another TCP connection Selective Repeat [Yavatkar94] Over FH to BS: Use TCP Over BS to MH: Use selective repeat on top of UDP No congestion control over wireless [Haas97] Also use less headers over wireless • Header compression 43 Issues with Splitting E2E totally broken 2 separate connections BS maintains hard state for each connection What if MH disconnected from BS ? Huge buffer requirements at BS What if BS fails ? Whats the Problem ? Handoff between BS requires state transfer What if Data and ACK travel on different routes ? BS will not see the ACK at all – splitting not feasible 44 TCP-Aware Link Layer 45 Snoop Link layer at BS buffers un-acknowledged packets Now, BS peeks into every returning TCP ACK from MH If DupACK • Retransmits the necessary packet • Drops the DupACK DupACK does not reach sender Prevents fast retransmit 46 Snoop : Example 35 36 TCP state maintained at link layer 37 38 40 39 38 FH 37 BS 34 MH 36 Example assumes delayed ack - every other packet ack’d 47 Snoop : Example 35 39 36 37 38 41 40 34 39 38 36 48 Snoop : Example 37 40 38 39 42 41 40 36 39 36 dupack Duplicate acks are not delayed 49 Snoop : Example 37 40 38 41 39 43 42 36 41 40 36 36 Duplicate acks 50 Snoop : Example 44 37 40 38 41 39 42 43 FH 37 41 BS Discard dupack MH 36 36 Dupack triggers retransmission 36 of packet 37 from base station BS needs to be TCP-aware to be able to interpret TCP headers 51 Snoop : Example 45 37 40 38 41 39 42 44 43 42 37 36 36 36 36 52 Snoop : Example 46 37 40 43 38 41 44 39 42 45 43 42 36 TCP sender does not fast retransmit 41 36 36 36 53 Snoop : Example 47 37 40 43 38 41 44 39 42 45 46 44 43 41 TCP sender does not fast retransmit 36 36 36 36 54 Snoop : Example 42 45 43 46 44 48 47 45 FH 44 BS 41 MH 43 36 36 36 36 55 Snoop [Balakrishnan95acm] bits/sec 2000000 1600000 1200000 base TCP Snoop 800000 400000 0 no error 256K 128K 64K 32K 16K 1/error rate (in bytes) 2 Mbps Wireless link 56 Issues with Snoop Link layer needs to be TCP aware Smelling cross layer Link layer needs to buffer and perform sliding window Not useful when TCP headers encrypted Not feasible when Data and ACK travel different routes RTT estimates can still go up due to link layer retransmission Affects performance of Snoop 57 Wireless TCP WTCP attempts to nullify RTT estimation problem When data packets are lost due to errors Link layer includes own time stamp in ACK packet ACK packets that have BS time stamps indicate a wireless loss RTT of these packets not considered for RTO calculation • But then, what if wireless hop is also congested !!!!!! • Time stamping cannot take care of that 58 Quick look at other schemes TCP-unaware schemes Explicit notification Receiver-based 59 TCP-Unaware, ELN Delayed DupACKs Receiver waits for sometime before sending DupACK If link retransmission solves problem • Then TCP sender does not send redundant packet Explicit Loss Notification (ELN) BS remembers only packet’s sequence numbers When DupACKs return through them, they check If packet was received by BS, then colors the DupACK Sender realizes that packet lost on wireless link • Does not cut down CW, just retransmits that packet 60 Receiver-Based TCP Receiver estimates cause of packet loss If estimate == wireless loss, sets ELN bit FH FH 12 11 10 BS BS MH T 12 10 MH When is this Mechanism a Big problem ? 11 Congestion loss 2T 12 FH BS 11 Error loss 10 MH 61 Closing Thoughts Reliable and in-order packet delivery important TCP aims to support these features Implements congestion control and flow control TCP widely tuned for wireline networks Proven to be efficient on the internet When network periphery has wireless “last mile” TCP exhibits myriad problems Mainly because of “misclassification between congestion and channel errors” Several solution approaches but many open problems 62 Questions ? 63 QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture. 64 Marathon Presentations 7 candidates 1 Slot on Apr 22 3 slots on Apr 24 3 more candidates: We need to decide on a time. 65 What’s Hot Now ?? TCP over wireless multihop (mesh) Each hop has contention-based MAC • Unpredictable delays and congestion Fairness between TCP e2e flows a very challenging problem Mobility can significantly affect TCP (Very difficult set of open problems) More fundamental: Is TCP the way to go for wireless Strong ongoing debate in community Useful queuing solutions in ad hoc networks Neighborhood RED solution … and many many more … 66 If all that did not make sense, or too heavy for “total recall”, then here is a visual example Thanks to Nitin Vaidya for tutorial slides (Highly recommended for those interested in TCP) 67 Cumulative Acknowledgements A new cumulative acknowledgement is generated only on receipt of a new in-sequence packet 40 39 33 38 34 41 35 40 34 39 35 i 37 data 38 36 i 36 ack 37 68 Delayed Acknowledgements An ack is delayed until another packet is received, or delayed ack timer expires (200 ms typical) Reduces ack traffic 40 39 New ack not produced on receipt of packet 36, but on receipt of 37 38 33 41 37 35 40 39 35 38 37 69 Duplicate Acknowledgements A dupack is generated whenever an out-of-order segment arrives at the receiver 40 39 38 37 34 42 41 36 40 36 (Above example assumes delayed acks) 39 36 Dupack On receipt of 38 70 Duplicate Acknowledgements Duplicate acks are not delayed Duplicate acks may be generated when a packet is lost, or a packet is delivered out-of-order (OOO) 40 39 37 38 34 41 40 36 39 37 36 36 Dupack On receipt of 38 71 Number of dupacks depends on how much OOO a packet is 40 39 37 34 41 36 New Ack 40 39 34 New Ack 41 40 36 New Ack New Ack 37 36 New Ack 42 38 36 Dupack 39 36 Dupack 38 New Ack 72