Announcements

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

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

3. DSR • Can DSR use routing table instead of source routing? • Why or why not?

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

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

6. Link Failure Reporting • 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 • When the next hop link in a routing table entry breaks, all activeneighbors are informed • Link failures are propagated by means of Route Error messages, which also update destination sequence numbers

7. Route Error • When node X is unable to forward packet P (from node S to 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

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

9. Why Sequence Numbers in AODV • To avoid using old/broken routes • To determine which route is newer • To prevent formation of loops • 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 ) A B C D E

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

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

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

13. Destination-Sequenced Distance-Vector (DSDV) [Perkins94Sigcomm] • Each node maintains a routing table which stores • next hop towards each destination • a cost metric for the path to each destination • a destination sequence number that is created by the destination itself • Sequence numbers used to avoid formation of loops • Each node periodically forwards the routing table to its neighbors • 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

14. Destination-Sequenced Distance-Vector (DSDV) • Assume that node X receives routing information from Y about a route to node Z • 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 Z X Y

15. Destination-Sequenced Distance-Vector (DSDV) • Node X takes the following steps: • 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) Z X Y

16. Transport Layer

17. provide logical communication between app processes running on different hosts transport protocols run in end systems send side: breaks app messages into segments, passes to network layer rcv side: reassembles segments into messages, passes to app layer more than one transport protocol available to apps Internet: TCP and UDP application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport Transport services and protocols

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

19. unreliable, unordered delivery: UDP no-frills extension of “best-effort” IP reliable, in-order delivery (TCP) congestion control flow control connection setup services not available: delay guarantees bandwidth guarantees application transport network data link physical application transport network data link physical network data link physical network data link physical network data link physical network data link physical network data link physical logical end-end transport Internet transport-layer protocols

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

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

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

23. Reliable Data Transfer Mechanisms

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

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

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

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

28. sender limits transmission: LastByteSent-LastByteAcked  CongWin Roughly, Both CongWin and RTT are time-varying How does sender perceive congestion? loss event = timeout or 3 duplicate acks TCP sender reduces rate (CongWin) after loss event three mechanisms: AIMD slow start conservative after timeout events CongWin rate = Bytes/sec RTT TCP Congestion Control: details

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

30. TCP in Wireless Networks • Transmission errors • Random errors • Burst errors • Mobility • Infrastructure wireless networks • Wireless ad hoc networks

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

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

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

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

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

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

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

38. Split Connection Approach : Advantages • Local recovery of errors • Faster recovery due to relatively shorter RTT on wireless link • BS-MH connection can be optimized independent of FH-BS connection • Different flow / error control on the two connections • Good performanceachievable using appropriate BS-MH protocol • 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

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

40. TCP-Aware Link Layer

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

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

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

44. Snoop : Example 35 TCP state maintained at link layer 36 37 38 40 39 38 37 FH BS MH 34 36 Example assumes delayed ack - every other packet ack’d

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

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

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

48. Snoop : Example 37 40 38 41 39 42 44 43 37 41 FH BS MH 36 36 Discard dupack Dupack triggers retransmission of packet 37 from base station BS needs to be TCP-aware to be able to interpret TCP headers 36

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

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