Hi Qin, Sabine, On Oct 31, 2013 5:48 AM, "Qin Wu" <[email protected]> wrote: > > Hi, Richard, Sabine: > > I think it is a very good idea to discuss schedule of TE metric as open issue to draft-wu-alto-te-metrics in ALTO session.
Given potential extended discussions needed, I am not optimistic that your 5-min slot can accommodate a discussion on introducing schedule. I liked the idea of schedule as I see clear use cases. Google Map goes back and forth with its predicted traffic mode. See this thread http://0-productforums.google.com.library.ccbcmd.edu/forum/m/#!topic/maps/iVaKdxUhuMw We will need some time to discuss this useful, but relatively complex design point. Is there a way to schedule more time for discussions? Richard > Please see my reply inline below. > > > > Regards! > > -Qin > > > > From: RANDRIAMASY, SABINE (SABINE) [mailto: [email protected]] > Sent: Thursday, October 31, 2013 7:57 AM > To: Y. Richard Yang > > Cc: Qin Wu; He, Peng; IETF ALTO > Subject: RE: [alto] I-D Action: draft-wu-alto-te-metrics-00.txt > > > > Hi Richard, > > > > The ALTO Cost Schedule was not discussed in the draft because, rather than as a Cost Metric, it is proposed as a Cost Mode applicable to metrics that have values changing in a predictable way. > > > > Definitely, except nominal capacity, TE metrics do have changing values, sometimes in a predicable way so that their ALTO abstraction can be exposed in the schedule mode. > > > > [Qin]: I agree TE metrics change over time, reporting TE metrics in a schedule mode is very interesting idea. > > However I am not sure each time when we provide TE metrics to alto client, we also MUST provide the schedule time associated with TE metrics. > > In some cases, the alto client only care about TE metrics rather than schedule time associated TE metrics. > > In some case, alto server only use new cost metrics as constraint attribute when return routingcost value to the alt client and does not need to return other TE Metrics besides routing cost. > > > > So supporting schedule of TE metric may not be a mandatory feature. > > > > As you pointed in thread "Re: [alto] ALTO Extension: Defining a Cost Metrics document?" (your e-mail dated 27/10/2013) > > > The measurement infrastructure might collect data at 1 min interval, and ALTO exposes only hourly data to certain clients? It is policy controlled. > > > > In such a case, the "unit" member describing the time intervals of the "cost-scope" of the schedule capability specified in the IRD would be: ["hour", 1]. One interpretation of this is that the network provider operating the ALTO Server considers that there is no significant variations in the value observed and that the application using the ALTO Client can rely on this information to schedule its connections. > > > > Ideally, a Cost Schedule should support the provision of information in time "units" with lengths guaranteeing that the underlying measurements have homogeneous values. > > > > The "unit" information could be completed with the attribute "Measurement interval", which indicates on which duration measurements are made or estimated, in your example, 1 minute, and give a hint on the accuracy and reliability of the provided ALTO information. Besides, as you pointed, different network and ALTO Server operators may support different measurement intervals. > > > > Last, I believe that the more abstraction there is in an ALTO TE metric, the closer the "Measurement interval" can be to the Schedule "unit" length, if necessary of course. > > > > [Qin]: It is not clear to me whether the time is referred to the time when TE metrics are sent or the time when TE metrics are received by ALTO server. This should be clear. > > Also it is better we don’t mix measurement unit with measurement interval, they are two different things. > > > > > > Interested people may look at the Cost Schedule presentation on http://tools.ietf.org/agenda/85/slides/slides-85-alto-4.pdf > > > > Thanks, > > Sabine > > > > > > > > De : [email protected] [mailto:[email protected]] De la part de Y. Richard Yang > Envoyé : mardi 29 octobre 2013 23:59 > À : RANDRIAMASY, SABINE (SABINE) > Cc : Qin Wu; He, Peng; IETF ALTO > Objet : Re: [alto] I-D Action: draft-wu-alto-te-metrics-00.txt > > > > Hi Sabine, > > I found the "schedule" concept very interesting and can be quite useful, for applications to schedule large traffic. I read that this is not defined in the draft in -te-metrics. Will you and Qin discuss this design in your slot? > > Thanks! > > Richard > > On Oct 28, 2013 7:56 AM, "RANDRIAMASY, SABINE (SABINE)" < [email protected]> wrote: > > > > -----Message d'origine----- > De : [email protected] [mailto:[email protected]] De la part de He, Peng > Envoyé : mercredi 23 octobre 2013 15:09 > À : Qin Wu; IETF ALTO > Objet : Re: [alto] I-D Action: draft-wu-alto-te-metrics-00.txt > > > [ ] Hi Peng, > Please see below and let me know if this would meet your request, > Best regards > Sabine > > > > Another side question: is there a 'cost' parameter that can show/represent the 'schedule' of the network links, e.g., before 12pm this link/tunnel will have say 100Mbps available, after 12pm, only 50mbps available, i.e., bandwidth scheduling or similar? Or this is more a management system/controller/server related data? > > [ ] There is a protocol extension proposal draft that proposes to provide cost values w.r.t. time and is called "ALTO Cost Schedule". ALTO Cost Schedule is specified as a cost mode where the ALTO Cost values are provided in the form of an array, where each array element corresponds to a given time period and has a value applicable to this period. The granularity of the time period, the number of provided values and other attributes are specified in the IRD. Note that the transaction format in this draft is compliant with the ALTO protocol version issued before the ALTO format changes in the Cost Type specification. > > In your example, the granularity may be 12 hours slots or say 1 hour slots to allow finer grain cost valuation. If we assume 1 hour slots and the availability of a metric called "availbw" expressed in mbps, where values can be provided both in regular 'numerical' mode with "permanent" validity and in 'schedule' mode: > > In the IRD we would have: (please forgive the possible mismatch of brackets) > > { > > ... usual ALTO resources ... > > "resources" : [ > ....... > > { > "uri" : " http://custom.alto.example.com/endpointcost/schedule/lookup";, > "media-types" : [ "application/alto-endpointcost+json" ], > "accepts" : [ "application/alto-endpointcostparams+json" ], > "capabilities" : { > "cost-constraints" : true, > "cost-modes" : [ "numerical", "schedule" ], > "cost-types" : [ "availbw", "availbw" ], > "cost-scope": [ "permanent", > {"unit": ["hour", 1], "size": 24, "begin": 0, > "time zone": "UTC", > "lastupdate": mm/hh/dd/mm/yyyy, > "nextupdate": mm/hh/dd/mm/yyyy} > ] > } > } > ] > } > > If the ALTO Servers provides availbw = 100mbps for the first 12 hours and 50mbps for the next 12 hours on the tunnel with example endpoints (192.0.2.2, 192.0.2.89), the ALTO request and response in schedule mode would look like: > > POST /endpointcost/lookup HTTP/1.1 > Host: alto.example.com > Content-Length: [TODO] > Content-Type: application/alto-endpointcostparams+json > Accept: application/alto-endpointcost+json,application/alto-error+json > > { > "cost-type" : ["availbw"], > "cost-mode" : ["schedule"], > "endpoints" : { > "srcs": [ "ipv4:192.0.2.2" ], > "dsts": [ > "ipv4:192.0.2.89", > "ipv4:198.51.100.34", > "ipv4:203.0.113.45" > ] > } > } > > > HTTP/1.1 200 OK > Content-Length: [TODO] > Content-Type: application/alto-endpointcost+json > > { > "meta" : {}, > "data" : { > "cost-type" : ["availbw "], > "cost-mode" : ["schedule"], > "map" : { > "ipv4:192.0.2.2": { > "ipv4:192.0.2.89" : [100, 100, 100, 100, 100, 100, 100, 100, 100, 100, 100, 100, 50 ... (12 same values)], > "ipv4:198.51.100.34" : [... (24 values) ...], > "ipv4:203.0.113.45" : [... (24 values) ...] > } > } > } > } > > The proposal is documented in http://tools.ietf.org/html/draft-randriamasy-alto-cost-schedule-02 where Section 3.3 provides an example on the Schedule attributes in the IRD, and section 3.3.1 provides example transactions with the Schedule mode. > > > [ ] > Regards, > Peng > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Qin Wu > Sent: Tuesday, October 22, 2013 9:17 PM > To: IETF ALTO > Subject: [alto] FW: I-D Action: draft-wu-alto-te-metrics-00.txt > > Hi, all: > We have posted a new draft to define a set of new cost metrics that are related to traffic engineering performance information. > > http://tools.ietf.org/html/draft-wu-alto-te-metrics-00 > > Please review the draft and provide your feedback and comments. > > Regards! > -Qin > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] > Sent: Monday, October 21, 2013 2:08 PM > To: [email protected] > Subject: I-D Action: draft-wu-alto-te-metrics-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : ALTO Traffic Engineering Cost Metrics > Author(s) : Qin Wu > Young Lee > Dhruv Dhody > Sabine Randriamasy > Filename : draft-wu-alto-te-metrics-00.txt > Pages : 26 > Date : 2013-10-20 > > Abstract: > Cost Metric is a basic concept in Application-Layer Traffic > Optimization (ALTO). It is used in both the Cost Map Service and the > Endpoint Cost Service. Future extensions to ALTO may also use Cost > Metric. > > Different applications may benefit from different Cost Metrics. For > example, a Resource Consumer may prefer Resource Providers that have > low latency to the Resource Consumer. However the base ALTO protocol > [ALTO] has defined only a single cost metric, i.e., the generic > "routingcost" metric (Sec. 14.2 of ALTO base specification [ALTO]). > > In this document, we define XXX Cost Metrics, derived from OSPF-TE > and ISIS-TE, to measure network delay, jitter, packet loss, hop > count, and bandwidth. The metrics defined in this document provide a > relatively comprehensive set of Cost Metrics for ALTO focusing on > traffic engineering. Additional Cost Metrics such as financial cost > metrics may be defined in other documents. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-wu-alto-te-metrics > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-wu-alto-te-metrics-00 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
