I understand your concern. It seems that we have 2 options addresseing multiple atttibutes: 1, ALTO server understand the requirements of applications and return guidance for peer selection based on some combination of multiple attributes. (This option seems to introduce more complexity into ALTO service implementation.) 2, ALTO service still act as ISP information base and return attributes information to applications and let applications decide how to select better peers. (This option would increase the comlexity of ALTO messages when more and more attributes are addressed.)
Any better ideas are welcome! 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 上午10:41 主题: Re: 回??:Re: [alto] list of possible attributes (was: Re: differences among applications) 收件人: zongning 63316 <[email protected]> 抄送: Sebastian Kiesel <[email protected]>, [email protected] > 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
