On Mon, Jul 2, 2012 at 8:43 AM, Sebastian Kiesel <[email protected]> wrote: > Sabine, Rich, > > >> >> This document seems geared towards P2P applications, although the >> >> abstract mentions CDN and "those that have a choice in connection >> >> endpoints". In some places, see detailed comments, "peer" should be >> >> replaced by "endpoints" when referring to a content location. In >> >> Section 8 Use Cases, some text should be added to recall this. >> > >> > Yes - that sounds reasonable. We'll do a search for the word 'peer' >> > to see if a better term can be used, and also add a reminder in the >> > use cases that P2P is not the only deployment setting. > > In RFC 5693 we have defined the term "resource provider" (and many more, > maybe we should check the protocol draft again for correct usage of the > ALTO terminology?).
For the specific point about use of the word "peer", when looking through the -11 version, the primary use is in section 8 where we are explicitly talking about p2p use cases. That use seems fine to me. There are a couple of places where 'peer' may be somewhat limiting (e.g., section 11.2) and should be changed. We can certainly do an inventory on terminology to see if anything else from RFC5693 should be applied. I'm pretty sure it won't just be substituting "endpoints" with either "resource consumer" or "resource provider" though, since that depends quite a bit on how the application uses ALTO information, and what the costs actually represent. That is, we can't simply say that that a resource consumer is choosing a resource provider. It's conceivable that the resource provider could be doing the choosing in a push-based protocol. As a slightly more interesting example, what if I also wanted to try and reduce latency for ACKs in the opposite direction to protect myself against asymmetric routing - then then I'd be querying a latency map for the cost from the resource consumer to the resource provider. In the ALTO Protocol we try to simply express these as costs between endpoints. It's an application-level concern about who does the choosing, and making sure they are using the costs appropriately. All that said, I think we do need to improve the protocol draft to explicitly say how "endpoint" relates to "resource consumer" and "resource provider" which is mentioned in other documents. How about the following: Add this to Section 2.1.1: "An Endpoint Address is typically either the address of a Resource Provider or Resource Consumer." Add change this text in Section 5: "Each Path Cost is the end-to-end cost from the source to the destination." to instead read: "Each Path Cost is the end-to-end cost from the source to the destination. For example, if the cost is expected correlated with throughput, a typical application concerned with bulk data transfer may use the Resource Provider as the source, and Resource Consumer as the destination." > > Btw. "Content Location" would IMO not be general enough, as we could use > ALTO also, e.g., to find a "good" media relay for VoIP NAT traversal. Agree. > > > Thanks > Sebastian _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
