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

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

William Herrin wrote:

On Wed, Feb 20, 2008 at 8:11 PM, Robin Whittle <rw@firstpr.com.au> wrote:

 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.


In the unlikely event that marketing folk convince users that a slice
of PA space is better than map-encap PI space, the RIB scalability
problem is solved and our job is done. The reason we're having this
discussion is that folks -aren't- satisfied with slices of PA space
and have been impinging on the RIB in any way they can connive.
IMHO, the comparison that needs to be made, is PI vs "foo", for any new thing "foo". Whether "foo" in some way makes use of PA infrastructure is irrelevant, really. It is only that we want to substantially limit the growth of PI space, to those who cannot live without it.
If "foo" involves trade-offs that are noticeable, such as delay or packet loss, *compared to PI*, 
then that becomes a barrier to deployment.
If "foo" does not have such barriers, or fewer barriers, IMHO, that should be given significant weight, in comparing 
various kinds of "foo".

While none of us has collected direct data on this point, the
circumstantial data is not the slightest bit ambiguous. According to
users' behavior with the DNS, brief lookup delays solely at the front
of a series of transactions are A-OK.


Not really.
DNS lookups will *block* most applications, until the DNS resolution succeeds or fails.
And that has perception in user-space, but no impact to the underlying protocols.
However, delays *within* the transport regime, are an entirely different can of worms.
Unless the transport itself is modified to handle this, I think it's best to see if we can avoid this. 
I think it is a non-negligible issue.

 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:


Nonsense. The map-encap scheme must be sufficiently attractive to a
large enough subset of the user base that they're willing to pay for
it to be deployed. No more and no less.


The problem is a spam-like asymmetry.
The problem with spam is, one party pays (the ISP delivering mail, and the end user ultimately) for the benefit of another party (the spammer).
For an ITR/ETR model, the benefit of the multihomed entity is only realized when the *clients* connecting to them have an ITR.
This is a prerequisite for EID address space that isn't routed - common to all map-and-encaps solutions.
The fact that the hardware used for the ITR function may already exist, and that the vendor may supply software upgrades with ITR functionality for free (something that is IMHO an elephant in the room), is less important than, the fact that until ITRs are universally available, the multihomed entity does not get the benefit. 

Compare that with PI space, where the benefit is universal and immediate.


No fundamental character of map-encap requires this. TRRP has no such
requirement inherent in its architecture. It doesn't require wide
adoption to begin delivering valuable results. Indeed, the theoretical
deployment timeline shows it producing valuable results with only a
handful of users.
You've lost me. Without an ITR (or equivalent host stack modifications), how do I connect to an EID host?
And if I'm the server operator, why would I do this (switch to EIDs) unless *everyone* has the same quality of connectivity 
reaching me?

The benefit for deployment needs to be universal, and absolute, not gradual.
Remember, the objective of someone deploying a site using EIDs, is extremely high availability, for inbound traffic.
That means no significant delays in client connections discovering alternate paths to the site if a link fails.
And that has to apply to every client on the planet, modulo client-side failures (where all sites become unreachable). 
 > 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.


If the price of BGP-managed PI space comes down, the problem is solved
and we can all go home. The assumption we're working under, correct or
not, is that fundamental limitations in the technology will cause the
cost of BGP-managed prefixes to level off in a log-normal fashion at
some price which is still too high for the kind of granular
multihoming and mobility that you and I desire.
I don't believe costs will go up, and certainly not with any proportionality, regarding PI space. 

The DFZ will either be happy, or very very unhappy.
We need to find a solution that everyone will accept, and deploy, that prevents the latter. 

This is a "commons" situation, with our goal being to avert tragedy.
It is one place where market economies will not do anything to help us, and in fact are likely to be something we need to be keenly aware of - doing good often flies in the face of market 
pressures.

In a financial model of a zero-sum game, money *is* the root of all evil.

Uh, I seem to have wandered a bit off-topic. Sorry. :-)

Brian Dickson

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