De : [email protected] [mailto:[email protected]] De la part de Richard Alimi Envoyé : jeudi 21 mars 2013 08:47 À : Scharf, Michael (Michael) Cc : ROOME, Wendy D (Wendy); [email protected] Objet : Re: [alto] minor inconsistency in draft 14
On Tue, Mar 19, 2013 at 2:10 PM, Scharf, Michael (Michael) <[email protected]<mailto:[email protected]>> wrote: > My understanding of the decision that an ALTO Server must > provide "routingcost" is also related with the design of > allowing default. For example, CostMapCapability can be empty > and implies "routingcost". One analogy one might or may not > like is that TLS (RFC5246) defines that > TLS_RSA_WITH_AES_128_CBC_SHA is mandatory. But we can imagine > that there is no mandatory and hence allows TLS negotiation > to fail. But I agree with you that removing the so far MUST > supported cost type and endpoint property will not impact > interop in the sense that the protocol still works, and a > conforming ALTO Server may just not returning any > information. What do you and others think? Another option would be to replace the term "routingcost" by something that does not specifically refer to a way how to determine that cost. For instance, "defaultcost"? But I don't have a strong preference here. I slightly prefer 'routingcost' because what we're actually conveying is the cost from the provider's point of view for routing traffic from a source to a destination. Of course, we've intentionally left the actual metric only loosely specified. 'defaultcost' (to me, anyways) seems to convey something like "I'm going to tell you the cost is X because I don't know any better". [ ] Hi, [ ] Although the Cost (Map or Endpoint) is not a MUST, whenever cost values are provided, having at least one common cost type would allow reliable information retrieval from multiple ALTO Servers as well as better inter ALTO Server communication. The 'routingcost' is a simple and generic way to tell "this way or endpoint for application traffic is better" or has this cost, with cost having a commonly understood meaning. Even with heterogeneous value ranges or accuracy levels throughout ALTO Servers or restriction to ordinal in some of them, knowing that the cost is generic and quantizes preference allows every ALTO Client to understand the values. And this in turn allows each Client to define its composition rules in order to infer its needed information. In other words, I understand that a client should be able to live with what it gets and use consistent and intelligent rules to efficiently use it. On the other hand it would hugely benefit from the possibility of using information that may be gathered from several servers to optimize applications running across several (ALTO) domains, thus covered by different ALTO servers, such as content delivery or virtualized applications, involving data centers distributed in multiple ALTO domains. Another case is when a client would like to aggregate ALTO information provided at different levels of details by cascaded ALTO Servers. Sabine Michael _______________________________________________ alto mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
