1 / 28

ICN Scenarios

ICN Scenarios. Co-authors Point of View Elwyn, Gareth, Daniel, Gennaro, and Spiros (not edited :). DTN. Delay Tolerant Networks: Scenario. DTNs designed for situations where inter-node connectivity is subject to disruptions and/or high propagation delays

maille
Download Presentation

ICN Scenarios

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ICN Scenarios Co-authors Point of View Elwyn, Gareth, Daniel, Gennaro, and Spiros (not edited :)

  2. DTN

  3. Delay Tolerant Networks: Scenario • DTNs designed for situations where inter-node connectivity is subject to disruptions and/or high propagation delays • Typically store-and-forward message passing • ICN + DTN = ICDTN • Powerful scenario because many benefits from the technologies' integration • Benefits include: • Connectivity resilience: no need for E2E paths • Information resilience: no need to reach original source, can use cached copies in islands • New optimisations: can use delay tolerant and information-centric attributes to optimise protocols (e.g. transmission scheduling).

  4. Delay Tolerant Networks: Evaluation • Opportunistic content sharing scenario • ICDTNs can be used to share content (tweets) • Issue Interest and Data packets between phones • Ideal for underground trains • No need for global connectivity or resolution • Emergency scenario • ICDTNs can be used to disseminate emergency information (e.g. evacuation maps) • First responders and civilians can exchange Interest and Data packets between devices • Ideal when infrastructure collapses (e.g. during earthquakes)

  5. Delay Tolerant Networks: Evaluation • Challenges in the scenario • Response routing, linking caching decisions with routing, responder selection, lack of resolution infrastructure etc. • Challenges in the evaluation • Simulation environment: de facto DTN simulator (ONE) is not information-centric • Standards: DTN standardisation has not followed information-centric principles much • Traces: little trace data for mobile content consumption patterns (and mobility in many cases)

  6. Multiple Network Paradigms: Scenario • Networks probably won’t just be IP • (IC)DTN is a prime candidate for alternative • Less likely that ICN will be the new ‘waist’ • Solutions for auth and content management needed • ICN technology should be able to ‘span’ across the paradigm boundaries • Examples: • Internet Deep Space Network • Internet Disconnected sensor networks • Internet Comms/Power challenged regions

  7. Multiple Network Paradigms: Evaluation • Ensure the same architecture works in all individual paradigms, and then… • Ensure: • Common identification format - URI? • Common API usable in all paradigms • Operations work across boundaries in both directions with adequate performance • Don’t cause malfunctions in network or apps if operations originated from other paradigm region

  8. Multiple Network Paradigms: Evaluation • Challenges in the scenario: • See the DTN scenario, plus… • Avoiding paradigm specific assumptions • Especially performance in the face of delay • Building effective gateways • Challenges in the evaluation: • Practical networks: currently not many exist • Simulation: No simulators exist AFAIK • Traces: Limited data available (N4C/SAIL)

  9. Multiply Connected Nodes and Economics

  10. Multiply Connected Nodes and Economics: Scenario • Smartphones likely to progress to parallel net connectivity instead of one at a time • Driven by • increased bandwidth in 4G • Advent of Small Cell Networks (SCN) and HetNet • New generation Bluetooth • Could have 4G, Wi-Fi & high speed Bluetooth • Economics becomes relevant • Which network caches what? • How to know which network to request content from? • Is there a mechanism for cache sharing?

  11. Multiply Connected Nodes and Economics: Evaluation • Evaluation across multiple network types needs: • a combination of technical and economic aspects • to capture their various interactions • Scenarios should aim to • illustrate scalability, efficiency and manageability • show the use of traditional & novel network policies. • specifically address how different actors have proper incentives, both • in a mixed environment of IP and layered ICN, and • (maybe eventually) in a pure ICN realm.

  12. Multiply Connected Nodes and Economics: Evaluation • Challenges in the scenario: • Finding content across multiple connections • Determining how to incentivise network owners • Designing policies across multiple networks • Challenges in the evaluation: • How to evaluate the economic aspects • Not a purely technical challenge

  13. IoT

  14. Daniel Corujo Internet of Things in ICN • Subjects ICN deployments to a myriad of requirements/possibilities/scenarios • Amount of generated data (huge sensor networks) • Hinting towards ICN+BigData (would anyone like to talk about this?) • True heterogeneous environment • Device characteristics (power, memory, battery, …) • Network technology and deployment (wired, wireless, coordinated, uncoordinated, static, mobile, …) • Information consumed/generated (Real-Time, n-RT, …)

  15. Daniel Corujo Internet of Things in ICN • ICN can contribute • By providing new/revolutionary/optimized ways of disseminating the IoT-generated/consumed information • Leveraging content naming and forwarding • By extending interfacing capabilities • i.e., “faces” instead of “interfaces”

  16. Daniel Corujo Scenarios/RFC-evolution • Three-level approach • Device/Application level: Optimize how the information is generated and moved around the access network • Core level: How can the Telco benefit from this? • Service Platform level: How to suite the information towards a customer/Service Provider business? • Analysis of the impact that the different ICN solutions have in these kind of environments • Large-scale testing results • Evolve to “on-site” developments

  17. Daniel Corujo Mobility in ICN • Optimization mechanisms need to be deployed and supported by mobility management • Detect handover opportunities/requirements • Maintain expected/experienced link conditions • Prepare target handover link • Tandem with other network mechanisms for added support • I.e., AAA, Security, etc.

  18. Daniel Corujo Scenarios/RFC • Think of this as well at Mobile Node level • Naming information can be helpful here • But caching might not! • Plus, it runs on battery • Many ICN deployments • How to best benefit from all of them? • Large-scale testing needed • Integration with other network mechanisms/aspects needed

  19. Smart City

  20. Challenges in a Smart City (sec. 2.11) • In a Smart City, a very huge number of devices will coexist; they (equipped by heterogeneous technologies) will interact among them to execute, join, and participate to a myriad of services. As a consequence, the following challenges will arise: • availability issue: need to fetch contents in a fast, reliable, and effective way; • location-dependence issue: no need to identify the location of data; • security issue: contents should be trusted independently from the location and the identity of who is providing them; • mobility issue: avoiding service interruption when users move across different access networks; • scalability issue: limited storage, bandwidth, and computational capabilities of service providers should not influence the quality of services; • fault-tolerance issue: ensure the resilience of ICT services to system failures.

  21. More detailsn Sec. 2.11 on why weneedSmart Cities need for ICN ? • The current Internet architecture is not able to efficiently face all of the aforementioned challenges • The ICN could fully resolve these issues by introducing: • addressing of contents through names; • in-network caching strategies; • routing-by-name techniques; • simplified management of mobility; • native support of security features; • simplified support for peer-to-peer communications; • native support for multicast communications. • The adoption of ICN in the context of Smart City could give enormous advantagesfor the improvement of the quality of services offered to all the citizens. • This demonstrates that Smart Cities represent a very important baseline scenario for ICN-based solutions.

  22. Sec. 3.3: more suggestions about what Zipf’s law to be used in comparison? Zipf’s law: Probability of requesting the content with rank “i” P(X=i) = ( 1/i^(alpha) ) / C, with C = SUM(1 / j^(alpha)), alpha > 0. The sum is obtained considering all values of j, 1 <= j <= M. It can be very useful for the definition of unified and shared evaluation settings for ICN simulations and tests, such as topologies, traffic loads and relevant metrics. In the present version of the draft we describe how Zipf’s law describes several traffic loads Question: define a specific traffic load condition using Zipf’s law for comparison?

  23. New subsection in sec. 3: Routing strategies to be used in ICN performance evaluation? • The design and the evaluation of aICN requires also to define the adopted Routing Protocol which is heavily correlated to the topology, the traffic load as well as to the set of relevant metrics used to validate it… • ..But.. • for a consistent performance evaluation in our humble opinion we think that could be very useful to consider in the scenarios comparisons using different routing strategies: • Well known routing strategies, like Flooding, Best Route, Min Delay, as a minimum requirements and a starting point. • Concurrent new ICN routing protocols (e.g., bloom-filer based) , if their implementation is feasible or it has already been released.

  24. Choosing Relevant Metrics • Goal: identify metrics for comparing between ICN approaches and against host-centric network • Survey of metrics in existing ICN approaches • Whole-approach metrics (traffic, system) • Component metrics (resolution, routing, cache) • Traffic metrics options • QoS, e.g., IETF IPPM • Application-level, e.g., playout continuity for streaming • QoE, e.g., MOS for VoIP • Future work • Extend IETF IPPM for ICN • Sync terminology (traffic, system, component, etc.)

  25. ICN Security Evaluation

  26. Security Considerations - 1 • Authentication • ICN majors on authentic content • Must handle both immutable & dynamic content • Authorization, Access Control, Statistics • Major research challenge • ICN architectures are good for open access • May be encrypted but not access controlled • Content owners lose control after publication • Difficult to collect access statistics • How to revoke content once published?

  27. Security Considerations - 2 • Privacy • Caching and access via caches has an impact on privacy • Request source anonymity doesn’t stop bad actors identifying material accessed and monitoring network traffic to identify sources • Just a bit more difficult than with an address • Longer lifetime of data in cache gives longer timescale for analysis

  28. Security Considerations - 3 • Changes to Network Threat Model • Trade off: network efficiency  privacy • Greater attack surface in ‘more powerful’ routers • ACLs no longer useful – no source address • DoS scenarios are altered • Caches may have per-request state • Caches can be abused • Bad actors cache bad content • DoS by decreasing cache efficiency with rubbish content • Privacy issues since caches are usually open access • Evaluation needs to consider how threats are mitigated

More Related