1 / 69

Interesting Papers from Mobicom ’04

Interesting Papers from Mobicom ’04. Vivek Raghunathan. Mobicom ’04. 27 papers, 3 days Paper distribution 15-16 systems (6-7 experimental) 5-6 theory 3 measurement 3 sensor network I’ll focus on the systems papers in this talk.

amy
Télécharger la présentation

Interesting Papers from Mobicom ’04

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interesting Papers from Mobicom ’04 Vivek Raghunathan

  2. Mobicom ’04 • 27 papers, 3 days • Paper distribution • 15-16 systems (6-7 experimental) • 5-6 theory • 3 measurement • 3 sensor network • I’ll focus on the systems papers in this talk Vivek Raghunathan <raghnthn at uiuc dot edu>

  3. MobiDesk: Mobile Virtual Desktop Computing (Baratto etal, Columbia) • Goal • Use network to decouple user’s desktop computing session from end-user device • All application logic is moved to hosting providers • End-user devices are dumb devices that accept user input and display application output • Desktop session is decoupled from hosting server so that session can be migrated from one server to another Vivek Raghunathan <raghnthn at uiuc dot edu>

  4. MobiDesk: Mobile Virtual Desktop Computing • Benefits • High availability and reliable application services • Persistence and continuity of business logic • Transparent user mobility • On-demand access to application/computational resources • Simple end-user devices may bridge the gap between haves and have-nots Vivek Raghunathan <raghnthn at uiuc dot edu>

  5. MobiDesk: Mobile Virtual Desktop Computing Vivek Raghunathan <raghnthn at uiuc dot edu>

  6. MobiDesk: Mobile Virtual Desktop Computing • Architecture overview • Layer 7 proxy exposes a single entry point to clients • Users access a completely private and mobile environment using a thin-client session viewer • MobiDesk virtualizes three resources • Display • Operating system • Network Vivek Raghunathan <raghnthn at uiuc dot edu>

  7. MobiDesk: Mobile Virtual Desktop Computing • Display virtualization • Virtual display driver intercepts display commands at video hardware layer and instead sends them over the network to a remote client • Allows reuse of higher level display level functionality, as in Xfree86 Vivek Raghunathan <raghnthn at uiuc dot edu>

  8. MobiDesk: Mobile Virtual Desktop Computing • Display virtualization • Client hardware resources are exported to the server and used if possible to reduce latency • Direct video support • Cursor drawing support • Latency reduction techniques • Server push • Display command scheduling • All client state is soft; all session state is stored at the respective session server Vivek Raghunathan <raghnthn at uiuc dot edu>

  9. MobiDesk: Mobile Virtual Desktop Computing • Operating system virtualization • Session can be isolated from system, check-pointed to storage, migrated to another server and transparently restarted • Each session gets its own virtual private namespace • Virtual: all OS resources are accessed through virtual identifiers • Private: only processes within session can see the namespace Vivek Raghunathan <raghnthn at uiuc dot edu>

  10. MobiDesk: Mobile Virtual Desktop Computing • OS virtualization: session virtualization • Virtualization layer associated a virtual name with the OS physical name • Traps all calls to OS and translates names • System call interposition: wrappers around system calls that translate virtual names to physical names and prevent accesses across the session boundary • chroot and file system stacking to provide each session with its own file system namespace Vivek Raghunathan <raghnthn at uiuc dot edu>

  11. MobiDesk: Mobile Virtual Desktop Computing • Network virtualization • Issues • Multiple sessions on the same server may run the same service • Ongoing network connections must be preserved when a session is migrated from one server to another Vivek Raghunathan <raghnthn at uiuc dot edu>

  12. MobiDesk: Mobile Virtual Desktop Computing • Network virtualization • All servers on same subnet • each session gets an IP address from the DHCP server and uses it as an alias on the NIC on the attached server • Gratuitous ARP is used to resolve MAC address change when sessions are migrated • Proxy re-directs traffic to and from aliased addresses corresponding to individual sessions Vivek Raghunathan <raghnthn at uiuc dot edu>

  13. MobiDesk: Mobile Virtual Desktop Computing • Network virtualization • Servers on different subnets • Cannot migrate an aliased address obtained in one subnet to another (INCONSISTENCY) • Solution: use virtual addresses for proxy mapping and map these virtual addresses to physical (aliased) addresses dynamically at the proxy • The aliased address may be reused in old subnet, confusing the proxy (CONFLICT) • Solution: each session is bound to a different virtual NIC at the proxy, and labels in packets are used to identify the virtual NIC to which the session is bound Vivek Raghunathan <raghnthn at uiuc dot edu>

  14. MobiDesk: Mobile Virtual Desktop Computing • Evaluation summary • OS virtualization overhead is negligible except for ioctl and semget/semctl • Network virtualization overhead is negligible • Display performance of MobiDesk is impressive compared to Sunray, Citrix, VNC etc. (full motion video) • All tests run on a high-bandwidth network (even WAN has 100Mbps bandwidth) Vivek Raghunathan <raghnthn at uiuc dot edu>

  15. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks (Adya etal, MSR) • Faults in wireless networks • Connectivity problems (RF holes) • Performance problems (ISM band interference) • Network security (Rogue AP problem) • Authentication problems (missing/expired IEEE 802.1x certificates) Vivek Raghunathan <raghnthn at uiuc dot edu>

  16. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks • Requirements • Clients can run monitoring software • Clients can start an infrastructure network or an ad hoc network of their own (Atheros, Native Wi-Fi) • A central database keeps track of all AP locations • Client and AP density is quite high Vivek Raghunathan <raghnthn at uiuc dot edu>

  17. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks Vivek Raghunathan <raghnthn at uiuc dot edu>

  18. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks • Architecture • Diagnostic Client (DC) • Runs on wireless clients • Monitors RF environment, traffic flow • Helps disconnected client, performance isolation • Diagnostic AP (DAP) • Merge DC data and forward to DS • Offload work from DS • Diagnostic Server (DS) • Diagnose global faults • Detect rogue AP • Locate disconnected client Vivek Raghunathan <raghnthn at uiuc dot edu>

  19. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks • Client Conduit • Mechanism to diagnose a disconnected client using a nearby connected client as a gateway • Could use MultiNet all the time and take the performance hit • Instead use IEEE 802.11 beaconing to detect problem and start MultiNet only when needed Vivek Raghunathan <raghnthn at uiuc dot edu>

  20. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks Vivek Raghunathan <raghnthn at uiuc dot edu>

  21. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks • Client Conduit • DC on D goes promiscuous and scans for a client connected to infrastructure and starts an AP on the same channel • Newly formed AP at D broadcasts beacon SOS_HELP_<num> like a regular AP • On hearing SOS_HELP_<num> beacon, C uses IEEE 802.11 active scanning to send a Probe Request of the form SOS_ACK_<num>: • Stays connected to infrastructure while doing this • Informs D that C has heard the request. • When D hears Probe Request, it stops sending SOS_HELP_<num> beacons and instead sends a Probe Response to C indicating that it would like to use C • D starts an ad hoc network and C uses MultiNet to join it. Vivek Raghunathan <raghnthn at uiuc dot edu>

  22. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks • Locating disconnected clients • If client hears no beacons, it becomes an AP and starts beaconing • Nearby clients measure RSSI of beacons and inform DS • DS uses a two-step procedure: • locates nearby clients using AP location information and RSSI measurements from nearby clients • Locates disconnected client using RSSI from it and location information of nearby client • Location error is around 10-12 meters Vivek Raghunathan <raghnthn at uiuc dot edu>

  23. Architecture and Techniques for Diagnosing Faults in IEEE 802.11 Infrastructure Networks • Performance monitoring • Monitor TCP RTT, loss rate • Isolate wireless from wired • Diagnose wireless network problems • Rogue AP detection • Detect compliant APs • DC uses active scanning to detect all APs Vivek Raghunathan <raghnthn at uiuc dot edu>

  24. VOR Base Stations for Indoor 802.11 Positioning (Badrinath etal, Rutgets) • Borrowed from the presentation at http://www.winlab.rutgers.edu/pub/docs/iab/2004Spring/16_Niculescu_Dragos.pdf Vivek Raghunathan <raghnthn at uiuc dot edu>

  25. VOR Base Stations for Indoor 802.11 Positioning • Existing indoor positioning systems: • Extra infrastructure (Active Badge) • good accuracy • specialized badges/beacons, LOS • Signal strength map (RADAR) • Works with IEEE 802.11 Aps • Centralized database • Have to construct SS map off-line Vivek Raghunathan <raghnthn at uiuc dot edu>

  26. VOR Base Stations for Indoor 802.11 Positioning • RADAR (MSR) • Build SS map by measuring signal strength from each point in the building to five base stations • When a node moves, base stations use measured SS to query the centralized database for the nearest match Vivek Raghunathan <raghnthn at uiuc dot edu>

  27. VOR Base Stations for Indoor 802.11 Positioning • Goals • No SS map • Move complexity to the 802.11 base station • Use • Angles • Ranges • Angles and Ranges Vivek Raghunathan <raghnthn at uiuc dot edu>

  28. VOR Base Stations for Indoor 802.11 Positioning • Idea: from VOR (VHF Omnidirectional Ranging) used for navigation in aircraft Vivek Raghunathan <raghnthn at uiuc dot edu>

  29. VOR Base Stations for Indoor 802.11 Positioning Idea Vivek Raghunathan <raghnthn at uiuc dot edu>

  30. VOR Base Stations for Indoor 802.11 Positioning Experimental setup Vivek Raghunathan <raghnthn at uiuc dot edu>

  31. VOR Base Stations for Indoor 802.11 Positioning Angles only positioning Vivek Raghunathan <raghnthn at uiuc dot edu>

  32. VOR Base Stations for Indoor 802.11 Positioning • Issues with angles only positioning • With multiple peaks: which direction is the peak direction? • 90% of time, it is the strongest or second strongest peak • Use range based trilateration to augment the angles only positioning • Correlate measured SS with distance using limited SS map (unlike RADAR) • Achieves 2.1m – 4m median error, comparable to RADAR Vivek Raghunathan <raghnthn at uiuc dot edu>

  33. Denial of Service Resilience in Ad Hoc Wireless Networks (Hubaux etal, EPFL) • DOS attacks in wireless networks • Jellyfish: protocol compliant, attacks congestion control • Jellyfish Reorder Attack • Jellyfish Periodic Drop Attack • Jellyfish Delay Variance Attack • Black hole attack: not protocol compliant • Both reduce throughput to zero Vivek Raghunathan <raghnthn at uiuc dot edu>

  34. Denial of Service Resilience in Ad Hoc Wireless Networks • Jellyfish Reorder Attack Vivek Raghunathan <raghnthn at uiuc dot edu>

  35. Denial of Service Resilience in Ad Hoc Wireless Networks • Jellyfish Periodic Drop Attack Vivek Raghunathan <raghnthn at uiuc dot edu>

  36. Denial of Service Resilience in Ad Hoc Wireless Networks • DOS increases wireless network capacity! Vivek Raghunathan <raghnthn at uiuc dot edu>

  37. Denial of Service Resilience in Ad Hoc Wireless Networks • Attack detection using neighbor information (Passive ACKs) does not work • Directional antennas • Power control • Need an end-to-end approach • Detect new routes disjoint from bad routes • Use probabilistic routing over multiple paths • Diagnosis timescale of the order of multiple RTTs Vivek Raghunathan <raghnthn at uiuc dot edu>

  38. Denial of Service Resilience in Ad Hoc Wireless Networks • TCP Reorder attack • TCP assumes in-order delivery while IP does not guarantee that • Solutions: • Receiver: delay the DUPACK timer • Sender: wait for a higher number of DUPACKs before triggering congestion control • Maybe we need to do away with congestion control using DUPACKs to detect loss … (modified TCP SACK?) Vivek Raghunathan <raghnthn at uiuc dot edu>

  39. lossy link good link good link Routing in Multi-Radio Multi-Hop Wireless Mesh Networks (Padhye etal, MSR) • Shortest-path is not always the best path (MIT Roofnet) • Link characteristic is not ON-OFF • Links have i.i.d. packet loss • A few HELLO packets get through and the lossy 1-hop path. Vivek Raghunathan <raghnthn at uiuc dot edu>

  40. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • ETX metric for a link = expected number of retransmissions on that link • Successful packet transmission = DATA + ACK • Measure packet loss rate pf, pr using broadcast packets • Then, • ETX = 1/[1 – (1- pf).(1-pr)] • ETX metric for a path = sum of ETX metrics for links along the path Vivek Raghunathan <raghnthn at uiuc dot edu>

  41. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • ETX and multiple radios • ETX does not consider bandwidth while selecting paths, so it will choose 802.11b over 802.11a if the loss rates are the same (longer range 802.11b links). • ETX does not give any preference to “channel-diverse” paths (more on this later) Vivek Raghunathan <raghnthn at uiuc dot edu>

  42. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • Idea: if we use multiple radios at every node, • node can simultaneously transmit and receive • node can simultaneously transmit on multiple channels • “self-interference” in routes can be reduced • can improve robustness to channel variation, noise by using different parts of the spectrum (802.11a/b) Vivek Raghunathan <raghnthn at uiuc dot edu>

  43. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • Model • Stationary nodes with one or more radios tuned to different non-interfering channels • Design goals for a new path metric • Takes bandwidth and loss rates on each link into account • Adding a link to the path does not decrease the path metric • Explicitly accounts for reduction in throughput due to interference among links that operate on the same channel Vivek Raghunathan <raghnthn at uiuc dot edu>

  44. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • Suppose we know ETTi = expected transmission time on a link. • ETTi takes the bandwidth and loss rate on the link into account (Property 1) • Adding a link to the path increases the metric (Property 2) • Does not distinguish between hops on different channels (no Property 3) Vivek Raghunathan <raghnthn at uiuc dot edu>

  45. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • Instead, define for channel j, • Path throughput is dominated by the bottleneck channel, i.e. by max Xj • Consider WCETT = max Xj • As more hops are added, the path metric may stay the same (weak Property 2) • Metric favors channel-diverse paths (Property 3) Vivek Raghunathan <raghnthn at uiuc dot edu>

  46. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • Combine both the metrics using a tunable parameter • ETT = ETX * S/B, where S = size of packet and B = bandwidth of link Vivek Raghunathan <raghnthn at uiuc dot edu>

  47. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • Other issues • How to measure bandwidth if IEEE 802.11 autorate is being used? (packet-pairs) • Broadcasts sent at 1Mbps, so loss rate may not correspond to actual unicast packet loss Vivek Raghunathan <raghnthn at uiuc dot edu>

  48. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • Implementation summary • Implemented on top of LQSR, a link-state source routed protocol • Layer 2 routing: higher layers only see a single virtual device • All higher layer stuff (arp, broadcast) works unmodified Vivek Raghunathan <raghnthn at uiuc dot edu>

  49. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • Evaluation summary • In single radio environments, WCETT provides 15-20% improvement over ETX • In two radio environments, provides a factor of two improvement over ETX • Does well! Vivek Raghunathan <raghnthn at uiuc dot edu>

  50. Routing in Multi-Radio Multi-Hop Wireless Mesh Networks • Open issues • Channel diversity metric merely takes into account number of links on a particular channel, while the position of those links could be significant. • Jointly select channels dynamically + multiple radio routing • WCETT + distance vector Vivek Raghunathan <raghnthn at uiuc dot edu>

More Related