I wasn't really suggesting we should have priorities, I was suggesting we should avoid them.
Your suggestion below will make the protocol quite chatty. On 2/11/09 6:26 PM, "zongning 63316" <[email protected]> wrote: > Hello, > I think the priorities across many attributes and their combinations should be > done in applications. ALTO service respond with several (ordered) lists, each > corresponding to an attribute. E.g. > <relative topological distance list> (if mandatory) > <relative operator's preference list> (if mandatory) > <achievable bandwidth list> (if indicated by queries from application) > <achievable latency list> (if indicated by queries from application) > etc... > Therefore, the complexity of handling these attributes will resides mostly on > applications and ALTO will still act as a knowledge base. > > My two cents. > > Best Regards > Ning Zong > ****************************************************************************** > ************ > This email and its attachments contain confidential information from HUAWEI, > which is intended only for the person or entity whose address is listed above. > Any use of the information contained herein in any way (including, but not > limited to, total or partial disclosure, reproduction, or dissemination) by > persons other than the intended recipient(s) is prohibited. If you receive > this e-mail in error, please notify the sender by phone or em > ail immediately and delete it! > > ****************************************************************************** > *********** > > ----- 原邮件 ----- > 发件人: Reinaldo Penno <[email protected]> > 日期: 星期四, 二月 12日, 2009 上午2:22 > 主题: Re: [alto] list of possible attributes (was: Re: differences among > applications) > 收件人: Sebastian Kiesel <[email protected]>, [email protected] > >> Hello, >> >> I mostly agree with your assessment of what an ALTO server is or >> is not. >> >> Having said that, is this list of basic attributes mandatory? Can >> we clarify >> basic vs. mandatory? I'm somewhat concerned with the complexity of >> the ALTO >> server. >> >> It would be good if an ISP could be up and running in a short >> timeframe once >> the protocol is well-defined. Having to honor many attributes will >> make the >> internal ALTO server implementation quite complex, with combinations, >> relative priorities across many attributes, etc. >> >> Thanks, >> >> Reinaldo >> >> >> >> >> On 2/11/09 5:54 AM, "Sebastian Kiesel" <[email protected]> >> wrote: >> >>> I don't like the idea of standardizing peer selection >> algorithms. Peer >>> selection must be able to consider various issues, which are not >>> restricted to topology and transport issues (e.g., fairness). >> Also, app >>> designers must be able to modify the selection algorithm on short >>> notice. Therefore, I don't believe it is reasonable or even >> feasible to >>> offload the actual peer selection from the application to an ALTO >>> server. Furthermore, an ALTO server should not formulate responses >>> based on assumptions on how the peer selection algorithm in the >> app works, >>> hoping to influence it in a desired way. >>> >>> I agree with Laird that the app should be able to tell ALTO which >>> attributes it cares about, and then ALTO gives advice while the >>> ultimate peer selection is performed in the app. >>> >>> The ALTO protocol should be extensible, i.e., it should be >> possible to >>> add new attributes later. Nevertheless, I believe it would be >> useful if >>> we could come up with a list of initial (or basic) attributes. >>> >>> >>> Here are some candidates, which have already been discussed in >> the past. >>> Any additions or comments on the usefulness are most welcome: >>> >>> - relative topological distance >>> relative means that a larger numerical value means greater >> distance,> but it is up to the ALTO service how to compute the >> values, and the >>> app will not be informed about the nature of the information. >>> One way *could* be counting AS hops, but when querying this >> parameter,> the app must not assume that the numbers actually >> are AS hops. >>> >>> >>> - absolute topological distance, using a defined metric >>> ... such as AS hops >>> >>> >>> - relative operator's preference >>> higher numerical value means that the app should prefer this >> candidate> peer over others with lower values (if no other >> reasons speak against >>> it, such as probed througput). Again, as this is a relative >> measure,> the ALTO service does not have to indicate how the >> values have been >>> computed. Examples could be: cost for peering or transit traffic, >>> traffic engineering inside the own network, and other policies. >>> >>> >>> - volume caps >>> "you can transfer up to [amount of data] until [deadline] from/to >>> this (group of) node(s). excess traffic will be >> (throtteled|charged> separately at [price unit] per [volume unit])" >>> >>> >>> - upper bound for achievable bandwidth (in replies) or >>> lower bound for required bandwidth (in queries) >>> >>> an arbitrary upper bound for the bandwith from/to the candidate. >>> this may be, but is not necessarily the provisioned access >> bandwith of >>> the candidate peer. >>> >>> The application MUST be aware that with high probability, >>> the actually achievable data transfer rate is significantly >> less, as: >>> - ALTO is not an admission control system >>> - ALTO may not know the instantaneous congestion status of >> the network >>> - ALTO may not know all link bandwidths, i.e., where the >> bottleneck> really is, and there may be shared bottlenecks >>> - ALTO may not know whether the candidate peer itself is >> overloaded> - ALTO may not know whether the candidate peer >> throttles the >>> bandwidth it devotes for the considered application >>> - ALTO may not know whether the candidate peer will throttle the >>> data it sends to us (e.g., because of tit-for-tat algorithm) >>> >>> That is, if the app really wants to know the effective >> bandwidth, it >>> has to do measurements. Nevertheless, this parameter may be >> useful for >>> excluding candidates right away. For example, if I was a FTTH >> customer> and wanted to do P2P HQ multimedia streaming, I could >> ask ALTO to >>> prune all known modem / GPRS users from a candidate list, because >>> without doing measurements it is clear that they will not be >> able to >>> exchange useful amounts of data with me. >>> >>> >>> - lower bound for achievable latency (or upper bound for >> acceptable latency) >>> Same considerations as for the previous parameter apply here, too. >>> Again, no guarantees, but only a means for quickly excluding >> hopeless> candidates even before giving them a try and doing >> measurements.> >>> >>> - provisioned access bandwidth, e.g. of cable / DSL customers >>> this has been proposed several times and questioned: >>> problems with privacy, "premium" customers with high access >> bandwidth> might attract so much traffic that their service is >> de-facto worse, ... >>> >>> >>> /* comments welcome */ >>> >>> Thanks, >>> Sebastian >>> >>> >>> >>> >>> >>> On Tue, Feb 10, 2009 at 10:00:42AM -0500, Laird Popkin wrote: >>>> Keep in mind that ALTO doesn't control the applications' peer >> assignment - it >>>> is a data source that provides guidance into the application. >> Ultimately the >>>> application uses that information, along with everything else >> that it knows, >>>> in order to determine its own optimal peer selection algorithm >> based on the >>>> specifics of the application. >>>> >>>> I would suggest that the application using ALTO should indicate >> what>> attributes that it cares about (e.g. latency, throughput, >> cost). The ALTO >>>> server can take this into account when providing guidance, if >> the ISP (or >>>> whoever is running the ALTO server) cares to do so. >>>> >>>> - Laird Popkin, CTO, Pando Networks >>>> mobile: 646/465-0570 >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
