Download
1 / 8
80 likes | 192 Vues
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
E N D
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 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) 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!
