Upload
zachery-sexton
View
213
Download
0
Tags:
Embed Size (px)
Citation preview
GD-Aggregate: A WAN Virtual Topology Building Tool for Hard Real-Time and
Embedded Applications
Qixin Wang*, Xue Liu**, Jennifer Hou*, and Lui Sha*
*Dept. of Computer Science, UIUC
**School of Computer Science, McGill Univ.
Demand
• Big Trend: converge computers with the physical world
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
• Similar traffic aggregation.
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
• Similar traffic aggregation.• Global/local traffic segregation;
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
• Similar traffic aggregation.• Global/local traffic segregation;• Network hierarchy and modularity
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
• Similar traffic aggregation.• Global/local traffic segregation;• Network hierarchy and modularity, which also assists composability,
dependability, debugging etc.
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
• Similar traffic aggregation.• Global/local traffic segregation;• Network hierarchy and modularity;
– Configurability:
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
• Similar traffic aggregation.• Global/local traffic segregation;• Network hierarchy and modularity;
– Configurability: • Runtime behavior regulation
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
• Similar traffic aggregation.• Global/local traffic segregation;• Network hierarchy and modularity;
– Configurability: • Runtime behavior regulation
– Flexibility:
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
• Similar traffic aggregation.• Global/local traffic segregation;• Network hierarchy and modularity;
– Configurability: • Runtime behavior regulation
– Flexibility: • Ease of reconfiguration
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
• Similar traffic aggregation.• Global/local traffic segregation;• Network hierarchy and modularity;
– Configurability: • Runtime behavior regulation
– Flexibility: • Ease of reconfiguration
– Hard Real-Time E2E Delay Guarantee
Demand
• Big Trend: converge computers with the physical world– Cyber-Physical Systems– Real-Time and Embedded (RTE) GENI– Virtual Organization
• Calls for RTE-WAN with following features:– Scalability:
• Similar traffic aggregation.• Global/local traffic segregation;• Network hierarchy and modularity;
– Configurability: • Runtime behavior regulation
– Flexibility: • Ease of reconfiguration
– Hard Real-Time E2E Delay Guarantee
Solution? The Train/Railway Analogy
Solution? The Train/Railway Analogy
• Similar traffic aggregation: carriage train
Solution? The Train/Railway Analogy
• Similar traffic aggregation: carriage train
• Global/local traffic segregation: express vs. local train
Solution? The Train/Railway Analogy
• Similar traffic aggregation: carriage train
• Global/local traffic segregation: express vs. local train• Hierarchical topology: express vs. local train
Solution? The Train/Railway Analogy
• Similar traffic aggregation: carriage train
• Global/local traffic segregation: express vs. local train• Hierarchical topology: express vs. local train• Configuration: routing, capacity planning
Solution? The Train/Railway Analogy
• Similar traffic aggregation: carriage train
• Global/local traffic segregation: express vs. local train• Hierarchical topology: express vs. local train• Configuration: routing, capacity planning• Flexibility: change the train planning, not the railway
The Equivalent of Train in Network?
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
A C B
Legend Aggregate.
End Node Intermediate Node
Member Flow
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
– Sender End Node: merges member flows into the aggregate
A C B
Legend Aggregate.
End Node Intermediate Node
Member Flow
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
– Sender End Node: merges member flows into the aggregate
– Receiver End Node: disintegrates the aggregate into original flows
A C B
Legend Aggregate.
End Node Intermediate Node
Member Flow
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
– Sender End Node: merges member flows into the aggregate
– Receiver End Node: disintegrates the aggregate into original flows
– Intermediate Nodes: only forward the aggregate packets
A C B
Legend Aggregate.
End Node Intermediate Node
Member Flow
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
Legend Aggregate.
End Node Intermediate Node
Member Flow
A C B
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
– Packets of member flows carriages
Legend Aggregate.
End Node Intermediate Node
Member Flow
A C B
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
– Packets of member flows carriages– Sender End Node: assembles the carriages into a train
Legend Aggregate.
End Node Intermediate Node
Member Flow
A C B
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
– Packets of member flows carriages– Sender End Node: assembles the carriages into a train– Receiver End Node: dissembles the train into carriages
Legend Aggregate.
End Node Intermediate Node
Member Flow
A C B
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
– Packets of member flows carriages– Sender End Node: assembles the carriages into a train– Receiver End Node: dissembles the train into carriages– Intermediate Nodes: only forward the train, but cannot add/remove
carriages
Legend Aggregate.
End Node Intermediate Node
Member Flow
A C B
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
– Packets of member flows carriages– Sender End Node: assembles the carriages into a train– Receiver End Node: dissembles the train into carriages– Intermediate Nodes: only forward the train, but cannot add/remove
carriages– Forwarding (routing) on the per train basis, not per carriage basis
Legend Aggregate.
End Node Intermediate Node
Member Flow
A C B
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
– Packets of member flows carriages– Sender End Node: assembles the carriages into a train– Receiver End Node: dissembles the train into carriages– Intermediate Nodes: only forward the train, but cannot add/remove
carriages– Forwarding (routing) on the per train basis, not per carriage basis– Local Train: few hops (physical links)
Legend Aggregate.
End Node Intermediate Node
Member Flow
A C B
The Equivalent of Train in Network?• An aggregate (of flows) is like a train
– Packets of member flows carriages– Sender End Node: assembles the carriages into a train– Receiver End Node: dissembles the train into carriages– Intermediate Nodes: only forward the train, but cannot add/remove carriages– Forwarding (routing) on the per train basis, not per carriage basis– Local Train: few hops– Express Train: many hops
Legend Aggregate.
End Node Intermediate Node
Member Flow
A C B
Virtual Link/Topology• Aggregates with the same sender and receiver
end nodes collectively embody a virtual link
A C BF1
F2
F3
Legend
Virtual Link Aggregate. Thickness implies the aggregate’s data throughput
End Node Intermediate Node
Virtual Link/Topology• Aggregates with the same sender and receiver
end nodes collectively embody a virtual link
• Many virtual links altogether build up virtual topology
A C BF1
F2
F3
Legend
Virtual Link Aggregate. Thickness implies the aggregate’s data throughput
End Node Intermediate Node
State-of-the-Art: GR-Aggregate
• How to build virtual link with hard real-time E2E delay guarantee?
State-of-the-Art: GR-Aggregate
• How to build virtual link with hard real-time E2E delay guarantee?
• [SunShin05]: Guaranteed Rate Aggregate (GR-Aggregate)
State-of-the-Art: GR-AggregateGuaranteed Rate Server (GR-Server) [Goyal97a]:
A queueing server S is a GR-Server, as long as there exists a constant rf (called guaranteed rate) for each of its flow f , such that
State-of-the-Art: GR-Aggregate
. history, arrivalpacket past s'GRSFunc)( fjf rfpL
Guaranteed Rate Server (GR-Server) [Goyal97a]:
A queueing server S is a GR-Server, as long as there exists a constant rf (called guaranteed rate) for each of its flow f , such that
State-of-the-Art: GR-Aggregate
. history, arrivalpacket past s'GRSFunc)( fjf rfpL
Guaranteed Rate Server (GR-Server) [Goyal97a]:
A queueing server S is a GR-Server, as long as there exists a constant rf (called guaranteed rate) for each of its flow f , such that
pfj: jth packet of flow f
State-of-the-Art: GR-AggregateGuaranteed Rate Server (GR-Server) [Goyal97a]:
A queueing server S is a GR-Server, as long as there exists a constant rf (called guaranteed rate) for each of its flow f , such that
pfj: jth packet of flow f
L(p): time when packet p leaves S
. history, arrivalpacket past s'GRSFunc)( fjf rfpL
State-of-the-Art: GR-AggregateGuaranteed Rate Server (GR-Server) [Goyal97a]:
A queueing server S is a GR-Server, as long as there exists a constant rf (called guaranteed rate) for each of its flow f , such that
pfj: jth packet of flow f
L(p): time when packet p leaves S
A specific function, called GRSFunc
. history, arrivalpacket past s'GRSFunc)( fjf rfpL
State-of-the-Art: GR-AggregateGuaranteed Rate Server (GR-Server) [Goyal97a]:
A queueing server S is a GR-Server, as long as there exists a constant rf (called guaranteed rate) for each of its flow f , such that
pfj: jth packet of flow f
L(p): time when packet p leaves S
A specific function, called GRSFunc
. history, arrivalpacket past s'GRSFunc)( fjf rfpL
State-of-the-Art: GR-AggregateGuaranteed Rate Server (GR-Server) [Goyal97a]:
A queueing server S is a GR-Server, as long as there exists a constant rf (called guaranteed rate) for each of its flow f , such that
pfj: jth packet of flow f
L(p): time when packet p leaves S
A specific function, called GRSFunc
. history, arrivalpacket past s'GRSFunc)( fjf rfpL
rf: guaranteed rate
State-of-the-Art: GR-AggregateGuaranteed Rate Server (GR-Server) [Goyal97a]:
A queueing server S is a GR-Server, as long as there exists a constant rf (called guaranteed rate) for each of its flow f , such that
pfj: jth packet of flow f
L(p): time when packet p leaves S
A specific function, called GRSFunc
rf: guaranteed rate
. history, arrivalpacket past s'GRSFunc)( fjf rfpL
State-of-the-Art: GR-Aggregate• [Goyal97a] proves WFQ, WF2Q are GR-Server, with
rf = f C, where f is the weight of flow f (note f ≤ 1), and C is the server output capacity.
State-of-the-Art: GR-Aggregate• [Goyal97a] proves WFQ, WF2Q are GR-Server, with
rf = f C, where f is the weight of flow f (note f ≤ 1), and C is the server output capacity.
• [SunShin05]: GR-Aggregate based Virtual Link:
State-of-the-Art: GR-Aggregate• [Goyal97a] proves WFQ, WF2Q are GR-Server, with
rf = f C, where f is the weight of flow f (note f ≤ 1), and C is the server output capacity.
• [SunShin05]: GR-Aggregate based Virtual Link:– Sender End: aggregates virtual link’s member flows into an
aggregate F using a GR-Server;
State-of-the-Art: GR-Aggregate• [Goyal97a] proves WFQ, WF2Q are GR-Server, with
rf = f C, where f is the weight of flow f (note f ≤ 1), and C is the server output capacity.
• [SunShin05]: GR-Aggregate based Virtual Link:– Sender End: aggregates virtual link’s member flows into an
aggregate F using a GR-Server;
– Intermediate Nodes: each forwards F with a GR-Server at a guaranteed rate of RF, where RF ≥ F, and F is F’s data throughput.
State-of-the-Art: GR-Aggregate• [Goyal97a] proves WFQ, WF2Q are GR-Server, with
rf = f C, where f is the weight of flow f (note f ≤ 1), and C is the server output capacity.
• [SunShin05]: GR-Aggregate based Virtual Link:– Sender End: aggregates virtual link’s member flows into an
aggregate F using a GR-Server;
– Intermediate Nodes: each forwards F with a GR-Server at a guaranteed rate of RF, where RF ≥ F, and F is F’s data throughput.
– Receiver End: disintegrates F into original flows.
State-of-the-Art: GR-Aggregate• [Goyal97a] proves WFQ, WF2Q are GR-Server, with
rf = f C, where f is the weight of flow f (note f ≤ 1), and C is the server output capacity.
• [SunShin05]: GR-Aggregate based Virtual Link:– Sender End: aggregates virtual link’s member flows into an
aggregate F using a GR-Server;
– Intermediate Nodes: each forwards F with a GR-Server at a guaranteed rate of RF, where RF ≥ F, and F is F’s data throughput.
– Receiver End: disintegrates F into original flows.
– E2E Delay d ≤ / RF + , where , are certain constants.
New Problem
• GR-Aggregate fits Internet traffic well.
New Problem
• GR-Aggregate fits Internet traffic well.
• When applied to Cyber-Physical Systems traffic
New Problem
• GR-Aggregate fits Internet traffic well.
• When applied to Cyber-Physical Systems traffic– Real-time sensing/actuating aggregate:
New Problem
• GR-Aggregate fits Internet traffic well.
• When applied to Cyber-Physical Systems traffic– Real-time sensing/actuating aggregate:
• Small data throughput, small E2E delay requirement
New Problem
• GR-Aggregate fits Internet traffic well.
• When applied to Cyber-Physical Systems traffic– Real-time sensing/actuating aggregate:
• Small data throughput, small E2E delay requirement
– Real-time video aggregate:
New Problem
• GR-Aggregate fits Internet traffic well.
• When applied to Cyber-Physical Systems traffic– Real-time sensing/actuating aggregate:
• Small data throughput, small E2E delay requirement
– Real-time video aggregate:• Large data throughput, small E2E delay requirement
New Problem
• GR-Aggregate fits Internet traffic well.
• When applied to Cyber-Physical Systems traffic– Real-time sensing/actuating aggregate:
• Small data throughput, small E2E delay requirement
– Real-time video aggregate:• Large data throughput, small E2E delay requirement
– Non-real-time traffic
New Problem
• For real-time sensing/actuating aggregate:
New Problem
• For real-time sensing/actuating aggregate: – Small data throughput, small E2E delay requirement
New Problem
• For real-time sensing/actuating aggregate: – Small data throughput, small E2E delay requirement
– GR-Aggregate E2E delay d ≤ / RF +
New Problem
• For real-time sensing/actuating aggregate: – Small data throughput, small E2E delay requirement
– GR-Aggregate E2E delay d ≤ / RF + – Assigning small guaranteed rate RF (i.e., RF = F)
large E2E delay;
New Problem
• For real-time sensing/actuating aggregate: – Small data throughput, small E2E delay requirement
– GR-Aggregate E2E delay d ≤ / RF + – Assigning small guaranteed rate RF (i.e., RF = F)
large E2E delay;
– Assigning large guaranteed rate RF (i.e., RF > F )
New Problem
• For real-time sensing/actuating aggregate: – Small data throughput, small E2E delay requirement
– GR-Aggregate E2E delay d ≤ / RF + – Assigning small guaranteed rate RF (i.e., RF = F)
large E2E delay;
– Assigning large guaranteed rate RF (i.e., RF > F ) other aggregates’ guaranteed rates < their data throughputs (when link capacity is precious).
New Problem
• For real-time sensing/actuating aggregate: – Small data throughput, small E2E delay requirement
– GR-Aggregate E2E delay d ≤ / RF + – Assigning small guaranteed rate RF (i.e., RF = F) large
E2E delay;
– Assigning large guaranteed rate RF (i.e., RF > F ) other aggregates’ guaranteed rates < their data throughputs (when link capacity is precious).GR-Aggregate does not talk about this situation.
New Problem
• For real-time sensing/actuating aggregate: – Small data throughput, small E2E delay requirement
– GR-Aggregate E2E delay d ≤ / RF + – Assigning small guaranteed rate RF (i.e., RF = F) large
E2E delay;
– Assigning large guaranteed rate RF (i.e., RF > F ) other aggregates’ guaranteed rates < their data throughputs (when link capacity is precious).GR-Aggregate does not talk about this situation.What will happen?
Solution Heuristic
• Observation:
Solution Heuristic
• Observation:
The purpose of using GR-Server to provide E2E delay guarantee is to provide a constant per hop transmission delay bound.
Solution Heuristic
• Observation:
The purpose of using GR-Server to provide E2E delay guarantee is to provide a constant per hop transmission delay bound.
• As long as we can provide such a bound, we are fine.
Solution Heuristic• So far we know WFQ, WF2Q are GR-Servers, and if flow f is assigned
weight f , it is guaranteed a rate of rf = f C.
Solution Heuristic• So far we know WFQ, WF2Q are GR-Servers, and if flow f is assigned
weight f , it is guaranteed a rate of rf = f C.
Conventionally, we assign weight f proportional to data throughput, i.e., f C ≥ f.
Solution Heuristic• So far we know WFQ, WF2Q are GR-Servers, and if flow f is assigned
weight f , it is guaranteed a rate of rf = f C.
Conventionally, we assign weight f proportional to data throughput, i.e., f C ≥ f.
• What if we assign arbitrary weight?
Solution Heuristic• So far we know WFQ, WF2Q are GR-Servers, and if flow f is assigned
weight f , it is guaranteed a rate of rf = f C.
Conventionally, we assign weight f proportional to data throughput, i.e., f C ≥ f.
• What if we assign arbitrary weight?
Discovery: as long as every flow is token-bucket-constrained and f
≤ C, every flow still has a bounded transmission delay, and there is an algorithm TDB({i},{li
max},C) to calculate this transmission delay bound f (l).
Solution Heuristic• So far we know WFQ, WF2Q are GR-Servers, and if flow f is assigned
weight f , it is guaranteed a rate of rf = f C.
Conventionally, we assign weight f proportional to data throughput, i.e., f C ≥ f.
• What if we assign arbitrary weight?
Discovery: as long as every flow is token-bucket-constrained and f ≤ C, every flow still has a bounded transmission delay, and there is an algorithm TDB({i},{li
max},C) to calculate this transmission delay bound f (l).
To the extreme, we can mimic prioritized preemption by assigning proper weights.
Solution Heuristic: What does arbitrary weight imply?
F1, data rate = 0.1 F2, data rate = 0.4 F3, data rate = 0.5
Solution Heuristic: What does arbitrary weight imply?
F1, data rate = 0.1 F2, data rate = 0.4 F3, data rate = 0.5
Server Capacity C = 1, all packet length l = 1.
Solution Heuristic: What does arbitrary weight imply?
F1, data rate = 0.1 F2, data rate = 0.4 F3, data rate = 0.5
Data Rate Proportional Weight: 1 = 0.1, 2 = 0.4, 3 = 0.5
Server Capacity C = 1, all packet length l = 1.
Solution Heuristic: What does arbitrary weight imply?
23 101 5.22
t (sec)1 2 3 4 5 6 7 8 9 100
F1, data rate = 0.1 F2, data rate = 0.4 F3, data rate = 0.5
Data Rate Proportional Weight: 1 = 0.1, 2 = 0.4, 3 = 0.5
Transmission delay bound inverse proportionally coupled with data
throughput
Server Capacity C = 1, all packet length l = 1.
Solution Heuristic: What does arbitrary weight imply?
23 101 5.22
t (sec)1 2 3 4 5 6 7 8 9 100
F1, data rate = 0.1 F2, data rate = 0.4 F3, data rate = 0.5
Data Rate Proportional Weight: 1 = 0.1, 2 = 0.4, 3 = 0.5
Prioritized Weight: 1 = 0.999, 2 = 0.000999, 3 = 0.000001
Transmission delay bound inverse proportionally coupled with data
throughput
Server Capacity C = 1, all packet length l = 1.
Solution Heuristic: What does arbitrary weight imply?
t (sec)1 2 3 4 5 7 8 9 100
11
6
22.29
202 63 23 101 5.22
t (sec)1 2 3 4 5 6 7 8 9 100
F1, data rate = 0.1 F2, data rate = 0.4 F3, data rate = 0.5
Data Rate Proportional Weight: 1 = 0.1, 2 = 0.4, 3 = 0.5
Transmission delay bound inverse proportionally coupled with data
throughput
According to TDB algorithm, transmission delay bound decoupled from data throughput, and reflects priority: higher priority maps to
shorter
Server Capacity C = 1, all packet length l = 1.
Prioritized Weight: 1 = 0.999, 2 = 0.000999, 3 = 0.000001
Solution: GD-AggregateProposal: Guaranteed Delay Server (GD-Server):
A queueing server S is a GD-Server, as long as there exists a non-negative monotonically non-decreasing function f(l) (called guaranteed delay function) for each of its flow f , such that
Solution: GD-Aggregate
. history, arrivalpacket past s'GDSFunc)( fjf fpL
Proposal: Guaranteed Delay Server (GD-Server):
A queueing server S is a GD-Server, as long as there exists a non-negative monotonically non-decreasing function f(l) (called guaranteed delay function) for each of its flow f , such that
Solution: GD-Aggregate
. history, arrivalpacket past s'GDSFunc)( fjf fpL
Proposal: Guaranteed Delay Server (GD-Server):
A queueing server S is a GD-Server, as long as there exists a non-negative monotonically non-decreasing function f(l) (called guaranteed delay function) for each of its flow f , such that
pfj: jth packet of flow f
Solution: GD-AggregateProposal: Guaranteed Delay Server (GD-Server):
A queueing server S is a GD-Server, as long as there exists a non-negative monotonically non-decreasing function f(l) (called guaranteed delay function) for each of its flow f , such that
pfj: jth packet of flow f
L(p): time when packet p leaves S
. history, arrivalpacket past s'GDSFunc)( fjf fpL
Solution: GD-AggregateProposal: Guaranteed Delay Server (GD-Server):
A queueing server S is a GD-Server, as long as there exists a non-negative monotonically non-decreasing function f(l) (called guaranteed delay function) for each of its flow f , such that
pfj: jth packet of flow f
L(p): time when packet p leaves S
A specific function, called GDSFunc
. history, arrivalpacket past s'GDSFunc)( fjf fpL
Solution: GD-AggregateProposal: Guaranteed Delay Server (GD-Server):
A queueing server S is a GD-Server, as long as there exists a non-negative monotonically non-decreasing function f(l) (called guaranteed delay function) for each of its flow f , such that
pfj: jth packet of flow f
L(p): time when packet p leaves S
A specific function, called GDSFunc
. history, arrivalpacket past s'GDSFunc)( fjf fpL
Solution: GD-AggregateProposal: Guaranteed Delay Server (GD-Server):
A queueing server S is a GD-Server, as long as there exists a non-negative monotonically non-decreasing function f(l) (called guaranteed delay function) for each of its flow f , such that
pfj: jth packet of flow f
L(p): time when packet p leaves S
A specific function, called GDSFunc
f(l) : guaranteed delay function
. history, arrivalpacket past s'GDSFunc)( fjf fpL
Solution: GD-AggregateProposal: Guaranteed Delay Server (GD-Server):
A queueing server S is a GD-Server, as long as there exists a non-negative monotonically non-decreasing function f(l) (called guaranteed delay function) for each of its flow f , such that
pfj: jth packet of flow f
L(p): time when packet p leaves S
A specific function, called GDSFunc
. history, arrivalpacket past s'GDSFunc)( fjf fpL
f(l) : guaranteed delay function
Solution: GD-Aggregate
• Discovery: If each ingress flow/aggregate is token-bucket-constrained, WFQ and WF2Q servers are GD-Servers.
Solution: GD-Aggregate
• Discovery: If each ingress flow/aggregate is token-bucket-constrained, WFQ and WF2Q servers are GD-Servers.
• Design: We modified the design of Sun and Shin’s GR-Aggregate into GD-Aggregate, (mainly) by changing GR-Servers to GD-Servers.
Solution: GD-Aggregate
• GD-Aggregate Features:
Solution: GD-Aggregate
• GD-Aggregate Features:– E2E Delay d ≤ k(lmax) + , where k(l) is the guaranteed delay
function at the kth hop, lmax is the maximal packet length.
Solution: GD-Aggregate
• GD-Aggregate Features:– E2E Delay d ≤ k(lmax) + , where k(l) is the guaranteed delay
function at the kth hop, lmax is the maximal packet length.
– We found a way to assign weight to mimic priority so that
Solution: GD-Aggregate
• GD-Aggregate Features:– E2E Delay d ≤ k(lmax) + , where k(l) is the guaranteed delay
function at the kth hop, lmax is the maximal packet length.
– We found a way to assign weight to mimic priority so that • An aggregate with small data throughput can have small k(l),
Solution: GD-Aggregate
• GD-Aggregate Features:– E2E Delay d ≤ k(lmax) + , where k(l) is the guaranteed delay
function at the kth hop, lmax is the maximal packet length.
– We found a way to assign weight to mimic priority so that • An aggregate with small data throughput can have small k(l),
• and hence small E2E delay guarantee.
Solution: GD-Aggregate
• GD-Aggregate Features:– E2E Delay d ≤ k(lmax) + , where k(l) is the guaranteed delay
function at the kth hop, lmax is the maximal packet length.
– We found a way to assign weight to mimic priority so that • An aggregate with small data throughput can have small k(l),
• and hence small E2E delay guarantee.
• No waste of link capacity
Solution: GD-Aggregate
• GD-Aggregate Features:– E2E Delay d ≤ k(lmax) + , where k(l) is the guaranteed delay
function at the kth hop, lmax is the maximal packet length.
– We found a way to assign weight to mimic priority so that • An aggregate with small data throughput can have small k(l),
• and hence small E2E delay guarantee.
• No waste of link capacity k(l) is a linear function of packet length l.
Solution: GD-Aggregate
• GD-Aggregate Features:– E2E Delay d ≤ k(lmax) + , where k(l) is the guaranteed delay
function at the kth hop, lmax is the maximal packet length.
– We found a way to assign weight to mimic priority so that • An aggregate with small data throughput can have small k(l),
• and hence small E2E delay guarantee.
• No waste of link capacity k(l) is a linear function of packet length l.
• Each priority’s capacity and delay guarantee can be planned with simple optimization tools.
Solution: GD-Aggregate
• GD-Aggregate Features:– E2E Delay d ≤ k(lmax) + , where k(l) is the guaranteed delay
function at the kth hop, lmax is the maximal packet length.
– We found a way to assign weight to mimic priority so that • An aggregate with small data throughput can have small k(l),
• and hence small E2E delay guarantee.
• No waste of link capacity k(l) is a linear function of packet length l.
• Each priority’s capacity and delay guarantee can be planned with simple optimization tools.
(8 Theorems, 4 Corollaries, 14 Lemmas)
Evaluation: Application Background
• Underground Mining: A Typical Cyber-Physical Systems Application
3000m
300m
6000m
Panel 1
Panel 2
Panel 3
North
EastWest
South
Coal
An underground coal mine
3000m
300m
6000m
Panel 1
Panel 2
Panel 3
Active Mining Area (Face)
Underground mines often cover huge areas; and are dangerous.
North
EastWest
South
Coal
3000m
300m
6000m
Panel 1
Panel 2
Panel 3
Active Mining Area (Face)
Underground mines often cover huge areas; and are dangerous.
Need to replace all human workers with remotely controlled robots/vehicles.
North
EastWest
South
Coal
3000m
300m
Active Mining Area (Face)
Above-Ground Remote Control
Room
6000m
Panel 1
Panel 2
Panel 3
Vision: Human remotely controls robots/vehicles from above-ground control room, via wired WAN backbone and wireless LANs
North
EastWest
South
Coal
3000m
300m
Active Mining Area (Face)
Above-Ground Remote Control
Room
6000m
A wireless LAN base station (a.k.a. access point, in the case of IEEE 802.11)
A wireline physical link, part of the underground mining RTE-WAN
Panel 1
Panel 2
Panel 3
Coal
North
EastWest
South
3000m
300m
Active Mining Area (Face)
Above-Ground Remote Control
Room
6000m
A wireless LAN base station (a.k.a. access point, in the case of IEEE 802.11)
A wireline physical link, part of the underground mining RTE-WAN
A virtual link (may consist of several GR/GD-aggregates) with its two end nodes
AB
Panel 1
Panel 2
Panel 3
Coal
North
EastWest
South
Evaluation: Traffic Feature
• Remote underground mining creates all typical CPS traffic (aggregates)
Evaluation: Traffic Feature
• Remote underground mining creates all typical CPS traffic (aggregates)
• Virtual link AB may consist of following aggregates:
Evaluation: Traffic Feature
• Remote underground mining creates all typical CPS traffic (aggregates)
• Virtual link AB may consist of following aggregates:– F1: tele-robotic sensing/actuating aggregate
small data throughput, short hard real-time E2E delay requirement ( ≤ 50ms)
Evaluation: Traffic Feature
• Remote underground mining creates all typical CPS traffic (aggregates)
• Virtual link AB may consist of following aggregates:– F1: tele-robotic sensing/actuating aggregate
small data throughput, short hard real-time E2E delay requirement ( ≤ 50ms)
– F2: tele-robotic video aggregatelarge data throughput, short hard real-time E2E delay requirement ( ≤ 50ms)
Evaluation: Traffic Feature
• Remote underground mining creates all typical CPS traffic (aggregates)
• Virtual link AB may consist of following aggregates:– F1: tele-robotic sensing/actuating aggregate
small data throughput, short hard real-time E2E delay requirement ( ≤ 50ms)
– F2: tele-robotic video aggregatelarge data throughput, short hard real-time E2E delay requirement ( ≤ 50ms)
– F3: Non-real-time traffic aggregatetolerates seconds of E2E delay.
Evaluation: Result
Aggregate’s data throughput (kbps)
Evaluation: Result
When link capacity C is precious, i.e., total data throughput of F1, F2, and F3 = = C.
Aggregate’s data throughput (kbps)
Evaluation: Result
When link capacity C is precious, i.e., total data throughput of F1, F2, and F3 = = C.
GR-Aggregate has to allocate guaranteed rate proportional to data throughput.
Aggregate’s data throughput (kbps)
Evaluation: Result
When link capacity C is precious, i.e., total data throughput of F1, F2, and F3 = = C.
GR-Aggregate has to allocate guaranteed rate proportional to data throughput.
Aggregate’s data throughput (kbps)
Evaluation: Result
When link capacity C is precious, i.e., total data throughput of F1, F2, and F3 = = C.
GR-Aggregate has to allocate guaranteed rate proportional to data throughput.
Aggregate’s data throughput (kbps)
Evaluation: Result
When link capacity C is precious, i.e., total data throughput of F1, F2, and F3 = = C.
GR-Aggregate has to allocate guaranteed rate proportional to data throughput.
GD-Aggregate can still let F1 has highest priority.
Aggregate’s data throughput (kbps)
Evaluation: Result
When link capacity C is precious, i.e., total data throughput of F1, F2, and F3 = = C.
GR-Aggregate has to allocate guaranteed rate proportional to data throughput.
GD-Aggregate can still let F1 has highest priority.
Aggregate’s data throughput (kbps)
Evaluation: Result
When link capacity C is precious, i.e., total data throughput of F1, F2, and F3 = = C.
GR-Aggregate has to allocate guaranteed rate proportional to data throughput.
GD-Aggregate can still let F1 has highest priority.
Aggregate’s data throughput (kbps)
Related Work
• Overlay Network: soft real-time, statistic
Related Work
• Overlay Network: soft real-time, statistic• DiffServ: FIFO, poor performance for bursty traffic
Related Work
• Overlay Network: soft real-time, statistic• DiffServ: FIFO, poor performance for bursty traffic• Real-Time Virtual Machine: still open problem,
especially on mutual exclusion and closed-form schedulability formulae.
Related Work
• Overlay Network: soft real-time, statistic• DiffServ: FIFO, poor performance for bursty traffic• Real-Time Virtual Machine: still open problem,
especially on mutual exclusion and closed-form schedulability formulae.
• [Geogiadis96] also found the decoupling technique, fluid model, no aggregation.
Related Work
• Overlay Network: soft real-time, statistic• DiffServ: FIFO, poor performance for bursty traffic• Real-Time Virtual Machine: still open problem,
especially on mutual exclusion and closed-form schedulability formulae.
• [Geogiadis96] also found the decoupling technique, fluid model, no aggregation.
• [Goyal97b] per packet guaranteed rate, known a priori, or refer to the minimum rate. Does not talk about aggregation.
Conclusion
GD-Aggregate:
Conclusion
GD-Aggregate:• Supports flow aggregation and E2E delay guarantee
Conclusion
GD-Aggregate:• Supports flow aggregation and E2E delay guarantee• A tool to build hard real-time virtual link/topology
Conclusion
GD-Aggregate:• Supports flow aggregation and E2E delay guarantee• A tool to build hard real-time virtual link/topology• Decouples E2E delay guarantee from data throughput
Conclusion
GD-Aggregate:• Supports flow aggregation and E2E delay guarantee• A tool to build hard real-time virtual link/topology• Decouples E2E delay guarantee from data throughput• Supports priority
Conclusion
GD-Aggregate:• Supports flow aggregation and E2E delay guarantee• A tool to build hard real-time virtual link/topology• Decouples E2E delay guarantee from data throughput• Supports priority• Simple linear closed-form formulae for analysis and
admission control
Conclusion
GD-Aggregate:• Supports flow aggregation and E2E delay guarantee• A tool to build hard real-time virtual link/topology• Decouples E2E delay guarantee from data throughput• Supports priority• Simple linear closed-form formulae for analysis and
admission control• Can be planned with simple optimization tools
References[Fisher04] B. Fisher et al., “Seeing, hearing, and touching: Putting it all
together,” SIGGRAPH'04 Course, 2004.[Georgiadis96] L. Georgiadis et al., “Efficient network QoS provisioning
based on per node traffic shaping,” IEEE/ACM Trans. on Networking, vol. 4, no. 4, August 1996.
[Goyal97a] P. Goyal et al., “Determining end-to-end delay bounds in heterogeneous networks,” Multimedia Systems, no. 5, pp. 157-163, 1997.
[Goyal97b] P. Goyal and H. M. Vin, “Generalized guaranteed rate scheduling algorithms: A framework,” IEEE/ACM Trans. on Networking, vol. 5, no. 4, pp. 561-571, August 1997.
[Hartman02] H. L. Hartman and J. M. Mutmansky, Introductory Mining Engineering (2nd Ed.). Wiley, August 2002.
[SunShin05] W. Sun and K. G. Shin, “End-to-end delay bounds for trafc aggregates under guaranteed-rate scheduling algorithms,” IEEE/ACM Trans. on Networking, vol. 13, no. 5, pp. 1188-1201, October 2005.
Thank You!