[RRG] Dynamics of the mapping function

[Robin Whittle <rw@firstpr.com.au>]

Hi Tony,

In your untitled message:

  http://psg.com/lists/rrg/2008/msg00964.html

you wrote:

> I'd like to turn now to the issue of the dynamics of the mapping function.

I understand from this that a new topic is being opened with the aim
of arriving at some text for which there is rough consensus.  I
understand that the matter of "mapping granularity" is still under
discussion.

> In particular, how fast can we allow the mapping entries to be updated?  Do
> we need to constrain the overall flux of the mapping?
> 
> As always, a clear, succinct articulation of the correct questions is more
> valuable than a position statement.  ;-)

OK.  The problem with a single set of questions is that the various
map-encap systems have radically different architectures and that
therefore the technical constraints, costs etc. are of a different
nature in each.

In LISP-ALT (and TRRP), the great thing is that the authoritative
query server (one or more ETRs for LISP-ALT) can change the mapping
for an EID prefix (micronet in Ivip terminology, TRRP too?) every
millisecond and there are no costs to the rest of the system.

However, since it is a pull-only system, if it is desired that the
frequent changes propagate quickly to ITRs which are currently
handling traffic addressed to this EID prefix, then the mapping
responses must go out with very short caching times.

So the question for a pure pull system is something like "How short
a caching time will the mapping have?"  This will vary with some
end-users having a caching time of a few hours or days, and perhaps
some having a caching time of a minute or less.

With Ivip, the mapping updates go out in real-time and have no
caching time - they remain in force for seconds or years, until
another mapping change is sent.

In Ivip's pull system, where ITRCs (and ITFH ITR functions in
sending hosts, but not behind NAT) query local full database query
servers (QSDs), perhaps through one or more intermediate QSCs
(caching query servers) there is a caching time for the replies.
There is also a "Notify" system by which the QSD will send a message
to any querier about a mapping change to a micronet for which the
QSD recently sent a reply.  (This is not a complete description of
the system.)

It is a local decision by the QSD what the caching time is, which it
can decide in various ways.  The Ivip spec may have some guidance on
these times, but it is likely to be up to the operator so set their
own chosen caching time, or to vary it according to the nature of
the request, to optimise their trade-offs of having to send out more
Notify messages for the longer caching time, vs. reducing the query
traffic if they shorten the time.  Also, they are trying to optimise
how much cache is used on their ITRs.

So for Ivip, the cache time is important, but not part of the spec.


I will write in a separate message some thoughts about this RRG
design process - which in this case struggles to remain meaningful
at a higher level than the inevitable low-level differences between
the potentially practical map-encap systems.

I think the problem with this "dynamics of the mapping system"
question is that in order for it to produce meaningful results for
each of the current map-encap proposals, it has to be transformed
into a series of different questions for each proposal. Therefore,
it doesn't enable a single answer or single set of answers to be
given which would lead to a meaningful actual design being generated
by the RRG.  Nor does it enable the different proposals to be
compared side-by-side, because each one has answers to different
questions.

  - Robin                http://www.firstpr.com.au/ip/ivip/




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