mobility in icn network assisted or endpoint driven n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Mobility in ICN: Network-assisted or endpoint-driven? PowerPoint Presentation
Download Presentation
Mobility in ICN: Network-assisted or endpoint-driven?

Loading in 2 Seconds...

play fullscreen
1 / 8

Mobility in ICN: Network-assisted or endpoint-driven? - PowerPoint PPT Presentation


  • 93 Views
  • Uploaded on

Mobility in ICN: Network-assisted or endpoint-driven?. A Myth to be ousted: Mobility is not solved!. Computer Laboratory. Objective of this Discussion. Debunking some of the obvious “solutions” Stimulating a discussion on what we learned from current working systems

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Mobility in ICN: Network-assisted or endpoint-driven?' - starr


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
mobility in icn network assisted or endpoint driven

Mobility in ICN: Network-assisted or endpoint-driven?

A Myth to be ousted: Mobility is not solved!

Computer Laboratory

objective of this discussion
Objective of this Discussion
  • Debunking some of the obvious “solutions”
  • Stimulating a discussion on what we learned from current working systems
  • Tie into architectural discussion of ICN
a myth debunked mobility in icn is solved
A Myth Debunked: Mobility in ICN is Solved

Let us focus on subscriber mobility first!

  • First heard in PSIRP review, mentioned also in CCN paper
  • Solution is so apparently simple:
    • When moving from one network attachment to another, we simply re-issue our interest (e.g., through re-subscription, re-sending interests…)
    • Information will now magically flow again to your (mobile) terminal
a myth debunked mobility in icn is solved 2
A Myth Debunked: Mobility in ICN is Solved (2)

Let us think about this in terms of numbers:

  • Let N be the number of active information items being used at the time of handover
  • A terminal hardly consumes only one information item!

-> what is the right assumption for N?

  • Even a browsing-like session can have easily tens of items “on a page”
  • And there’s stuff going on in the background, e.g., sync, IMs, (cloud) file systems, …

-> Let us start with N=1000

  • Every handover will create 1000*(average_length_of_ID+Ethernet header*) bytes upstream control traffic -> easily about >30kBytes per handover and per device!

-> that hardly scales: it is simple but ineffective!

(*) in case you use Blackadder directly on Ethernet – you need to add any overlay overhead for other deployments

a myth debunked mobility in icn is solved 3
A Myth Debunked: Mobility in ICN is Solved (3)

Let us now move on to publisher mobility

  • Re-publishing will cause AT LEAST the same overhead!
    • In CCN it is unclear how ‘publication’ is really done, so hard to say
  • Solution: anchor points
    • Information is effectively ‘uploaded’ to stationary anchor point
    • All subscriptions/interests go to (stable) anchor point

-> SOLVED?!

BUT: Do we really want to rely on infrastructure nodes to handle local mobility scenarios?

let us look at the real world
Let us look at the REAL World
  • Non-IP world
    • Network-assisted approaches dominate
    • E.g., RNC/BS interaction in GSM (with specs for up to 160km/h)
    • Mobile might provide handoff trigger
    • Make-before-break is the goal
  • IP world
    • Largely endpoint-driven
    • Can only provide break-before-make
    • SEAMOBY work in IETF aimed at make-before-break -> inconclusive standards
    • Intra-domain handovers largely at, e.g., WiFi level
how to realistically achieve network assistance
How to (Realistically) Achieve Network Assistance?
  • Path (re-)computation seems almost inevitable when aiming for network assistance
    • However, it is NOT the only way!
  • Computation of full path unrealistic -> regionalise mobility management and therefore path computation
    • Open issue how to do this in PURSUIT
  • In PURSUIT, path re-computation would only affect the publisher!
    • Open issue how to handle mobility of large groups
  • Path re-computation can be triggered by any, e.g., link information
    • Much of the previous mobility work needs ‘translation’ into ICN!
take away
Take Away
  • Mobility can be done in a simple yet ineffective way
    • BUT: It is NOT solved in ICN!
  • Realistically, only a combination of network assistance with terminal support works
    • ICN changes little on that assumption
  • One form of network assistance is path (re-)computation
    • PURSUIT is well suited for this task since it separates functions appropriately!

Most importantly: much work is still needed!