Subject: Re: [lisp] LISP Over Lossy Links

From: [email-masked] (Noel Chiappa)
Date: Wed, 16 Sep 2009 10:52:59 -0400 (EDT)

> From: =?iso-8859-1?q?Lor=E1nd_Jakab?= <[email-masked]>

    > The first time I load any web page, load time will increase with 3
    > seconds for each external IP it references, in addition to DNS
    > lookups and download times.
    > Of course this is not really an issue if the ITR is a border router
    > of a busy domain, most popular destinations will be cached.

Exactly. Also, the mapping system in use for this experimental phase (i.e.
the ALT mapping system) was adopted in large part because it re-used lots
of existing stuff (e.g. BGP and GRE tunnels), minimizing the amount of new
code that had to be written before the experiment could get off the ground.

We did design another mapping system, CONS, which had extensive caching,
etc to speed up finding mappings (i.e. to reduce the resolution time to
less than the RTT to the location of the destination's authoritative
mapping, on average), but it has been temporarily put to the side in order
to get the experiment running.

I expect the decision on what to do with CONS, eventually, will depend on
the outcome of the experiment: maybe it will be adopted for other reasons
(e.g. traffic loads in the mapping system), but later rather than sooner;
maybe we will do something else; who knows? It will depend on what we find
out with the experimental deployment.

    > But if we consider the other deployment scenarios discussed recently
    > on list, it may become an issue.

Exactly - which is why it is important to have an experiment, to see what
actually happens. There is a small LISP testbed at the moment, divided
into alpha- and beta-test groups, but it will be necessary to to run a
more extensive system, with a good amount of actual traffic on it, to see
how well it actually works for actual real usage.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 16 Sep 2009 11:24:33 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    >> Have a slightly more robust mapping timer that doesn't simply
    >> discard expired entries, but holds them in reserve.

    > I think that this is a better, and simpler, choice than above.

It also doesn't require any protocol changes; it can be added in a
machine-by-machine way. So it's trvial to add to the spec/deploy. Marking
expired entries as 'provisional' (i.e. you keep using them while you start
a refresh) would be an obvious thing to do if we discover issues in actual
service.

    >> Pre-cache popular sites.

    > I _suppose_ this could work, although which sites are popular seems
    > to change rather rapidly.

CONS had a very elegant (i.e. simple, cheap _and_ effective :-) algorithm for
automatically 'floating' commonly-used entries back through the mesh, closer
to the entities asking for the mappings; I devised it (at no little cost in
brain-sweat :-) precisely to avoid the problem you allude to! :-)

Depending on exactly where we go with the mapping system, we could I am
sure do something along these lines.

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 16 Sep 2009 11:51:52 -0400 (EDT)

> From: Florin Coras <[email-masked]>

    > if the Map-Reply takes more than 3s due to the delay brought by the
    > Mapping System or is lost, the ITR would send another Map-Request
    > because the SYN timer (3 seconds) has expired
    > ...
    > Therefore the ITR should retransmit Map-Requests using an
    > independent timer instead of depending on receiving the next TCP
    > syn.

Again, this is a change that is easy to do later, because there is no
protocol change. We can change the spec, and it can be deployed in each
LISP device independently. So let's see if experience shows we need it,
before we make things more complicated?

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 16 Sep 2009 16:14:58 -0400 (EDT)

> There is an important difference between LISP and ARP that may make the
    > trade-offs quite different for LISP than they are for ARP.

This is quite a valid point, and your data is also very interesting.

Nonetheless, the fact remains that most of the solutions people have
discussed for this (refreshing old mappings that are in use; keeping mappings
that time out, and using them provisionally; retransmitting Map-Requests -
all of which I find excellent suggestions) do not involve protocol changes,
and can thus be added without any up-heaval, later on.

So at this point in time, it might be more productive overall to focus on
things that _will_ require protocol changes? The longer those are put off,
the more painful it will be (since we're still in a 'flag day' deployment
model on the testbed).

There is also some concern, I gather, that the protocol is perceived by some
as being 'too complex'. So adding that factor to the decision-making process
is another reason to leave things out, if the cost of doing so is minimal,
until we have empirical evidence that the performance seen by users is
inadequate.

    > I do consider this to be a major area of concern for LISP.

This is quite understandable, and reasonable.

    > So, when we define the actual experiments that we intend to run .. I
    > think we should pay special attention to covering the performance
    > impact of LISP on connection establishment.

This is an excellent idea, one I completely agree with.

Once we have more data from actual experience - which will guide us to know
how big the problem is, and therefore how big a hammer, out of the list of
suggestions available, we will need - we can pick some set of these
suggestions up and implement them.

	Noel