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? 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
