Re: [RRG] Map-encap space for "server" vs. "client" end-users?

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

Hi Bill,

You wrote, in part:

>>  OK.  Renumbering a bunch of web servers also means having to alter
>>  the records in a bunch of nameservers - not all of which would be
>>  controlled by the hosting company.
> 
> Yes, this is among the many reasons why provider independent space is
> such a desirable thing.

We all agree on the need for more end-users to be able to keep their
addresses, meaning fully portable PI space, but by a different
mechanism than the current BGP approach.


> My point was in a different direction: content publishers already
> tolerate delays on the same scale as the difference we're talking
> about between push and pull. They tolerate these delays today solely
> for the sake of their developers' convenience. There is simply no data
> to support the conclusion that they wouldn't tolerate the same
> character and scale of delay for the sake of their system
> administrator's convenience.

If the entire Net changed to add some small delay, then this would
not be a barrier to adoption of the new map-encap scheme.  However,
as I and others have written, if the new address space performs
worse, in a way which really matters to end-users or which could be
construed by marketing people as such, then it will be very hard to
get widespread adoption of the map-encap scheme.

Yet I think we need this very widespread adoption for end-users
large and small if the system is to be effective at solving either
the routing scalability problem or the closely related problem of
improving IPv4 address utilization.

> The notion that a pull-based map system will necessarily be too slow
> ain't nothin' but a theory and the theory is both unsupported by any
> data and apparently contradicted by some of the data that is
> available.

The ALT scheme is not just a global query server system (tending to
be slow, long-path and less reliable than using local query
servers), but is worse still due to the aggressive address
aggregation causing path lengths often far longer than the
geographic direct path.  See the thread "ALT's strong aggregation
often leads to *very* long paths".  Nobody disagreed, but there was
talk of more meshy cross-linking to give a better chance of a
geographically short path.  K. Sriram's diagram:

  http://www.antd.nist.gov/~ksriram/strong_aggregation.png

is also instructive.

TRRP has a similar delay problem, which would occur frequently
enough to be significant.  The ITR has to sequentially query and get
responses from several DNS-like servers in order to find the
authoritative server with the mapping information.  Unless you
anycast those intermediate servers (which does not scale well) then
there will be significant delays in quite a few circumstances.  This
seems to be far worse with IPv6, where each level in the DNS-like
hierarchy is a smaller number of bits, and there are more bits in
the EID address than with IPv4.

To some extent you could solve this by sending back a response,
giving authoritative nameservers for several levels of subdomain -
which enables the ITR to jump a few levels along its path of enquiry
without sending another query and response.  But the inherent
problems of global query server systems still remain in TRRP, even
if you could optimise it significantly.

Only anycasting most or all of the TRRP DNS-like nameservers so all
the queries were answered by  a somewhat local (same country or
continent) server would significantly remove the delays inherent in TRRP

Even if we think the delays are insignificant, they can still
prevent the map-encap scheme being adopted, as Marshall Eubanks wrote:

  http://psg.com/lists/rrg/2008/msg00381.html


>>  > If you're placing a /18 on the 'net, we
>>  > can easily accommodate you with the hardware that's already
>>  > deployed, let alone with hardware currently shipping.
>>
>>  I think you are saying that larger end-users might as well use the
>>  conventional techniques we use today - a BGP advertised prefix.
> 
> Yes. The worldwide cost of one advertised prefix works out to
> something in the neighborhood of US $8000/year and falling. The system
> is only broken for prefixes whose value is less than that.

From the point of view of large end-users with cash to burn, the
system isn't broken.  However, as the cost falls and more end-users
gear up to get this kind of space, the system becomes more broken
from the point of view of the companies who run DFZ routers, due to
the bloat in the number of DFZ routes - which is the primary problem
we are here to fix.

I argue that the new map-encap space must be equally attractive to
large and small end-users, including those with current BGP-managed
PI space:

  Large companies with PI, small with map-encap space?
  http://psg.com/lists/rrg/2008/msg00275.html

No-one has yet debated this.

>>  If map-encap space had deficiencies, such as frequent delays in
>>  initial packets, then the big end-users (who have a choice whether
>>  to adopt it or not) would avoid it like the plague.  Only the
>>  smaller end-users, who can't afford or justify one or more /24s of
>>  conventional BGP-managed PI space, would be choosing map-encap space
>>  - because they have no other option.
> 
> This is a bad thing? As an (er hem) larger gentleman, I can tell you
> without reservation that one-size-fits-all never does.

Ah yes, but many folks are establishing their nook in the Net with
the intention of growing enormously.  We need them to adopt
map-encap space - which means they need to be confident it will
still the best arrangement when they are bigger.

>>   Large companies with PI, small with map-encap space?
> 
> I would put it differently. Just 'cause I can't afford a Porsche
> doesn't mean I care to ride the bus. Bare BGP prefixes for those who
> cough up the cash. Map-encap for those who value it less but still
> want something that isn't as ghetto as slices of PA space.

This might work to some extent, but not if the price of BGP-managed
PI space comes down.

I think it strongly desirable that the new architecture provide a
form of address space which is really attractive to all end-users.
I think this is a feasible goal.

  - 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