Addressing Data Compatibility on
Programmable Network Platforms
Ada Gavrilovska, Karsten SchwanCollege of Computing
Georgia Tech
AirportLAN
AirportLAN
AirportLAN
AirportLAN
Cluster ComputingReal Time
Information Processing
Cluster ComputingReal Time
Information Processing
Simulation Optimization
Baggage Status
OperationalFlight Displays
Baggage Displays
Crew andEquipmentStatus
FAA FlightData
Passenger paging andresponse
GateReaders
Wide-areaTransport
High Performance ComputingReal-time Decision Tools
Scalable Robust Services
Storage
capture, display, transport, filter, transform
Delta AirLines: An Operational I nf ormation System
Real-Time Information Transport
Visualization
Recovery and Replay
Real-timeSituation
AssessmentSecurity Systems
EquipmentInspection
AirplaneData Traffic
distributed networked infrastructures
advanced network services:– transformation for interoperability with external partners/heterogeneous clients– data integration from multiple sources– distribution to/specialization for multiple sinks
service quality guarantees
Need for Efficient Data Exchanges
• Data Exchanges:– across distributed components, from heterogeneous
sources to variety of clients– discrepancies among the data representations used by
sources, clients, or intermediate application components
• (e.g., due to natural mismatches or due to dynamic component evolution)
– requirements to route, combine, or otherwise manipulate data as it is being transferred
– efficiency == perceived service quality, honoring performance guarantees (SLAs…)
• expressed in the context of the application
Network-near service execution
• Existing middleware-level approaches enable ‘horizontally’ flexible service deployment solutions:– on nodes along data path
• Our approach: enable ‘vertical’’ flexibility by permitting applications to push service execution closer to the network
• Our assumption: nodes have multiple execution contexts– smart, programmable NICs– dedicated/specialized cores for communication– attached network processors (Intel IXP NPs)
‘In-transit’ Data Transformations
• by default, deliver data to/from application components on general purpose processing context– kernel or application (OS-bypass
capabilities)• enable execution of
middleware-/application-level processing actions jointly with communications– use metadata to describe application
data, processing actions & requirements, platform state…
– offload computational CPU, enable direct data placement of needed data, benefit from specialized hardware…
• configure paths dynamically – application needs, context
capabilities…
Enabling In-Transit Data Morphing
• Represent application-level data– reliable UDP in NP– application meta-data for format description
• Classification– flexible classification based on tag consisting of network and application-level
fields • Handlers
– stream handlers – computational unit applied to application data, can be executed jointly with fast path at well-defined application points
– may be chained -> handler chains• Operations
– support individual data manipulations as well as merging and splitting• Reconfiguration
– modify data path through platform, parameters, or deploy new codes
Execution environment
Meeting application-level quality
• every 3s deliver complete, or at least partial updates– if latency increases, drop immediately remainder of data item– e.g., data reformatting…
• under heavy loads, maintain acceptable service-levles for critical data/customers only– discard all other data, deploy specialized `handlers’ for
critical data– e.g., filter + downsample…
• deploy service to processing context better suited for its execution– service implementation and performance profile differs based
on context/resources available – e.g., multicast…
• plus IXP2850 as alternate switch
Physical Testbed
Handler chaining: feasibility and complexity
0
10
20
30
40
50
60
70
80
90
100
1 2 3
Series1
Series2
caterer
blocked seats
Rule Chains
Thr
ough
put (
Mbp
s)
Benefit from specialized hardware
• In transit data morphing– merging data from
multiple clients, distributing subsets of it, reformatting…
– varied merge criteria, performance dominated by merge operation, not occupancy of hash tables in our case
• Other services– data reformatting,
multicast/mirroring, filtering…
– `database-operands’
0
10000
20000
30000
40000
50000
60000
host, 2 ixp, 2 ixp, 3 ixp, 4
Merging handler - location, fan-in
Proc
essi
ng ti
me
(cyc
les)
Benefit from appropriate service placement
• Performance advantage: – offload and overlap communication/computation– deploy specialized actions
Throughput (generic vs. specialized handler)
0
100
200
300
400
500
600
700
800
200 350 495 695 830
Input Stream (Mbps)
Out
put T
hrou
ghpu
t (M
bps)
Generic
Specialized
Conclusions and future work• Programmable networking platforms are suitable for efficient
execution of higher-level services• Select classes of services benefit for parallelism and
specialized hardware components available• Flexible reconfiguration needed to address dynamics in
application interests and operating conditions• Understanding of handler resource requirements, efficient
monitoring of platform resource capability and compiler tools needed
• Currently integrating runtime environment underneath an existing event-based middleware system
• Considering future (heterogeneous) multicore platforms• Other services – e.g., virtualization
• www.cercs.gatech.edu/projects/npg
Query Performance
Scalable Data Distribution (contd.)
• Graphs…