More wireless: Sensor networks and TCP on mobile hosts CSU CS557, Spring 2018 Instructor: Lorenzo De Carli (Slides by Christos Papadopoulos, remixed by Lorenzo De Carli)
Outline Routing in sensor networks directed diffusion - Intanagonwiwat00a Improving Reliable Transport and Handoff Performance in Cellular Networks - Balakrishnan95
Routing in Sensor Networks Directed Diffusion
Remote Sensing remote approach few, large, expensive sensors are far from phenomena they use complex algorithms to factor out noise e.g. satellite-based sensing, radio telescopes problem: SNR decreases rapidly with distance noise limits performance (resolution)
Sensor Arrays LARGE DATA Centralized approach some, cheap(?), dumb sensors - paced close to phenomena collected data is sent to smart, expensive central node(s) for processing Problem: data is continuous time series bandwidth requirements may be high may not be able to use wireless difficult to deploy
Future Wireless Sensor Networks small event Distributed approach Many small, smart, cheap sensors close to phenomena Nodes have limited processing capability Why wireless? Deployment is trivial Enables large numbers of nodes Dense sensing
Future Wireless Sensor Networks small event Challenges For ease of deployment, must also be battery operated Energy management now becomes an important issue Energy cost of communication outweighs other costs in the system Energy required to transmit 1 bit 10m is same as energy for 1000 processor operations How do we overcome this? Process data within the network
Directed Diffusion Users express interest in data (becoming sink) specified by attributes, not IP address Sink sends out interests by default: flooded through network could use attributes for help (geography) could use cached old routes
Directed Diffusion - II Sources reply to interests with data first, send exploratory ( low rate ) data flooded on return paths Sink reinforces a path sets up reinforced path non-exploratory ( high rate ) data only follows reinforced paths
Interest Propagation Initial interest specifies low data rate as exploratory The desired data rate will be achieved by reinforcement After receiving an interest, the node creates state and resends to a subset of its neighbors Flood the interest Direct interest or limit scope using GPS info (if available) Direct interest using route history
Exploratory Data Propagation and Gradient Establishment sensor s first data is exploratory (low-rate data) sent throughout network, establishing gradients map attributes to next hop at each node in network nodes have multiple gradients
Reinforcement sink reinforces some path to get high rate or nonexploratory data each hop propagates reinforcement back to sources which link to reinforce? default: lowest latency alternatives: maximum remaining energy, greedy tree, or node with new events
Negative Reinforcement Should detect and prune unnecessary paths E.g., paths that send duplicate info Negative reinforcement implicit negative reinforcement (just let gradient time out) explicit negative reinforcement
Naming and attributes IP has node address and ports and DNS and URLs needs resource discovery humans use search engines embedded systems use something like Jini (AKA Apache River) directed diffusion uses attribute-based naming sinks subscribe to sensor EQ acoustic; target IS lions; lat GT 100; lat LT 101; long GT 43; long LT 44 sensors publish sensor IS acoustic; target EQ *; lat IS 100.5; long IS 43.05
Filters sink F F F F F F: watch for sensor data type lion and aggregate it filter suppresses duplicate data F F F source additional source F Support app-specific, in-network processing duplicate suppression aggregation collaborative signal processing caching, etc. Mechanism: assume filters are pre-deployed in net match on attributes filter can take any action (send new msgs, suppress messages, etc.)
Differences from Traditional Networking Neighbor-to-neighbor communication (not end-to-end) Localized algorithms no globally unique IDs no explicit global information (routing tables) Data and queries are named independently from their producers In-network processing Application-specific net-wide attributes (like sensor type or latitude/longitude) app-specific data aggregation
Energy Scaling [Intanagonwiwat00a, figure 4a] Good performance even as number of nodes grows Diffusion uses less energy than omniscient multicast ( optimal ) how? duplicate suppression (can t do it in IP) in-network aggregation
Energy Scaling - II So there are really two core ideas to this work: 1.Networking/routing stack specialized for sensor data 2.In network processing/aggregation enabled by network stack #1 produces energy savings by optimizing paths; #2 produces energy savings by performing data aggregation in the network Note that in principle one could implement #2 on top of a traditional IP stack - but would require more effort (no native support for interests, etc.)
In-Network Processing Duplicate suppression is critical to diffusion Shows the importance of appspecific in-net processing [Intanagonwiwat00a, figure 6b]
What have we learned about sensor networks? looking at sensor networks 100s of embedded, unattended, small devices multi-hop communication coordinate communication between sensors and users data-centric communication not end-to-end in-network processing (ex. aggregation) uses application-specific routing (mixes routing layer and application) uses attribute-based names, rather than addresses
Critique Discussion Really, a radically new networking architecture motivated by a new technology Articulates the rationale behind this architecture well In-network processing Routing scheme is complex and difficult to to analyze
Improving Reliable Transport and Handoff Performance in Cellular Networks Hari Balakrishnan, Srinivasan Seshan, Randy Katz; WINET 1(4), December 1995
Problem: TCP Loss Handling in Wireless TCP assumes loss implies congestion TCP s reaction: reduce sending rate Wireless adds losses due to corruption, collision, handoff desired reaction: retransmit lost packets quickly Approach: let base-station help out
Problem #1: TCP losses Fixed Host (FH) Base Station (BS) Mobile Host (MH) Wired link Wireless link Fixed host interprets losses as sign of congestion - unnecessary congestion control! Wireless channel experience losses due to fading, interference, etc.
Problem #2: Handoffs During an handoff, a mobile node moves between different base stations As packets are rerouted, losses and delays may be introduced TCP dislikes both Base Station #1 Base Station #2 Mobile Host (MH) Mobile Host (MH)
Key Ideas Deals with TCP in mobile environments packet loss (corruption) handoff (changing from one base station to another) Snoop to deal with non-congestion-related losses base stations cache TCP segments and quickly retransmit Efficient procedure for low-latency handoff cache TCP segments at nearby base-stations to allow rapid handoff
Alternatives Make TCP distinguish congestion vs. other kinds of loss good idea: done with ECN but done after this work and not widely deployed even today requires changes to FH and MH Split-connection TCP: use one TCP connection BS, another to MH but requires changes to FH, BS, MH Link-layer retx good idea, but must be careful to avoid interactions between linklayer and TCP Also, what about apps that do not care about losses?
Constraints Incremental deployment Solution should not require modifications to fixed hosts If possible, avoid modifying mobile hosts Preserve TCP end-to-end semantics ACK of a packet means it s at the receiver, not the base station
Snoop Overview FH-to-MH: Base Station (BS) snoops passing traffic (data/acks); quickly retx s data FH data Fixed Host (FH) sends data to MH no change to FH code acks BS MH Mobile Host (MH) receives data, sends ACKs as usual MH-to-FH: FH acks data BS MH BS adds SACK support (even if FH doesn t support it)
FH-to-MH Snoop Data Processing Packet in sequence Add to cache and pass on Out of sequence, cached Greater than last acked: pass on Else: generate ACK to fixed host (why not just drop)? Out of sequence, not cached Lost or delayed out-of-order Pass on, and keep information to process dupacks
Snoop ACK Processing New ACK Pass on to FH Clean up cache Duplicate ACK If data not in cache, or sender retransmitted, pass on to FH If in cache, respond immediately Suppress other dupacks
Handoff Support: inspired by mobile IP
Handoff Support General approach: extend mobile IP to multicast pkts to several FA s (base stations, BSes) MH informs BS when it s changing BSes are pre-loaded w/ data, can run snoop and quickly repair losses
Performance - snoop
Performance - handoff 1.4e+07 1.2e+07 Sequence number 1e+07 8e+06 6e+06 4e+06 2e+06 0 0 10 20 30 40 50 60 70 80 90 Time (seconds) Figure 9. Sequence numbers for transfer to mobile host over channel with handoffs every 10 seconds. beacon arrives disable old BS msg sent enable new BS msg sent last pkt from old BS first pkt from new BS 5-25 ms 2-10 ms 0-40 ms Time (ms) 3-20 ms Figure 10. Timing of handoff events
Observations Nice aspects of Snoop: minimal changes to improve performance good backwards compatibility Soft State design preserves TCP semantics implementation