Hi Qin, Please find some comments inline <MSC/>.
From: Qin Wu [mailto:[email protected]] Sent: Saturday, February 15, 2014 4:57 AM To: Scharf, Michael (Michael) Cc: IETF ALTO Subject: RE: Review of draft-ietf-alto-deployments-08#appendix-A Hi, Michael: Thanks for re-work and updating to monitoring section. I have a few comments to section 3.4 you updated. 1. The monitoring infrastructure can be third party,Or can be integrated into ALTO server? If it is the third party based, I think the trust relationship between monitoring system and alto server needs to be established, otherwise, security concern may be raised. <MSC> I think the most realistic case it that it is neither third party, nor an integrated function of the ALTO server. Instead, a network service provider would probably monitor the benefits of its ALTO service by a monitoring infrastructure, which could be an extension of the general network monitoring / OAM. It could be possible that third parties (e.g., academic researchers) want to monitor the benefits as well; in that case, there is indeed a question whether they would have access to network service provider data beyond what the ALTO service provider exposes. However, since the IETF does not mandate how to implement an ALTO server, an implementer could obviously also come up with a huge all-in-one ALTO server implementation that realizes many other functions beyond providing the ALTO service itself. I could add a sentence like "Monitoring the benefits of an ALTO service could also be realized by third parties. In this case, insight into ALTO data may require a trust relationship between the monitoring system operator and the network service provider offering an ALTO service." Would this address your comment? </MSC> 2. Section 4.3 says: " An NSP offering ALTO could consider the impact on (or integration with) traffic engineering and the deployment of a monitoring service to observe the effects of ALTO operations. " Traffic engineering is related to monitoring ALTO performance? I think you may gather traffic engineering information from routing protocol, these traffic engineering information can be used to reflect network performance and provide fine granularity of cost map or network map? However it has nothing to do with performance of ALTO? Performance of ALTO is more about how many request or response can be handled, <MSC> This sentence is taken from Section 16.1.4 of the ALTO protocol spec (http://tools.ietf.org/html/draft-ietf-alto-protocol-25#page-81). Actually, the whole scope of Section 3.4 in draft-ietf-alto-deployment is explained in Section 16.1.4 of the ALTO protocol spec. Given that explanation there, I am not sure if I understand your question and/or concern. Specifically, the whole section 3.4 of draft-ietf-alto-deployment deals NOT with how to retrieve routing protocol information (including e.g. TE information from IGP) and how to put it into network and cost maps. This is discussed in Section 3.2.1. Let me try to explain how I understand draft-ietf-alto-protocol-25: This sentence deals with understanding what impact the ALTO guidance has on applications, and whether the ALTO service operation is efficient and effectively improving "better-than-random" resource selections by applications. I understand here "traffic engineering" in a very general way. For instance, an NSP offering an ALTO service for P2P applications would typically expect that the amount of aggregated inter-domain traffic is reduced. If ALTO is effective, the NSP can probably slow down upgrades of Internet-peering-point capacities; this is traffic engineering, but that kind of information may not be carried in, or retrieved from routing protocols, and it may not be used to calculate ALTO maps. If traffic is kept local in access network domains, the capacity planning and traffic engineering of core network links can be adapted, because they may have less utilization, e.g., bandwidth allocations of core links could be adapt. This can be part of the typical mid-/long-term capacity planning processes of a network service provider. Furthermore, please note the ALTO protocol spec has another section (Section 16.2.5. Performance Management) that describes examples for system metrics characterizing the performance of an ALTO server (e.g., number of requests, CPU/memory utilization, etc.). If you struggle with the term "ALTO performance" in the headline, we could perhaps better align the section headlines to draft-ietf-alto-protocol-25, i.e.: OLD: 3.4. Monitoring the Performance of ALTO 3.4.1. Supervising the Benefits of ALTO 3.4.2. How to Monitor ALTO Performance NEW: 3.4. Monitoring the Impact of ALTO 3.4.1. Supervising the Benefits of ALTO 3.4.2. How to Observe the Impact of ALTO Would this address your question? </MSC> 3. Section 3.4.2 says: " Total amount and distribution of traffic: ALTO enables ISPs to influence and localize traffic of applications that use the ALTO service. An ISP may therefore be interested in analyzing the impact on the traffic, i.e., whether network traffic patterns are shifted. For instance, if ALTO shall be used to reduce the inter- domain P2P traffic, it makes sense to evaluate the total amount of inter-domain traffic of an ISP. " How traffic distribution is related to ALTO performance monitoring, I can not understand this. <MSC> Again, please refer to Section 16.1.4 in draft-ietf-alto-protocol-25. That document states "Deployment of an ALTO Server may shift network traffic patterns.". This paragraph just explains examples how one can monitor whether ALTO achieves the shift of traffic distribution that an NSP wants to achieve by ALTO. </MSS> 4. Section 3.4.2 says: " Application performance: The objective of ALTO is improve application performance. ALTO can be used by very different types applications, with different communication characteristics and requirements. For instance, if ALTO guidance achieves traffic localization, one would expect that applications achieve a higher throughput and/or smaller delays to retrieve data. Application- specific performance characteristics (e.g., video or audio quality) can be useful as well. In addition, selected statistics from the TCP/IP stack in hosts can be useful, e.g., the number of retransmitted TCP segments. " It is not clear to me whether you measure traffic performance or ALTO performance? I think application performance you described here has nothing to do with ALTO performance. Only ALTO system performance is related to ALTO performance. I feel you mix traffic performance With ALTO performance. What am I missing? <MSC> The draft explains the categories "total amount and distribution of traffic", "application performance", and "ALTO system performance", and they all refer to different aspects. For the headline, I was looking for a short term that encompasses all different aspects, and I came up with "ALTO performance" (obviously, this is not the ALTO system performance). If you expand it as "application-layer topology optimization performance", in my understanding "ALTO performance" refers to how efficient and effective the application topologies are optimized by deploying an ALTO service. However, as already mentioned, if the term "ALTO performance" should be confusing, I could use the term "impact of ALTO" instead of "ALTO performance", i.e., rename the section to "3.4.2. How to Observe the Impact of ALTO". In that case, it should be clear that it deals with much more than ALTO system performance, "traffic performance", etc. Would this solve your question? </MSC> Thanks Michael _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
