Re: [lisp] WG Review: Recharter of Locator/ID Separation Protocol (lisp)

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

 



    > From: John Scudder <jgs@xxxxxxxxxxx>

    > Re cache management schemes, I think that depends on whether you
    > mean "system level behavior" of a small-scale system, or one
    > operating at large scale or under some kind of stress. The earlier
    > discussion notwithstanding, for practical purposes caching is
    > central to LISP; as such, it's a little weird to say it's
    > architecturally unimportant.

I didn't hear him say that. I think he said 'the details of particular
cache management algorithm(s) aren't important to an _architectural_
understanding of LISP'.

Now, what you mean by 'architectural understanding' and what I (and
probably Joel) mean by 'architectural understanding' may be two different
things, which may be the source of the problem.

What I mean by that term is 'how is the entire system broken up into
subsystems' (i.e. what are the functional units), and 'how do they
interact'. I.e. a very high-level view of how the system as a whole
operates - an overview in which more detailed views of individual
subsystems can be slotted.

That is something totally different from 'a complete model/understanding of
how the system operates in various operational environments', which is
somewhere in the direction of what you seem to want?


Now, clearly the latter is something useful to have, but I'd like to point
out that in its maximum generality it may be a 'boil the ocean' kind of
goal.

E.g. to have a complete and total understanding of how, say, the Internet
path selection system as whole operates, you'd have to model every last
piece of it (every router, etc, etc), because there's no analytical proof
that it operates in any particular way. However, of necessity, any such a
model is probably infeasible - we can build smaller models, and see how
they operate, but they can only offer limited insight (how limited, we
cannot say for sure) into just how the full-scale system is going to work.

To do that, we just built it (why do multi-dimensional mice come to mind
here?), and we can instrument it and watch it (as numerous studies have
done, e.g. the very fine work by Craig Leibowitz and Abha Ahuja some years
ago). But any sub-full-scale model is necessarily going to be 'an
incomplete description of reality', to use the fine phrase from EPR.


Which is not to say that better understanding of how the caching in LISP works
in various operating environments (e.g. under various kinds of attack/stress),
and how different potential cache management algorithms would work across a
range of operational scenarios, is not useful and/or desirable. Of course it
would be.

(Do we have any volunteers? A considerable amount of work on caching
simulation has already been done, but of course there's an infinite space of
possible things to explore, both on the algorithm side and the operational
scenario side.)

However, i) such work is not a 'description of the architecture' as I
understand it, nor ii) is it _absolutely_ necessary before trying a system in
large scale, because to do it 'perfectly' is an impossible 'chicken and egg'
situation: there is no perfect model _other than the system itself_. The only
way to _really_ see how it works is to build it.

Or am I too misunderstanding something?

	Noel
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]