On Tue, Jul 3, 2012 at 12:15 AM, Y. Richard Yang <[email protected]> wrote: > Hi Sebastian, Rich, > > On Tuesday, July 3, 2012, Sebastian Kiesel wrote: > For example, the resource consumer may not ask, as >> >> 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). > > > Using your good reasoning below, even the preceding sentence may have > subtlety: "ask" may imply some messages, but the app may not have a > message. How about remove "ask"? > > >> >> 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.
I agree that this is a good way to state the common use case. >> >> > 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." > > > Suppose we want to simplify the definition by removing "address" from the > the above. > Then we have "An Endpoint is typically either a Resource Provider or > Resource > Consumer." How does this read? What is an atypical case? Removing address sounds good to me. One of the suggestions elsewhere on the list was to add 'Endpoint' as a term, so I put this text in that new section. >> 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 ... >> > Agree on the subtlety. Instead of an example in the definition, how about a > short discussion paragraph starting as "Each application has its > interpretation > on who assumes the role of ... and hence how to utilize Path Cost provided > by ALTO. For example, ..." Thank you Sebastian and Richard for the suggestions. How about the following paragraph added to Section 5 just after paragraph 2: Each application may independently determine how the Resource Consumer and Resource Provider are designated as the source or destination, and hence how to utilize the Path Cost provided by ALTO. For example, if the cost is expected to be correlated with throughput, a typical application concerned with bulk data retrieval may use the Resource Provider as the source, and Resource Consumer as the destination. Thanks, Rich > > -yry > >> >> S. >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
