On Fri, Jul 12, 2013 at 7:02 AM, Wendy Roome <[email protected]>wrote:
> 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. > Having two separate servers would require two separate entry-points into the alto server discovery. Then the client has to pick a server at discovery time. This implies that ALTO server discovery has to find multiple servers for a client, which I'm not sure it is prepared to handle (and it was hard enough as it was). > > (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. > Absolutely. > > - 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
