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) 1 2 3456789100 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) 1 2 3456789100 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 = 0.000999, 3 = 0.000001 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) 12 3 4 5 78910 06 t (sec) 1 2 3456789100 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 = 0.000999, 3 = 0.000001

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 802.11) 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 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 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, 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 (2 nd 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.

136. Thank You!