Hi Matthias, Good comments. See inline. >-----Original Message----- >From: [email protected] [mailto:[email protected]] On >Behalf Of Matthias Waehlisch >Sent: Thursday, July 30, 2009 10:39 PM >To: alto >Subject: [alto] ALTO Server Discovery > >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? >
It is intended to describe using exsiting mechanisms for ALTO discovery. However, you may need different mechanism in different scenarios. OTOH, the ALTO discovery may partly depend on the framework of ALTO protocol, but we don't have a working group item for ALTO protocol now. That's why we don't go to deep details of each possible discovery mechanism at present. > Personally, I would prefer a decent description of the >problem space, which can be used to derive suggestions for >possible solutions. We describe ALTO service deployment and ALTO discovery scenarios for that purpose in section 3 and section 4. > 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). We don't want to invent a new unnecessary discovery protocol here. > > * 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.) > I agree. For (a)/(b), the question is who will be the ALTO Discovery Server. It may be the DHCP server, DNS server... For (c), yes, that's why caching an ALTO server address previously used may not work properly sometimes. > 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. > Agree. We already gave some thoughts to RGs when using DHCP option for getting the access domain name. It's true that some mechanism has its limitations and the final mechanism will depend on the scenario. > o Proxy-based service requests: A tracker, for example, >initiates a service request on behalf of an ALTO Discovery Client. > That's a typical case. There are two ways for ALTO discovery in this case, the tracker discovers ALTO server for the requesting client, or the client discovers its own ALTO server and sends to the app tracker. > 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. >... > A third party, for example, can provide >information in both cases. It's true. >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. > Thanks, we will do that in the next version. > para. 3: What do you mean with "spanning different networks"? > It actually means the service is provided from the ALTO server to 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. > Figure 3 means that some application community such as some distributed coordiante system could provide the ALTO service to other clients, whatever the specific application that client belongs to. > > 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". > Good suggestion. > 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. > Only the ALTO server that is provided by the p2p community or a third party could serve multiple networks. The ALTO server provided by the ISP can not serve the clients in another ISP's network because they have different policy and different views. What we discussed here in the draft is the former case. > 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. > You are right. > "Each of the ALTO servers may have a FQDN." - why is this assumption >specific to cross-domain scenarios? > We also have this assumption for intra-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. > I'm not sure if the ALTO discovery client has to choose... Personally I don't think so. > > 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? > It simply means the ALTO servers are discovered by the p2p application clients separately, and then sent to the app tracker. > 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. > That's true. Here we want to give an introduction of these cases and then say the discovery process may be different to them. > 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. > Thanks for your input. It's a general discussion here. > 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"? > To the internet or to a single domain. > Section 4.2.1, 1. para.: Why is the statement in this >paragraph specific >to local ALTO services? > We may need to add another section for inter-domain ALTO service. > 2. para.: "[...] or through its application tracker." - this >conflicts >with your statement in para. 1: "In p2p applications without a tracker >[...]". > There is no conflict because "p2p applications without a tracker" is not the premise of all the text in section 4.2.1. > 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? > Here it means the IP address of an ALTO server may change. It does not mean you switch from one ALTO server to another. We have considerations for caching problem in the document. It is an implementation issue to solve it (maybe in many ways). > "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. > Thanks, we will consider it in the next revision. > * Why do you not mention RFC2608? > Sorry for missing that. > Thanks, Haibin _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
