On Wednesday, July 17, 2013, Ben Niven-Jenkins wrote: > > On 17 Jul 2013, at 20:14, Wendy Roome wrote: > > > I agree that requiring a server to return arbitrary old versions of a > > network map is way too much. As Ben said, if the tag in the latest cost > > map doesn't match the tag in the network map you've cached, use the id to > > find the resource for the full map and fetch it again. If the new tag > > doesn't match, back off and try again. And if it still doesn't match, > file > > a trouble report. > > > > Although that does raise an issue. Suppose you had v0 of the network map, > > and you get a cost map based on v1. You re-get the network map, and that > > returns v2. Eg, they updated the network map again. In this case you > > should reget the costmap until that returns one based on v2. > >
> > That implies it would be helpful if tags were ordered, so a client could > > tell which one was "newer". Anyone care to take on that can of worms?? > > No. > > > Or > > should we just resolve it with the pragmatic observation that servers > > won't change network maps very often? > > I don;t think we need to worry. It's up to the client (based on > configured/built-in policy) how to handle that situation, maybe the client > caches old versions until it gets some matching pair (as it considers > possibly old information to be more useful than no information) and assumes > the next matching pair will be later than the current pair it is using. > > I think it is fair for a client to assume that repeated requests return > the current or later versions of the map. Anything else is outside of the > protocol IMO and the desired behaviour will depend on the specific > deployment/use case. Agree that we do not need to worry about the case and rely on eventual convergence, for now, considering our use cases. The dependency between cost map and network map is a simple case of the more general specification dependency problem. If/when define more general topology services in ALTO, other consistency such as snapshot consistency (e.g., supported by allowing retrieval of snapshots) can be helpful, in particular at modular information representation (divide into network and cost maps), large scale, more dynamic environments. But it may be better started some real, specific cases. Richard > > Ben > > > > > - Wendy Roome > > > > > > > > On 07/17/2013 14:52, "Ben Niven-Jenkins" > > <[email protected]<javascript:;>> > wrote: > > > >> Richard, Colleagues, > >> > >> On 16 Jul 2013, at 17:35, Y. Richard Yang wrote: > >>> - Q3: What is the meaning of "uses"? > >>> > >>> A: Currently, "uses" only lists the "id", which is only the "class" > >>> name, not including the instance/version. Hence, we may encounter > >>> consistency problem, for example, the cost map object retrieved may be > >>> based on one instance of the "uses" id but the current instance version > >>> of "id" is no longer the version. This case is already raised by you > and > >>> Rich. I am not surprised by Rich's answer of using eventual > consistency, > >>> because I believe that this is Google's software package management > >>> design, but I also heard that Amazon uses snapshot based design, which > >>> works as well. In other words, one approach is that we extend the API > to > >>> return a given version (vtag) of an id, and the uri announced is the > >>> base uri that one can retrieve different versions. For the example in > >>> [5]: > >>> > >>> { > >>> "uri" : "http://alto.example.com/networkmap";, > >>> "media-type" : "application/alto-networkmap+json", > >>> "id" : "default-networkmap" > >>> }, > >>> > >>> It means that one can fetch > >>> http://alto.example.com/networkmap/<tag> > >>> > >>> to obtain a given tag of "default-networkmap", if the server still has > >>> it. > >> > >> Why do we need all this complexity? The assumption is the clients are > >> only interested in the latest version of the map, right? (i.e. there are > >> no requirements for ALTO server to store/serve historical versions of > >> maps) > >> > >> You GET the network map then GET the cost map. If their vtags don't > agree > >> you repeat until they do. Apart from fundamental deployment > >> errors/failures the cases where the map versions do not agree are likely > >> to be (relatively) infrequent and transitory. > >> > >> None of this is any different to before we started discussing "ids" so > if > >> it wasn't a problem then, why is it a problem we need to solve now? > >> > >> Ben > >> > > > > > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
