Subject: [lisp] Mapping system observations

From: Damien Saucez <[email-masked]>
Date: Thu, 9 Aug 2012 22:13:28 +0200

Hello,

We finally had no time to briefly present a measurement
campaign we made on the mapping system.

The slides are on 
http://www.ietf.org/proceedings/84/slides/slides-84-lisp-8.pdf
and I invite you to comment.

As you certainly know, the mapping system has been migrated
to LISP-DDT with success on 3/14/2012. As the migration was
planed, we have decided to measure it! To do so, we used
vantage points around the world in different network types (EID
space, commercial Internet, research Internet...). These vantage
points have measured for a period of about one month the
mapping system. To do so, they have send a Map-Request
for all the EID prefixes with lig, and this every 15 minutes.
We expected to observe a big difference of delay and mappings
between ALT and DDT. However, the result we obtain is that
the change is not very significant. There is no particular loss
of map-Request/Map-Reply during the transition and the delay
is not significantly increased or reduced. However, we observe
a much more variable delay now with DDT than before where 
delays were very stable with time.

After these measurements, we looked at the long term trends in
the mapping system thanks to lispmon. The general trend is that
the number of mapping increases (and more particularly the
negative mappings) and that very few mappings use several
RLOCs. Looking at this.

This work is very brief and only show basic results, however, it
raises two interesting questions. First, how can we make the DDT
retrieval delay more stable (maybe it is just a question of
organisation and trafic). Second, can we imagine to simplify the
mappings such a way that all the complexity of mappings with
the priority, weight, R-bit... is there only when necessary?

I am looking forward for your comments,

Damien Saucez

---

From: Lori Jakab <[email-masked]>
Date: Thu, 09 Aug 2012 18:21:41 -0700

> negative mappings) and that very few mappings use several

One of the reasons for more negative mappings may be some operational
changes that happened first on the ALT, and then the way DDT works. When
I started monitoring the beta network, all the 153.16.0.0/16 prefix was
considered EID space, and a Map-Request would either return a positive
reply, or nothing at all. Only queries outside 153.16/16 returned
forward-native. At one point that changed, and depending on active
registrations, negative Map-Replies were returned from within that
block. And with DDT, I think there is even more granular information
about prefix status.

-Lori

---

From: Vince Fuller <[email-masked]>
Date: Mon, 13 Aug 2012 13:18:40 -0700

> delays were very stable with time.

Hi Damien-

Thanks for the interesting analysis.

I'll offer a simple explanation for why lookup delay on the pilot network
has become more variable with the deployment of DDT: we have a somewhat
pathalogical configuration on the pilot network. In particular, the pilot
DDT topology includes regional DDT Map Servers in that can accept 
registrations from every ETR in a region. The ETRs in the region, though,
are only configured to register to a subset of the DDT Map Servers in that
region. When a DDT Map Request is sent to a DDT Map Server that doesn't
have a particular ETR registered, a Map-Referral message with action code
"MS-NOT-REGISTERED" is returned, which causes the requestor to re-try to
a different DDT Map Server in the current referral set and results in
at least one additional DDT message round-trip-time.

This "misconfiguration" is deliberate and is in place for internal testing
and configuration management purposes. Such a configuration would not be
used on a "real world" network so variable lookup performance on the pilot
network should not be considered representative of how things would work
in operational deployment.

Hope this helps.

	--Vince

---

From: Damien Saucez <[email-masked]>
Date: Mon, 13 Aug 2012 22:35:31 +0200

Hello Vince,

That makes a sense.

Is this publicly documented somewhere?

Damien Saucez

Damien Saucez

---

From: Vince Fuller <[email-masked]>
Date: Mon, 13 Aug 2012 14:38:32 -0700

> Is this publicly documented somewhere?

No, and I don't see much of a reason to document a test configuration that
we explicitly *don't* recommend for use by operational networks.

	--Vince

---

From: Damien Saucez <[email-masked]>
Date: Tue, 14 Aug 2012 00:35:01 +0200

> we explicitly *don't* recommend for use by operational networks.

Sure, but as we are using the beta network, it might help to understand 
observations if there is a place where we can have a bit of information
about the configurations. I usually looked at the rancid, but now the
network is too large for me to manually check what is happening.

Thanks,

Damien Saucez