icn scenarios

ICN Scenarios

Co-authors Point of ViewElwyn, Gareth, Daniel, Gennaro, and

Spiros(not edited :)

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

Delay Tolerant Networks: Evaluation

Opportunistic content sharing scenarioICDTNs can be used to share content (tweets)

Issue Interest and Data packets between phones

Ideal for underground trainsNo 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)

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 evaluationSimulation environment: de facto DTN simulator

(ONE) is not information-centricStandards: DTN standardisation has not followed

information-centric principles muchTraces: little trace data for mobile content

consumption patterns (and mobility in many cases)

Multiple Network Paradigms: Scenario

Networks probably won’t just be IP(IC)DTN is a prime candidate for alternativeLess 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 NetworkInternet Disconnected sensor networksInternet Comms/Power challenged regions

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 paradigmsOperations work across boundaries in both directions

with adequate performanceDon’t cause malfunctions in network or apps if operations

originated from other paradigm region

Multiple Network Paradigms: Evaluation

Challenges in the scenario:See the DTN scenario, plus…Avoiding paradigm specific assumptions

Especially performance in the face of delayBuilding effective gateways

Challenges in the evaluation:Practical networks: currently not many existSimulation: No simulators exist AFAIKTraces: Limited data available (N4C/SAIL)

Multiply Connected Nodes and Economics

Multiply Connected Nodes and Economics: Scenario

Smartphones likely to progress to parallel net connectivity instead of one at a timeDriven by

increased bandwidth in 4GAdvent of Small Cell Networks (SCN) and HetNetNew generation Bluetooth

Could have 4G, Wi-Fi & high speed Bluetooth

Economics becomes relevantWhich network caches what?How to know which network to request content from?Is there a mechanism for cache sharing?

Multiply Connected Nodes and Economics: Evaluation

Evaluation across multiple network types needs:a combination of technical and economic aspectsto capture their various interactions

Scenarios should aim to illustrate scalability, efficiency and manageabilityshow 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.

Multiply Connected Nodes and Economics: Evaluation

Challenges in the scenario:Finding content across multiple connectionsDetermining how to incentivise network ownersDesigning policies across multiple networks

Challenges in the evaluation:How to evaluate the economic aspects

Not a purely technical challenge

Daniel Corujo

Internet of Things in ICN

Subjects ICN deployments to a myriad of requirements/possibilities/scenariosAmount of generated data (huge sensor networks)

Hinting towards ICN+BigData (would anyone like to talk about this?)

True heterogeneous environmentDevice characteristics (power, memory, battery, …)Network technology and deployment (wired, wireless,

coordinated, uncoordinated, static, mobile, …)Information consumed/generated (Real-Time, n-RT, …)

Daniel Corujo

Internet of Things in ICN

ICN can contributeBy providing new/revolutionary/optimized ways of

disseminating the IoT-generated/consumed information

Leveraging content naming and forwardingBy extending interfacing capabilities

i.e., “faces” instead of “interfaces”

Daniel Corujo

Scenarios/RFC-evolution

Three-level approach1) Device/Application level: Optimize how the information is

generated and moved around the access network2) Core level: How can the Telco benefit from this?3) 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 resultsEvolve to “on-site” developments

Daniel Corujo

Mobility in ICN

Optimization mechanisms need to be deployed and supported by mobility managementDetect handover opportunities/requirementsMaintain expected/experienced link conditionsPrepare target handover linkTandem with other network mechanisms for added

supportI.e., AAA, Security, etc.

Daniel Corujo

Scenarios/RFC

Think of this as well at Mobile Node levelNaming information can be helpful hereBut caching might not!Plus, it runs on battery

Many ICN deploymentsHow to best benefit from all of them?

Large-scale testing neededIntegration with other network mechanisms/aspects

needed

Smart City

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 e ective way;ff• 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 di erent ffaccess 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.

More details n Sec. 2.11 on why we needSmart Cities need for ICN ?

The current Internet architecture is not able to e ciently face all of the ffiaforementioned 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 advantages for the improvement of the quality of services o ered to all the citizens.ff

This demonstrates that Smart Cities represent a very important baseline scenario for ICN-based solutions.

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?

New subsection in sec. 3: Routing strategies to be used in ICN performance evaluation?

The design and the evaluation of a ICN 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 approachesWhole-approach metrics (traffic, system)

Component metrics (resolution, routing, cache)

Traffic metrics optionsQoS, e.g., IETF IPPM

Application-level, e.g., playout continuity for streaming

QoE, e.g., MOS for VoIP

Future workExtend IETF IPPM for ICN

Sync terminology (traffic, system, component, etc.)

ICN Security Evaluation

Security Considerations - 1

AuthenticationICN majors on authentic contentMust handle both immutable & dynamic content

Authorization, Access Control, StatisticsMajor research challengeICN architectures are good for open access

May be encrypted but not access controlled

Content owners lose control after publicationDifficult to collect access statisticsHow to revoke content once published?


PrivacyCaching and access via caches has an impact on

privacyRequest 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


Changes to Network Threat ModelTrade off: network efficiency privacyGreater attack surface in ‘more powerful’ routersACLs no longer useful – no source addressDoS scenarios are altered

Caches may have per-request state

Caches can be abusedBad actors cache bad contentDoS by decreasing cache efficiency with rubbish contentPrivacy issues since caches are usually open access

Evaluation needs to consider how threats are mitigated

icn scenarios

Documents