Subject: Re: [alto] I-D Action: draft-wu-alto-te-metrics-00.txt

From: "Y. Richard Yang" <[email-masked]>
Date: Sat, 2 Nov 2013 20:39:24 -0400

Hi Qin, Sabine,

On Oct 31, 2013 5:48 AM, "Qin Wu" <[email-masked]> 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-masked]]
> 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-masked] [mailto:[email-masked]] 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-masked]> wrote:
>
>
>
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 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-masked] [mailto:[email-masked]] 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-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
> Sent: Monday, October 21, 2013 2:08 PM
> To: [email-masked]
> 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-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/alto
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Qin Wu <[email-masked]>
Date: Sun, 3 Nov 2013 01:14:00 +0000

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-masked] [mailto:[email-masked]] 代表 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-masked]<mailto:[email-masked]>> 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

> From: RANDRIAMASY, SABINE (SABINE) [mailto:[email-masked]<mailto:[email-masked]>]
> 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.
>
>
>
> 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-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Y. Richard Yang
> 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-masked]<mailto:[email-masked]>> wrote:
>
>
>
> De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de He, Peng
> 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)
>
>    {
>
>          "uri" : "http://custom.alto.example.com/endpointcost/schedule/lookup",
> 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:
>
>   Host: alto.example.com<http://alto.example.com>
>   Content-Length: [TODO]
>           "ipv4:192.0.2.89"    : [100, 100, 100, 100, 100, 100, 100, 100, 100, 100, 100, 100, 50 ... (12 same 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
>
>
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Qin Wu
> We have posted a new draft to define a set of new cost metrics that are related to traffic engineering performance information.
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
> To: [email-masked]<mailto:[email-masked]>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> 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>.
>
> [email-masked]<mailto:[email-masked]>
> Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Sun, 3 Nov 2013 04:53:17 +0000

Hi Richard and Qin,

I agree that even a 10 minutes slot will be focused on the selection and specification of TE based ALTO Costs and on the next steps to this draft. The Cost schedule is a specific Cost Mode that is well suited to TE based metrics that usually change frequently and are a major use case. We may thus point this out as related discussion topic that may continue on the mailing list.
Best regards,
Sabine

De : [email-masked] [mailto:[email-masked]] De la part de Qin Wu
Envoyé : dimanche 3 novembre 2013 02:14
À : Y. Richard Yang
Cc : IETF ALTO
Objet : [alto] 答复: I-D Action: draft-wu-alto-te-metrics-00.txt

Regards!
-Qin
发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 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,

Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 3 Nov 2013 12:03:40 -0500

On Saturday, November 2, 2013, RANDRIAMASY, SABINE (SABINE) wrote:

>  Hi Richard and Qin,
>
> I agree that even a 10 minutes slot will be focused on the selection and
> specification of TE based ALTO Costs and on the next steps to this draft.
> The Cost schedule is a specific Cost Mode that is well suited to TE based
> metrics that usually change frequently and are a major use case. We may
> thus point this out as related discussion topic that may continue on the
> mailing list.
>
>
Personally, I feel that metric definitions and "schedule" will be better
to be defined in different drafts because they are different topics. More
generally, I see your "schedule" as a starting point for a powerful API
into potentially a large amount of metric data that may be available by a
network. The data can be based on both historically collected and/or
planned data (e.g., scheduled maintenance). The metrics may or may not
change rapidly---many diurnal patterns are slow enough for a
slow-path software controller to adapt to. In short, a sense that we are
defining a simple but general API in the statistics/prediction domain will
be very helpful to move forward.

Thanks!

Richard

Best regards,
>
> Sabine
>
>
>
>
>
> *De :* [email-masked] <javascript:_e({}, 'cvml',
> [email-masked]');> [mailto:[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>]
> *De la part de* Qin Wu
> *Envoyé :* dimanche 3 novembre 2013 02:14
> *À :* Y. Richard Yang
> *Cc :* IETF ALTO
> *Objet :* [alto] 答复: I-D Action: draft-wu-alto-te-metrics-00.txt
>
>
>
> Sabine and I have already had some offline discussion and list discussion
> on the list when we prepare the slides for this draft.
>
> *发件人**:* [email-masked] [mailto:[email-masked]] *代表* 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,
>
> 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
> <

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Sun, 3 Nov 2013 17:08:05 +0000

Hi Richard,

Thanks for your two points. I agree, it is better to have separate. TE metrics are a major use case to the Schedule and  there are others as well worth being exposed.
Best regards
Sabine

De : [email-masked] [mailto:[email-masked]] De la part de Y. Richard Yang
Envoyé : dimanche 3 novembre 2013 18:04
À : RANDRIAMASY, SABINE (SABINE)
Cc : Qin Wu; Y. Richard Yang; IETF ALTO
Objet : Re: FW: I-D Action: draft-wu-alto-te-metrics-00.txt

Personally, I feel that metric definitions and "schedule" will be better to be defined in different drafts because they are different topics. More generally, I see your "schedule" as a starting point for a powerful API into potentially a large amount of metric data that may be available by a network. The data can be based on both historically collected and/or planned data (e.g., scheduled maintenance). The metrics may or may not change rapidly---many diurnal patterns are slow enough for a slow-path software controller to adapt to. In short, a sense that we are defining a simple but general API in the statistics/prediction domain will be very helpful to move forward.

Thanks!

Richard

Best regards,
Sabine

De : [email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');> [mailto:[email-masked]<javascript:_e(%7b%7d,%20'cvml',[email-masked]');>] De la part de Qin Wu
Envoyé : dimanche 3 novembre 2013 02:14
À : Y. Richard Yang
Cc : IETF ALTO
Objet : [alto] 答复: I-D Action: draft-wu-alto-te-metrics-00.txt

Regards!

-Qin

Hi Qin, Sabine,

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<

--
--
 =====================================
| Y. Richard Yang <[email-masked]<mailto:[email-masked]>>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: Qin Wu <[email-masked]>
Date: Sun, 3 Nov 2013 23:04:48 +0000

I tend to agree.
But I am okay with either separating or putting two together.

Regards!
-Qin
发件人: [email-masked] [mailto:[email-masked]] 代表 Y. Richard Yang
发送时间: 2013年11月4日 1:04
收件人: RANDRIAMASY, SABINE (SABINE)
抄送: Qin Wu; IETF ALTO
主题: Re: [alto] FW: I-D Action: draft-wu-alto-te-metrics-00.txt

Thanks!

Richard

Best regards,
Sabine

Regards!

-Qin

Hi Qin, Sabine,

---

From: "He, Peng" <[email-masked]>
Date: Sun, 3 Nov 2013 20:24:50 -0500

Hi Sabine,

Sorry for the late response. Yes, I like this 'schedule' mode concept in your draft. Also agreed that might need to add this  into the draft of -te-metrics, or a separate one. 

Is it possible to consider the 'numerical' mode as a special case of 'schedule' mode, i.e., a constant value for all the time period, or it would be better to have both 'numerical' and 'schedule' modes separately?

Regards,
Peng

-----Original Message-----
From: RANDRIAMASY, SABINE (SABINE) [mailto:[email-masked]] 
Sent: Monday, October 28, 2013 7:54 AM
To: He, Peng; Qin Wu; IETF ALTO
Subject: RE: I-D Action: draft-wu-alto-te-metrics-00.txt

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 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

   {

    "resources" : [
     .......

      {

  {

  HTTP/1.1 200 OK
  Content-Length: [TODO]

  {
    "meta" : {},
    "data" : {

[     ] 
Regards,
Peng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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:

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 21, 2013 2:08 PM
To: [email-masked]
Subject: I-D Action: draft-wu-alto-te-metrics-00.txt

Abstract:

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.

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Tue, 5 Nov 2013 00:00:59 +0000

Hi Peng,

Please see my answer inline.
Thanks,
Sabine

-----Message d'origine-----
De : He, Peng [mailto:[email-masked]] 
Envoyé : lundi 4 novembre 2013 02:25
À : RANDRIAMASY, SABINE (SABINE); Qin Wu; IETF ALTO
Objet : RE: I-D Action: draft-wu-alto-te-metrics-00.txt

Hi Sabine,

Sorry for the late response. Yes, I like this 'schedule' mode concept in your draft. Also agreed that might need to add this  into the draft of -te-metrics, or a separate one. 
[     ] There seems to be an agreement on keeping the 'schedule' in a separate draft.

[     ] In a sense, 'numerical' and any other applicable mode are particular cases of schedule, with one single metric value provided. But I think it is simpler to provide the value as it is done in the base protocol and add just one "cost scope" attribute equal to "permanent". Otherwise we would need to define corresponding "cost scope" attributes (unit, size etc...) and carry them in the ALTO response, giving useless additional work to the ALTO Client. 

The draft provides an example in section 3.3 where the two modes 'numerical' and 'schedule' co-exist in the IRD. That is, for metric 'routingcost' the ALTO Server can provide a single 'synthetic' value as well as its detail in the 'schedule' mode. 

Of course, the draft needs further work to specify how the IRD indicates the "basic" type of JSONValue used for metrics provided in the schedule mode (e.g. 'numerical', 'string' ...). Likewise, any suggestion that may clarify the cost schedule terminology is welcome.

Regards,
Sabine

Regards,
Peng

-----Original Message-----
From: RANDRIAMASY, SABINE (SABINE) [mailto:[email-masked]] 
Sent: Monday, October 28, 2013 7:54 AM
To: He, Peng; Qin Wu; IETF ALTO
Subject: RE: I-D Action: draft-wu-alto-te-metrics-00.txt

-----Message d'origine-----

[     ] Hi Peng, 

   {

    "resources" : [
     .......

      {

  {

  HTTP/1.1 200 OK
  Content-Length: [TODO]

  {
    "meta" : {},
    "data" : {

[     ] 
Regards,
Peng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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:

Regards!
-Qin
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, October 21, 2013 2:08 PM
To: [email-masked]
Subject: I-D Action: draft-wu-alto-te-metrics-00.txt

Abstract: