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

["Tony Li" <tony.li@tony.li>]

|Excerpts from Tony Li on Wed, Mar 12, 2008 09:26:06AM -0400:
|> No matter what you and I say, some folks will try to use the routing
|> architecture to provide mobility (e.g. Connexion
|> http://en.wikipedia.org/wiki/Connexion_by_Boeing).  As a 
|result, we have no
|> choice but to deal with mobility, if only to bound the 
|amount of damage that
|> is inflicted as a result.
|
|Yes but it's a cart and horse question.  The routing and addressing
|architecture is fundamental.  It should take mobility into
|consideration, but that doesn't mean that a solution to mobility
|problems should be incorporated *into* the routing architecture, just
|that it should *support* mobility.  People will actually use all sorts
|of unexpected clever hacks to support mobility based on whatever
|routing architecture we provide.  Our job is to make that easier, but
|we should not constrain what they can do.


Let me see if I can rephrase the discussion.  The mapping function will
necessarily operate at a given maximum granularity and maximum churn rate.
Whatever levels we choose to support in the architecture, the Connexion
example shows that people *will* use things for some form of
mobility/portability/migration.  Given that a defined mapping needs to
define the granularity and churn rate, that completely bounds how much
mobility can be supported directly by routing.  

Or, in other words, we should drop the mobility discussion for now, deal
with the granularity and churn issues, and then see if we are happy with the
bounds that that imposes on mobility.


|> If you don't want to deal with it under the label of mobility, then
|> we can change it to "the maximum amount of churn that any single
|> player can inject".
|
|or *should* inject.  There is a tradeoff here.  Supporting churn by
|individual nodes is one dimension along which to evaluate an
|architecture.  The routing architecture, as a whole, may be
|significantly more robust by cutting off the churn it allows at some
|threshold.  (But you know that)


Indeed.  In fact, I would argue that the architecture should have a
well-defined, strongly enforced churn rate, for safety reasons alone.

Tony


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