Subject: [alto] ALTO Server Discovery

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 30 Jul 2009 16:39:17 +0200

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-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net