Overview of Mobile Computing (1): Issues and Design Guidelines

Problem Space for Mobile Computing Look at: 1.Applications/Services 2.OS issues 3.Middleware (skip): 1.Transcoding Application Layer Middleware and OS Transport Layer Network Layer Link Layer & Below

Issues Mobile Computing 3 Challenges: Diversity, wireless, and mobility o Wireless causes network variations o Mobility causes network disconnection/reconnection o Diversity in portable device types the users are operating Hardware variation: screen size/resolution, color/grayscale bit depth, memory, CPU Software variations: OS types, applications, implementations

Three Key Aspects in Systems Design 1.Does the system work? It is about working solution 2.Does the system work well? It is about performance 3.Does the system work well consistently over an extended period of time? It is about reliability/robustness/resilience

Design Guidelines for Networking Systems & Service Sofware Guideline #1: Keep It Simple, Stupid (KISS)! o The design is simple, but can NOT be simpler Simplifying things is always worth the effort! o “Simple” does not necessarily imply few components/operations/coding, etc. Conceptually simple is the key o The design is simple, but not simplistic Simplistic: overlooked some important aspects o history shows that simple design is the best It is also robust and flexible

Systems Design Guideline Guideline #2: It is all about tradeoff !! o Used together with the guideline of “prioritized goals” o Systems design is not hard science, it is ENGINEERING Engineering is not about correct/wrong, it is about tradeoff! No system is best in all dimensions/aspects! o tradeoff of different goals, resource constraints, different performance metrics, etc.

Warning: Do NOT overly emphasize Performance Optimization! Performance is important, but not all aspects of systems software! Limitations of optimization-driven solution o A system optimized along one dimension may be vulnerable in other dimensions Recent research results from HOT paper from Caltech

Adaptation in Mobile Computing 1.Adaptation via indirection to handle device diversity Proxy based architecture: “client-proxy-service” Internet model: client-server based programming Does it violate “end-to-end argument” principle? 2.Adaptation to handle dynamics Adaptive content delivery Case study: transcoding service for mobile devices

Why proxy ? Advantages for servers: o Servers concentrate on serving high quality content, rather than having to keep multiple versions o Servers do not pay the costs required to do on-demand distillation Advantages for clients: o Low-end clients can rely on the proxy to optimize content from servers designed for high-end clients o Client communicates with a single logical entity— proxy, allowing the client to manage bandwidth at the application level Advantages for both: o Pushing the complexity away from both clients and servers by relocating it into the network infrastructure o value-added services

Proxy based design still fits in “Generalized e2e” principle! network side –Avoid putting application-specific functions in the network core –Push application-specific functions up and out to the edges Application side –Decide where application-level services should be attached

A Few More Useful Tips for Systems Design Heterogeneity is inevitable and must be supported by design o Hardware; application protocols Duplication of the same protocol functionality should be avoided as far as possible All designs must scale Keep the solution simple: choose the simplest solution if possible Modularity is good. Do not wait until a perfect solution is found

More Tips Avoid options and parameters whenever possible. They should be configured/negotiated dynamically rather than manually Be strict when sending, and tolerant when receiving. You may silently drop faulty input when in doubt without returning an error message. Be parsimonious with unsolicited (multicast or broadcast) packets Circular dependencies must be avoided

Name and Address Issues Avoid any design that requires addresses to be hard coded or stored on non-volatile storage User applications should use names rather than addresses in general A single naming structure is used Public names (e.g. DNS names) are in case- independent ASCII. Addresses must be unambiguous Upper layer protocols must be able to identify end-points unambiguously

Implementations Objects should be self describing (including type and size). Other type codes and magic numbers assigned by IANA may be used. Any implementation which does not include all of the required components cannot claim conformance with the standard Designs must be international, with support for localization Prefer unpatented technology

Case Study: Transcoding for mobile computing Client variations along 3 dimensions: o Network variation bandwidth, latency and error behavior o Hardware variation screen size/resolution, color/grayscale bit depth, memory, CPU o Software variation Applications for specific MIME types (PDF, PS, PPT, AVI, etc.) Codecs for specific encodings (H263, JPEG, etc.) Transcoding goals: o Reduce latency experienced by user Reduce image’s color depth, resolution to get smaller file o Provide access to new types of content PDF  text, Speech  text

Transcoding design issues Design issues for adapting to variation: o How: Datatype-specific lossy compression mechanisms: distillation & refinement based on (MIME) type of data o Where: at the content server or at a proxy o When: static or on-demand

Distillation and refinement Main idea: high-level semantic types (MIME types) dictate data-type-specific operations o Images: can discard color info, high-frequency components, or pixel resolution o Video: additionally include frame rate reduction o Formatted text: can discard some formatting information Data-type-specific distillation: highly lossy, data- type-specific compression that preserves most of the semantic content of a data object while adhering to a particular set of constraints Data-type-specific refinement: fetching some parts (possibly all) of a source object at increased quality, possibly the original representation

Choices to handle client variations Server ignores variations: o low-end clients may suffer Server use the most basic types & minimal graphics: o high-end client suffers Servers provide multiple formats: o used today by major websites (ESPN, Amazon, Yahoo) o need to categorize clients into discrete classes Progressive encodings: o typically assume that all parts of the encoded documents are equally important On-demand distillation and refinement: o generate on-the-fly based on client characteristics

An Adaptive-Proxy Based Middleware Design Framework Three-tier model: client – proxy – server A programming model for proxy-based design: TACC o Transformation: distillation, filtering, format conversion, etc. o Aggregation: collect and collate data from various sources o Caching: both original and transformed content o Customization: user-customized service (user profiling, adaptive service to each user’s needs or device characteristics)

Sharing semantics: How to share data among different clients and the system? Traditional transactional database model: ACID (atomicity, consistency, isolation, and durability) o strongest semantics at the highest cost and complexity o No guarantee for availability o Suited for e-commerce transaction, billing users, maintaining user profile info etc. Many users/services prefer availability rather than strong consistency or durability: o Stale data can be temporarily tolerated as long as all copies of data eventually reach consistency after a short time o Soft state: can be used to improve performance o Approximate answers are preferred if delivered quickly compared to exact but slow answer

BASE semantics for transcoding service in mobile computing BASE: basically available, soft state, eventual consistency o Handle partial failures in clusters with less complexity and cost o Trading consistency for simplicity o Trading consistency for availability o Use of soft state to allow each watcher process to detect that its peer is alive (rather than mirroring the peer’s state), be able to restart its peer (rather than take over its peer’s duties)

Adaptive transcoding proxy Web server  transcoding proxy  web browser Proxy architecture: o Content analysis o Adaptive transcoding policies: when and how much to transcode o Transformation modules: text modification, images decode & compress Key design goal: o Improve latency experienced by user at heterogeneous devices o fixed quality or fixed delay