[RRG] Re: Supposed impossibility of scaling for mobility

[Robin Whittle <rw@firstpr.com.au>]

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-push-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