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
• Tie into architectural discussion of ICN
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 reissue 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)
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)
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
• 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?
• 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
• 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!