1. Mobility in ICN: Network-assisted or endpoint-driven? A Myth to be ousted: Mobility is not solved! Computer Laboratory

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

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

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

5. 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?

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

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

8. 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!