Transcript Massachusetts Institute of Technology Separating Network Striping Policy from Mechanism Asfandyar Qureshi and John Guttag.

Massachusetts Institute of Technology
Separating Network Striping
Policy from Mechanism
Asfandyar Qureshi
and
John Guttag
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.
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
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)
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
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
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
Network Striping
‘Stripe’ Application Data across Multiple
Network Channels
» Take data units from application and send
them in some order over the channels.
A
M streams
B
N channels
M streams
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
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
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
Network Striping: Scheduling
Different types of Service
(Bandwidth + QoS)
INTERFACES
Different Requirements
(Bandwidth + QoS)
STREAMS
APPLICATION
NETWORK SERVICES
Network Striping: Scheduling
Different types of Service
(Bandwidth + QoS)
INTERFACES
Different Requirements
(Bandwidth + QoS)
STREAMS
APPLICATION
NETWORK SERVICES
Network Striping: Scheduling
Different Requirements
(Bandwidth + QoS)
STREAMS
APPLICATION
HORDE
Different types of Service
(Bandwidth + QoS)
INTERFACES
Middleware
NETWORK SERVICES
Network Striping: Scheduling
Different Requirements
(Bandwidth + QoS)
DATA UNITS
APPLICATION
HORDE
Different types of Service
(Bandwidth + QoS)
TX SLOTS
Middleware
NETWORK SERVICES
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?
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
Horde Middleware: Overview
APPLICATION
HORDE
API
Packet Scheduler
Network Channel Management
O/S NETWORK SERVICES
Horde Middleware: Overview
APPLICATION
HORDE
API
Packet Scheduler
Network Channel Management
O/S NETWORK SERVICES
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]
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]
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
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
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
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
Expressing Objectives
Stream audio1 values an average latency less
than one second:
objective {
context {
stream:foo { stream_id == “audio1” }
}
goal { foo::latency_ave < 1000 }
utility { foo { 100 } }
}
Expressing Objectives
Stream audio1 values an average latency less
than one second:
objective {
context {
stream:foo { stream_id == “audio1” }
}
goal { foo::latency_ave < 1000 }
utility { foo { 100 } }
}
Expressing Objectives
Stream audio1 values an average latency less
than one second:
objective {
context {
stream:foo { stream_id == “audio1” }
}
goal { foo::latency_ave < 1000 }
utility { foo { 100 } }
}
Expressing Objectives
Stream audio1 values an average latency less
than one second:
objective {
context {
stream:foo { stream_id == “audio1” }
}
goal { foo::latency_ave < 1000 }
utility { foo { 100 } }
}
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 } }
}
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
Horde Middleware: Overview
APPLICATION
HORDE
API
Packet Scheduler
Network Channel Management
O/S NETWORK SERVICES
Horde Middleware: Overview
APPLICATION
HORDE
API
Packet Scheduler
Network Channel Management
O/S NETWORK SERVICES
Channel Management
Packet Scheduler
Network Channel Management
O/S NETWORK SERVICES
Congestion Control
» Limits the scheduler’s sending rate
Channel Bandwidth and QoS Estimation
» Prediction (near future)
» Needed to make good scheduling decisions
Channel Managers
Packet Scheduler
M1
M2
MN
O/S NETWORK SERVICES
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
Transmission Slots
For Scheduler, channels are
sources of TxSlots
» Scheduler can abstract away
channel specific idiosyncrasies
Scheduler
S
TxSlots grant TX capabilities
» Scheduler collects slots and
maps data to each slot
Encapsulate expected QoS
» Have fields for expected
latency, loss probability, etc
Mk
O/S
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
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
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