Robin,
> > I said what is left to do is 1) make a decision (see text right above
> > this line) or 2) blend two mapping database scheme. We don't know yet.
> > We need to experiment.
>
> How would experimentation with your current prototype LISP system
> lead to any fresh insights about the fundamental limitations of ALT
> or NERD?
I don't think any is saying that. My sense is that its
more the case that while we work on the theoretical
aspects of these system (as this thread is, and that is
all goodness), there are things that one can learn by
observing a system's behavior. To do that you need
implementations (or at least simulations). Suffice it to
say that a lot has been learned in the process of trying
to make things work (especially in the cases of large
dynamic systems that are difficult to characterize in a
bottom up fashion).
So there's a theory v. practice point here (and I'll
leave alone for the moment the whole issue of emergent
properties that really can't be studied in a bottom up
fastion).
> NERD on its own won't work because every ITR in the world would need
> the full feed of mapping updates.
Notwithstanding Eliot's calculations, this is a concern
many of us has voiced.
01: That's why hybrid systems seem so attractive; but then
you trade off rate v. state. v. lookup latency. All of
these systems seem to occupy a different point on in this
space (except for perhaps CONS and ALT, which are
architecturally similar in this respect). I'm sure there
are other dimensions one can through into this, but for
now my sense is that these three dominate.
> ALT on its own won't work because the ITR drops or greatly delays
> (sending them to the ETR via the ALT network) the initial packets
> while it waits for the mapping information. This would make EID
> address space suck - so no-one would want to use it.
goto 01;
(I [again, and others] have been concerned not only about
latency [your point] but also about the aggregate traffic
load in the ALT core [consider near the "top" of the
hierarchy, i.e., data traffic "rate" in the control
plane]).
> The logic of this seems inexorable: Any global query system would
> often be so slow that it wouldn't be acceptable unless every ITR is
> able to deliver the initial packets via some other mechanism within
> a fraction of a second. If all caching ITRs can do that, then why
> bother with a global query server network at all?
I don't know if the logic is "inexorable", but your point
is well taken. We need to examine the tradeoffs in the
3-space I described above.
> I don't think anyone believes ALT or NERD alone could possibly form
> an acceptable solution, far less the optimal one.
Again, "anyone" is a lot of folks.
> So that leaves your other suggestion: blending the two systems
> together. This is what I explored - making changes to them starting
> from the position of the two systems running alongside each other.
So this is an architectural tradeoff in the space I was
describing. As Noel is found of saying, TANSTAAFL.
> When you have NERD ITRs around the place, there is no need to build
> the ALT global query and packet delivery system, because it makes
> much more sense to use the nearest NERD ITR as a default mapper and
> to have a full database Query Server at the same location - perhaps
> in the same device as the NERD ITR. Then there is no need for ALT,
> CONS or any other global (expensive, hard to administer, slow and
> unreliable) query server system.
But then you need to construct the complete map; again,
this is just a point in the tradeoff space I described
above. It would appear that there are only a finite
number of ways to skin a cat...
> If you or anyone else disagrees with my sequence of improvements to
> LISP, you will be able to argue why a particular stage of my
> improvements makes the system worse and/or suggest some better set
> of improvements.
I have a somewhat different suggestion. I don't see any
"solutions convergence" occurring, at least on RRG
list. What might be helpful is objective criteria that
could be used to pick "more optimal" points in the
archtiectural space (here I mean the rate*space*latency
space). Give such critera, we could do the
evaluation. Without such critera, well, we're
speculating.
Now, I'm not saying we need a "requirements document"
(been there, done that). But we do need something
objective that we can use to compare against.
Dave
signature.asc
Description: Digital signature
