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

From: Richard Alimi <[email-masked]>
Date: Thu, 20 Jun 2013 00:45:21 -0700

[ We would like to hear feedback on this.  We are planning to revise and
submit a new version ASAP, so please voice opinions on this within the next
few days, by Monday, June 24th. ]

Background:

Today, the ALTO protocol as a 'version tag' to indicate which version of a
network map is used by a particular cost map.

In a particularly simple case, a single ALTO server is served by a single
hostname (or IP address, whatever), and it exposes a single network map and
one or more cost maps.  There is no ambiguity here - a client automatically
knows that any version tag refers to the single network map that is hosted
by the server.

There are two alternate scenarios where ambiguities arrive:

(Scenario 1) An IRD hosted by alto.isp1.example.com refers cost maps
provided by some third-party, say alto.third-party.example.com.  In this
scenario, do version tags exposed by
alto.third-party.example.comcorrespond to the network map provided by
alto.isp1.example.com?

(Scenario 2) A single ALTO server (single hostname) wishes to provide two
different network maps (say, different levels of aggregation) and wants to
provide cost maps for each of them.  Currently, the version tag
accompanying a cost map is not sufficient for a client to determine which
network map a particular cost map is based on.

Proposal:

To resolve these problems, we'd like to propose a simple change to the
version tag accompanying the cost map - it would now include the URI to the
network map in addition to an opaque ID.

OLD (what we have now):

{
 "meta" : {},
 "data" : {
   "cost-type" : {"cost-mode"  : "numerical",
                  "cost-metric": "routingcost"},
   "map-vtag"  : "1266506139",
   "map" : {
     "PID1": { "PID1": 1,  "PID2": 5,  "PID3": 10 },
     "PID2": { "PID1": 5,  "PID2": 1,  "PID3": 15 },
     "PID3": { "PID1": 20, "PID2": 15  }
   }
 }
}

NEW PROPOSAL:

{
 "meta" : {},
 "data" : {
   "cost-type" : {"cost-mode"  : "numerical",
                  "cost-metric": "routingcost"},
   "network-map" : {

     "uri": "http://alto.example.com/networkmap1"

     "vtag": "1266506139"

     }

   "map" : {
     "PID1": { "PID1": 1,  "PID2": 5,  "PID3": 10 },
     "PID2": { "PID1": 5,  "PID2": 1,  "PID3": 15 },
     "PID3": { "PID1": 20, "PID2": 15  }
   }
 }
}

Compared to the current approach we have in draft -16 (which is for a
version tag to be consistent within resources served by the same hostname),
this has the following advantages:
- It provides a more flexible solution to Scenario 1
- It allows us to handle Scenario 2

An possible addition to this approach would be explicitly declare the
dependency between the cost map and the network map in the IRD.

Feedback would be great.  The editors believe this would be a strong
improvement to the draft.

Thanks,
Rich

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Fri, 21 Jun 2013 14:33:53 +0000

Hi Rich,

Definitely, scenario2 and 1 are convincing motivations and I support your proposal. I also approve specifying the dependency in the IRD to avoid requesting an irrelevant Cost Map in such scenarios.
Best regards
Sabine

De : [email-masked] [mailto:[email-masked]] De la part de Richard Alimi
Envoyé : jeudi 20 juin 2013 09:45
À : [email-masked]
Objet : [alto] Clarifying Cost Map Dependencies on a Network Map

[ We would like to hear feedback on this.  We are planning to revise and submit a new version ASAP, so please voice opinions on this within the next few days, by Monday, June 24th. ]

Background:

Today, the ALTO protocol as a 'version tag' to indicate which version of a network map is used by a particular cost map.

In a particularly simple case, a single ALTO server is served by a single hostname (or IP address, whatever), and it exposes a single network map and one or more cost maps.  There is no ambiguity here - a client automatically knows that any version tag refers to the single network map that is hosted by the server.

(Scenario 1) An IRD hosted by alto.isp1.example.com<http://alto.isp1.example.com> refers cost maps provided by some third-party, say alto.third-party.example.com<http://alto.third-party.example.com>.  In this scenario, do version tags exposed by alto.third-party.example.com<http://alto.third-party.example.com> correspond to the network map provided by alto.isp1.example.com<http://alto.isp1.example.com>?

(Scenario 2) A single ALTO server (single hostname) wishes to provide two different network maps (say, different levels of aggregation) and wants to provide cost maps for each of them.  Currently, the version tag accompanying a cost map is not sufficient for a client to determine which network map a particular cost map is based on.

Proposal:

To resolve these problems, we'd like to propose a simple change to the version tag accompanying the cost map - it would now include the URI to the network map in addition to an opaque ID.

OLD (what we have now):

{

 "meta" : {},

 "data" : {

   "map" : {

   }

 }

}

NEW PROPOSAL:

{

 "meta" : {},

 "data" : {

   "network-map" : {

     "vtag": "1266506139"

     }

   "map" : {

   }

 }

}

Compared to the current approach we have in draft -16 (which is for a version tag to be consistent within resources served by the same hostname), this has the following advantages:
- It provides a more flexible solution to Scenario 1
- It allows us to handle Scenario 2

An possible addition to this approach would be explicitly declare the dependency between the cost map and the network map in the IRD.

Feedback would be great.  The editors believe this would be a strong improvement to the draft.

Thanks,
Rich

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 24 Jun 2013 19:19:35 +0000

I agree that in particular scenario 2 is relevant and should be addressed. 

Like Sabine, I wonder how a client would actually deal with two different network maps if we don't provide any hint in the IRD (probably IRD entries can be entirely optional if there is only one network map). Should the client query all candidate cost maps in that case?

For what it is worth, at first sight, an alternative to the proposed "refers-to" solution on slide 8 of the interim meeting slide deck would be an extended IRD entry for each network map:

       {
         "uri" : "http://alto.example.com/networkmap1",
         "media-type" : "application/alto-networkmap+json",
         "used-by": {
           "http://alto.example.com/costmap/num/routingcost_lowres"
         }
       },
       {
         "uri" : "http://alto.example.com/networkmap2",
         "media-type" : "application/alto-networkmap+json",
         "used-by": {
           "http://alto.example.com/costmap/num/routingcost_highres"
         }
       },

One motivation for that syntax would be to better explain the differences between the several network maps. I don't have any strong preference, though.

Another potential solution would be to define network map capabilities (such as "resolution" for scenario 2). Has this been discussed already? That approach alone might not solve scenario 1.

Finally, after having re-read some parts of -16, I wonder if some sections implicitly assume that there is only a single network map (notable exception: Section 6.3). For instance:

"10.1.1. Network Map

   The Network Map Information Resource lists for each PID, the network
   locations (endpoints) within the PID.  It MUST be provided by an ALTO
   Server."

"It" is a little bit unclear to me. More explicit would be something like "An ALTO server MUST provide at least one network map."

Best regards

Michael

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Richard Alimi
> Sent: Thursday, June 20, 2013 9:45 AM
> To: [email-masked]
> Subject: [alto] Clarifying Cost Map Dependencies on a Network Map
> 
> [ We would like to hear feedback on this.  We are planning to 
> revise and submit a new version ASAP, so please voice 
> opinions on this within the next few days, by Monday, June 24th. ]
> 
> Background:
> 
> Today, the ALTO protocol as a 'version tag' to indicate which 
> version of a network map is used by a particular cost map.
> 
> In a particularly simple case, a single ALTO server is served 
> by a single hostname (or IP address, whatever), and it 
> exposes a single network map and one or more cost maps.  
> There is no ambiguity here - a client automatically knows 
> that any version tag refers to the single network map that is 
> hosted by the server.
> 
> (Scenario 1) An IRD hosted by alto.isp1.example.com refers 
> cost maps provided by some third-party, say 
> alto.third-party.example.com.  In this scenario, do version 
> tags exposed by alto.third-party.example.com correspond to 
> the network map provided by alto.isp1.example.com?
> 
> (Scenario 2) A single ALTO server (single hostname) wishes to 
> provide two different network maps (say, different levels of 
> aggregation) and wants to provide cost maps for each of them. 
>  Currently, the version tag accompanying a cost map is not 
> sufficient for a client to determine which network map a 
> particular cost map is based on.
> 
> Proposal:
> 
> To resolve these problems, we'd like to propose a simple 
> change to the version tag accompanying the cost map - it 
> would now include the URI to the network map in addition to 
> an opaque ID.
> 
> OLD (what we have now):
> 
> {
>  "meta" : {},
>  "data" : {
> Compared to the current approach we have in draft -16 (which 
> is for a version tag to be consistent within resources served 
> by the same hostname), this has the following advantages:
> An possible addition to this approach would be explicitly 
> declare the dependency between the cost map and the network 
> map in the IRD.
>

---

From: Richard Alimi <[email-masked]>
Date: Sun, 30 Jun 2013 23:43:42 -0700

On Mon, Jun 24, 2013 at 12:19 PM, Scharf, Michael (Michael) <
[email-masked]> wrote:

> Like Sabine, I wonder how a client would actually deal with two different
> network maps if we don't provide any hint in the IRD (probably IRD entries
> can be entirely optional if there is only one network map). Should the
> client query all candidate cost maps in that case?
>

One possibility would be to first grab for the desired cost map, and then
retrieve the network map it depends on.  There is a potential loss in
efficiency since the client could fetch the network map and cost map in
parallel.

This seems to point in favor of listing the dependency explicitly in the
IRD, and I'm okay with that.  IIRC, Richard Yang was in favor of this as
well.

All that said, I was sitting down to write the text, and it turns out to be
a bit tricky.  In particular, when one specifies the URI for the network
map in the "refers-to" attribute, which URI is it?  Is it the exact same
URI present in the Network Map's entry in the IRD, or is it some canonical
(absolute) URI for that Network Map resource?  If the former, then those
URIs may be relative and this doesn't handle Scenario 1 very well.  If the
latter, then the ALTO Server generating the IRD has to know the series of
redirects that the client may experience (since the client may get relative
URIs for each Information Resource, and Section 5 of RFC3986 indicates that
the result of the relative -> absolute conversion may be dependent on
redirects that were followed).  These solutions get to be kind of ugly.

Two ideas come to mind for what we can do:
(1) Give each Information Resource a UUID, and refer to the dependencies by
UUID instead of a URI.
(2) Consider the addition of metadata to the IRD to declare dependencies to
be an extension (but we must still change Version Tags to declare the URI
for the Network Map in the base protocol).

I do think this is a nice-to-have optimization, but I don't think its
strictly necessary to satisfy this use case.  I could be persuaded either
way.

[ The change to the Version Tags ends up being straightforward, since the
server specifies all of them explicitly and can enforce that a single
Network Map URI be returned; there is no ambiguity introduced by relative
URIs in that case. ]

> For what it is worth, at first sight, an alternative to the proposed
> "refers-to" solution on slide 8 of the interim meeting slide deck would be
> an extended IRD entry for each network map:
>
>        {
> One motivation for that syntax would be to better explain the differences
> between the several network maps. I don't have any strong preference,
> though.
>
>
Interesting idea.  I'm trying to think about what would be more natural
from an implementation standpoint.  If I were writing a client, I think I
would primarily be interested in the cost map, and then I would need to
figure out which Network Map is required to interpret that Cost Map.  From
that standpoint, it seems like listing the dependency along with the Cost
Map seems more natural.  I have a slight preference for the "refers-to"
approach but beyond what I just mentioned I don't have any strong technical
reasons.

> Another potential solution would be to define network map capabilities
> (such as "resolution" for scenario 2). Has this been discussed already?
> That approach alone might not solve scenario 1.
>
>
I don't think the notion of network map capabilities has been discussed
yet, but given that we need to finish up the protocol ASAP, perhaps that
could be an extension?

>
> Finally, after having re-read some parts of -16, I wonder if some sections
> implicitly assume that there is only a single network map (notable
> exception: Section 6.3). For instance:
>
> "10.1.1. Network Map
>
> "It" is a little bit unclear to me. More explicit would be something like
> "An ALTO server MUST provide at least one network map."
>

Yes - agreed. We'll adjust the text here.  Thanks for pointing this out.

Thanks!
Rich