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. > > > 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? > > 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, ..." -yry > S. > _______________________________________________ > alto mailing list > [email protected] <javascript:;> > https://www.ietf.org/mailman/listinfo/alto >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
