Separating Network Striping Policy from Mechanism

1. Separating Network Striping Policy from Mechanism Asfandyar Qureshi and John Guttag

2. Overview • Horde: Networking Middleware • Provides a simple and robust way for multi-stream applications to communicate over multiple channels with widely varying characteristics. • Key problems addressed: • Allow applications to abstractly influence packet scheduling. • Provide a mechanism that derives the appropriate packet TX schedules.

3. Talk Structure • Motivation and Background • Motivating Application • Public Wireless Networks • Network Striping • WWAN Striping Challenges • Packet Scheduling • Horde Middleware • Services Provided • Objective Driven Scheduling • Channel Management

4. Motivating Application • Mobile Telemedicine (joint with MGH) • Provide advanced remote diagnostics capabilities • Allow doctors to examine patients in-transit • What we want to send • Unidirectional VIDEO (~300 kbit/sec) • Bidirectional AUDIO (~64 kbit/sec) • Low-rate Physiological data (EKG, Heart-rate, etc)

5. Mobile Telemedicine • Communication requirements • Sustained high throughput • Low-latency • Vehicular motion in an urban area • Economics • System must be viable to deploy and operate • Approach • Use COTS components and public carrier wireless communications infrastructure

6. Public Wireless Networks • Wireless Wide-Area Data Networks are ubiquitous in urban Areas • Multiple providers (T-mobile, Verizon, …) • Multiple technologies (GSM/GPRS, CDMA, …) • Providers have overlapping coverage • Network QoS is not great and not stable • Latencies are high and variable • GPRS: mean = 560ms, stdev = 100ms • CDMA: mean = 320ms, stdev = 80ms • Upload bandwidths (moving) are low and variable • GPRS: mean = 20 kbps, stdev = 5 • CDMA: mean = 120 kbps, stdev = 20

7. Public Wireless Networks • Wireless Wide-Area Data Networks are ubiquitous in urban Areas • Multiple providers (T-mobile, Verizon, …) • Multiple technologies (GSM/GPRS, CDMA, …) • Providers have overlapping coverage • Network QoS is not great and not stable • Latencies are high and variable • GPRS: mean = 560ms, stdev = 100ms • CDMA: mean = 320ms, stdev = 80ms • Upload bandwidths (moving) are low and variable • GPRS: mean = 20 kbps, stdev = 5 • CDMA: mean = 120 kbps, stdev = 20

8. Network Striping • ‘Stripe’ Application Data across Multiple Network Channels • Take data units from application and send them in some order over the channels. A B N channels M streams M streams

9. Challenges I: Application • Bandwidth Limited Application • Can send more data than network can accommodate • Different Types of Streams with Dissimilar Needs • Video, Audio, Bulk Data • Different Network QoS Sensitivities • Want applications to be independent of the number and types of channels

10. Challenges II: Networks • Network Channels are Dissimilar • CDMA has 6x the bandwidth of GPRS • Different technologies, many idiosyncrasies • Network QoS Varies in Time • Packet latency stdev’s are ≥80 • Number of Channels Varies • Motion makes this problem worse • Forward Compatibility • Different wireless network technologies will eventually be deployed

11. Horde: Design Goals • A Wireless Striping Middleware • Can be useful to expose aspects of the striping operation to applications • Develop a Powerful Set of Abstractions • Make it easy to build diverse applications • Don’t sacrifice performance • Support a heterogeneous set of unstable wireless channels • Modularity is important

12. Network Striping: Scheduling APPLICATION Different Requirements (Bandwidth + QoS) STREAMS Different types of Service (Bandwidth + QoS) INTERFACES NETWORK SERVICES

13. Network Striping: Scheduling APPLICATION Different Requirements (Bandwidth + QoS) STREAMS Different types of Service (Bandwidth + QoS) INTERFACES NETWORK SERVICES

14. Network Striping: Scheduling APPLICATION Different Requirements (Bandwidth + QoS) STREAMS HORDE Middleware Different types of Service (Bandwidth + QoS) INTERFACES NETWORK SERVICES

15. Network Striping: Scheduling APPLICATION Different Requirements (Bandwidth + QoS) DATA UNITS HORDE Middleware Different types of Service (Bandwidth + QoS) TX SLOTS NETWORK SERVICES

16. Packet Scheduling (simple) • Randomized Round Robin • Stripe four streams with the same throughputs across one CDMA and three GPRS channels • All streams get the same QoS • Should all streams get the same QoS?

17. Packet Scheduling (better) • Objective Driven Scheduling • Packet scheduler incorporates application specific information (Streams 2 and 4 are video streams) • Optimizes the division of the shared network resource based on stream sensitivities

18. Horde Middleware: Overview APPLICATION HORDE API Packet Scheduler Network Channel Management O/S NETWORK SERVICES

19. Horde Middleware: Overview APPLICATION HORDE API Packet Scheduler Network Channel Management O/S NETWORK SERVICES

20. Horde Middleware • Provides a Number of Services • Schedule data streams over channels • Applications can modulate per stream QoS • Applications abstractly influence striping policy • Network channel congestion control • Stream flow control • Initial Implementation • User-space • Event driven API • Similar to Congestion Manager [OSDI ’00]

21. Horde Middleware • Provides a Number of Services • Schedule data streams over channels • Applications can modulate per stream QoS • Applications abstractly influence striping policy • Network channel congestion control • Stream flow control • Initial Implementation • User-space • Event driven API • Similar to Congestion Manager [OSDI ’00]

22. QoS Modulation • Streams have varying QoS sensitivities • QoS is multidimensional • Bandwidth • Latency • Loss and loss correlation • Want to allow applications to express stream QoS sensitivities • Interface must be flexible • Applications must be easy to program

23. Application Utility • UTILITY: When an application sends data, it receives some utility from the consumption of its data at another host • Total value derived from network service, minus cost • Utility can be affected by the type of the data unit (e.g., a video I-frame) or the network-QoS for the data unit • Similar to Microeconomics net consumer utility • Utility Function • We use a notion of an application-specified utility function • This function allows the packet scheduler to abstractly determine application sensitivities • Pick Schedules that Maximize Utility

24. Horde: QoS Objectives • Applications express QoS ‘objectives’ • Objectives define QoS constraints on streams • Each objective defines a QoS goal and how the achievement of that goal adds to, or subtracts from, overall application utility • E.g., an objective for a video stream could express that I-frame ADU’s should have lower loss than P-frame ADU’s

25. Horde: QoS Objectives • Objectives are: • Modular • Correspond to QoS Dimensions • Can refer to such things as expected latency and loss for an ADU or stream • Independent of the number of channels • The number and the nature of active network channels is likely to vary in a mobile application • Expressed using a specification language

26. Expressing Objectives • Streamaudio1 values an average latency less than one second: objective { context { stream:foo { stream_id == “audio1” } } goal { foo::latency_ave < 1000 } utility { foo { 100 } } }

27. Expressing Objectives • Streamaudio1 values an average latency less than one second: objective { context { stream:foo { stream_id == “audio1” } } goal { foo::latency_ave < 1000 } utility { foo { 100 } } }

28. Expressing Objectives • Streamaudio1 values an average latency less than one second: objective { context { stream:foo { stream_id == “audio1” } } goal { foo::latency_ave < 1000 } utility { foo { 100 } } }

29. Expressing Objectives • Streamaudio1 values an average latency less than one second: objective { context { stream:foo { stream_id == “audio1” } } goal { foo::latency_ave < 1000 } utility { foo { 100 } } }

30. Expressing Objectives • I-frames should have lower loss than others: objective { context { adu:foo { (stream_id == “video1”) && (frame_type == “I”) } adu:bar { (stream_id == “video1”) && (frame_type != “I”) } } goal { prob(foo::lost?) < prob(bar::lost?) } utility { foo { 100 } } }

31. Objective Driven Scheduling • Find high expected utility TX schedules • Interpret set of expressed objectives • Search over sub-space of possible TX schedules • For example: a random walk

32. Horde Middleware: Overview APPLICATION HORDE API Packet Scheduler Network Channel Management O/S NETWORK SERVICES

33. Horde Middleware: Overview APPLICATION HORDE API Packet Scheduler Network Channel Management O/S NETWORK SERVICES

34. Channel Management • Congestion Control • Limits the scheduler’s sending rate • Channel Bandwidth and QoS Estimation • Prediction (near future) • Needed to make good scheduling decisions Packet Scheduler Network Channel Management O/S NETWORK SERVICES

35. Channel Managers • A single channel manager instance for each active network interface • Different channel manager implementations for different network types • Example: one implementation to deal with CDMA, one for GPRS, and another one for 802.11 Packet Scheduler M1 M2 MN O/S NETWORK SERVICES

36. Transmission Slots • For Scheduler, channels are sources of TxSlots • Scheduler can abstract away channel specific idiosyncrasies • TxSlots grant TX capabilities • Scheduler collects slots and maps data to each slot • Encapsulate expected QoS • Have fields for expected latency, loss probability, etc Scheduler S Mk O/S

37. Phantom TX Slots • Short-term channel QoS prediction boosts scheduler accuracy • E.g., If a low-latency slot is likely to be available shortly, defer scheduling an urgent packet. • Phantom TxSlots allow scheduler to factor in channel-specific predictions • Phantoms are TxSlots that can’t be used to send data • Phantoms have confidence levels Scheduler S Mk O/S

38. Summary • Goal was to build a flexible network striping middleware for WWANs • Handle both channel and stream heterogeneity • Two key abstractions • Objectives • Allow abstract manipulation of striping policy • Transmission Slots • Decouple scheduler from channel specific idiosyncrasies

39. Conclusions • Using Horde it is possible to express rich objectives • Rich enough for many interesting apps • Maybe richer than needed • Very simple schedulers can produce better schedules than would be produced in the absence of objectives • Objective driven scheduling accounts for different stream QoS sensitivities