Hi all, De : [email protected] [mailto:[email protected]] De la part de Y. Richard Yang Envoyé : jeudi 17 octobre 2013 23:06 À : RANDRIAMASY, SABINE (SABINE) Cc : IETF ALTO; [email protected]; [email protected]; Greg Bernstein; Qin Wu; Young Lee Objet : Re: ALTO Extension: Defining a Cost Metrics document?
Dear Sabine, Qin, On Thu, Oct 17, 2013 at 2:17 PM, RANDRIAMASY, SABINE (SABINE) <[email protected]<mailto:[email protected]>> wrote: Hello, This is definitely a good idea and it will be interesting to merge the metric definitions of the current drafts. Thanks a lot for the work on systematically defining a set of metrics. Please see below. I agree that it is a good idea to merge the definitions. I started the exercise, using the RFC 6390 definition template This is a good starting point indeed. We should also define "routingcost" in this metrics document. and found that there are other definition attributes that highlight the attractiveness of the ALTO Service that may be used at several layers of the network, with several levels of control and by several parties. This multi-level/layer concept is quite interesting. Can you please elaborate a bit? [ ] I was referring to the large bandwidth use case where the ALTO Service exposes a topology and paths abstractions with a granularity below the e2e level. There has been a number of metrics proposed besides 'routingcost' and 'hopcount'. One aspect that should be documented is the usage of such metrics in different environments. For instance, some drafts assume a controlled environment where metric values are closer or equal to real values where as other drafts assume a less or no access control and propose abstracted metric values to reflect preferences w.r.t. these metrics. So it could be useful to include attributes in the metric definition reflecting their degree (may be yes/no) of abstraction, Let me try to understand. The hopcount metric might say 5 hops, and then a "hopcount-detail" will give the exact 5 hops; an AScount metric might say 5 ASes, and ASPath then lists the 5 AS's, and then routePath lists the spwcifi routes, for example? Or this is too detailed? [ ] Yes, That is a possibility and up to the server to define the level of detail in terms of units that may be for instance IP hops, AS hops, some other unit or no unit that is the value of hopcount reflects the preference of the Server operator, with the optimum being MIN and the composition operator is SUM. In such a case, should'nt we introduce different metric names, such as "AShopcount", "IPhopcount", "hopcount" ? What is the opinion in the ALTO WG? I was also thinking on the "available path bandwidth" example: In a controlled environment an ALTO Server may be ready to expose the real value or a statistic, possibly say over which time period, so the metric values would look like N Gbs. In that case, the metric description may indicate that the ALTO value reflects or estimates reality. In a less controlled environment or for whatever reason, the ALTO Server just wants to express a preference w.r.t. available bandwidth and express this as a "bandwidth score", for example between 0 and N=20 or 100, indicating that the higher the value, the more available bw there is. A score will keep the real value confidential but reflects at least proportionality. In that case, the description should indicate that the value is an abstraction. Note that in both cases the description would indicate that the optimum is MAX and the composition operator is MIN. or whether their values are explicitly provided or are just used in a hidden way to filter or tie-break other metric values. Filtering-only metrics can be tricky, but of course interesting. [ ] Agree. We may leave this for the moment. Besides, most currently documented ALTO metrics relate to the transport topology where as the protocol architecture and initial extension discussions mentioned metrics relating to capabilities, of endpoints such as storage or CPU capacity. So I could be useful to document the potential providers of the different metrics and the potential users. I am not sure we may want to combine transport and storage/CPU metrics in a single documents. My first reaction is that separate documents may be a more modular design, and I can think more. [ ] These metrics refer to the CDN and Virtualized applications in Data Centers use cases mentioned in draft tools.ietf.org/html/draft-marocco-alto-next-00#page-5 submitted for IETF83 in Paris to prepare the i2aex meeting. Such metrics can be supported using the base protocol and the Basic ALTO architecture figure 1 mentions third parties and content providers, besides routing protocols etc. as possible entities to provision ALTO information. But I agree, we may first focus on metrics reporting on e2e network paths and may start defining them in a separate document. Thanks! Richard What is your opinion? Thanks Sabine De : [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] De la part de Y. Richard Yang Envoyé : lundi 14 octobre 2013 01:20 À : IETF ALTO Cc : [email protected]<mailto:[email protected]>; RANDRIAMASY, SABINE (SABINE); [email protected]<mailto:[email protected]>; Greg Bernstein; Qin Wu; Young Lee Objet : ALTO Extension: Defining a Cost Metrics document? Dear all, I am reading up on the documents that define cost metrics. The motivation is that the base ALTO protocol (http://www.ietf.org/id/draft-ietf-alto-protocol-20.txt) has defined only one Cost Metric: 'routingcost': - Defined the semantics at Sec. 6.1.1.1 of , and then listed it at Table 3. - Used "hopcount" in examples of Sec. 9.2.3 and 9.2.4, but the semantics of not formally defined. Given the aforementioned state of the base protocol, I see good value in that the WG produces a WG document that defines a relatively complete set of Cost Metrics. I particular, I read the following: - http://tools.ietf.org/html/draft-lee-alto-app-net-info-exchange-02 (Sec. 3.4 introduced three metrics: hopcount, latency, pktcost, and cost) - http://tools.ietf.org/html/draft-wu-alto-json-te-01 Defined a set of metrics: in Sec. 4. This work, as stated in the document, is motivated by - http://www.ietf.org/id/draft-ietf-ospf-te-metric-extensions-04.txt During the review of ALTO base protocol, we are suggested to document performance metrics (cost metrics) per the guideline of - RFC 6390 Guidelines for Considering New Performance Metric Development. A. Clark, B. Claise. October 2011. (Format: TXT=49930 bytes) (Also BCP0170) (Status: BEST CURRENT PRACTICE) Here a first question, I have, is whether the authors will produce a "simple" document, at the upcoming IETF, whose only purpose is to: define a set of cost metrics, including the nameing, the semantics, ... following the guideline per RFC 6390, that can benefit the base protocol. I feel that such a document is focused, and has good value by itself. The implications of the introducing multiple cost metrics can be explored in another document, which I will send in another email shortly. Thanks. Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
