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

From: Wendy Roome <[email-masked]>
Date: Fri, 12 Jul 2013 10:02:52 -0400

You're welcome, Rich!

(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*.

Is that just semantics? Of course it is! But semantics are powerful.

NOTE: Nothing says those ALTO servers have to be on different hosts. They
can all use the same hostname, just with different URIs. Similarly, although
our examples don't show it, an IRD can have URIs for different hostnames.
That is, IRDs and ALTO Servers are orthogonal to hostnames.

Here's another way to look at it: in terms of the protocol, I don't see any
advantage to having one server with two network maps, versus regarding them
as two separate servers. Can anyone give a use case where it helps to offer
them in the same server?  Yes, combining them could be marginally more
efficient, because a client could retrieve one IRD vs two. But let's face
reality, compared to the rest of the transmission costs, that's trivial.

BTW, here's a straw-man example of why you might think you'd want to combine
different network maps into the same server. Within one "ALTO Server", it's
implicit that if several different cost services offer the same numeric cost
metric, then those costs are comparable between services. (At least that's
implicit to me!) So if an ALTO Server provides MapA and MapB, and MapA's
cost service says  the "routingcost" from endpoint X to Y is 42, and MapB's
cost service says the cost from X to Z is 57, a client can assume that Y is
better than Z. 

But a provider can easily accomplish the same result with two separate ALTO
Servers. The provider just tells clients that ServerA and ServerB use the
same algorithms to calculate costs.

(2) Yes, I agree "atomicity" is too strict. As you said, we should just
require that they converge. But they should converge in minutes, not hours.
If convergence requires human intervention, as in my example of two separate
groups in the same company, convergence could take days.

- Wendy

From:  Richard Alimi <[email-masked]>
Date:  Fri, July 12, 2013 02:59
To:  Wendy Roome <[email-masked]>
Subject:  Re: [alto] Clarifying Cost Map Dependencies on a Network Map

Thanks for the feedback.

Two quick comments:
(1) I think there is value in allowing multiple network maps for an ALTO
Server, all being served under the same hostname.  it may be "cheap" to use
a new hostname, but at that point I believe a restriction of one network map
per hostname would reduce the flexibility when it comes to deployment.   We
have tried hard to keep the ALTO protocol flexible by just identifying
resources by URIs and avoiding ties to a particular hostname.  I see the
fact that an "ALTO Server' is not tied to a single hostname as a feature.

(2) I think we should avoid requirements on atomicity, but instead be
satisfied with eventual consistency.  If updates are happening so frequently
that ALTO Clients are not converging (e.g., the network map is updating too
frequently), then we probably need the notification protocol that has been
proposed as an extension.

---

From: Richard Alimi <[email-masked]>
Date: Fri, 12 Jul 2013 08:31:52 -0700

On Fri, Jul 12, 2013 at 7:02 AM, Wendy Roome <[email-masked]>wrote:

> can all use the same hostname, just with different URIs. Similarly,
> although our examples don't show it, an IRD can have URIs for different
> hostnames. That is, IRDs and ALTO Servers are orthogonal to hostnames.
>

> Here's another way to look at it: in terms of the protocol, I don't see
> any advantage to having one server with two network maps, versus regarding
> them as two separate servers. Can anyone give a use case where it helps to
> offer them in the same server?  Yes, combining them could be marginally
> more efficient, because a client could retrieve one IRD vs two. But let's
> face reality, compared to the rest of the transmission costs, that's
> trivial.
>
> BTW, here's a straw-man example of why you might think you'd want to
> combine different network maps into the same server. Within one "ALTO
> Server", it's implicit that if several different cost services offer the
> same numeric cost metric, then those costs are comparable between services.
> (At least that's implicit to me!) So if an ALTO Server provides MapA and
> MapB, and MapA's cost service says  the "routingcost" from endpoint X to Y
> is 42, and MapB's cost service says the cost from X to Z is 57, a client
> can assume that Y is better than Z.
>
> But a provider can easily accomplish the same result with two separate
> ALTO Servers. The provider just tells clients that ServerA and ServerB use
> the same algorithms to calculate costs.
>

Having two separate servers would require two separate entry-points into
the alto server discovery.  Then the client has to pick a server at
discovery time.  This implies that ALTO server discovery has to find
multiple servers for a client, which I'm not sure it is prepared to handle
(and it was hard enough as it was).

> If convergence requires human intervention, as in my example of two
> separate groups in the same company, convergence could take days.
>

Absolutely.

> a new hostname, but at that point I believe a restriction of one network
> map per hostname would reduce the flexibility when it comes to deployment.
>   We have tried hard to keep the ALTO protocol flexible by just identifying
> satisfied with eventual consistency.  If updates are happening so
> frequently that ALTO Clients are not converging (e.g., the network map is
> updating too frequently), then we probably need the notification protocol
> that has been proposed as an extension.
>
>

---

From: Wendy Roome <[email-masked]>
Date: Fri, 12 Jul 2013 12:51:15 -0400

First, if discovery returns an IRD with two Network Maps, how does the
client know which map to use? Yes, we could add metadata to describe each
map's properties, and the client software could search that. But if we can
do that, why not associate that metadata with the IRD -- and hence the
server -- and have discovery do the searching?

Second, I gather discovery is designed to find "the ALTO server recommended
by your ISP". That's very useful, but that's not the only game it town. I
think there will be plenty of ALTO servers which aren't discovered via that
mechanism. For example, what happens if the client wants  the "hopcount"
metric, and "the ALTO server recommended by your ISP" doesn't offer it?

Finally, I think the ALTO servers that participate in discovery will be
simple "generic" servers. They'll offer the required services -- a network
map and a cost map for "routingcost" -- but that¹s it. No one writing a
client that uses an ALTO server obtained via discovery will count on the
server offering anything more than the required services, and hence there
will be no reason for those generic servers to provide anything more.

- Wendy Roome

From:  Richard Alimi <[email-masked]>
Date:  Fri, July 12, 2013 11:31
To:  Wendy Roome <[email-masked]>
Cc:  alto <[email-masked]>
Subject:  Re: [alto] Clarifying Cost Map Dependencies on a Network Map

Having two separate servers would require two separate entry-points into the
alto server discovery.  Then the client has to pick a server at discovery
time.  This implies that ALTO server discovery has to find multiple servers
for a client, which I'm not sure it is prepared to handle (and it was hard
enough as it was).

---

From: Richard Alimi <[email-masked]>
Date: Sat, 13 Jul 2013 13:44:12 -0700

> server -- and have discovery do the searching?

Given the current discovery protocol, that effectively means the client is
going to run some algorithm to figure out which of the IRD URIs it
discovers is desired (this is assuming, of course, that the discovery
protocol is setup to return multiple URIs).  At that point, why not
discover a single IRD and then let the client figure out which one it wants
based on the metadata in each IRD?  The metadata in the IRD can be extended
in the future as needed;  the discovery protocol uses other standards
(e.g., DNS) which can be less expressive.

As for a motivation for having multiple network maps and how it can work,
consider this:
(1) Client says it is interested in the 'hopcount' metric, so it finds the
cost map that provides it.
(2) Client looks in the IRD entry for that cost map, and it says that it
depends on "fine-grained-network-map"
(3) Client finds the corresponding network map and fetches it

A different cost map can depend on a different network map.

>
> Second, I gather discovery is designed to find "the ALTO server
> recommended by your ISP". That's very useful, but that's not the only game
> it town. I think there will be plenty of ALTO servers which aren't
> discovered via that mechanism. For example, what happens if the client
> wants  the "hopcount" metric, and "the ALTO server recommended by your ISP"
> doesn't offer it?
>

This sounds like the conversation is diverging from the original one -
sounds like a separate feature request for discovery and not the base
protocol?

> map and a cost map for "routingcost" -- but that’s it. No one writing a

I disagree.  I would expect other cost metrics to be made available as time
goes on.  But this also sounds like it's diverging from the original topic.

---

From: Sebastian Kiesel <[email-masked]>
Date: Sun, 14 Jul 2013 09:16:41 +0200

Richard, Wendy,

> (e.g., DNS) which can be less expressive.

just a reminder: the discovery procedure takes a value obtained from
DHCP or manual input or (for 3pdisc) the client's IP address plus a
selector whether we want to look for HTTP, HTTPS or both types of URIs,

It produces zero, one, or more tuples (URI, order, preference).
The two numerical values can be used to express priorities on a semantic
level (e.g., several information sources with different levels of detail
available) as well as from a load balancing / failover strategy point of
view (if one version of the content exists in several replica).

  Sebastian

---

From: Richard Alimi <[email-masked]>
Date: Sun, 14 Jul 2013 09:12:10 -0700

Hi Sebastian,

Yes - sorry I did not state this properly.   If there are multiple network
maps with varying levels of detail (or other differences) and the ALTO
Client in a position to figure out which one it wants, then its easier to
extend the ALTO-level information to convey this.  If the network provider
is in a position to make this determination, then it can be done at
discovery-time.

Rich

On Sun, Jul 14, 2013 at 12:16 AM, Sebastian Kiesel <[email-masked]>wrote:

> > On Fri, Jul 12, 2013 at 9:51 AM, Wendy Roome <[email-masked]
> >wrote:
> >