Subject: Re: [alto] What is an ALTO server?

From: Wendy Roome <[email-masked]>
Date: Fri, 19 Jul 2013 15:20:24 -0400

Folks,

I'll explain my position one more time, and then I'll shut up.

I think the "multiple network map" extensions in draft 17 do not help.
They do not provide any features that weren't available draft 16. All they
do is add complexity.  I suggest rolling back to the draft 16 IRD
structure.

Here's why. With draft 16, if a provider wanted to offer 3 network maps,
they'd provide 3 separate IRDs, one per network map. Say
     http://www.myalto.com/map1/directory
     http://www.myalto.com/map2/directory
     http://www.myalto.com/map3/directory
A client would have to select the IRD via some mechanism that's beyond the
protocol.

In draft 17, the provider can put 3 network maps in one IRD, say
     http://www.myalto.com/directory
But logically, the "id" & "uses" fields partition that IRD into 3 separate
service clusters, one per network map. There are no tie-ins between
clusters. Yes, the client only has to cope with one IRD, but it has to
pick one of the three network maps via some mechanism that's beyond the
protocol.

I claim the only difference is that in -16, a client needed the IRD uri,
while in -17, a client needs that uri plus the network map name. In both
schemes, each network map has a name. It's just that in -16, the map name
is embedded in the IRD's uri, while in -17, the map name is additional
configuration data. So why is -17 any more powerful than -16?

And because the -16 scheme was a lot simpler, I recommend reverting to
that.

BTW, I think part of the problem was that somewhere along the way we
started to assume that a hostname can only have one IRD -- see the
examples. If you believe that, then it certainly makes sense to extend
IRDs to allow multiple network maps. But I see no reason for that
limitation. 

Apologies to those who spent a lot of work on draft 17, but that's how I
see it. And that's all I'll say in public unless someone asks. Private
discussions are welcome, of course.

	- Wendy Roome

>Message: 2
>Date: Fri, 19 Jul 2013 11:44:29 +0200
>From: Sebastian Kiesel <[email-masked]>
>Subject: Re: [alto] What is an ALTO server?
>
>Enrico, all,
>
>On Fri, Jul 19, 2013 at 10:50:47AM +0200, Enrico Marocco wrote:
>>On 7/19/13 10:30 AM, Sebastian Kiesel wrote:
>>> Sure. I know these paragraphs. But these would be compatible with all
>>> of the three definition approaches in my original mail (see below).
>>> So I am wondering whether we need a more precise definition. What is
>>> the unique thing that defines an individual ALTO server? The single
>>>IRD,
>>> the single network map, ...?
>>I may be missing something, but I actually don't get what we'd gain in
>>redefining concepts that are very common to most protocols, and in
>>particular to HTTP that ALTO builds on.
>>To turn the question around, what's the server when you open a web URL
>>in your browser? The L2 load balancer in front of the datacenter that
>>you'll hit first? The chain of reverse proxies you're likely going to
>>hit? The worker process putting together the biggest amount of bytes
>>that will go in the HTTP response you'll get in return? The virtual
>>machine on which such process runs? The physical box?
>>Again, I may be missing something, but this looks like a slippery slope
>>I'd rather not go to..
>
>The point behind my question is, when I read the thread on costmap
>dependencies there are several statements what an ALTO server should
>(not) do or have, e.g. more than one network map.  As an example, let me
>quote a mail from Wendy:
>
>>(1) I certainly agree that there is value in allowing a provider to offer
>>multiple network maps. I merely suggested that when provider does that,
>>we
>>regard each network map, and the associated cost services, as a different
>>ALTO Server. So if a provider has several network maps, they offer one
>>ALTO
>>*Service* with several separate ALTO *Servers*.
>[Message-ID: <[email-masked]>]
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 19 Jul 2013 19:10:26 -0400

Hi Wendy,

Personally, I prefer that we do not limit to one network map per IRD,
because I see use cases where multiple network maps are more natural. In
addition to use cases of different granularities, there are other use
cases. One example is the CDN use case by Jan, where multiple network maps
are helpful.

Here is some thinking on resolving the dependency/reference issue.

- The objective of ALTO is to allow a network to provide information
resources (IRs). Since we are RESTful based, we can consider each IR as a
web page, if this helps with a mental model.

- We distinguish two types of IRs:

  leaf IR: the data conveyed in such an IR does not refer to the data
defined in another IR;

 non-leaf: a non leaf IR.

For example, in the current ALTO information resources, network maps are
leaf, but cost maps are not, because the definition of a cost map can refer
to PIDs defined in a network map (or even maps, if we want to be
aggressive). Given the cost map but not the network map, the client cannot
"resolve" the values of all references (i.e., the values of PIDs).

Now, build a dependency graph G of all ALTO information resources available
by an ALTO Server (Service), where there is a link from IRa to IRb, iff the
definition of IRa depends on some definition provided in IRb. We write such
a dependency as IRa -> IRb. The objective of an IRD is to help IRa to find
IRb. Assume that the dependency graph G has no loop. Then the ALTO service
provider can compute many IRDs---an ALTO provider may not want to provide
all IRs to a specify client. Specifically, assume that the network decides
to provide a set S of IRs to some (class of) clients. Then, the network
computes a (minimal) IRD through closure, i.e.,

- start the IRD containing the resources in S
- if there is a path from an IR i in S to another IR in j in the dependency
graph G, add j to the IRD

One can see that an client obtaining the preceding IRD can resolve all
definitions.

The preceding dependency graph does reveal that there can be reference
ambiguity, in the *general* case. For example, IRa -> IRb, and IRa -> IRc.
But an item used in IRa may be defined in both IRb and IRc. As a made-up
example, IRa is a cost map and refers to PIDs named "a", "b", "c"; IRb is a
network map that defines PIDs named "a", and "b"; and IRc is another
network map that defines PIDs named "a" and "c". Then IRa cannot resolve
without ambiguity of the definition of "a". ALTO can solve such issues
using more qualified names such as IRb.a to denote that it is the "a"
defined in IRb. In the current spec, since the only dependency is from a
cost map to only one network map (a cost map can specify "uses" for only
one network map"), we do not have such an issue, but we can solve the issue
if the more general information distribution structure is needed.

Does this address the problems that you have in mind?

Thanks!

Richard

On Fri, Jul 19, 2013 at 3:20 PM, Wendy Roome <[email-masked]>wrote:

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

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 22 Jul 2013 18:14:49 -0500

On 07/19/2013 06:10 PM, Y. Richard Yang wrote:
 > because I see use cases where multiple network maps are more natural. 
[...]

Richard, Wendy: This has been an invigorating discussion.

I believe that the semantics in -17 are quite flexible and allow us to
represent one or more network maps in an IRD.  This is all good.

I believe what is missing in -17 is the notion of a default network
map, which will allow a client to stay simple if it does not want to
deal with the complexity of understanding multiple maps by following the
delegation URL or even the complexity of handling multiple network
map resources in the same IRD.

Let me be more clear.

 From early on, ALTO has assumed that an IRD provides a network map and
one or more cost maps.  It was also implicitly assumed that the cost
maps referenced the network map that was received in the IRD.  This was
a simple and effective model.  The IRD could be generated dynamically
after HTTP-digesting a client so as to provide a different view to a
different client, or the IRD could be generated by traversing an
acyclic dependency graph [1] where network maps are modeled as
vertices with out-degree of 0 (leaf) and cost maps are modeled as
vertices with at an out-degree of at least 1 (non-leaf) [1].

But regardless how you derive an IRD, the sacrosanct assumption was
that the IRD contained a network map and one or more cost maps.  We now
have a situation where there may be multiple network maps, either in
the same IRD or through delegation, and cost maps that refer to
different network maps.

Opinions have been expressed that the client becomes complex or that
the server becomes complex since the costs have to be cross-referenced
to the appropriate network map.  No doubt, there is additional
complexity that needs to be understood in sufficient detail to deliver
the protocol document to the IESG in short time.

I believe that a reasonable way to tame the complexity while allowing
for future flexibility is to designate one network map in the parent
IRD as the default network map.  (As a definition of the parent IRD, I
mean the IRD that is obtained through the ALTO server discovery
process.)  I note that S8.5.3 of -17 contains a resource whose id is
"default-network-map", but this is different than *choosing* one
resource that is the *authoritative* default network map.  Today, this
normative text is missing from the draft; there is nothing in the text
that names a network map in the IRD as a default map.

Perhaps an attribute could be assigned to such a network map to
indicate its usage as a default network map, or perhaps we can choose
to represent the default network map with a reserved id.  Either method
is fine as long as there is normative text in the draft that ensures
the existence of a single network map that is considered the default
network map.

Why is the notion of this default network map so important?  Well, it
allows for simpler clients.  Clients that choose not to deal with the
complexity of multiple network maps spread out in different subdomains
(delegation) simply look for the default network map in the parent
IRD and apply the mandatory 'routingcost' cost metric to the default
network map.  Clients that are prepared to deal with additional
complexity can do so by supporting multiple network maps spread out in
different subdomains (delegation).

One can argue that the ALTO server is forced to deal with simple
clients by ensuring that a reasonable default network map and a cost
map corresponding to it are always available.  But that is not a new
onus on the ALTO  server, it always did that.

In summary, it seems to me that we can easily support multiple network
maps through one IRD semantic as well as allow the latent notion that
an IRD contains an authoritative network map simply by designating a
default network map more explicitly.  This allows clients to stay
simple if they desire and does not add any additional burden on the
server beyond providing one network map and one cost map as it has
always done.

Thoughts?

[1] http://www.ietf.org/mail-archive/web/alto/current/msg02054.html

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

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

Hi Vijay,

Let me try to summarize your proposed strategy:

Syntax
=====
For the root IRD (the one discovered from the discovery protocol) obtained
by a client, if there are *more than one* network map resources listed in
the IRD, one and only one of the network maps MUST be marked with a
"default" attribute.

Footnotes: (1) in the general case, an IRD may have 0 network maps (e.g.,
only endpoint properties); (2) consider the deployment cases where the ALTO
Service provides multiple "orthogonal" network maps (i.e. harder to argue
which one is more "default" than the other, the IRD can choose to mark one
as default.

Q: should we change "more than one" to "at least one" in the preceding? If
not, the interpretation is that when only one network map, it has a default
attribute automatically marked.

Semantics
========
1. If a client uses only network map as guidance for traffic localization,
it should use the default network map, as the default behavior;

2. If a client uses both network map and cost map, it should use the
"routingcost" cost map based on the default network map, as the default
behavior.

Q: what if there are multiple "routingcost" cost maps based on the same
network map? I would say Forbidden.

Is this what you have in mind?

Richard

On Mon, Jul 22, 2013 at 7:14 PM, Vijay K. Gurbani <[email-masked]> wrote:

> [1] http://www.ietf.org/mail-**archive/web/alto/current/**msg02054.html<http://www.ietf.org/mail-archive/web/alto/current/msg02054.html>
>
> Thanks,
>
> - vijay
> --
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.**com<[email-masked]>
> Web: http://ect.bell-labs.com/who/**vkg/<http://ect.bell-labs.com/who/vkg/> | Calendar:
> http://goo.gl/x3Ogq
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 24 Jul 2013 00:03:38 +0100

Richard, Colleagues,

On 23 Jul 2013, at 18:39, Y. Richard Yang wrote:

> For the root IRD (the one discovered from the discovery protocol) obtained by a client, if there are *more than one* network map resources listed in the IRD, one and only one of the network maps MUST be marked with a "default" attribute.
> 
> Footnotes: (1) in the general case, an IRD may have 0 network maps (e.g., only endpoint properties); (2) consider the deployment cases where the ALTO Service provides multiple "orthogonal" network maps (i.e. harder to argue which one is more "default" than the other, the IRD can choose to mark one as default.

I can't help but wonder if you're over-thinking this.

As I see it clients that are only expecting a single network map need a mechanism to decide which network map to use. A default name provides that purpose. For clients that are expecting multiple maps, the default name is really just like any other map name - the client knows which maps it is interested in and retrieves them accordingly. For ALTO services that are offering multiple maps where no default makes sense then clients that only handle a single map aren't going to be able to make use of that ALTO service anyway so it doesn't matter.

Do we need anything more complex than putting the above into better words?

Ben

> 
> Q: should we change "more than one" to "at least one" in the preceding? If not, the interpretation is that when only one network map, it has a default attribute automatically marked.
> 
> Semantics
> ========  
> 1. If a client uses only network map as guidance for traffic localization, it should use the default network map, as the default behavior;
> 
> 2. If a client uses both network map and cost map, it should use the "routingcost" cost map based on the default network map, as the default behavior.
> 
> Q: what if there are multiple "routingcost" cost maps based on the same network map? I would say Forbidden.
> 
> > because I see use cases where multiple network maps are more natural. [...]
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 23 Jul 2013 20:37:09 -0500

On 07/23/2013 12:39 PM, Y. Richard Yang wrote:
> For the root IRD (the one discovered from the discovery protocol)
> obtained by a client, if there are *more than one* network map resources
> listed in the IRD, one and only one of the network maps MUST be marked
> with a "default" attribute.

Richard: Yes.  (Sorry for the delay, email is sporadic due to travel.)

> Footnotes: (1) in the general case, an IRD may have 0 network maps
> (e.g., only endpoint properties); (2) consider the deployment cases
> where the ALTO Service provides multiple "orthogonal" network maps (i.e.
> harder to argue which one is more "default" than the other, the IRD can
> choose to mark one as default.

For (1), I suspect you are thinking of datacenter type of
applications.  In such a case, it is obvious perhaps that there will not
be any cost maps either.  So, the semantics could simply be that the
absence of a network map implies no contract to provide cost maps
either, and therefore the IRD only contains properties of some kind.

Regarding (2), if the intent is to keep the client simple (one of the
prerequisites I gathered from the earlier thread), then indicating one
of these orthogonal maps as default seems reasonable.  Either the
provider can do so or the client can simply pick one map and consider
it as the default.  My preference would be for the service provider
to mark one as default.  After all, the service provider knows (a)
the network and (b) the identity of the client.  Knowing (b), the
service provider can tailor the network map appropriately (at least
that is what we have been assuming so far).

> Q: should we change "more than one" to "at least one" in the preceding?
> If not, the interpretation is that when only one network map, it has a
> default attribute automatically marked.

Fine, just so long as we spell this out in the draft.

> Semantics
> ========
> 1. If a client uses only network map as guidance for traffic
> localization, it should use the default network map, as the default
> behavior;

Yes.

> "routingcost" cost map based on the default network map, as the default

Yes.

> network map? I would say Forbidden.

Yes.

We need to get a protocol out that is reasonably broad enough to cover
many cases without having to poke at corner cases.  My feeling is that
we are close to this now.  If we get overwhelmed by the corner cases,
we may not get too far too quickly.

Thanks,

- vijay

---

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

Hi Ben,

On Tue, Jul 23, 2013 at 7:03 PM, Ben Niven-Jenkins
<[email-masked]>wrote:

> listed in the IRD, one and only one of the network maps MUST be marked with
> a "default" attribute.
> >
> (e.g., only endpoint properties); (2) consider the deployment cases where
> the ALTO Service provides multiple "orthogonal" network maps (i.e. harder
> to argue which one is more "default" than the other, the IRD can choose to
> mark one as default.
>
Clearly I am trying to think over whether we should introduce the default
attribute :-)

> As I see it clients that are only expecting a single network map need a
> mechanism to decide which network map to use. A default name provides that
> purpose. For clients that are expecting multiple maps, the default name is
> really just like any other map name - the client knows which maps it is
> interested in and retrieves them accordingly. For ALTO services that are
> offering multiple maps where no default makes sense then clients that only
> handle a single map aren't going to be able to make use of that ALTO
> service anyway so it doesn't matter.
>

Good summary of the cases. The complexity is the last case: multiple
network maps and not clear which one should be marked as the default. The
"agony" was that we still require that the operator mark one network map as
default, if we introduce default, which can then become operational
confusing. By thinking it through, we plan to add a sentence to indicate
that when such a case happens, the marking is essentially irrelevant, as
you suggested.

Thanks!

Richard

---

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

Hi Vijay,

> that is what we have been assuming so far).
Sounds good.

> Fine, just so long as we spell this out in the draft.
OK.

> we may not get too far too quickly.
Agree.

Thanks!

Richard