Hi, just to clarify about the "list of initial (or basic) attributes": My proposal is NOT to mandate that every ALTO server or client must support all of them! My idea is that the members of this WG should compile a list of attributes, each with a well-defined semantic and at least some support (i.e., some people should say that they would like to consider this type of information in their peer selection / scheduling / whatever algorithms). This is important to determine how much flexibility in the ALTO protocol we actually need, and therefore, comments on this initial list of attributes or additions are most welcome. People implementing ALTO would be free to implement only a subset of this list, or adding their own attributes.
thanks, Sebastian -- Sebastian Kiesel mailto:[email protected] Network Research Division tel:+49-6221-4342-232 fax:+49-6221-4342-155 NEC Laboratories Europe Kurfuerstenanlage 36, 69115 Heidelberg, Germany -- NEC Europe Limited Registered in England 2832014 Registered Office NEC House, 1 Victoria Road, London W3 6BL On Wed, Feb 11, 2009 at 10:19:46AM -0800, Reinaldo Penno wrote: > 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
