Re: [lisp] Mapping system observations

Damien Saucez <damien.saucez@uclouvain.be> Thu, 09 August 2012 20:36 UTC

Return-Path: <damien.saucez@uclouvain.be>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663C621F86F9 for <lisp@ietfa.amsl.com>; Thu, 9 Aug 2012 13:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.182
X-Spam-Level:
X-Spam-Status: No, score=-8.182 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxyiQMmeEMMm for <lisp@ietfa.amsl.com>; Thu, 9 Aug 2012 13:36:36 -0700 (PDT)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3B31E21F86F8 for <lisp@ietf.org>; Thu, 9 Aug 2012 13:36:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.77,742,1336341600"; d="scan'208";a="152789594"
Received: from 9.82.69.86.rev.sfr.net (HELO [172.16.139.253]) ([86.69.82.9]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 09 Aug 2012 22:36:33 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\))
From: Damien Saucez <damien.saucez@uclouvain.be>
In-Reply-To: <20120809202635.9515718C0F3@mercury.lcs.mit.edu>
Date: Thu, 09 Aug 2012 22:36:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CD74CDB1-4C8E-49DE-9854-586769294006@uclouvain.be>
References: <20120809202635.9515718C0F3@mercury.lcs.mit.edu>
To: jnc@mercury.lcs.mit.edu
X-Mailer: Apple Mail (2.1485)
Cc: benoit.donnet@ulg.ac.be, lisp@ietf.org
Subject: Re: [lisp] Mapping system observations
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2012 20:36:37 -0000

Noel,
On 09 Aug 2012, at 22:26, jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote:

>> From: Damien Saucez <damien.saucez@gmail.com>
> 
>> However, we observe a much more variable delay now with DDT than before
>> where delays were very stable with time.
> 
> Is this variation for a single MR<->{something} interaction, or is this the
> overall time from i) an ITR needing a mappping to ii) it getting the mapping?
> If the latter, it makes sense that there is more variation.

It's the average delay among all the EID retrieved at the given time from the
vantage point.
> 
> Previously, the Map-Request was sent over the ALT (via the ALT's root, in
> almost all cases) to the ETR, and then the reply came back. Not a lot to vary
> there (although the path from the root to the Map-Server would vary a bit).
> 
> Now, depending on how the delegation tree is configured (i.e. how many layers
> from the root to the Map-Server for the mapping in question), how many of
> those delegations are cached in the Map-Resolver the ITR is talking to, etc
> you would expect to see a certain amount of variation.
> 

agree, we therefore need to figure out where to place DDT nodes, how much
the (root) nodes must be replicated, and how deep the tree must be to achieve
stable and low delays.

Damien Saucez


> 	Noel