I thought we got 10 min time slot. Sure, we can take offline if out of time. Sabine and I have already had some offline discussion and list discussion on the list when we prepare the slides for this draft. I did agree to add this feature but apparently as an option feature. I am also available before ALTO or after ALTO for discussing this. It will be great we can talk on Sunday.
Regards! -Qin 发件人: [email protected] [mailto:[email protected]] 代表 Y. Richard Yang 发送时间: 2013年11月3日 8:39 收件人: Qin Wu 抄送: IETF ALTO 主题: Re: [alto] I-D Action: draft-wu-alto-te-metrics-00.txt Hi Qin, Sabine, On Oct 31, 2013 5:48 AM, "Qin Wu" <[email protected]<mailto:[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]<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]> > [mailto:[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]<mailto:[email protected]>> > wrote: > > > > -----Message d'origine----- > De : [email protected]<mailto:[email protected]> > [mailto:[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<http://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]> > [mailto:[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]> > [mailto:[email protected]<mailto:[email protected]>] > On Behalf Of [email protected]<mailto:[email protected]> > Sent: Monday, October 21, 2013 2:08 PM > To: [email protected]<mailto:[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<http://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]<mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ > alto mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/alto > _______________________________________________ > alto mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/alto
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
