Subject: Re: [alto] 回复 :Re: list of possible attributes (was: Re: differences among applications)

From: Reinaldo Penno <[email-masked]>
Date: Wed, 11 Feb 2009 18:39:31 -0800

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-masked]> 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-masked]>
> 日期: 星期四, 二月 12日, 2009 上午2:22
> 主题: Re: [alto] list of possible attributes (was: Re: differences among
> applications)
> 收件人: Sebastian Kiesel <[email-masked]>, [email-masked]
> 
>> 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-masked]>
>> 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-masked]
>> https://www.ietf.org/mailman/listinfo/alto
>>