The document discusses the development and benefits of intelligent containers (icons) in edge computing, designed to autonomously manage latency-critical services. It highlights the need for open infrastructure standards and independent edge providers to facilitate decentralized service deployment, reducing cloud dependency and administrative overhead. The document also raises questions about the intelligence required for effective operation and future work on implementing negotiation protocols and advanced prediction capabilities.

1. ICON:
Intelligent Container Overlays
A. Zavodovski, N. Mohan, S. Bayhan, W. Wong and J. Kangasharju
HotNets 2018,
November 15-16, 2018

2. Motivation: Edge Computing
2

3. Motivation: Edge Computing
2
Latency-critical
services are
predeployed to
edge facilities

4. Motivation: Edge Computing
2
Latency-critical
services are
predeployed to
edge facilities

5. Motivation: Edge Computing
2
Latency-critical
services are
predeployed to
edge facilities

6. Motivation: Edge Computing
2
Latency-critical
services are
predeployed to
edge facilities

7. Motivation: Edge Computing
2
Latency-critical
services are
predeployed to
edge facilities
Using app without
edge is slow, users
are not quite content

8. Motivation: Edge Computing
2
Latency-critical
services are
predeployed to
edge facilities
How to discover local
edge servers? Are there
any?
Using app without
edge is slow, users
are not quite content

9. 3
CDN for Services?

10. NO!
3
CDN for Services?

11. NO!
3
CDN for Services?
Open Standards

12. NO!
3
CDN for Services?
Decentralized Solution
Open Standards

13. NO!
3
CDN for Services?
Something like the Internet!
Decentralized Solution
Open Standards

14. Motivation
• Growing demand for edge computing, making edge pervasive
• Applications should unfold towards the edge autonomously
• Managing applications by setting only high level objectives
• Autonomous adaptation to the changing environment
4

15. Motivation
• Growing demand for edge computing, making edge pervasive
• Applications should unfold towards the edge autonomously
• Managing applications by setting only high level objectives
• Autonomous adaptation to the changing environment
• Towards common standards of self-organized service
provisioning on global scale
4

16. Motivation
• Growing demand for edge computing, making edge pervasive
• Applications should unfold towards the edge autonomously
• Managing applications by setting only high level objectives
• Autonomous adaptation to the changing environment
• Towards common standards of self-organized service
provisioning on global scale
• Not only about the edge!
4

17. ICON: Intelligent Container
• Virtualized entity containing a service
• Built on top of Docker container, VM, unikernel, etc.
• Oriented towards microservices architecture (application is a collection of
loosely coupled services)
5

18. ICON: Intelligent Container
• Virtualized entity containing a service
• Built on top of Docker container, VM, unikernel, etc.
• Oriented towards microservices architecture (application is a collection of
loosely coupled services)
• Capable of observing the environment
• Monitors where incoming flows come from
• Discovers potential deployment locations
6

19. ICON: Intelligent Container
• Virtualized entity containing a service
• Built on top of Docker container, VM, unikernel, etc.
• Oriented towards microservices architecture (application is a collection of
loosely coupled services)
• Capable of observing the environment
• Monitors where incoming flows come from
• Discovers potential deployment locations
• Capable of taking decisions and acting autonomously
• Migrates or replicates closer to end-users to satisfy, e.g., latency objectives
• Terminates if utility falls below predefined threshold
7

20. Operation of ICON
• Initially, ICON is in the cloud
• One or multiple origination points
8

21. Operation of ICON
• Initially, ICON is in the cloud
• One or multiple origination points
• ICON monitors incoming flows
• Where requests are coming from?
9

22. Operation of ICON
• Initially, ICON is in the cloud
• One or multiple origination points
• ICON monitors incoming flows
• Where requests are coming from?
• ICON discovers deployment
locations
• In the domain of end-users or on a
path to it
10

23. Operation of ICON
• Initially, ICON is in the cloud
• One or multiple origination points
• ICON monitors incoming flows
• Where requests are coming from?
• ICON discovers deployment locations
• In the domain of end-users or on a path
to it
• ICON can take autonomous decisions
• Deploy replica of itself
11

24. Operation of ICON
• Initially, ICON is in the cloud
• One or multiple origination points
• ICON monitors incoming flows
• Where requests are coming from?
• ICON discovers deployment locations
• In the domain of end-users or on a path
to it
• ICON can take autonomous decisions
• Deploy replica of itself
12

25. The Operation of ICON
• Initially, ICON is in the cloud
• One or multiple origination points
• ICON monitors incoming flows
• Where requests are coming from?
• ICON discovers deployment locations
• In the domain of end-users or on a path
to it
• ICON can take autonomous decisions
• Deploy replica of itself
• Migrate closer to the end-users
13

26. Overlay of ICONs
14
Tokyo
Origin

27. Overlay of ICONs
15
Tokyo
Wellington
LisbonNew
York
Origin

28. Overlay of ICONs
16
Tokyo
Wellington
LisbonNew
York
Los
Angeles
Rio
Origin

29. Overlay of ICONs
• Tree is formed organically as ICONs
deploy replicas of themselves
• Efficient for information propagation
• Coordination
• Control
• Other topologies are possible (e.g.,
swarm)
17

30. Independent Edge Providers (IEPs)
• Facility where ICON can deploy itself
• Can be:
• Facility operated by a cloud provider (e.g., Cloudfront, Azure
Stack)
• Telco edge server (MEC)
• Crowdsourced: iExec, Golem, etc.?
• Runs container yard application
• Built on top of e.g., Kubernetes, Mesos or Docker Swarm
• ICON negotiates with the yard on deployment timeslot, hardware
resources, price, etc.
• Contractual agreements and transactions
• Smart contracts are possible option
18

31. Independent Edge Providers (IEPs)
• Facility where ICON can deploy itself
• Can be:
• Facility operated by a cloud provider (e.g., Cloudfront, Azure
Stack)
• Telco edge server (MEC)
• Crowdsourced: iExec, Golem, etc.?
• Runs container yard application
• Built on top of e.g., Kubernetes, Mesos or Docker Swarm
• ICON negotiates with the yard on deployment timeslot, hardware
resources, price, etc.
• Contractual agreements and transactions
• Smart contracts are possible option
18
Anyone can
establish an IEP

32. Discovery of IEPs
• Assumption: IEPs add edge
SRV records to authoritative
DNS servers of their domains
19

33. Discovery of IEPs
• Assumption: IEPs add edge
SRV records to authoritative
DNS servers of their domains
• Perform tomography
• Traceroute to end-users
20

34. Discovery of IEPs
• Assumption: IEPs add edge
SRV records to authoritative
DNS servers of their domains
• Perform tomography
• Traceroute to end-users
• Identify on-path domains
21

35. Discovery of IEPs
• Assumption: IEPs add edge
SRV records to authoritative
DNS servers of their domains
• Perform tomography
• Traceroute to end-users
• Identify on-path domains
• Perform SRV query
22

36. Discovery of IEPs
• Assumption: IEPs add edge
SRV records to authoritative
DNS servers of their domains
• Perform tomography
• Traceroute to end-users
• Identify on-path domains
• Perform SRV query
22

37. Discovery of IEPs
• Assumption: IEPs add edge
SRV records to authoritative
DNS servers of their domains
• Perform tomography
• Traceroute to end-users
• Identify on-path domains
• Perform SRV query
22

38. Intelligence of ICONs
• Easy version: Governed by utility function
• Weights are “control knobs”, e.g., budget vs. latency
• Application owner can also “hotswap” the entire utility function
• Thresholds: When expected utility of an action exceeds certain
boundary value:
• Replicate
• Migrate
• Terminate
• More complex version: Overlay forms a picture of the world and
adapts the network as a whole
23

39. Open Questions
24

40. Open Questions
• Intelligence
• What kind of intelligence do ICONs need?
24

41. Open Questions
• Intelligence
• What kind of intelligence do ICONs need?
• Discovery of the closest ICON
• How new clients will discover the ICON which is closest to them?
24

42. Open Questions
• Intelligence
• What kind of intelligence do ICONs need?
• Discovery of the closest ICON
• How new clients will discover the ICON which is closest to them?
• Security
• Trusted execution environments?
24

43. Open Questions
• Intelligence
• What kind of intelligence do ICONs need?
• Discovery of the closest ICON
• How new clients will discover the ICON which is closest to them?
• Security
• Trusted execution environments?
• Contractual agreement between ICON and independent edge
providers
• Are smart contracts the best option?
24

44. Future Work
25

45. Future Work
• Implementing container yard for hosting ICONs
25

46. Future Work
• Implementing container yard for hosting ICONs
• Negotiation protocol
• Like all routers support IP, facilities providing capacity to run services should
support some common protocol to negotiate on new service deployment
25

47. Future Work
• Implementing container yard for hosting ICONs
• Negotiation protocol
• Like all routers support IP, facilities providing capacity to run services should
support some common protocol to negotiate on new service deployment
• Sophisticated intelligence
• Proactively predicting where from most of the requests will come
25

48. Future Work
• Implementing container yard for hosting ICONs
• Negotiation protocol
• Like all routers support IP, facilities providing capacity to run services should
support some common protocol to negotiate on new service deployment
• Sophisticated intelligence
• Proactively predicting where from most of the requests will come
• Game theoretic analysis
• What if two (or more) competing applications are deployed using ICONs?
25

49. Future Work
• Implementing container yard for hosting ICONs
• Negotiation protocol
• Like all routers support IP, facilities providing capacity to run services should
support some common protocol to negotiate on new service deployment
• Sophisticated intelligence
• Proactively predicting where from most of the requests will come
• Game theoretic analysis
• What if two (or more) competing applications are deployed using ICONs?
• Specialized ICONs forming chains of services, and multitier apps
• Not limited to edge, e.g., a database may also be packed as ICON
• How to coordinate?
25

50. Summary: Why ICONs?
26

51. Summary: Why ICONs?
• IEPs to tackle growing demand for edge computing
• Less cloud monopoly
26

52. Summary: Why ICONs?
• IEPs to tackle growing demand for edge computing
• Less cloud monopoly
• Open infrastructure standards to enable ad hoc deployment of
services on global scale
26

53. Summary: Why ICONs?
• IEPs to tackle growing demand for edge computing
• Less cloud monopoly
• Open infrastructure standards to enable ad hoc deployment of
services on global scale
• Reducing administrative overhead: applications move across the
network themselves following high level objectives
26

54. Summary: Why ICONs?
• IEPs to tackle growing demand for edge computing
• Less cloud monopoly
• Open infrastructure standards to enable ad hoc deployment of
services on global scale
• Reducing administrative overhead: applications move across the
network themselves following high level objectives
• Taking advantage of autonomous local decision-making leads to
faster adaptation to changing environment
26

55. Summary: Why ICONs?
• IEPs to tackle growing demand for edge computing
• Less cloud monopoly
• Open infrastructure standards to enable ad hoc deployment of
services on global scale
• Reducing administrative overhead: applications move across the
network themselves following high level objectives
• Taking advantage of autonomous local decision-making leads to
faster adaptation to changing environment
26
Thank you!

56. Summary: Why ICONs?
• IEPs to tackle growing demand for edge computing
• Less cloud monopoly
• Open infrastructure standards to enable ad hoc deployment of
services on global scale
• Reducing administrative overhead: applications move across the
network themselves following high level objectives
• Taking advantage of autonomous local decision-making leads to
faster adaptation to changing environment
26
Thank you! aleksandr.zavodovski@helsinki.fi