Re: [RRG] cache issues in LISP and CONS

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Scott Brim <swb@employees.org>

    > Well, to start with there's your default mapper :-).

That's a interesting idea. Has the default mapper stuff been worked out in
detail?

    > I believe caching can help a lot, but we need to simulate it.

I am a bit dubious about simulations; CDR caching is simply enough it's
probably easier to just add it, and see how it performs in actual usage.


    > From: Robin Whittle <rw@firstpr.com.au>

    > You could probably create a complex combination of caching and genuine
    > push of update messages to make the CAR-CDR network faster.
    > The question is whether it would be easier to create a complex and
    > souped up CAR-CDR system than to establish a clean - although ambitious
    > - system to distribute mapping data globally,

Well, that's the $64,000 question. There's no question that a pure push
system will have better performance (in terms of resolution delays) than even
an optimized pull system. How much better depends on a lot of factors, but
there will always be some cases where pure push outperforms any pull system.
However, a pure push system awill also have a *lot* more overhead. Is "a
*lot*" too much? I don't know.

I tried to do some back-of-the-envelope math, and I decided that depending on
what assumptions you made about how often bindings changed (I seem to get a
new IP address at home every couple of months as my ISP reorganizes), how
small address blocks became (i.e. will we go below /24's), etc you could get
answers ranging from easy to do (a couple of updates per second) to
unreasonable (a thousand per second). 

I do have a few things I can say for sure. For one, I don't think it's
feasible to do significant amounts of mobility with a pure push system; it
will raise the update rate too much. Doing mobility will greatly increase the
size of the table (since individual hosts will be mobile) as well as the
update rate, making push doubly infeasible.

For another, a lot of the table (and the updates to it) will be unused in
basically every box; as the Internet increasingly splits into
language-specific regions (I doubt a lot of people in South America are
looking at pages in Mandarin). Most hosts on the Internet rarely, if ever,
communicate with large portions of the rest of it, and this tendency for
differentiated communication patterns becomes more prominent as one gets
toward the leaves (which is where pure push has to send mappings, if you want
to get rid of *all* mapping delays).

In general, I think that push is architecturally brittle, in that one can't
do a lot with it. It either works, or it doesn't (like the DFZ today).

Yes, optimized pull systems are more complex. It's TANSTAAFL: you don't get a
system with almost as good speed characteristics, and a lot less operational
overhead, and also have minimal complexity. It's like the old "fast, cheap,
good" axiom, only this version is "speed, overhead, complexity: pick any two".

	Noel

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