Hi Marco and Song,
I quickly gone through the draft and have the following questions and
comments:
* What is the actual intention of the draft: Is it a problem statement,
requirement draft, or an aggregation of solutions including suggestions
for specific scenarios?
Personally, I would prefer a decent description of the problem space,
which can be used to derive suggestions for possible solutions. As far as
I understand, ALTO does not want to define a new discovery protocol - btw:
which is fine -, but rather describe the use of existing (service
discovery) mechanisms in the context of ALTO (in the sense of a Best
Current Practice).
* What is the problem of service discovery in the context of ALTO?
Some thoughts: The general service discovery problem includes:
(a) Service Advertisement/Locate Service Server: You need to find an
agent/server that is be aware of the service location. In the ALTO case,
you need to locate the ALTO Discovery Server.
(b) Service Request: You need to request the location of the service.
In the ALTO case, you contact the ALTO Discovery Server to get the
location of the ALTO Service.
(c) Topology Sensitivity: The service discovery should account for the
current location of the service client. (I'm not fully sure if this a
general issue of service discovery, at least you may need it for ALTO.)
ALTO-specific issues might be:
o Uncontrolled end user domains: In general, end user devices are not
administrated by an ISP-instance. This includes residential gateways,
which may complicate, for example, the activation of further technologies
such as multicast.
o Proxy-based service requests: A tracker, for example, initiates a
service request on behalf of an ALTO Discovery Client.
o ...
Some specific comments on dedicated sections:
Section 3: Figure 1 should be moved to section 2, because it is the
reference case for the ALTO Service Discovery including definition of
symbols, e.g., "ooo".
Section 3.1, para. 1: "ALTO servers can be deployed in an ISP-centric
deployment or on the application level by application providers [...]." -
that's confusing. In general, ALTO servers will be deployed on the
application level/layer. You should use a consistent terminology, e.g.,
ISP-centric and application-centric.
The subsequent explanations of the two deployment cases are not very
clear. A third party, for example, can provide information in both cases.
Implications for the service discovery process are not presented. ...
Probably, you want to show (a) motivations to deploy an ISP- or
application-specific ALTO service, (b) implications for the service
discovery process.
para. 3: What do you mean with "spanning different networks"?
"[...] and provide an ALTO service to numerous application clients." -
this holds for ISP-specific ALTO services, as well.
Figure 3 does not show application-specific ALTO-servers. You need a
second ALTO server for application B.
Section 3.2: The title seems misleading. Instead of "Cross-domain vs.
Localized ALTO Server Discovery", I would suggest something like
"Inter-domain vs. Intra-domain ALTO Server Discovery".
1. para: "For cross domain scenarios [...]" - these scenarios have not
been introduced.
"For cross domain scenarios, the ALTO service includes the ALTO servers
provided by p2p application community as well as the ALTO servers provided
by a third party [...]" - the categories are confusing. These are two
different issues, or not?:
(1) ALTO servers distributed over several domains vs. local servers
(2) ALTO servers provided by ISPs vs. P2P community.
3. para.: "Each network operator may have its own traffic optimization
policy based on his network topology [...]" - the optimization policy is
probably not only based on the network topology.
"Each of the ALTO servers may have a FQDN." - why is this assumption
specific to cross-domain scenarios?
4. para.: "The ALTO client (e.g. the Tracker) must be able to discover
and choose the ALTO server that has the information that is specific to
those clients located within that network." - this seems like an
intermingled requirement:
(1) The ALTO Discovery Client must be able to discover an ALTO Server
with respect to a specific scope, i.e., intra-domain or inter-domain wide.
(2) The ALTO Client must be able to choose among several ALTO servers.
?? I'm not sure if this should be performed by the ALTO Client and not bt
the ALTO Discovery Client.
Section 4.1: "Discovery Metrics" - the title is misleading. Subsequent
subsections do not define any metrics.
Section 4.1.1, 2. para.: "In a hybrid model [...]" - what do you mean
with "hybrid"? A combination of P2P and client-server technology?
Section 4.1.2, 1. para.: "The ALTO service could be provided in a
distributed and cooperative fashion by the Peers in an overlay, or it can
be provided by a centralized entity (the ALTO Server) for a given scope.
[...]" - I'm not really sure what you are talking about, and the
consequences for the discovery process. Both cases differ in the way how
ALTO data is acquired and/or stored. But this is out of scope, right? In
both cases, you need an entity that answer ALTO Queries. And you need to
find the entity providing this service.
3. para: The perspective is a bit confusing: In this paragraph, you
discuss discovery mechanisms and judge their applicability to the location
of the ALTO server ... It is more helpful to state the different locations
of the ALTO server and the corresponding requirements for the discovery
service.
"Multicast discovery generally works within a single LAN only [...]" -
sure? Multicast exhibits an inter-domain deployment problem, but there are
deployments within dedicated ISP-domains.
Section 4.2, 1. para.: "[...] one is the ALTO server providing service
to the overall network, and the other is where the ALTO server is
providing service to the local network." - what do you mean with "overall
network" and "local network"?
Section 4.2.1, 1. para.: Why is the statement in this paragraph specific
to local ALTO services?
2. para.: "[...] or through its application tracker." - this conflicts
with your statement in para. 1: "In p2p applications without a tracker
[...]".
Section 4.2.2, 2. para.: The concrete example for a discovery mechanism
is not very helpful at this point.
Section 5, 2. para.: The categories of the enumeration seem not correct.
"Well known port" - that's the general problem to find the service
address. It's not specific to ports.
"IP address change" - you address the problem of caching?
"Mobile Scenarios" - this discussion should be moved to section 4.
I do not want to comment the different solutions ... But I have one
comment regarding the multicast approaches:
* You discuss that there is no wide multicast support at residential
gateways. That's probably not true - otherwise multicast related IPTV
services offered by several ISPs would not work. The RGs probably do not
support multicast routing, but this is not required. I would suspect that
several RGs support some kind of IGMP/MLD proxying (RFC4605).
* You should add anycast-based service discovery. It does not introduce
specific requirements at RGs. It's suitable for ISP-centric discovery.
* Why do you not mention RFC2608?
Thanks
matthias
--
Matthias Waehlisch
. FU Berlin, Inst. fuer Informatik, AG CST
. Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email protected] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
