Hi Sebastian, Rich, Richard
Y. Richard Yang a écrit :
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?
This reads clear. An ALTO Endpoint covers both Consumer and Provider.
Resources pushers and sinks are implicitely mapped onto source and
destination in the ALTO Cost Maps, that thus also support asymetrical
traffic cases.
Would this point fit in the Endpoint definition section planned before
current Section 2.1.1 Endpoint address ?
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?
I agree with this question as Section 2.1.3 Network Location says:
"denoting a single endpoint or
group of endpoints". Section 5 may address this question this with some
additonal text.
Section 5 currently says:
"An ALTO Cost Map defines Path Costs pairwise amongst sets of source
and destination Network Locations. Each Path Cost is the end-to-end
cost from the source to the destination."
How about adding a sentence like:
"The Path Cost between Network Locations grouping several Endpoints
(opt: and represented by their PID) is provided by The ALTO Cost Map
Service. The ALTO protocol additonally MAY provide Path Costs between
individual Endpoints (opt: represented by their address) via the ALTO
Endpoint Cost Service."
> 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, ..."
yes, and again say that the application must be aware that the roles
that they have set are to be mapped with the roles of source and
destination implicitely encoded in the ALTO Cost Maps.
Re-adding a comment from Sebastian yesterday, I have the following :
Sebastian: "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."
It may be interesting to consider other cases such as media relays. Wouldn't it be worth adding such a use case to be discussed in either the ALTO or i2aex WG? Do you have one in mind?
Sabine
-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
