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
--
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
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
