Dear all,
Plese find below some comments about the current draft and some thoughts :
* First, I think there are many interesting things in this draft, which could
help, and it's good
* I think it's also good to go for a simpler interface and re-using existing
protocols or solutions (e.g. reusing HTTP with specific header is good) and not
creating another new one protocol
* My main concern (as previously and as many other people think) is the way to
prefer the "map service" approach or the "ranking service" approach. In the
current version of the draft, I've seen the map service is mandatory but others
are optional. I don't think it's a good option for several reasons:
* We are aware that ALTO will be deployed in real-life only if
providers and ISP come to an agreement (eventually sign a contract, monetize...
). Therefore I think it will limit the scope of ALTO for P2P applications since
I'm not sure many ISP will agree to "favor" come contents (mainly illegal
contents in coutries where laws are created to mitigate illegal content). The
impact in the network reduction could then be more limited as expected.
* With relation with previous point, I think the draft (and more
globally discussions) are very "P2P-coloured". I mean we always have P2P
applications in mind but others could benefit of such interface. We should not
restrict our solution to P2P networks. One use-case that could used ALTO and
that could have the agreement of ISPs are CDN networks. Using ALTO in order to
select the optimal (or better) surrogate server for delivering the content
could be something ISP would like. For this case, having the whole map of the
ISP network (or if not the whole, even a coarse-grained view of the network) is
not really useful, since the end-user client will be connected to only one
surrogate (or perhaps 2 or 3 in the future; but it will be limited in numbers).
Then for the CDN use-case, I don't think the "map service" option is the best
one. The "ranking service" will be better and just returning back the address
of 1 or 2 surrogate servers when requesting by the client. I think there are
others types of applications, which deal with more legal contents than P2P,
that could benefit from ALTO, and that ISP could like to deploy jointly with
ALTO.
* Having the "map service" as mandatory could lead to a strange
situation. For example, if the ISP does not want to disclose about its
topology, it will ask the apps providers to use the ranking service. Let's
suppose they agree. Since the "map service" is mandatory, the providers as well
as the ISP will have to use it and to provide information (which could be very
useless like "My network and the rest of the world", or even simply only one
PID which is the world) and then use the "ranking service". The use of the
mandatory map service then leads to get useless information with a
request/response message (which will not bring any value), will spend some time
for this message and will load the network with useless information. If the 2
actors have started directly with the ranking service, it would have been
better.
* Again, having the "map service" function as the only one function
implemented is not good if the ISP wants to include more dynamic metrics in its
topology (e.g. delay, available bandwidth, latency... as introduced in section
7.3.1.2). We can imagine ISPs that deploy probes in their networks to always
have up-to-date status of their network conditions, and update the network
topology accordingly. Then if a peer requests preferences from the ISPs, having
a network map, fetched some times before, could not reflect the current
conditions of the network. And requesting frequently the ALTO server to get an
updated view, could lead to many signalling messages in the network and finally
load the network more than initially planned (and then contrary to the initial
goal of ALTO).
* For the same reason, I don't think the re-distribution of network
information directly between peers (section 6.1.2) is a good solution, since
out-of-date information could be transmitted and finally a new peer, getting
the topology from others peers (which had this information for some times ago)
could use it and could be negative for the ISP at the time the peer uses it (in
case entwork conditions had changed since that time). Then I'm not in favour
of this redistribution mechanism.
* For those reasons, I think we should let the final decision of the
option to use to ISP and providers when they will define their contract, their
agreement and not put some mandatory service and others optional. All should be
optionnal. Maybe a solution to cope with that is to define "sub-drafts" (sorry
I don't know if can can say this word :-) and specifying different options to
use (e.g. RFC-xxx-1 with map service, RFC-xxx-2 with ranking serice"...) and
actors will select the one they agree to use (maybe could be several in they
agree on it).
Best Regards,
Bertrand Mathieu
-----Message d'origine-----
De : [email protected] [mailto:[email protected]] De la part de Enrico
Marocco
Envoyé : lundi 16 novembre 2009 10:25
À : [email protected]
Objet : [alto] Adopting draft-penno-alto-protocol as WG item
During the meeting in Hiroshima the group showed consensus for adopting
draft-penno-alto-protocol as the base draft for the request/response protocol
deliverable in the WG charter.
People who haven't had a chance to express their opinion, please do that on
this list by the end of this week.
--
Ciao,
Enrico
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
