You're welcome, Rich! (1) I certainly agree that there is value in allowing a provider to offer multiple network maps. I merely suggested that when provider does that, we regard each network map, and the associated cost services, as a different ALTO Server. So if a provider has several network maps, they offer one ALTO *Service* with several separate ALTO *Servers*.
Is that just semantics? Of course it is! But semantics are powerful. NOTE: Nothing says those ALTO servers have to be on different hosts. They can all use the same hostname, just with different URIs. Similarly, although our examples don't show it, an IRD can have URIs for different hostnames. That is, IRDs and ALTO Servers are orthogonal to hostnames. Here's another way to look at it: in terms of the protocol, I don't see any advantage to having one server with two network maps, versus regarding them as two separate servers. Can anyone give a use case where it helps to offer them in the same server? Yes, combining them could be marginally more efficient, because a client could retrieve one IRD vs two. But let's face reality, compared to the rest of the transmission costs, that's trivial. BTW, here's a straw-man example of why you might think you'd want to combine different network maps into the same server. Within one "ALTO Server", it's implicit that if several different cost services offer the same numeric cost metric, then those costs are comparable between services. (At least that's implicit to me!) So if an ALTO Server provides MapA and MapB, and MapA's cost service says the "routingcost" from endpoint X to Y is 42, and MapB's cost service says the cost from X to Z is 57, a client can assume that Y is better than Z. But a provider can easily accomplish the same result with two separate ALTO Servers. The provider just tells clients that ServerA and ServerB use the same algorithms to calculate costs. (2) Yes, I agree "atomicity" is too strict. As you said, we should just require that they converge. But they should converge in minutes, not hours. If convergence requires human intervention, as in my example of two separate groups in the same company, convergence could take days. - Wendy From: Richard Alimi <[email protected]> Date: Fri, July 12, 2013 02:59 To: Wendy Roome <[email protected]> Subject: Re: [alto] Clarifying Cost Map Dependencies on a Network Map Thanks for the feedback. Two quick comments: (1) I think there is value in allowing multiple network maps for an ALTO Server, all being served under the same hostname. it may be "cheap" to use a new hostname, but at that point I believe a restriction of one network map per hostname would reduce the flexibility when it comes to deployment. We have tried hard to keep the ALTO protocol flexible by just identifying resources by URIs and avoiding ties to a particular hostname. I see the fact that an "ALTO Server' is not tied to a single hostname as a feature. (2) I think we should avoid requirements on atomicity, but instead be satisfied with eventual consistency. If updates are happening so frequently that ALTO Clients are not converging (e.g., the network map is updating too frequently), then we probably need the notification protocol that has been proposed as an extension.
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
