Richard, Here are my answers to your questions:
#1: Draft 27, section 11.2.3.6, defines a cost map as a map from (src,dest) to JSONValues, not just numbers. I believe that was added at some point to allow for multi-cost arrays and string-valued costs. The document does go on to say: > An implementation of the protocol in this document > > SHOULD assume that the cost is a JSONNumber and fail to parse if it > > is not, unless the implementation is using an extension to this > > document that indicates when and how costs of other data types are > > signaled. > > Incremental update is indeed an extension, so allowing nulls does not violate the base protocol. #2: Here's my assessment of how well that approach -- "use full-map message to present the deltas" -- would work for incremental update for other full-map services: Network Map: The incremental-update message would give new pattern arrays for all PIDs that changed. This works, but is inefficient if PIDs have 100's of CIDRs, and only a few change. Cost Map with Multi-Cost Extension: If any cost in the set changes for a src/dest pair, the incremental update message would give the full array for that pair. This works, although it may be inefficient when only one cost in the set changes. PID Property Map Extension: The incremental update message would give the new value for any pid/property pair that changed, or null for any property that was deleted. This works just as well as for cost maps. - Wendy Roome > > From: "Y. Richard Yang" <y...@cs.yale.edu> Date: Thu, July 31, 2014 at 15:34 > Turns out that our JSON cost-map representation is also perfect > representation of an incremental update. Just change the semantics > slightly: > > * Start with the previous cost matrix, rather than an empty matrix. > * For a null-valued cost point, remove that point from the previous > version, if it existed. > * For a non-null cost point, add it to the matrix, either replacing the > previous value or creating a new one. Two comments: 1. A small technical question: what is the JSON type for each element of the cost matrix? It is a JSON number before. Now it is JSON number \union null? The more general, intended question is whether it will be beneficial to introduce a generic data type to denote operations. 2. A more general question is: how widely applicable is your design (i.e., using the original data type plus some small annotation to convey updates? Or more interestingly, where the design does not work (well)? > So for cost maps, efficient custom patch messages are "free². Or at least > "no additional work." :-) > > For network maps, the case isn't as clear. The data structure that best > captures the semantics of a network map is a lookup table from CIDRs to > PID names. Alternatively, a network map is a lookup table from PID names > to sets of CIDRs, with the additional assertion that a CIDR is in only one > set. Our JSON representation is a lookup table from PID names to arrays of > CIDRs. > > Our JSON network map message does not do a good job of representing > network map deltas such as "move 1.0.0.0/16 <http://1.0.0.0/16> from PID1 to > PID2". > > On the other hand, JSON patch doesn't do a good job of representing > network map changes either, if only because we use an array to represent a > set, so JSON patch thinks the order matters. > > On top of that, I claim that incremental update simply isn't that > important for network maps. A fundamental assumption behind the design of > ALTO is that network maps will not change very often. When a network map > changes, it completely invalidates all previously retrieved cost maps. Any > change to a network map, no matter how simple, is a flag day. > > So how about this compromise: for cost maps, define incremental update > using our existing cost map message format. If the JSON group asks why > don't we use JSON patch, just say that our message format perfectly > captures the semantics of all legal cost map changes, and ALTO clients and > servers already support it, so we don't need any additional patch > mechanism. > This compromise looks reasonable to me. To proceed, it will be great if the overall update framework is laid out (e.g., indicate the default as well as the patch mechanism(s) for each data type), so that we can claim that ALTO has a complete patch mechanism? > For network maps, do not define incremental update at this time. Wait > until some ALTO servers actually implement incremental cost map update -- > and clients use it! -- and then see if there is any demand for incremental > update for network maps. > See above. Richard
_______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
