On Mon, Jul 1, 2013 at 11:34 AM, Y. Richard Yang <[email protected]> wrote:
> > On Mon, Jul 1, 2013 at 11:29 AM, Richard Alimi <[email protected]> wrote: > >> >> >> On Sun, Jun 30, 2013 at 11:43 PM, Richard Alimi <[email protected]>wrote: >> >>> >>> On Mon, Jun 24, 2013 at 12:19 PM, Scharf, Michael (Michael) < >>> [email protected]> wrote: >>> >>>> 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? >>>> >>> >>> 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. ] >>> >> >> Thinking about this some more, even changing the Version Tag to have a >> unique name (e.g., a UUID) instead of the Network Map URI would be quite a >> bit cleaner. >> >> Unless there are objections, I'll do the following: >> (1) Give each Information Resource an 'id' attribute which is a UUID >> (2) Define the 'refers-to' attribute which identifies the Information >> Resource on which it depends by its UUID >> (3) Define Version Tag to be: >> object { >> JSONString id; // UUID of the network map >> JSONString tag; // opaque identifier that changes with the version >> (as we have today) >> } VersionTag; >> >> How does this sound? >> > > A quick question on a potential scenario. Suppose a client fetches a cost > map (say costmapserver.alto.example.com), and hence obtains the UUID of > the network map. How does the client map the UUID to where to fetch the > network map, which might be hosted at networkmap.alto.example.com? > Presumably the IRD that pointed the user at costmapserver.alto.example.comwould have listed the UUID for that network map as one of its other resource entries. If the ALTO Client arrived at costmapserver.alto.example.com without any other knowledge of other maps, then I'm not sure there is much we can do. That seems to be a problematic deployment scenario with the ALTO Server Discovery pointing to the wrong place. In fact, i think this would violate the requirement that the Network Map must be provided since the ALTO Client wasn't given a path to locate it. > Thanks. > > Richard > > >> Thanks, >> Rich >> >> >>> >>> >>>> 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. >>>> >>>> >>> 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 >>>> >>>> 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." >>>> >>> >>> Yes - agreed. We'll adjust the text here. Thanks for pointing this out. >>> >>> Thanks! >>> Rich >>> >>> >>>> >>>> Best regards >>>> >>>> Michael >>>> >>>> >>>> >>>> > -----Original Message----- >>>> > From: [email protected] [mailto:[email protected]] On >>>> > Behalf Of Richard Alimi >>>> > Sent: Thursday, June 20, 2013 9:45 AM >>>> > To: [email protected] >>>> > 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. >>>> > >>>> > 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.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" : { >>>> > "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 >>>> > >>>> >>> >>> >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> >> >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
