Hi Rich, On Mon, Jul 02, 2012 at 11:09:51AM -0700, Richard Alimi wrote: > 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. I would exactly say this. Or maybe, to be more precise: A resource consumer chooses - or asks a third party to choose on behalf of it - one or several resource providers from a set of candidate resource providers (and ALTO is consulted in order to improve that decision). However, it it is important that resource is not neccessarily a file or content stream. Therefore, the above sentence does not imply that most of the data flows from the resource provider(s) to the resource consumer! Because we might have independent control and data connections it would also be too simplistic to say the resource consumer is the "connection/flow initiator", though most of the time this is true. > It's conceivable that the resource > provider could be doing the choosing in a push-based protocol. If we have a push-based protocol, where one could send some kind of information to one of several "sinks", I'd say that the (ALTO-/RFC5693-)resources are these sinks, and the "pusher" is the resource consumer, which consumes the sink-resource. > 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. ack. > It's an application-level concern about who does the > choosing, and making sure they are using the costs appropriately. Each application uses its own terminology and has specific ideas on who assumes the roles of "client", "server", "peer", ... My understanding of the ALTO terminology is that we can use it to describe the (ALTO-relevant) features of an arbitrary protocol in a uniform way. And in particular, I would describe the general ALTO problem as: We have 1 resource consumer and N candidate resource providers. We want to have data flows between the resource consumer and M < N resource providers. Therefore, we need to choose M out of N, and ALTO is supposed to help on that decision. > 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." Is it always the address of exactly one host (either r.prov. or r.cons.)? Otherwise, the already defined term "host group descriptor" might make sense? > 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." change "a typical application concerned with bulk data transfer" to "a typical application concerned with bulk data retrieval", then we have one of the most important use cases as an example - though the example does not reflect the full complexity of that issue ... S. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
