icn scenarios
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
ICN Scenarios
Co-authors Point of ViewElwyn, 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 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
IoT
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?
Security Considerations - 2
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
Security Considerations - 3
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