Re: [RRG] ALT's strong aggregation often leads to *very* long paths

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Robin Whittle <rw@firstpr.com.au>

    >> The fine details differ a fair amount, for a long list of reasons
    >> having to do with the operational environment and requirements, etc,

    > ... function of the entire CONS network .. was to look up a distributed
    > global database and return the answer. ..
    > However the CONS network was a network of message passing devices, not
    > unlike routers.

It is true that the CONS system operates in detail somewhat differently from
the DNS (but I already said as much :-).

One of those differences, as you point out, is that when traversing the
hierarchy to resolve a hierarchically structured name, in CONS the entities
in the hierarchy talk to one another on the requester's behalf, whereas in
DNS, generally (i.e. in non-recursive mode) the entity trying to acquire the
mapping talks directly to each node in the hierarchy in turn.

I wasn't in the loop when this operational mode was originally picked for
CONS, but I imagine it was done for two main reasons: efficiency, but mostly
security. (If I've guessed wrong, hopefully the initial CONS designers will
enlighten me!)

Efficiency because to the degree that the path between the entities in the
resolution hiearchy to the entity holding the desired mapping is shorter than
a path that repetitively loops back to the source of the request (as it will
be in all but pathological cases), reponse time will be faster.

Security is because the limited number of inter-node links are configured and
protected, whereas if the 'original requester communicates directly with each
entity in the hierarchy' model is used, there was originally no signing
mechanism in CONS to protect the data, and thus no way to authenticate the
reponses - other than a painfully slow specially-opened TCP connection. (These
days, security - particularly against DoS attacks - is more of an concern than
back when the DNS was designed.)

Although the CONS network is indeed a network of message passing devices, I
think it's unwise to think of it as being "not unlike routers" because I think
it's too easy to thereby confuse people (into thinking, e.g. that it forwards
user data traffic). Once might just as well say that the network of SMTP
servers is "not unlike routers"!


    > The CONS nodes (CARs and CDRs) were functioning as peer elements in a
    > message passing network

The word "peer" is one I find slightly confusing when used to describe a
system which explicitly has "child" and "parent" nodes/entities; to me,
intuitively, a peer can only be something at the same level in the hierarchy,
not at a level above or below.

It was explained to me that the use of peer to mean 'entity with which one
communicates directly' came from BGP, and BGP peers. However, this seems to
me to ignore the fact that in BGP, there is no hierarchy - all BGP nodes are
'at the same level', at least in terms of the operation of the protocol (I am
aware that in operational terms, we have lots of non-transit leaf nodes).


    > If you imagine a modified version of the diagram, with "ITR2" to "ITR8"
    > converted to "ALT router 2" to "ALT router 8"

This is a reminder that we need to be careful with terminology. People are
discussing a number of similar mapping systems, and components thereof, and
we need to be careful to not mix them up. (E.g. CONS is not LISP - it's just
one potential way to provide the mappings which LISP needs.)

	Noel

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