[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] ALT + NERD is inelegant & inefficient, compared to APT or Ivip



	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

Attachment: signature.asc
Description: Digital signature