[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] Re: Supposed impossibility of scaling for mobility



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

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

Robin Whittle wrote:
Hi Dino and Joel,

In the RRG meeting (audio http://videolab.uoregon.edu/events/ietf/
where there should soon be an archive of Tuesday's meeting) you and
perhaps some other folks were extremely negative about the routing
system, in the form of map-encap, achieving mobility directly.  So
much so, that I understand you want mobility not to be a goal.

Yet I believe that a fast-push hybrid push-pull system with reliable
notification from local query servers to ITRs will give users ~5
second latency real-time control over all the world's ITRs.  Also,
this system doesn't have the delay or drop problems inherent in pure
pull (LISP-ALT and TRRP), so that's another thing we wouldn't need
to worry about when asking people to adopt it.

You seem very committed to the idea that mobility is impossible to
achieve with map-encap.
...

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