I have heard it now too often (as recent as during the AsiaFI summer school) and it needs to be addressed here: the mobility problem in ICN is NOT solved by simply re-subscribing (or re-sending interests, depending what ‘language’ you are speaking) from the subscriber side!
With recent discussions, e.g., in the IRTF, that focus on publisher mobility, there is an assumption that I’m hearing too often lately in presentations, namely that subscriber mobility is a done deal - just re-subscribe!
Yes, it is a brute force solution to a problem that is significantly more challenging than the simple solution suggests. Re-subscribing is indeed possible but one has to keep in mind the possible implications of this approach. Per device, there are likely many pieces of information that the device’s software is interested in. Hence, what looks like a straightforward solution quickly turns into a nightmare to happen on your wireless link.
Let’s expand on this by assuming a mobile device that holds 1000 active subscriptions to individual information items – that’s not an unreasonable number, considering mashed-up (and highly desegregated) content on, e.g., a webpage or a distributed filesystem app running on your device (think Google Drive), or many other possible apps running while you are using your mobile device. Changing your access point now leads to re-subscriptions to these 1000 items – in a basic re-subscription solution, this leads to an upstream traffic burst of approximately 1000*(average_length_of_ID+Ethernet header) (in case you use Blackadder which operates directly on Ethernet – you need to add any overlay overhead for other deployments). With an average length of, say, 30 bytes per ID, that’s 30k+ per handover. Make that 10000 objects being active, and you reach 300k+. At the same time, let us consider mobility in wireless environments where more than one device is handing over at any time – so you need to multiply any figure with the number of mobile handsets that are doing so.
You possibly see where this is going. Re-subscribing is, clearly, a SIMPLE solution to a problem that can be very hard to solve EFFICIENTLY!
The considerations above leave out the computational overhead that these messages create (either at the topology manager in the PURSUIT case or through the distribution within the network and the necessary PIT updates in CCN). I even assert that this computational overhead is something that we will need to deal with in any case. The main point here though is that the wireless access network is a scarce resource by any measure, even with increasing link speeds in recent technologies. Filling this bandwidth with control traffic, initiated by the mobile handset, seems just simply wrong, while seemingly ignoring the possibility for network-assisted handovers.
It is the latter that is one of the reasons for the explicit topology management that is realised in the PURSUIT architecture. While it allows for simple solutions such as re-subscription for mobility management, it also allows for network-assisted solutions that can possibly avoid a signalling avalanche that is outlined above.
I wish that in future presentations, I will see less claims that subscriber mobility is a done deal - it’s hard and let’s realise that!