Re: [alto] Cost Maps, Endpoint Cost Maps and Coarse Grained Searches

Lyle Bertz <> Tue, 15 September 2015 00:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6719D1B37BE for <>; Mon, 14 Sep 2015 17:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.641
X-Spam-Level: *
X-Spam-Status: No, score=1.641 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CrdLB5s7vCcq for <>; Mon, 14 Sep 2015 17:18:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C19381A0203 for <>; Mon, 14 Sep 2015 17:18:13 -0700 (PDT)
Received: by vkfp126 with SMTP id p126so69215756vkf.3 for <>; Mon, 14 Sep 2015 17:18:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WhYFNwr3lnAlDim0JEdr+qmS44oeO5ySf1fNg03E6JE=; b=V+YSWTH3sEx8owBLZh0lTw13/zYjuK9MeyI/CD574NTSmv7a5dEOkfmN7aKV4NsfPy zr3cUdj3PdQ1FtT1VTDgOsW6zUJVohOgC4gIPwUBL+lEfY80AlnWFrb+6g5bzx+8KKDk Qu6Q/Ag2mOHaadAOF94fcMyewm1XVqvrw8QrnIsPWLL9CuOxfEXK3CvxLSN8XEIIl9us l05AbuajLVGQmZFNUJqnTyiprNRqAOVote3Meh2KfgywlpkJ1m4blhYNgdwG6uNWcBMo pmqLU8lz9qBqC4GOPwoDBq/ILeYgLoTm4IAcFvZwzgAnMfmfKom3twFOdzGrP2gYW+xN 6mLw==
MIME-Version: 1.0
X-Received: by with SMTP id m6mr17810663vke.54.1442276292887; Mon, 14 Sep 2015 17:18:12 -0700 (PDT)
Received: by with HTTP; Mon, 14 Sep 2015 17:18:12 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 14 Sep 2015 19:18:12 -0500
Message-ID: <>
From: Lyle Bertz <>
To: "Y. Richard Yang" <>
Content-Type: multipart/alternative; boundary=001a11416e8c1b0f56051fbe1edf
Archived-At: <>
Subject: Re: [alto] Cost Maps, Endpoint Cost Maps and Coarse Grained Searches
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Sep 2015 00:18:20 -0000


Thanks for the response.

My concern here is the costmap references a network map.   Per Section 6 of
RFC 7285

For a given ALTO network map, an ALTO cost map defines path costs
   pairwise amongst the set of source and destination network locations
   defined by the PIDs contained in the network map

This implies a measurement between endpoint in a network map and one in a
location NOT covered by the network map MUST be in the endpoint costmap.
It doesn't seem like much of an issue until you think about building an
endpoint cost service.

If there is no fine grained result present in the server, then it is my
understanding that the ONLY way you will have a coarse grained result is to
find a network map (and corresponding costmap for it and the specific
metric in question) where both endpoints belong to the same network map.

At least, I *think* that is the way I understand it.

If that is the case then it implies that 'off network map' measurements are
fine grained only.   I was wondering if this was intentional in the design
of ALTO or not?


On Fri, Sep 11, 2015 at 5:36 PM, Y. Richard Yang <>; wrote:

> Hi Lyle,
> It is cool to hear about this Erlang implementation! Please see below.
> On Tue, Sep 8, 2015 at 9:53 PM, Lyle Bertz <>; wrote:
>> All,
>> I am implementing an Erlang based ALTO server and had a couple of
>> questions based upon an observation of 7285.
>> The Cost Map is assumed to be coarse grained and one cannot make a
>> determination about whether an endpoint cost measure is fine or coarse per
>> the RFC.
> Agree. One cannot determine how fine-grained (precision) of given costs of
> a cost map.
>> If i am to search for a cost between two endpoints (1 source and 1
>> destination) and 'miss' on the first endpoint map I am looking at the other
>> endpoint costs responses I may have available for an answer.  In such a
>> case I can just look for the two endpoints and, if present, I have a hit
>> and I am good to go.
> Not sure I understand the setting. A bit more elaboration?
>> However, if I am looking to Cost Maps the map dependency assumes that
>> both endpoints are members of the same map.   This implies that only
>> endpoint cost maps can contain metrics between two endpoints that are not
>> in the same map.
> A cost map can have an entry between the same PID. Hence, an ALTO server
> can give some hint about the cost of endpoints in the same group. I
>> I find this interesting in that as a designer if you want all data in
>> Network Cost Maps you have to model the entire internet or you can just
>> rely on endpoint cost maps.
> Interesting comment. RFC7285 does require a network map to be complete and
> hence covers the entire Internet. But it does not require a cost map to be
> complete. Hence, if an ALTO server puts a default as a PID say
> pid0, it covers the entire Internet. But it can refuse to provide costs
> to/from pid0.
>> What was the intent in this relationship?  I like the open ended option
>> the endpoint cost maps provide but I am a bit reluctant to begin coding
>> something that may have not been an intentional feature in ALTO.
> If I understand the issue here correctly, the intent is that cost map
> provides coarse grained network info, while endpoint cost map (service) is
> for more (set in terms of number of endpoints) fine-grained cost.
> Make sense?
> Richard
>> Thanks.
>> Lyle
>> PS - Code for Erlang ALTO server (very Alpha) can be found at
>> <>
> Cool! I am eager to take a look!
>> _______________________________________________
>> alto mailing list