Announcements r 10 project groups m Presentation 1129

Announcements r 10 project groups m Presentation: 11/29, 12/4, 12/6 r Paper review starts next class (this Wed. ) m 15 classes to discuss papers m Turn in 11 reviews (1 review per class at most) m Reviews are due at the beginning of class 1

Outline r Finish DSR/AODV/DSDV r TCP performance in wireless networks 2

DSR r Can DSR use routing table instead of source routing? m Why or why not? 3

AODV r Route Requests (RREQ) are forwarded in a manner similar to DSR r When a node re-broadcasts a Route Request, it sets up a reverse path pointing towards the source m AODV assumes symmetric (bi-directional) links r When the intended destination receives a Route Request, it replies by sending a Route Reply r Route Reply travels along the reverse path set-up when Route Request is forwarded 4

Timeouts r A routing table entry maintaining a reverse path is purged after a timeout interval m timeout back should be long enough to allow RREP to come r A routing table entry maintaining a forward path is purged if not used for an active_route_timeout interval m even if the route may actually still be valid 5

Link Failure Reporting r A neighbor of node X is considered active for a routing table entry if the neighbor sent a packet within active_route_timeout interval which was forwarded using that entry r When the next hop link in a routing table entry breaks, all active neighbors are informed r Link failures are propagated by means of Route Error messages, which also update destination sequence numbers 6

Route Error r When node X is unable to forward packet P (from node S to r r node D) on link (X, Y), it generates a RERR message Node X increments the destination sequence number for D cached at node X The incremented sequence number N is included in the RERR When node S receives the RERR, it initiates a new route discovery for D using destination sequence number at least as large as N When node D receives the route request with destination sequence number N, node D will set its sequence number to N, unless it is already larger than N 7

Link Failure Detection r Hello messages: Neighboring nodes periodically exchange hello message r Absence of hello message is used as an indication of link failure r Alternatively, failure to receive several MAC-level acknowledgement may be used as an indication of link failure 8

Why Sequence Numbers in AODV r To avoid using old/broken routes m To determine which route is newer r To prevent formation of loops A m m B C D E Assume that A does not know about failure of link C-D because RERR sent by C is lost Now C performs a route discovery for D. Node A receives the RREQ (say, via path C-E-A) Node A will reply since A knows a route to D via node B Results in a loop (for instance, C-E-A-B-C ) 9

Why Sequence Numbers in AODV A B C D E m Loop C-E-A-B-C 10

Optimization: Expanding Ring Search r Route Requests are initially sent with small Time-to-Live (TTL) field, to limit their propagation m DSR also includes a similar optimization r If no Route Reply is received, then larger TTL tried 11

Summary: AODV r Routes need not be included in packet headers r Nodes maintain routing tables containing entries only for routes that are in active use r At most one next-hop per destination maintained at each node m DSR may maintain several routes for a single destination r Unused routes expire even if topology does not change 12

Destination-Sequenced Distance. Vector (DSDV) [Perkins 94 Sigcomm] r Each node maintains a routing table which stores m next hop towards each destination m a cost metric for the path to each destination m a destination sequence number that is created by the destination itself • Sequence numbers used to avoid formation of loops r Each node periodically forwards the routing table to its neighbors m m Each node increments and appends its sequence number when sending its local routing table This sequence number will be attached to route entries created for this node 13

Destination-Sequenced Distance-Vector (DSDV) r Assume that node X receives routing information from Y about a route to node Z X Y Z r Let S(X) and S(Y) denote the destination sequence number for node Z as stored at node X, and as sent by node Y with its routing table to node X, respectively 14

Destination-Sequenced Distance-Vector (DSDV) r Node X takes the following steps: X m m m Y Z If S(X) > S(Y), then X ignores the routing information received from Y If S(X) = S(Y), and cost of going through Y is smaller than the route known to X, then X sets Y as the next hop to Z If S(X) < S(Y), then X sets Y as the next hop to Z, and S(X) is updated to equal S(Y) 15

Transport Layer 16

Transport services and protocols r provide logical communication network data link physical al ic g lo d en d- en network data link physical po s an tr rt between app processes running on different hosts r transport protocols run in end systems m send side: breaks app messages into segments, passes to network layer m rcv side: reassembles segments into messages, passes to app layer r more than one transport protocol available to apps m Internet: TCP and UDP application transport network data link physical 17

Transport vs. network layer r network layer: logical communication between hosts r transport layer: logical communication between processes m relies on and enhances, network layer services Household analogy: 12 kids sending letters to 12 kids r processes = kids r app messages = letters in envelopes r hosts = houses r transport protocol = Ann and Bill r network-layer protocol = postal service 18

Internet transport-layer protocols r unreliable, unordered delivery: UDP network data link physical po rt r services not available: m delay guarantees m bandwidth guarantees s an m network data link physical tr m congestion control flow control connection setup d en d- m en delivery (TCP) al r reliable, in-order network data link physical ic no-frills extension of “best-effort” IP g lo m application transport network data link physical 19

UDP: User Datagram Protocol r “no frills, ” “bare bones” Internet transport protocol r “best effort” service, UDP segments may be: m lost m delivered out of order to app r connectionless: m no handshaking between UDP sender, receiver m each UDP segment handled independently of others [RFC 768] Why is there a UDP? r no connection establishment (which can add delay) r simple: no connection state at sender, receiver r small segment header r no congestion control: UDP can blast away as fast as desired 20

TCP: Overview r point-to-point: m one sender, one receiver r reliable, in-order byte steam: m no “message boundaries” r pipelined: m TCP congestion and flow control set window size r send & receive buffers RFCs: 793, 1122, 1323, 2018, 2581 r full duplex data: m bi-directional data flow in same connection m MSS: maximum segment size r connection-oriented: m handshaking (exchange of control msgs) init’s sender, receiver state before data exchange r flow controlled: m sender will not overwhelm receiver 21

Reliable Data Transfer Reliable data transfer over a reliable channel r over a channel with error m NACK + ACK r over a channel with error and loss m ACK + timeout 22

Reliable Data Transfer Mechanisms Mechanism Details Checksum Detect bit errors Timer Detect packet loss at sender Sequence number Detect packet loss and duplicates at receiver ACK Inform sender that pkt has been received NACK Inform sender that pkt has not been received correctly Window, pipelining Increase throughput, and adapt to receiver buffer size and network congestion 23

TCP Flow Control r receive side of TCP connection has a receive buffer: flow control sender won’t overflow receiver’s buffer by transmitting too much, too fast r speed-matching service: r app process may be slow at reading from buffer matching the sending rate to the receiving app’s drain rate r Rcvr advertises spare room by including value of Rcv. Window in segments r Sender limits un. ACKed data to Rcv. Window m guarantees receive buffer doesn’t overflow 24

Principles of Congestion Control Congestion: r informally: “too many sources sending too much data too fast for network to handle” r different from flow control r manifestations: m lost packets (buffer overflow at routers) m long delays (queueing in router buffers) r a top-10 problem! 25

Approaches towards congestion control Two broad approaches towards congestion control: End-end congestion control: r no explicit feedback from network r congestion inferred from end-system observed loss, delay r approach taken by TCP Network-assisted congestion control: r routers provide feedback to end systems m single bit indicating congestion (SNA, DECbit, TCP/IP ECN, ATM) m explicit rate sender should send at (XCP) 26

TCP congestion control: additive increase, multiplicative decrease r Approach: increase transmission rate (window size), Saw tooth behavior: probing for bandwidth congestion window size probing for usable bandwidth, until loss occurs m additive increase: increase Cong. Win by 1 MSS every RTT until loss detected m multiplicative decrease: cut Cong. Win in half after loss time 27

TCP Congestion Control: details r sender limits transmission: Last. Byte. Sent-Last. Byte. Acked Cong. Win r Roughly, rate = Cong. Win Bytes/sec RTT r Both Cong. Win and RTT are time-varying How does sender perceive congestion? r loss event = timeout or 3 duplicate acks r TCP sender reduces rate (Cong. Win) after loss event three mechanisms: m m m AIMD slow start conservative after timeout events 28

Summary: TCP Congestion Control r When Cong. Win is below Threshold, sender in slow-start phase, window grows exponentially. r When Cong. Win is above Threshold, sender is in congestion-avoidance phase, window grows linearly. r When a triple duplicate ACK occurs, Threshold set to Cong. Win/2 and Cong. Win set to Threshold. r When timeout occurs, Threshold set to Cong. Win/2 and Cong. Win is set to 1 MSS. 29

TCP in Wireless Networks r Transmission errors m Random errors m Burst errors r Mobility m Infrastructure wireless networks m Wireless ad hoc networks 30

Impacts of Random Errors r Random errors may cause fast retransmit m Fast retransmit results in • retransmission of lost packet • reduction in congestion window m Reducing congestion window in response to errors is unnecessary m Reduction in congestion window reduces the throughput r Random errors may cause timeout m Multiple packet losses in a window can result in timeout when using TCP-Reno (and to a lesser extent when using SACK) 31

Burst Errors May Cause Timeouts r If wireless link remains unavailable for extended duration, a window worth of data may be lost m m passing a truck driving through the tunnel r Timeout results in m Possibly long idle time m Slow start, which reduces congestion window to 1 MSS and reduces ssthresh to 1/2 m Reduction in window and ssthresh in response to errors are unnecessary 32

Various Schemes r Link level mechanisms r Split connection approach r TCP-Aware link layer r TCP-Unaware approximation of TCP-aware link layer r Explicit notification r Receiver-based discrimination r Sender-based discrimination 33

Link Level Schemes Link layer state TCP connection application transport network link physical rxmt network wireless 34

Link Layer Schemes (Cont. ) Ideas r Recover wireless losses using FEC code, retransmission, and/or adapting frame size Characteristics r Hide wireless losses from TCP sender r Link layer modifications needed at both ends of wireless link m TCP need not be modified When is a reliable link layer beneficial to TCP performance? r If it provides almost in-order delivery and r TCP retransmission timeout large enough to tolerate additional delays due to link level retransmits 35

Split Connection Approach Per-TCP connection state TCP connection application transport network link physical rxmt wireless application 36

Split Connection Approach (Cont. ) r Idea m End-to-end TCP connection is broken into one connection on the wired part of route and one over wireless part of the route r Characteristics m Hides transmission errors from sender m Primary responsibility at base station m If specialized transport protocol used on wireless, then wireless host also needs modification 37

Split Connection Approach : Advantages r Local recovery of errors m Faster recovery due to relatively shorter RTT on wireless link r BS-MH connection can be optimized independent of FH-BS connection m Different flow / error control on the two connections r Good performance achievable using appropriate BS -MH protocol m m Standard TCP on BS-MH performs poorly when multiple packet losses occur per window (timeouts can occur on the BS-MH connection, stalling during the timeout interval) Selective acks improve performance for such cases 38

Split Connection Approach : Disadvantages r End-to-end semantics violated m ack may be delivered to sender before data delivered to the receiver m May not be a problem for applications that do not rely on TCP for the end-to-end semantics r May not be useful if data and acks traverse different paths (both do not go through the base station) r Extra copy and storage required at base station 39

TCP-Aware Link Layer 40

Snoop Protocol [Balakrishnan 95 acm] r Retains local recovery of Split Connection approach and link level retransmission schemes r Improves on split connection m end-to-end semantics retained m soft state at base station, instead of hard state 41

Snoop Protocol Per TCP-connection state TCP connection application transport network link physical FH BS rxmt wireless network MH 42

Snoop Protocol r Buffers data packets at the base station BS m to allow link layer retransmission r When dupacks received by BS from MH, retransmit on wireless link, if packet present in buffer r Prevents fast retransmit at TCP sender FH by dropping the dupacks at BS FH BS MH 43

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 44

Snoop : Example 35 39 36 37 38 41 40 34 39 38 36 45

Snoop : Example 37 40 38 39 42 41 40 36 39 36 dupack Duplicate acks are not delayed 46

Snoop : Example 37 40 38 41 39 43 42 36 41 40 36 36 Duplicate acks 47

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 48

Snoop : Example 45 37 40 38 41 39 42 44 43 42 37 36 36 49

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 50

Snoop : Example 47 37 40 43 38 41 44 39 42 45 46 44 43 41 TCP sender does not fast retransmit 36 36 51

Snoop : Example 42 45 43 46 44 48 47 45 FH 44 BS 41 MH 43 36 36 52

Snoop Protocol: Advantages r Snoop prevents fast retransmit from sender despite transmission errors, and out-of-order delivery on the wireless link r Base station retransmits only if it results in at least 3 dupacks r If wireless link level delay-bandwidth product is less than 4 packets, a simple (TCP-unaware) link level retransmission scheme can suffice m Since delay-bandwidth product is small, the retransmission scheme can deliver the lost packet without resulting in 3 dupacks from the TCP receiver 53

Snoop Protocol Characteristics r Hides wireless losses from the sender r Requires modification to only BS (network- centric approach) 54

Snoop Protocol : Advantages r High throughput can be achieved m performance further improved using selective acks r Local recovery from wireless losses r Fast retransmit not triggered at sender despite out-of-order link layer delivery r End-to-end semantics retained r Soft state at base station m loss of the soft state affects performance, but not correctness 55

Snoop Protocol : Disadvantages r Link layer at base station needs to be TCP- aware r Not useful if TCP headers are encrypted (IPsec) r Cannot be used if TCP data and TCP acks traverse different paths (both do not go through the base station) 56

TCP-Unaware Approximation of TCP-Aware Link Layer 57

Delayed Dupacks Protocol [Mehta 98, Vaidya 99] r Attempts to imitate Snoop without making the base station TCP-aware r Snoop implements two features at the base station m m link layer retransmission reducing interference between TCP and link layer retransmissions (by dropping dupacks) r Delayed Dupacks implements the same two features m m at BS : link layer retransmission at MH : reducing interference between TCP and link layer retransmissions (by delaying third and subsequent dupacks) 58

Delayed Dupacks Protocol r TCP receiver delays dupacks (third and subsequent) for interval D, when out-of-order packets received r Dupack delay intended to give link level time to retransmit r Pros m Delayed dupacks can result in recovery from a transmission loss without triggering a response from the TCP sender r Cons m Recovery from congestion losses delayed 59

Various Schemes r r r Link-layer retransmissions Split connection approach TCP-Aware link layer TCP-Unaware approximation of TCP-aware link layer Explicit notification m m ELN: Base station tags dup-ack with ELN if it’s wireless related loss ECN: Router tags packet if it experiences congestion r Receiver-based discrimination m Receiver attempts to guess cause of packet loss m When receiver believes that packet loss is due to errors, it sends a notification to the TCP sender m TCP sender, on receiving the notification, retransmits the lost packet without reducing congestion window r Sender-based discrimination m Sender can attempt to determine cause of a packet loss m If packet loss determined to be due to errors, do not reduce congestion window 60

Summary Schemes Idea Who Characteristics Link layer retx Wireless end points Hide wireless error Split connection Independent optimization of wireless conn. Base station Hide wireless error Snoop Link layer retx + drop dup ACK at base station Base station Hide wireless error + avoid unnecessary cwnd reduction Delayed dup ACK Link layer retx + delay dup ACK at wireless host Base station Wireless host Hide wireless error + avoid unnecessary cwnd reduction 61

Comparison (Cont. ) Schemes Idea Who Characteristics ELN Tag dup ack with ELN if loss occurs at wireless link Base station Avoid unnecessary cwnd reduction Receiver When receiver believes Receiver Avoid that packet loss is due Sender unnecessary to errors, it sends a cwnd reduction notification to the TCP sender Sender When sender believes that packet loss is due to errors, it does not reduce cwnd. Sender Avoid unnecessary cwnd reduction 62

Techniques to Improve TCP Performance in Presence of Mobility 63

Classification r Hide mobility from the TCP sender r Make TCP adaptive to mobility 64

Using Fast Retransmits to Recover from Timeouts during Handoff [Caceres 95] r During the long delay for a handoff to complete, a r r whole window worth of data may be lost After handoff is complete, acks are not received by the TCP sender Sender eventually times out and retransmits If handoff still not complete, another timeout will occur Performance penalty m m Time wasted until timeout occurs Window shrunk after timeout 65

Mitigation Using Fast Retransmit r When MH is the TCP receiver: after handoff is complete, it sends 3 dupacks to the sender m this triggers fast retransmit at the sender m instead of dupacks, a special notification could also be sent r When MH is the TCP sender: invoke fast retransmit after completion of handoff 66

M-TCP [Brown 97] r In the fast retransmit scheme [Caceres 95] m sender starts transmitting soon after handoff m But congestion window shrinks r M-TCP attempts to avoid shrinkage in the congestion window 67

M-TCP Uses TCP Persist Mode r When a new ack is received with receiver’s advertised window = 0, the sender enters persist mode r Sender does not send any data in persist mode m except when persist timer goes off r When a positive window advertisement is received, sender exits persist mode r On exiting persist mode, RTO and cwnd are same as before the persist mode m Reusing the old state is not always appropriate 68

Office hour r Friday 3 -4 pm r No office hour on Monday r By appointment 69

TCP in Mobile Ad Hoc Networks 70

How to Improve Throughput r Network feedback r Inform TCP of route failure by explicit message r Let TCP know when route is repaired m Probing m Explicit notification r Reduces repeated TCP timeouts and backoff 71

Performance Improvement With feedback Actual throughput Without network feedback Ideal throughput 2 m/s speed 72

Impact of Route Caching r Route caching has been suggested as a mechanism to reduce route discovery overhead [Broch 98] r Each node may cache one or more routes to a given destination r When a route from S to D is detected as broken, node S may: m Use another cached route from local cache, or m Obtain a new route using cached route at another node 73

Actual throughput (as fraction of expected throughput) To Cache or Not to Cache Average speed (m/s) 74

Why Performance Degrades With Caching r When a route is broken, route discovery returns a cached route from local cache or from a nearby node r After a time-out, TCP sender transmits a packet on the new route. However, the cached route has also broken after it was cached timeout due to route failure timeout, cached timeout, second cached route is broken route also broken r Another route discovery, and TCP time-out interval r Process repeats until a good route is found 75

Issues: To Cache or Not to Cache r Caching can result in faster route “repair” r Faster does not necessarily mean correct r If incorrect repairs occur often enough, caching performs poorly r Need mechanisms for determining when cached routes are stale 76

Caching and TCP performance r Caching can reduce overhead of route discovery even if cache accuracy is not very high r But if cache accuracy is not high enough, gains in routing overhead may be offset by loss of TCP performance due to multiple time-outs 77

A Comparison of Mechanisms for Improving TCP Performance over Wireless Links Hari Balakrishnan Venkata N. Padmanabhan Srinivasan Seshan Randy H. Katz UC Berkeley 78

What questions would you like to answer when comparing different schemes to improve TCP? 79

Goals r What combination of mechanisms result in best performance? m Link layer approach m TCP variants • TCP-aware vs. TCP-agnostic r How important is it for LL-scheme to be TCP-aware? r How useful is SACK and SMART for dealing with (bursty) lossy links? r Is it important to split TCP to get good performance? 80

Experimental Results r Modifications of TCP Reno r IBM Thinkpads and Pentium PCs r 10 mbps Ethernet links r 1. 5 mbps max th’put , 1. 35 mbps wide area th’put r 1400 bytes TCP data size 81

Experimental Results r Performance of LL protocols 82

Experimental Results r Congestion Window size comparisons 83

Experimental Results r Different transport layer schemes 84

Experimental Results n. Performance of Split Connection Protocols 85

Experimental Results r Benefits of SACKs 86

Lessons r TCP-aware link layer is better than link layer approach alone m TCP-aware link-layer protocol with SACK performs the best r Split connection is not necessary for good performance r SACK is effective especially for bursty losses r End-to-end schemes (e. g. , ELN, SACK) are useful 87