Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations


Presentation on theme: "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."— Presentation transcript:

1 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.

2 Demand Big Trend: converge computers with the physical world

3 Demand Big Trend: converge computers with the physical world –Cyber-Physical Systems

4 Demand Big Trend: converge computers with the physical world –Cyber-Physical Systems –Real-Time and Embedded (RTE) GENI

5 Demand Big Trend: converge computers with the physical world –Cyber-Physical Systems –Real-Time and Embedded (RTE) GENI –Virtual Organization

6 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:

7 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:

8 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.

9 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;

10 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

11 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.

12 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:

13 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

14 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:

15 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

16 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

17 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

18 Solution? The Train/Railway Analogy

19 Similar traffic aggregation:carriage train

20 Solution? The Train/Railway Analogy Similar traffic aggregation:carriage train Global/local traffic segregation: express vs. local train

21 Solution? The Train/Railway Analogy Similar traffic aggregation:carriage train Global/local traffic segregation: express vs. local train Hierarchical topology: express vs. local train

22 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

23 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

24 The Equivalent of Train in Network?

25 An aggregate (of flows) is like a train A C B Legend Aggregate. End NodeIntermediate Node Member Flow

26 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 NodeIntermediate Node Member Flow

27 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 NodeIntermediate Node Member Flow

28 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 NodeIntermediate Node Member Flow

29 The Equivalent of Train in Network? An aggregate (of flows) is like a train Legend Aggregate. End NodeIntermediate Node Member Flow A C B

30 The Equivalent of Train in Network? An aggregate (of flows) is like a train –Packets of member flows carriages Legend Aggregate. End NodeIntermediate Node Member Flow A C B

31 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 NodeIntermediate Node Member Flow A C B

32 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 NodeIntermediate Node Member Flow A C B

33 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 NodeIntermediate Node Member Flow A C B

34 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 NodeIntermediate Node Member Flow A C B

35 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 NodeIntermediate Node Member Flow A C B

36 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 NodeIntermediate Node Member Flow A C B

37 Virtual Link/Topology Aggregates with the same sender and receiver end nodes collectively embody a virtual link A C B F1 F2 F3 Legend Virtual Link Aggregate. Thickness implies the aggregates data throughput End NodeIntermediate Node

38 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 B F1 F2 F3 Legend Virtual Link Aggregate. Thickness implies the aggregates data throughput End NodeIntermediate Node

39 State-of-the-Art: GR-Aggregate How to build virtual link with hard real-time E2E delay guarantee?

40 State-of-the-Art: GR-Aggregate How to build virtual link with hard real-time E2E delay guarantee? [SunShin05]: Guaranteed Rate Aggregate (GR-Aggregate)

41 State-of-the-Art: GR-Aggregate Guaranteed Rate Server (GR-Server) [Goyal97a]: A queueing server S is a GR-Server, as long as there exists a constant r f (called guaranteed rate) for each of its flow f, such that

42 State-of-the-Art: GR-Aggregate Guaranteed Rate Server (GR-Server) [Goyal97a]: A queueing server S is a GR-Server, as long as there exists a constant r f (called guaranteed rate) for each of its flow f, such that

43 State-of-the-Art: GR-Aggregate Guaranteed Rate Server (GR-Server) [Goyal97a]: A queueing server S is a GR-Server, as long as there exists a constant r f (called guaranteed rate) for each of its flow f, such that p f j : jth packet of flow f

44 State-of-the-Art: GR-Aggregate Guaranteed Rate Server (GR-Server) [Goyal97a]: A queueing server S is a GR-Server, as long as there exists a constant r f (called guaranteed rate) for each of its flow f, such that p f j : jth packet of flow f L(p): time when packet p leaves S

45 State-of-the-Art: GR-Aggregate Guaranteed Rate Server (GR-Server) [Goyal97a]: A queueing server S is a GR-Server, as long as there exists a constant r f (called guaranteed rate) for each of its flow f, such that p f j : jth packet of flow f L(p): time when packet p leaves S A specific function, called GRSFunc

46 State-of-the-Art: GR-Aggregate Guaranteed Rate Server (GR-Server) [Goyal97a]: A queueing server S is a GR-Server, as long as there exists a constant r f (called guaranteed rate) for each of its flow f, such that p f j : jth packet of flow f L(p): time when packet p leaves S A specific function, called GRSFunc

47 State-of-the-Art: GR-Aggregate Guaranteed Rate Server (GR-Server) [Goyal97a]: A queueing server S is a GR-Server, as long as there exists a constant r f (called guaranteed rate) for each of its flow f, such that p f j : jth packet of flow f L(p): time when packet p leaves S A specific function, called GRSFunc r f : guaranteed rate

48 State-of-the-Art: GR-Aggregate Guaranteed Rate Server (GR-Server) [Goyal97a]: A queueing server S is a GR-Server, as long as there exists a constant r f (called guaranteed rate) for each of its flow f, such that p f j : jth packet of flow f L(p): time when packet p leaves S A specific function, called GRSFunc r f : guaranteed rate

49 State-of-the-Art: GR-Aggregate [Goyal97a] proves WFQ, WF 2 Q are GR-Server, with r f = f C, where f is the weight of flow f (note f 1), and C is the server output capacity.

50 State-of-the-Art: GR-Aggregate [Goyal97a] proves WFQ, WF 2 Q are GR-Server, with r f = 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:

51 State-of-the-Art: GR-Aggregate [Goyal97a] proves WFQ, WF 2 Q are GR-Server, with r f = 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 links member flows into an aggregate F using a GR-Server;

52 State-of-the-Art: GR-Aggregate [Goyal97a] proves WFQ, WF 2 Q are GR-Server, with r f = 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 links member flows into an aggregate F using a GR-Server; –Intermediate Nodes: each forwards F with a GR-Server at a guaranteed rate of R F, where R F F, and F is Fs data throughput.

53 State-of-the-Art: GR-Aggregate [Goyal97a] proves WFQ, WF 2 Q are GR-Server, with r f = 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 links member flows into an aggregate F using a GR-Server; –Intermediate Nodes: each forwards F with a GR-Server at a guaranteed rate of R F, where R F F, and F is Fs data throughput. –Receiver End: disintegrates F into original flows.

54 State-of-the-Art: GR-Aggregate [Goyal97a] proves WFQ, WF 2 Q are GR-Server, with r f = 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 links member flows into an aggregate F using a GR-Server; –Intermediate Nodes: each forwards F with a GR-Server at a guaranteed rate of R F, where R F F, and F is Fs data throughput. –Receiver End: disintegrates F into original flows. –E2E Delay d / R F +, where, are certain constants.

55 New Problem GR-Aggregate fits Internet traffic well.

56 New Problem GR-Aggregate fits Internet traffic well. When applied to Cyber-Physical Systems traffic

57 New Problem GR-Aggregate fits Internet traffic well. When applied to Cyber-Physical Systems traffic –Real-time sensing/actuating aggregate:

58 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

59 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:

60 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

61 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

62 New Problem For real-time sensing/actuating aggregate:

63 New Problem For real-time sensing/actuating aggregate: –Small data throughput, small E2E delay requirement

64 New Problem For real-time sensing/actuating aggregate: –Small data throughput, small E2E delay requirement –GR-Aggregate E2E delay d / R F +

65 New Problem For real-time sensing/actuating aggregate: –Small data throughput, small E2E delay requirement –GR-Aggregate E2E delay d / R F + –Assigning small guaranteed rate R F (i.e., R F = F ) large E2E delay;

66 New Problem For real-time sensing/actuating aggregate: –Small data throughput, small E2E delay requirement –GR-Aggregate E2E delay d / R F + –Assigning small guaranteed rate R F (i.e., R F = F ) large E2E delay; –Assigning large guaranteed rate R F (i.e., R F > F )

67 New Problem For real-time sensing/actuating aggregate: –Small data throughput, small E2E delay requirement –GR-Aggregate E2E delay d / R F + –Assigning small guaranteed rate R F (i.e., R F = F ) large E2E delay; –Assigning large guaranteed rate R F (i.e., R F > F ) other aggregates guaranteed rates < their data throughputs (when link capacity is precious).

68 New Problem For real-time sensing/actuating aggregate: –Small data throughput, small E2E delay requirement –GR-Aggregate E2E delay d / R F + –Assigning small guaranteed rate R F (i.e., R F = F ) large E2E delay; –Assigning large guaranteed rate R F (i.e., R F > F ) other aggregates guaranteed rates < their data throughputs (when link capacity is precious). GR-Aggregate does not talk about this situation.

69 New Problem For real-time sensing/actuating aggregate: –Small data throughput, small E2E delay requirement –GR-Aggregate E2E delay d / R F + –Assigning small guaranteed rate R F (i.e., R F = F ) large E2E delay; –Assigning large guaranteed rate R F (i.e., R F > F ) other aggregates guaranteed rates < their data throughputs (when link capacity is precious). GR-Aggregate does not talk about this situation. What will happen?

70 Solution Heuristic Observation:

71 Solution Heuristic Observation: The purpose of using GR-Server to provide E2E delay guarantee is to provide a constant per hop transmission delay bound.

72 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.

73 Solution Heuristic So far we know WFQ, WF 2 Q are GR-Servers, and if flow f is assigned weight f, it is guaranteed a rate of r f = f C.

74 Solution Heuristic So far we know WFQ, WF 2 Q are GR-Servers, and if flow f is assigned weight f, it is guaranteed a rate of r f = f C. Conventionally, we assign weight f proportional to data throughput, i.e., f C f.

75 Solution Heuristic So far we know WFQ, WF 2 Q are GR-Servers, and if flow f is assigned weight f, it is guaranteed a rate of r f = f C. Conventionally, we assign weight f proportional to data throughput, i.e., f C f. What if we assign arbitrary weight?

76 Solution Heuristic So far we know WFQ, WF 2 Q are GR-Servers, and if flow f is assigned weight f, it is guaranteed a rate of r f = 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 },{l i max },C) to calculate this transmission delay bound f (l).

77 Solution Heuristic So far we know WFQ, WF 2 Q are GR-Servers, and if flow f is assigned weight f, it is guaranteed a rate of r f = 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 },{l i max },C) to calculate this transmission delay bound f (l). To the extreme, we can mimic prioritized preemption by assigning proper weights.

78 Solution Heuristic: What does arbitrary weight imply? F 1, data rate = 0.1 F 2, data rate = 0.4F 3, data rate = 0.5

79 Solution Heuristic: What does arbitrary weight imply? F 1, data rate = 0.1 F 2, data rate = 0.4F 3, data rate = 0.5 Server Capacity C = 1, all packet length l = 1.

80 Solution Heuristic: What does arbitrary weight imply? F 1, data rate = 0.1 F 2, data rate = 0.4F 3, 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.

81 Solution Heuristic: What does arbitrary weight imply? t (sec) F 1, data rate = 0.1 F 2, data rate = 0.4F 3, 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.

82 Solution Heuristic: What does arbitrary weight imply? t (sec) F 1, data rate = 0.1 F 2, data rate = 0.4F 3, data rate = 0.5 Data Rate Proportional Weight: 1 = 0.1, 2 = 0.4, 3 = 0.5 Prioritized Weight: 1 = 0.999, 2 = , 3 = Transmission delay bound inverse proportionally coupled with data throughput Server Capacity C = 1, all packet length l = 1.

83 Solution Heuristic: What does arbitrary weight imply? t (sec) t (sec) F 1, data rate = 0.1 F 2, data rate = 0.4F 3, 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 = , 3 =

84 Solution: GD-Aggregate 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

85 Solution: GD-Aggregate 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

86 Solution: GD-Aggregate 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 p f j : jth packet of flow f

87 Solution: GD-Aggregate 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 p f j : jth packet of flow f L(p): time when packet p leaves S

88 Solution: GD-Aggregate 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 p f j : jth packet of flow f L(p): time when packet p leaves S A specific function, called GDSFunc

89 Solution: GD-Aggregate 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 p f j : jth packet of flow f L(p): time when packet p leaves S A specific function, called GDSFunc

90 Solution: GD-Aggregate 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 p f j : jth packet of flow f L(p): time when packet p leaves S A specific function, called GDSFunc f (l) : guaranteed delay function

91 Solution: GD-Aggregate 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 p f j : jth packet of flow f L(p): time when packet p leaves S A specific function, called GDSFunc f (l) : guaranteed delay function

92 Solution: GD-Aggregate Discovery: If each ingress flow/aggregate is token-bucket-constrained, WFQ and WF 2 Q servers are GD-Servers.

93 Solution: GD-Aggregate Discovery: If each ingress flow/aggregate is token-bucket-constrained, WFQ and WF 2 Q servers are GD-Servers. Design: We modified the design of Sun and Shins GR-Aggregate into GD-Aggregate, (mainly) by changing GR-Servers to GD- Servers.

94 Solution: GD-Aggregate GD-Aggregate Features:

95 Solution: GD-Aggregate GD-Aggregate Features: –E2E Delay d k (l max ) +, where k (l) is the guaranteed delay function at the kth hop, l max is the maximal packet length.

96 Solution: GD-Aggregate GD-Aggregate Features: –E2E Delay d k (l max ) +, where k (l) is the guaranteed delay function at the kth hop, l max is the maximal packet length. –We found a way to assign weight to mimic priority so that

97 Solution: GD-Aggregate GD-Aggregate Features: –E2E Delay d k (l max ) +, where k (l) is the guaranteed delay function at the kth hop, l max 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),

98 Solution: GD-Aggregate GD-Aggregate Features: –E2E Delay d k (l max ) +, where k (l) is the guaranteed delay function at the kth hop, l max 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.

99 Solution: GD-Aggregate GD-Aggregate Features: –E2E Delay d k (l max ) +, where k (l) is the guaranteed delay function at the kth hop, l max 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

100 Solution: GD-Aggregate GD-Aggregate Features: –E2E Delay d k (l max ) +, where k (l) is the guaranteed delay function at the kth hop, l max 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.

101 Solution: GD-Aggregate GD-Aggregate Features: –E2E Delay d k (l max ) +, where k (l) is the guaranteed delay function at the kth hop, l max 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 prioritys capacity and delay guarantee can be planned with simple optimization tools.

102 Solution: GD-Aggregate GD-Aggregate Features: –E2E Delay d k (l max ) +, where k (l) is the guaranteed delay function at the kth hop, l max 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 prioritys capacity and delay guarantee can be planned with simple optimization tools. (8 Theorems, 4 Corollaries, 14 Lemmas)

103 Evaluation: Application Background Underground Mining: A Typical Cyber- Physical Systems Application

104 3000m 300m 6000m Panel 1 Panel 2Panel 3 North EastWest South Coal An underground coal mine

105 3000m 300m 6000m Panel 1 Panel 2Panel 3 Active Mining Area (Face) Underground mines often cover huge areas; and are dangerous. North EastWest South Coal

106 3000m 300m 6000m Panel 1 Panel 2Panel 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

107 3000m 300m Active Mining Area (Face) Above-Ground Remote Control Room 6000m Panel 1 Panel 2Panel 3 Vision: Human remotely controls robots/vehicles from above-ground control room, via wired WAN backbone and wireless LANs North EastWest South Coal

108 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 ) A wireline physical link, part of the underground mining RTE-WAN Panel 1 Panel 2Panel 3 Coal North EastWest South

109 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 ) 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 A B Panel 1 Panel 2Panel 3 Coal North EastWest South

110 Evaluation: Traffic Feature Remote underground mining creates all typical CPS traffic (aggregates)

111 Evaluation: Traffic Feature Remote underground mining creates all typical CPS traffic (aggregates) Virtual link AB may consist of following aggregates:

112 Evaluation: Traffic Feature Remote underground mining creates all typical CPS traffic (aggregates) Virtual link AB may consist of following aggregates: –F 1 : tele-robotic sensing/actuating aggregate small data throughput, short hard real-time E2E delay requirement ( 50ms)

113 Evaluation: Traffic Feature Remote underground mining creates all typical CPS traffic (aggregates) Virtual link AB may consist of following aggregates: –F 1 : tele-robotic sensing/actuating aggregate small data throughput, short hard real-time E2E delay requirement ( 50ms) –F 2 : tele-robotic video aggregate large data throughput, short hard real-time E2E delay requirement ( 50ms)

114 Evaluation: Traffic Feature Remote underground mining creates all typical CPS traffic (aggregates) Virtual link AB may consist of following aggregates: –F 1 : tele-robotic sensing/actuating aggregate small data throughput, short hard real-time E2E delay requirement ( 50ms) –F 2 : tele-robotic video aggregate large data throughput, short hard real-time E2E delay requirement ( 50ms) –F 3 : Non-real-time traffic aggregate tolerates seconds of E2E delay.

115 Evaluation: Result Aggregates data throughput (kbps)

116 Evaluation: Result When link capacity C is precious, i.e., total data throughput of F 1, F 2, and F 3 = = C. Aggregates data throughput (kbps)

117 Evaluation: Result When link capacity C is precious, i.e., total data throughput of F 1, F 2, and F 3 = = C. GR-Aggregate has to allocate guaranteed rate proportional to data throughput. Aggregates data throughput (kbps)

118 Evaluation: Result When link capacity C is precious, i.e., total data throughput of F 1, F 2, and F 3 = = C. GR-Aggregate has to allocate guaranteed rate proportional to data throughput. Aggregates data throughput (kbps)

119 Evaluation: Result When link capacity C is precious, i.e., total data throughput of F 1, F 2, and F 3 = = C. GR-Aggregate has to allocate guaranteed rate proportional to data throughput. Aggregates data throughput (kbps)

120 Evaluation: Result When link capacity C is precious, i.e., total data throughput of F 1, F 2, and F 3 = = C. GR-Aggregate has to allocate guaranteed rate proportional to data throughput. GD-Aggregate can still let F 1 has highest priority. Aggregates data throughput (kbps)

121 Evaluation: Result When link capacity C is precious, i.e., total data throughput of F 1, F 2, and F 3 = = C. GR-Aggregate has to allocate guaranteed rate proportional to data throughput. GD-Aggregate can still let F 1 has highest priority. Aggregates data throughput (kbps)

122 Evaluation: Result When link capacity C is precious, i.e., total data throughput of F 1, F 2, and F 3 = = C. GR-Aggregate has to allocate guaranteed rate proportional to data throughput. GD-Aggregate can still let F 1 has highest priority. Aggregates data throughput (kbps)

123 Related Work Overlay Network: soft real-time, statistic

124 Related Work Overlay Network: soft real-time, statistic DiffServ: FIFO, poor performance for bursty traffic

125 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.

126 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.

127 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.

128 Conclusion GD-Aggregate:

129 Conclusion GD-Aggregate: Supports flow aggregation and E2E delay guarantee

130 Conclusion GD-Aggregate: Supports flow aggregation and E2E delay guarantee A tool to build hard real-time virtual link/topology

131 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

132 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

133 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

134 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

135 References [Fisher04] B. Fisher et al., Seeing, hearing, and touching: Putting it all together, SIGGRAPH'04 Course, [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 [Goyal97a] P. Goyal et al., Determining end-to-end delay bounds in heterogeneous networks, Multimedia Systems, no. 5, pp , [Goyal97b] P. Goyal and H. M. Vin, Generalized guaranteed rate scheduling algorithms: A framework, IEEE/ACM Trans. on Networking, vol. 5, no. 4, pp , August [Hartman02] H. L. Hartman and J. M. Mutmansky, Introductory Mining Engineering (2 nd Ed.). Wiley, August [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 , October 2005.

136 Thank You!


Download ppt "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."

Similar presentations


Ads by Google