Re: [RRG] NTP and various proposals.

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

    > From: "William Herrin" <bill@herrin.us>

    > It's 18 minutes that you have to keep receiving and asking to receive
    > map updates for the destination even though there's no associated
    > user-level traffic.

Huh? Why? I thought Tony mean that you'd just be have to be sure to keep the
binding in the ITR's cache for at least 18 minutes; do that, and the next
NNTP query will reset the timer, and around we go again. No resolution
traffic at all.


    > You can't simply extend the cache validity of course. 18 minutes is too
    > long for multihoming, let alone mobility.

I don't know about multihoming, but let's think about mobility.

I claim that trying to do mobility (or much of *anything*) with the timeout
field in the binding is inappropriate. My reasoning is simple: to get
reponsesiveness within N seconds, you'd have to set the timeout on the
binding to N seconds, and that means you radically jack up the amount of
queries/updates (which depends on whether you are in a pull or push model).
This is clearly nonsensical.

Clearly the right thing is for timeouts on bindings to be longer, and when a
binding *changes*, entities using that binding have to have some way of
finding out that the binding has changed. That's economy of effort: if the
binding doesn't change, there's *zero* overhead, and if it does change, only
the people using it pay (once) to get the new binding. So how do we do that?
Two possible answers that I can see:

One - the 'owner' of the binding remembers who has a copy, and tells them
when it's changed. That requires us to maintain a lot of state (who has a
copy of the binding), it's brittle, subject to failure if that state is
damaged or lost. So I reject that one out of hand.

Two - there's a cheap/easy way to tell, *when you use a binding*, that it's
incorrect outdated. The only thing is, can we come up with a cheap/easy way
to tell? Asking the resolution system on every tick 'is this binding still
valid' is not cheap/easy. However, there's another way.

To use an EID->RLOC_of_ETR binding, the packet has to pass through the ETR.
All that has to happen is that the ETR (which is *forwarding* packets, so
it's by definition selecting a next-hop for them) has to have a table of
(EID, next-hop) bindings (the table may be notional, in that in some designs
it is currently just a mapping, not an actual table of tuples, but I propose
we make it an explicit table). Now the solution is obvious: if a packet
arrives at an ETR, and there's no EID->next_hop binding (or it's marked
"moved to a new ETR"), the source (ITR, etc) are sent a "not here" message.
*Then*, and only then, does it query the resolution system to see where the
destination has moved too.

(If you want even more efficiency, the old ETR can redirect the ITR to the
new ETR. More complex, because the destination has to update all its old
ETRs, etc, but faster - it can even triangle-route data packets instead of
dumping them.)


The exact details I'm hazy on, because I don't know exactly what the
performance/etc targets are, and we're back in that
complexity/overhead/performance vector-space.

But this seems to me to be the architectural avenue to work in - find a
cheap/easy way to *tell* when a binding has changed, and do the 'update
everything' actions only when needed.

	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