Re: [RRG] Why delaying initial packets matters

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

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

    >> You can have systems which are 'pure pull' but which have the property
    >> that queries are answered "a lot closer and faster", close to as
    >> fast as a push system - just add intelligent caching.

    > if you expect those local caches to accumulate a large body of
    > information - large enough to make reliance on the slow ALT global
    > query server system rare enough not to be much of a problem

First, I'm not assuming any particular design (especially as it stands
today), be it ALT, CONS, or anything else.

Second, it's not at all clear to me that a cache needs to accumulate "a large
body of information" to get a fairly high hit rate. (Or, at least, to get
over the knee where you get into the diminishing returns region, where adding
extra cache entries only slightly increases the hit rate - at that point, to
get a big increase in performance, you have to go to full push.)

    > then you are going to have to cache mapping information for a long
    > time. This has the severe cost that you either need to accept low rates
    > of mapping change by end-users, or you need to add complexity in the
    > form of a "notify" system when the mapping is changed.

This doesn't currently seem to be a major problem with DNS; why do you think
it will be a problem here?

Yes, if we want to do e.g. mobility with this mapping layer, we'll have to
look at the question of outdated mappings, but there are a number of
approaches to solving that, depending on where one wants to land in
performance/complexity/overhead space.

    > the worst case situation will occur frequently enough to be a blight on
    > this new kind of address space: where the mapping and initial packet
    > delivery depends on the slow and not necessarily reliable ALT network.

Who's talking about ALT?

    > I would rather have a clean, ideally fast, push system to get the
    > mapping data out to lots of ITRs and full database query servers.

If you're sending it to ITRs, it's full push.

The notion of having a widely distributed set of full database query servers
is an interesting one; let me ponder that. Right off the bat I see some
issues (e.g. how do you assemble a "full database" when it's inherently a
distributed artifact - it's the same problem as 'how would you assemble a
full DNS database), but without thinnking it through I don't want to give an
opinion.


    > But what if the ETR is not reachable?

We clearly need to have mechanisms to track whether ETR's are up or not, lest
we produce the same kind of 'black hole' problems we have with routers that
die.

    > This reliance on ETRs for functions other than decapsulating packets
    > and responding to reachability and PMTU probing strikes me as
    > problematic and overly complex.

First, I'm not sure we want ITRs individually probing ETRs to see if they are
alive. This kind of approach was rejected in other circumstances (e.g.
host-router reachability) because of traffic load issues.

Second, why would it be "problematic and overly complex" to have other
functionality in the ETR's? Once the ITR gets the EID->RLOC binding for a
given EID, the ITR is normally only communicating with the ETR at that RLOC
anyway, so it's natural to emplace maintainence functionaltiy in the ETR -
it's doing anything *else* that's more complex.

    > For one thing, you have to have inter-ETR communication.

Why? Unless you want fast (i.e. less than an extra round-trip delay)
handover, all the ETR has to know is 'this EID is no longer at me' - from
there, the ITR has to do another binding lookup.

Again, there's a cost/performance/complexity tradoff.

    > For another you need a lot of *configuration* and authentication
    > stuff, since an ETR .. would need a way of proving to ITRs all around
    > the Net (and the ALT network etc.) that it is one of the authoritative
    > sources of mapping information for an EID which is assigned to an
    > end-user.

No. If you did have ETRs providing a new binding, they'd just have to get a
signed binding (from the entity which is normally authorized to hand out
those bindings), and pass that along.

	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