Download Co-authors Point of View

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


ICN + DTN = ICDTN


Typically store-and-forward message passing
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
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)
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)
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
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
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)
Multiply Connected Nodes and
Economics
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?
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.
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
IoT
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, …)
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”
Daniel Corujo
Scenarios/RFC-evolution
Three-level approach
1) Device/Application level: Optimize how the information
is generated and moved around the access network
2) 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 results
Evolve to “on-site” developments
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.
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
Daniel Corujo
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 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.
More details n Sec. 2.11 on why we
needSmart 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 advantages
for 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.
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.
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
24
Sync terminology (traffic, system, component, etc.)
ICN Security Evaluation
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?
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
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