Subject: Re: [rrg] Arguments in favour of Core-Edge Elimination vs. Separation?

From: [email-masked] (Noel Chiappa)
Date: Tue, 26 Jan 2010 16:03:53 -0500 (EST)

> From: Brian E Carpenter <[email-masked]>

    > The real disagreement was not about this estimate, but about whether we
    > need to solve the problem only for those 10 million PI EID prefixes, or
    > for a much larger number of SOHO+mobile EID prefixes.

I think we probably need to have a solution that is _architecturally_ capable
of supporting the larger number. (I'm speaking of a location/identity
separation solution here, of course.) I.e. we may have to advance a ways down
a multi-phase deployment path to get a system that can support that kind of
scaling, but it has to be possible to have such a path.

I've been thinking about this recently, as a result of an offline
conversation, and I think it _is_ doable, in scaling terms (and I'm thinking
about this in the context of mapping cache, of course).

It's not the generic individual site which I am most concerned about (I think
the size of cache will scale reasonably for them), but the Large Content
Providers, which will be communicating with large parts of the network. If
the cache for such an LCP is kept in some small number of boundary devices, I
think the cache there probably would get too large.

However, if the mapping function moves closer to the servers, the cache size
will scale more reasonably. (A hand-wavy argument that the scaling will be
feasible is provided by noting that at the limiting case, a single server, it
can only support a limited number of TCP connections anyway, so it perforce
will be talking to a limited share of the network.)

In other words, we need solutions that are CES to start with (to make initial
deployment feasible), but can morph into CEE _for some nodes_, to scale
long-term.

Yes, almost all of this probably would be unneccessary if we had a clean-slate
architecture, one in which we didn't even have to do (identity->location)
lookups. Still, we don't get to choose...

	Noel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jan 2010 10:51:37 +1300

Noel,

> will be talking to a limited share of the network.)

I don't think that's even very hand-wavy. If a server can handle state
for N simultaneous transactions, and the extra state per transaction to
cache the mapping info is a small fraction of the total state per
transaction, surely we can pick the cache lifetime so that the cache
size also scales like N.

Also, in the context of large-scale services, "server" these days
means a rack or a room full of virtual servers, which are there
precisely to deal with scaling like N.

So it becomes necessary, not optional, to move the mapping cache
to the places where state has to scale anyway. That takes it
out of traditional networking equipment, I think.

Regards
   Brian Carpenter