RE: [RRG] Re: Supposed impossibility of scaling for mobility

[<hannu.flinck@nsn.com>]

Routing and mobility act on different time scales. 5 - 10s handovers are
not acceptable in any working system. I agree that an ideal routing
scalability solution could support and handle some forms of mobility
(maybe network mobility?), but I fail to see why to put so much emphasis
to mobility support as we do not even have the scalability part carved
out. 

Robin, your solution seems to build on the idea that the MN could tell
its location and from there to determine where the closest TTR is
located. Are you assuming GPS or are you possibly concluding from the
EID (care of address) that is not topologically determining? Or are you
pinging the original TTR?

Many times in the real life systems it is exactly the access that costs,
therefore the access authorization plays a critical role. TTR or some
other part of the system, maybe the AAA needs to be involved to grant
the access. Naturally we need to bring in the user identities as well
for the AAA.

There are a number of active WGs addressing the various aspects of the
mobility, shouldn't we co-ordinate with them?

But now the routing part of the problem is escaping me!

Regards Hannu 

>-----Original Message-----
>From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf 
>Of ext Robin Whittle
>Sent: Wednesday, March 12, 2008 15:36
>To: Routing Research Group
>Cc: Joel M. Halpern
>Subject: [RRG] Re: Supposed impossibility of scaling for mobility
>
>Hi Joel,
>
>Thanks for your response, in which you wrote:
>
>> Robin,
>>     I think that you are misunderstanding my point.
>
>> Let me try listing some items I take as givens.  Others may disagree.
>> 
>> 1) Solving problems that we don't need to solve is going to weaken a 
>> solution.  (Good solutions will, as Noel seems to like to put it, 
>> unexpectedly solve additional problems.  But that is different for 
>> designing to solve a varied selection of problems all at once.)
>
>I think this is not necessarily the case.
>
>Multihoming service restoration and portability both can be 
>done best by the end-user deciding which ETR to use, in their 
>own way, and having fast control of the world's ITRs to 
>implement that decision.  The other proposals add a lot of 
>complexity to the ITRs or Default Mappers trying to do what 
>the designers imagine the end-user would want to do.  But with 
>a fast push system with notify, the designers don't need to 
>try to anticipate end-user's desires - the system lets the 
>end-user control the mapping in real time.
>
>This is the best arrangement for multihoming etc. and it so 
>happens that this arrangement also supports a new form of mobility.
>
>I didn't design Ivip to do this, but by adding TTRs, you can 
>make it do a great new kind of mobility.  TTRs can be added to 
>any map-encap system - they behave to the rest of the system 
>like ETRs.  They can't be prevented either.  They could be 
>added to LISP, APT or TRRP, even without protocol 
>standardisation or permission by the IETF.
>
>
>> 2) "Mobility" is not a single problem.  In the text I have 
>elided, you 
>> indicate that you specifically mean mobility over 100s or 1,000s of 
>> kilometers.  But other folks mean other things.  Solving 
>"Mobility" is 
>> almost meaningless, given the range of problems.
>
>Well, I have written more expansively than simply "Mobility" 
>on what Ivip would provide:
>
>http://psg.com/lists/rrg/2008/msg00535.html
>http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-pu
>sh-00.pdf
>
>including what it wouldn't provide and which aspects of 
>mobility access networks could provide better than Ivip.
>
>
>> 2') My personal opinion is that the value in addressing the 
>long range 
>> mobility problem is extremely small.  The end station rarely if ever 
>> needs to preserve its connectivity when moving between arbitrary 
>> connectivity points separated by 1,00s of km.
>
>This is like saying in the early 70s that there really isn't a 
>great need for mobile telephones.
>
>Sure, we get on fine without globally portable, mobile, IP 
>addresses now.  But if we had them, everyone and their dog 
>(Aussie expression) would want one, and would be prepared to 
>pay for it.
>
>
>> There are cases where
>> special infrastructure and special needs require such, but you cope 
>> with those in other ways.  There are cases where local moves are not 
>> topologically local.  (And various groups have looked at properties 
>> that help address those cases.)
>
>Once you have a global system of ITRs, all you need to do is 
>control them in "real-time" and people will of their own 
>accord create TTRs and provide the powerful mobility I am describing.
>
>Since we need to build this network, we might as well do a 
>proper job of it, I think.
>
>Having your own IP address which you keep on your cellphone 
>always sounds like overkill now, but it would be easier than 
>mucking around with DNS, restarting sessions etc.  The path 
>lengths would be close to optimal, and the correspondent hosts 
>can be ordinary computers anywhere.
>
>
>> 2'') Yes, mobility can be thought of as just another change.  But it 
>> has very different characteristics than the changes caused either by 
>> re-homing or by failure / recovery.  So treating it as 
>identical will, 
>> in my opinion, likely hurt both the base solution and the mobility 
>> handling.
>
>In that case, you should be able to point out where in my 
>proposals, the extra provisions for mobility cause some 
>detriment to the initial purpose of achieving multihoming and 
>portability of addresses in a scalable fashion.
>
>Actually, nothing at all is added to Ivip's fast-push system 
>or the ITRs.  Its just that you can use this system with TTRs 
>acting like ordinary ETRs, and do this new form of mobility.
>
>
>> 3) Every approach to a problem has limits.  And we should 
>assume that 
>> those limits are going to be lower than we expect.  As one member of 
>> this community said to me on many occasions "The difference between 
>> theory and practice is even larger in practice than it is in theory."
>> [1]  And we know from experience which way that difference will go.
>
>> So, given that all the solutions will be less capable than 
>we expect, 
>> and given that reducing the problems to be addressed generally gives 
>> one more head-room in any solution, it seems to me to be a 
>really good 
>> idea to NOT solve problems we don't need to solve.
>
>You are so sure that by doing mobility I must be compromising 
>multihoming or scalability etc. that you don't feel the need 
>to read and criticise my actual proposal?
>
>It is not necessarily true that a solution will be less 
>capable than we expect.
>
>IPv4 is a good example - I can't imagine its designers really 
>expected it to do what it does so well today.
>
>I didn't design Ivip to do mobility - I just discovered that 
>with a simple addition, which doesn't affect the basic Ivip 
>system in any way, it does it.  The system promises to be more 
>capable than I planned it to be.  This is partly a result of 
>the modular approach I took - splitting off the failure 
>detection and ETR selection decision and expecting the 
>end-users to do this.
>
>
>> That doesn't mean that we should refrain from looking at interesting 
>> ideas, like your fast-push.  It just means that we should evaluate 
>> them against the alternatives for the problems that we need 
>to solve, 
>> rather than choosing a mechanism based on a problem we don't 
>need to deal with.
>
>I am not saying Ivip's mobility capability be a justification 
>for it doing anything else less capably.
>
>Ivip is less capable in one sense, in that it doesn't have 
>explicitly load sharing.  But by splitting the traffic over 
>multiple IP addresses and having real time control over the 
>ETR used for each such address, or micronet of addresses, you 
>may be able to achieve better load sharing than by BGP or than 
>by LISP, APT or TRRP.
>
>That is a result of simplifying the mapping data and the ITR - 
>it is not a compromise prompted by anything I had to do to 
>support mobility.  I changed nothing - I just invented the 
>idea of a TTR.
>
>Hybrid push-pull is the only way to eliminate delay (apart 
>from a few tens of milliseconds) apart from the unscalable 
>full-push of NERD.  So in terms of no delay vs delay of 
>initial packets, it is APT and Ivip vs LISP-ALT and TRRP.
>
>ALT and TRRP can scale to endless EIDs, but as far as I can 
>see, neither would stimulate users to generate more than a few 
>tens or hundreds of millions - since neither can do mobility.  
>So it is no benefit that ALT or TRRP could easily scale to a 
>billion EIDs.
>
>If NERD, ALT, APT or TRRP was built, pretty soon, folks would 
>be trying to add fast push to it, to do mobility.  The result 
>would be far uglier than a system like Ivip which was designed 
>to do fast push with reliable, fast, local pull and notify.
>
>
>> We have all recognized that the rate*state (or churn, or whatever 
>> characterization matters most) is an important factor in the 
>> complexity of the problem.  Mobility, even bounded subsets of the 
>> mobility problem, adds to that measure.  So unless there is some 
>> driving need, I would prefer to keep those factors out.
>> 
>> Yours,
>> Joel M. Halpern
>> 
>> [1] Steve Crocker
>
>OK - I understand you have generalised reasons for pessimism, 
>based on long experience.  I regret that I haven't yet 
>prompted you to actually read and critique my proposal.
>
>  - Robin
>
>
>--
>to unsubscribe send a message to rrg-request@psg.com with the 
>word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
>

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg