PURSUIT Architecture From Ideas over an Approach to Design to an Architecture and Its Choices

1. PURSUIT ArchitectureFrom Ideas over an Approach to Design to an Architecture and Its Choices Dirk Trossen, Computer Laboratory

2. The Breadth of the Challenge Ideas Design Approaches Architectures Space of ICN Design Choices

3. The Coverage of PURSUIT Ideas Design Approach Architectures Space of ICN Design Choices

4. Take the Input… Better alignment of interests Operating on Information (structures) Pub/sub service model Late binding (to location) Incorporate computation & storage A new way to design systems Increased optimization potential Reflexive vs. Reflective

5. …Borrow From Meta-Reasoning… • Different timeframes for operations (and their optimization) • But possibly through the same approach for design? Operational Problem Threshold-based Trigger Reflective Processes React Attention Filter Measure Reflexive Processes Ignore

6. Routing …And Turn It All Into A Vision! • Provides an improved impedance match between net & svc/apps • Better aligned with today’s application concepts • Provides tussle delineation of crucial functions • Better suited for future (unknown) business models • Enables optimized sub-architectures • Better suited for variety of access technologies • Provides high performance • Scales to the needs of the Future Internet Envision a system that dynamically adapts to evolving concerns and needs of their participating users Security network economics Unification of wireline and wireless

7. Starting Point: Solving Problems in Distributed Systems • One wants to solve a problem, each of which might require solving another problem • Examples: • Send data from A to B(s), involving fragmentation along the link(s) • Disseminate a video over a local network • Problems involve “a collection of information that”an implementation “can use to decide what to do”, which is to implement a problem solution (*) -> Computation in distributed systems is all about information dissemination (pertaining to a task at hand) *S. J. Russell, P. Norvig, “Artificial Intelligence: A Modern Approach”, 2nd Edition, Pearson Educ., 1998

8. Turning into Design Principles… • Everything is Information • Higher-level information semantics are constructed as graphs of information • Information is scoped • Provide a simple mechanism for structuring data and limiting the reachability of information to the parties having access to the particular mechanism that implements the scoping • Functionality is scoped • Functions to disseminate information implement a scoped strategy! • Scoped information neutrality • Within each scope of information, data is only forwarded based on the given (scoped) identifier • Ensure balance of power • No entity is provided with data unless it has agreed to receive those beforehand

9. …Translated onto Invariants (Across Architectures) • Flat-label referencing: identify anything as information • Scoping: group information and functions (including scopes themselves) • Pub/sub service model: anything is delivered by pub/sub • Separation of functions: each scope provides functions for finding (rendezvous), constructing (topology) and delivering (forwarding) • Can be implemented jointly for optimization reasons • Dissemination strategy per scope: the implementation of the functions is described by a dissemination per scope • Inherited by each sub-scope

10. Information is everything and everything is information Scopes build information networks Notion of metadata by linking to other identifiers Policy is metadata Producers and consumers need no internetwork-level addressing! Information-Centrism is Key Data: Mail Data: Picture Governance policy Governance policy Scope Company A Scope Family Scope Friends Governance policy Spouse Father Friend Colleague

11. Operating on Graphs of Information SId1 SId2 SId1 SId1 SId2 RId3 RId4 RId1 RId2 RId3 SId3 RId1 RId2 RId3 data 256 bit Statistically unique within its scope – although global uniqueness can be defined through dissemination strategy e.g., P:L

12. Information Semantics: Immutable vs. Mutable Items • Documents • Each RId points to immutable data (e.g., document version) • Not well suited for real-time type of traffic • Each item is identifiable throughout the network • Channel • Each RId points to channel of data (e.g., a video stream), i.e., the data is mutable • Well-suited for video type of traffic • Problems with caching though (since no individual video segments visible)

13. Idea: Use an algorithm to tie together a set of data items Allow for data items to be addressed individually through algorithmically generated RIds Allow for addressing collection through algorithm (and its seed) Example: reliable fragmentation Thought exercise: algorithmic scoping! Access ‘channel’ via seed RId, go to segment via alg(seed) Publish alg as metadata to seed -> Channel implicitly visible to network, together with individual segment RIds, by virtue of alg as implicit channel Id, alg being app-specific Information Semantics: Algorithmic Identification alg(seed) Segment determined via RId = alg(seed), e.g., alg = seqNo

14. Put Together: A Functional Model For Solving Problems • Each scope implements the solution to a problem • The architecture is concerned with facilitating the exchange of information for the problem solution! • Think object-oriented! • Functional and information scoping is achieved here! • Strategies are represented through standards, running code etc! • Strategies can be represented as explicit representations • Semantic Web technologies help here • Functions need not to be strongly separated • Example: link-local dissemination! Pub/Sub Service Model Dissemination Strategy Rendezvous Topology Forwarding Functional scoping Information scoping SId RId RId Recursion

15. An E2E Principle… The problem in question can be implemented through an assembly of sub-problem solutions, whose individual dissemination strategies are not in conflict with the ones set out by the problem in question. • Hence, problems are assembled to larger solutions by recursively applying the scoping invariant of the functional model! • Conflicts are avoided through design and re-design, e.g., via standards procedures! • Can extend this to runtime reconciliation! NOTE: I leave it as a thought exercise to relate this to the IP E2E principle!

16. Core Functions vs. Problem Solutions • Core functions • Rendezvous, topology management and forwarding • Finding, constructing a delivery graph and delivering along this graph • Problem solutions • Low-level: anything from reliability over retransmissions to fragmentation but also management problems (e.g., link state collection) • High-level: anything from complex information space (say video collection) to individual items and their delivery (say a single video)

17. Where is the Boundary? Example: Reliability • Realize as part of (core) forwarding function • Becomes part of dissemination strategy • Realize as individual problem solution over given forwarding function(s) • Can be realized over many strategies Best Current Practice here: Minimality and flexibility • Favors option 2 since • it keeps individual dissemination strategies (and their realization) minimal • Allows for different reliability solutions over a single strategy • BUT: it does not prohibit option 1!

18. Apps pub sub Node Architecture pub pub Service Model RP : Rendezvous point ITF : Inter-domain topology formation TM : Topology management FN : Forwarding node Put Together in A High-Level Architecture Fragmentation Caching Topology Rendezvous Helper ITF ITF RP … RP Rendezvous Network Error Ctrl Network Architecture Forwarding TM TM TM TM FN Forwarding Network Forwarding Network Forwarding Network Forwarding Network

19. Realizing Our Architecture • Apply the design approach (i.e., functional model and E2E principle) across the various level of the architecture • Node/Link-local as well as global realizations • Implement the core functions at these various levels • Rendezvous, topology, forwarding • Add specific appropriate network-level problem solutions • Reliability, fragmentation, … • Two Areas highlighted in the following: domain-local forwarding & mobility

20. Conclusions • PURSUIT is not (only) about architecture – it is about a new way to design systems • Concise foundation in a functional model approach allows for this new design • Core for this approach is information required for a computational problem in a holistic view • Architectures are enabled by a (possibly differing) choice of solutions • That includes architectures like DONA, CCN, even IP! • Working on particular choices ourselves though • More to come in later presentations

21. A Subset of the Larger Team • Cambridge: George Parisis, Ben Tagger • AUEB: George Xylomenos, Christos Tsilopoulos, Xenofon Vasilakos, Alex Kostopoulos • CERTH: Paris Pflegkas, Vasilis Sourlas • Aalto: Kari Visala, Pasi Sarolahti, Sasu Tarkoma, Dmijtri Lagutin, Arto Karila • NSN: Jarno Rajahalme • RWTH: Janne Riihijarvi, Borislava Gajic • Ericsson: Petri Jokela, Andras Zahemsky, Jimmy Kjallman (and Pekka Nikander, of course) • CTVC: Stuart Porter, Martin Long • MIT: Karen Sollins, David Clark • ISI: John Wroclawski, Steve Schwab