Subject: Re: [alto] Clarifying Cost Map Dependencies on a Network Map

From: Wendy Roome <[email-masked]>
Date: Thu, 18 Jul 2013 13:31:08 -0400

I like the idea of reserving the id "default-network-map" (say) for the
server's "default" or "general purpose" network map. Clients would use
that map unless explicitly configured to use a different one.

However, I think default-network-map should be optional. The server should
offer one only if it is a truly a general-purpose map. Why? Because I can
imagine an ALTO server that provides nothing but specialized network maps.
Clients of that server should be configured with the desired network map
id. Clients that try to use the default map should fail.

This does imply that any ALTO server returned by the discovery protocol
must provide default-network-map.

If anyone objects to reserving an id name, we could add an optional
"default-network-map-id" attribute to the IRD's metadata.

Because "routingcost" is the implicit default cost metric, I don't think
reserving an id for a default cost map would provide any benefit.

	- Wendy Roome

On 07/17/2013 17:57, "[email-masked]" <[email-masked]> wrote:

>Message: 1
>Date: Wed, 17 Jul 2013 21:03:18 +0100
>From: Ben Niven-Jenkins <[email-masked]>
>To: Wendy Roome <[email-masked]>
>Cc: alto <[email-masked]>
>Subject: Re: [alto] Clarifying Cost Map Dependencies on a Network Map
>Message-ID: <[email-masked]>
>Content-Type: text/plain;	charset=us-ascii
>
>We can reserve an id for a 'default' map the clients can fallback to. If
>there's demand for multiple maps and they provide value clients will
>provide hooks to select a map. If there isn't then none of this matters
>:-) Ben
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 23 Jul 2013 13:10:23 -0400

Hi Wendy,

Sorry for the belated reply. Please see below.

> imagine an ALTO server that provides nothing but specialized network maps.

Yes. I agree that an ALTO Service that provides only specialized network
maps can already provide value. For example, one network map lists the
mapping from access technology (e.g., ADSL, Fiber, LTE...) to its pool of
IP addresses... Another network map lists each country/city code and the
lists of  IP addresses... Such maps can provide information to some
applications.

I agree that in such a setting, there may not be a general-purpose network
map: every network map is specialized, and we do not have to force the ALTO
Service Provider to single one out as the "default".

> must provide default-network-map.
Not sure I understand why must return a default-network-map?

> "default-network-map-id" attribute to the IRD's metadata.

 I feel that an attribute makes more sense. But increasingly, I feel less
convinced that an ALTO Service needs to provide a default attribute to a
network map.

My understanding of the context where a default map can help is default
behaviors of an application programming API design. Let's consider the
origin application context. It is a P2P app who wants to fetch the
routingcost. The default API should look for the (or the first) cost map
resource in the IRD with routingcost as the cost metric. This resource will
list the network map that the cost map uses. Hence, if we want to help this
case, and for the case where there are multiple cost maps of "routingcost",
we mark one of these as the default (or a numerical priority value).
Another solution is to specify the "semantics" that the first entry of the
same type of resource is the default. This is less robust, but avoids new
syntax. A third solution is to assign a preference value of the same type
of resource to give them an ordering. Hence, it is a more general solution
than marking a single one as default.

What do you think?

Richard

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Wendy Roome <[email-masked]>
Date: Tue, 23 Jul 2013 16:52:35 -0400

Here's why an IRD returned by ALTO discovery must must have a default
network map. Consider an ALTO client that gets the server URI via discovery.
By definition, a discovery client must be provider-independent. Because
resource ID names are provider-specific, a discovery client cannot be
pre-configured with a map ID. Hence any IRD returned by discovery MUST mark
one of its maps as the default. If not, a discovery client can't decide
which network map to use.

Of course, there'd be no problem if ALTO discovery could return a map ID as
well as a URI. But I gather that's not possible.

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Tue, July 23, 2013 13:10
Subject:  Re: [alto] Clarifying Cost Map Dependencies on a Network Map

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 23 Jul 2013 18:19:40 -0400

Hi Wendy,

Very interesting proof-style argument!

I will rephrase your statement slightly and let's see if I understand it
correctly.

Let ird be the uri of the IRD that a client c discovers. Let o_ird be the
object content that the client c fetches when retrieving the URI ird.
Assume that o_ird contains at least two resource IDs (at the same domain or
not) whose media-type is networkmap. Then the client c encounters a
complexity of choosing among multiple network maps.

Before we solve the problem by naming or assigning attributes to network
maps, let's try to get some sense on the cases that a network provides
multiple network maps. Consider two given network maps nm1 and nm2. There
are two types of relationship between them:

1. They are independent, e.g., nm1 maps access technology; nm2 maps
geolocation;
2. They are related. In particular, we can define a refinement
relationship, i.e., nm2 is a refinement of nm1, iff for any pid2 in
nm2, all IP addresses in pid2 belongs to only one pid in nm1.

In the current ALTO spec, there is no syntax to define the second case,
although there were discussions in early days on defining one pid based on
another pid (e.g., first define ASN and then use ASN). Note that a client
can discover refinement by fetching two network maps and conducting a
test as in the definition, although this can be expensive.

Now, consider the set of network maps contained in o_ird. Build a graph
where each node is a network map in o_ird. Some of them are related by the
refinement relation. If nm2 is a refinement of nm1, we draw an edge from
the node representing nm1 to that representing nm2. If this graph has a
single root, then it is natural to label the root as the "default" or
"root". If it has multiple roots, then I assume that one of the roots is
likely labeled as default, but the semantics is less clear.

Richard

On Tuesday, July 23, 2013, Wendy Roome wrote:

> network map. Consider an ALTO client that gets the server URI via
> discovery. By definition, a discovery client must be provider-independent.
> Because resource ID names are provider-specific, a discovery client cannot
> be pre-configured with a map ID. Hence any IRD returned by discovery MUST
> mark one of its maps as the default. If not, a discovery client can't
> decide which network map to use.
>
> Of course, there'd be no problem if ALTO discovery could return a map ID
> as well as a URI. But I gather that's not possible.
>
> - Wendy Roome
>
>
> From: "Y. Richard Yang" <[email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');>>

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 24 Jul 2013 09:48:26 +0200

> well as a URI. But I gather that's not possible.

The current discovery procedures do not support that, and it seems to me
that this would only move the problem to another subsystem instead of
solving it - if you cannot decide which map to mark as default in the
IRD, how could you decide which map name to indicate as default using a
to-be-defined extension of the discovery mechanism?

Thanks
Sebastian

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 24 Jul 2013 15:14:17 +0000

I am not trying to open again the discussion on HTTP-based discovery we had some time ago, but it looks to me that situations like the one described by Wendy could imply that we'd need some mechanism for optionally providing metadata as a result of the initial discovery process. Unless I am missing something, this would be a case for an extended HTTP-based discovery.

I think we could discuss on this during the extended evening session that Enrico announced for Wednesday.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 24 Jul 2013 17:33:59 +0200

I don't think we need an extension to the discovery procedure for that.
As I said, I think it would just shift the problem, not solve it.

In a deployment scenario where a network operator actually can clearly
decide that some group of hosts "A" should use map_A as default
(unless they know better and want to override it) and group "B" should
use map_B, they can configure two IRDs, e.g.
altoserver.isp.example/A/ird  and altoserver.isp.example/B/ird 
and let the discovery procedure return the right URI for the each
group member.

Then, the altoserver.isp.example/A/ird  must express that map_A is
the default map for all clients that have discovered this IRD.
The ALTO protocol must provide the possibility to express that.

Sebastian

On Wed, Jul 24, 2013 at 03:14:17PM +0000, Diego R. Lopez wrote:
> I am not trying to open again the discussion on HTTP-based discovery
> we had some time ago, but it looks to me that situations like the one
> described by Wendy could imply that we'd need some mechanism for
> optionally providing metadata as a result of the initial discovery
> process. Unless I am missing something, this would be a case for an
> extended HTTP-based discovery.
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 24 Jul 2013 13:57:31 -0400

Hi Sebastian,

> The ALTO protocol must provide the possibility to express that.
I see two ways to express this in the ALTO protocol (not through another
configuration channel):

(1) prune: delete map_B from the IRD given to hosts "A", and delete map_A
from the IRD given to hosts "B". This assumes that each hosts group needs
only one map, e.g., a fish-eye map for each of the two coasts.

(2) mark one as the default, which I believe that we will add as a
consensus on the mailing list. In other words, the IRD page is still
dynamic, depending on the receiver.

Which approach to take will then be a deployment's decision.

Richard

> discovery.

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 24 Jul 2013 20:48:59 +0200

Hi Richard,

> Which approach to take will then be a deployment's decision.

I support adding the neccessary protocol elements needed to
support (2).

Speaking of dynamically generated IRDs: how would the ALTO server
identify the client in order to generate an IRD specifically for it?

This could be done based on the source IP address of the HTTP
connection, or based on an X-Forwarded-For header in HTTP.  But how
would we do that in the third-party use case, e.g., if a P2P tracker
issues ALTO queries on behalf of (topologically distant) resource
consumers? Is there a way to explicitly tell the resource consumer's
ID/IPaddress when requesting an IRD?

Sebastian

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 24 Jul 2013 15:00:57 -0400

Hi Sebastian,

On Wed, Jul 24, 2013 at 2:48 PM, Sebastian Kiesel <[email-masked]>wrote:

> > On Wed, Jul 24, 2013 at 11:33 AM, Sebastian Kiesel <[email-masked]
> >wrote:
> >
Great. It appears that we have good support for adding (2) now.

> connection, or based on an X-Forwarded-For header in HTTP.

For requests originated from end users, the preceding can serve
as the  customization parameter.

> But how

Third party is a more challenging case. It is interesting that you appear
to suggest that the requestor of the IRD can indicate the end user that
the request is for, say in X-Forwarded-For. This will require that the ALTO
Server check the field, and the (third-party) requestor set the field.
Interesting
idea. I am not sure if we want to take on this in the base protocol. But it
is quite interesting, and I never thought about this possibility.

Thanks!

Richard

---

From: Sebastian Kiesel <[email-masked]>
Date: Wed, 24 Jul 2013 21:16:06 +0200

Hi Richard,

On Wed, Jul 24, 2013 at 03:00:57PM -0400, Y. Richard Yang wrote:
> the request is for,

"yes" up to here ...

> say in X-Forwarded-For.

... this seems too much of a hack to me.

maybe  GET http://altoserver.example/ird&rc=192.0.2.55
(RC=ressource consumer) or what would be a RESTful solution approach?

> This will require that the ALTO

if we cannot find a very simple solution that still can be added to the
base protocol without the risk of side effects, I could imagine a future
extension that uses POST to request the IRD and give more information
about the client and its expectations wrt. the ALTO guidance.

thanks
Sebastian

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 24 Jul 2013 15:29:54 -0400

Hi Sebastian,

On Wed, Jul 24, 2013 at 3:16 PM, Sebastian Kiesel <[email-masked]>wrote:

> > On Wed, Jul 24, 2013 at 2:48 PM, Sebastian Kiesel <[email-masked]
> >wrote:
> >

In addition to a reaction of it being a hack, some other reactions that I
can "hear" include that this creates cross-layer issues (against); we
should use existing mechanisms whenever possible (for).

> about the client and its expectations wrt. the ALTO guidance.
The idea of introducing parameters in the request for IRD (i.e., filtered
IRD)
is an interesting one. I will think more about it.

Thanks!

Richard