Subject: [Ecrit] schulzrinne-ecrit-lump high level model question

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 29 Jul 2005 23:47:58 -0400

It seems that you have a whole bunch of hierarchal distributed data and are
trying to make a localized query against it. There are two basic approaches,
one would be to (as this draft) suggests, distribute the query so it moves
through hierarchy and finds the answer. The other approach would be to move
the data thought the hierarchy so everyone had a copy of all it and could
resolve the query.

Some things that might choose between these two approaches are
1) is it too much data to keep a copy of all of it
2) is the data changing too frequently to propagate accurate copies of it
3) how quick to the queries need to be (classic time/space tradeoff)
4) how many nodes have to be "up" and reachable for a query to succeed

I guess my question is, are the two approaches I suggest both possible, and
if so, which one is the right one for the 911 problem.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 30 Jul 2005 09:42:23 -0400

Depends on your point of view.  There is too much data for every possible
routing node to keep all of it.  It is possible to keep enough of it that
the probability you will have what you need is fairly large.  The mechanisms
have to be there to work when caching fails.

My usual example is a call from a café with a wifi hotspot through a VPN
tunnel to an enterprise VoIP system, where the café is in Chicago and the
VoIP system is in Sierra Leone.  The Sierra Leone system can reasonably keep
all the routing data for Sierra Leone, and possibly surrounding areas, or
frequently encountered areas.  It can't keep route data for any place any of
its employees could possibly visit.  The reverse occurs.  The Chicago system
can reasonably cache the state of Illinois, and surrounding areas.  With
some effort, it could cache all of the U.S.  It's not reasonable to cache
the entire globe with present systems.

The data does not change all that often.  Propagating change is probably not
too bad from the point of view of frequency of change, although the number
of potential routing elements is large, so if you did that, you need a
pretty robust system.

Queries need to be fast in human terms.  Two seconds is a very long time to
wait for a ring when it's an emergency.  We deal with 6-8 seconds now in
some circumstances.  Probably it's okay to have the outlier cases take a few
extra seconds.  Better not happen too often though.

Clearly, you want routing to work when things fail.  That's pretty important
I think.  It's one of the big reasons I keep pushing the DNS idea even
though I know a lot of people have negative reactions.  The thing is, we
know it works when lots of things fail.  No other idea we have talked about
has that characteristic.  Most of them have never even been deployed in any
scale like what we are discussing.  We simply don't know what will happen.
To me, that's a really poor idea.  Better to use DNS.

I think the LUMP idea has a lot of merit.  I think it might work really
well.  I think it does have the kind of tradeoffs needed for the problem,
and I think some decent implementations that did some proactive caching
would probably help.  I think it has better tradeoffs than the IRIS
approach.  I don't have anywhere near the confidence I would have in the DNS
that it will though, and I think that's a very poor tradeoff for this
application.

You have to ask yourself: If it was my call, or my daughter's call, and
there was some really big disturbance in the force, what would I want to
depend on working - IRIS, LUMP, or DNS?

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings
Sent: Friday, July 29, 2005 11:48 PM
To: [email-masked]
Subject: [Ecrit] schulzrinne-ecrit-lump high level model question

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 30 Jul 2005 10:06:05 -0400

Just to add to Brian's note:

LUMP tries to do a bit of both (query-to-data and data-to-querier), 
using caching, flooding and replication for the latter. This definitely 
needs more explanation and exploration. I don't think we can predict the 
mix, but need, in my opinion, have tools that allows us to shift the 
balance as bandwidth vs. storage vs. speed-of-data-change trade-offs change.

Henning