Re: [RRG] cache issues in LISP and CONS - it's bad . . .

["William Herrin" <bill@herrin.us>]

On 10/23/07, louise.burness@bt.com <louise.burness@bt.com> wrote:
> > We're talking about replacing/supplementing BGP in
> > what is not the first table-size crisis while DNS chugs along
> > happy as a clam. This says something about the relative
> > merits of push versus pull mapping systems.
>
>  Does this really say anything about the relative merits of push versus
> pull?

Louise,

I suppose its fair to look at the assumptions. If the assumption is
that a given map server will need to interact with most of the maps
then its pretty easy to falsify the claim. If the assumption is that a
given map server will need to interact with only a small number of
maps then the claim is fairly straightforward.

Let me ground that a bit: if we get great heirarchical aggregation
where each map covers a very large number of EIDs then push will be
more efficient. If we get heavy fragmentation and deaggregation then a
pull will be best. So, pull out your crystal ball and tell me which
assumption will hold true.


> I rather thought DNS chugs along because it does not have to handle the
> same amount of changes that BGP does?

DNS experiences a vast amount of churn, far more than BGP. It doesn't
meaningfully impact the system overall because resolvers only care
about the changes to the records with which they're currently
interacting.

Two major sources of churn in DNS:

1. Dynamicly constructed A-records form the technological basis by
which CDNs like Akamai function. Every single query may return a
different result.
2. Orgs like dnydns.com change A records every time a single PC comes
up or goes down.

> Ok, the churn problem is harder if
> you try push, but people expect to be able to make route changes in
> seconds, ms being talked about as a target; I rather think to change my
> DNS entry takes a little longer.

That is a weakness with the basic DNS approach. Resolvers hold the old
record until the TTL expires. In a practical sense, the lower bound
for a TTL will be about 60 seconds and even that's pushing it.

TRRP posits an optional preemptive change notification to address this
weakness. http://bill.herrin.us/network/trrp-preempt.html  PCN sends a
notification packet to all recent requestors when an entry changes,
advising them that they should immediately expire the old entry. If
widely adopted (its optional after all) then sub-second changes to the
target ETR should be possible.

Regards,
Bill Herrin

-- 
William D. Herrin                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

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