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

From: Qin Wu <[email-masked]>
Date: Wed, 23 Oct 2013 01:17:27 +0000

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

---

From: "He, Peng" <[email-masked]>
Date: Wed, 23 Oct 2013 09:09:23 -0400

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?

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.

_______________________________________________
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

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 Oct 2013 08:50:46 +0000

Hi, Peng:
Thank for your comment.
If cost metrics don't change or change not very frequently, e.g.,maximum bandwidth represents link capacity and usually doesn't change.
For those cost metric, such cost parameter does not need or can be ignored.
However for cost metrics which do make frequently changes over measurement interval, such metrics need to rely on measurement interval to know
Whether or how cost metric, e.g., bandwidth change during a period of time. The measurement interval can be preconfigured.

Take cost metrics defined in this draft as an example, these cost metrics are derived from ISIS-TE or OSPF-TE, so we can rely on IGP protocol to
Specify such configurable interval. If we gather these cost metrics from other means, we need to figure out how to measure schedule of the metrics just
As you said, could be control plane based or management plane based.
I prefer we should focus on using some mechanisms that have been already standardized to decide schedule of cost metrics rather than basing on some proprietary solutions.

Regards!
-Qin
-----Original Message-----
From: He, Peng [mailto:[email-masked]] 
Sent: Wednesday, October 23, 2013 9:09 PM
To: Qin Wu; IETF ALTO
Subject: RE: I-D Action: draft-wu-alto-te-metrics-00.txt

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:

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Mon, 28 Oct 2013 11:54:06 +0000

-----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

[     ] 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:

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:

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 29 Oct 2013 18:59:08 -0400

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:

> 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:
>
>          "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:
>
>           "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
>
>
>
> We have posted a new draft to define a set of new cost metrics that are
> related to traffic engineering performance information.
>
> 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-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Wed, 30 Oct 2013 23:57:03 +0000

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.

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.

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

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

   {

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

      {

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

  {

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

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

[     ]
Regards,
Peng

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[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]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, October 21, 2013 2:08 PM
To: [email-masked]<mailto:[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<http://tools.ietf.org>.

_______________________________________________
I-D-Announce mailing list
[email-masked]<mailto:[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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/alto

---

From: Qin Wu <[email-masked]>
Date: Thu, 31 Oct 2013 09:47:26 +0000

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.
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,

[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.

[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.

Thanks,
Sabine

Hi Sabine,

Thanks!

Richard

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

   {

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

      {

  {

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

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

[     ]
Regards,
Peng

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[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]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, October 21, 2013 2:08 PM
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-wu-alto-te-metrics-00.txt

Abstract:

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Thu, 31 Oct 2013 12:05:30 +0000

Hi Qin,

Please see my comments inline, I hope it addressed your questions
Best regards
Sabine

De : Qin Wu [mailto:[email-masked]]
Envoyé : jeudi 31 octobre 2013 10:47
À : RANDRIAMASY, SABINE (SABINE); Y. Richard Yang
Cc : He, Peng; IETF ALTO
Objet : RE: [alto] I-D Action: draft-wu-alto-te-metrics-00.txt

Hi, Richard, Sabine:

Regards!
-Qin

Hi Richard,

[     ] The schedule time and other Schedule Mode attributes are only specified in the IRD. If you look at the example request/response in section 3.3.1 of http://tools.ietf.org/html/draft-randriamasy-alto-cost-schedule-02 the client requests "cost metric" with "cost mode" (= schedule) and just gets a value array to be interpreted as specified in the IRD.

So supporting schedule of TE metric may not be a mandatory feature.
[     ] it does not need to. It is meant for applications (i) that are not real time and (ii) can schedule their connection at optimal times (iii) and therefore would like to have value in the form of a schedule. The schedule mode can co-exist with other modes such as numerical and ordinal, see IRD example in section 3.3.

[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.
[     ] I don't really consider the time where ALTO Server receives information as I think that if the ALTO Client trusts the Server,  it  is not supposed to know it. On the other hand, the Server IRD exposes the dates of the last and next update, and by the way the following other information on the Schedule, see again IRD example.  (Again, this is the ancient cost-mode & cost type encoding)

.............
"cost-constraints" : true,
           "cost-modes" : [ "numerical", "numerical", "schedule" ],
           "cost-types" : [ "routingcost", "hopcount", "pathoccupationcost" ],
           "cost-scope":  [ "permanent", "permanent",
                            {"unit": ["hour", 1], "size": 24, "begin": 0,
                             "time zone": "UTC",
                             "lastupdate": mm/hh/dd/mm/yyyy,
                             "nextupdate": mm/hh/dd/mm/yyyy}
.............

The schedule mode only applies to metric "pathoccupationcost". In that case, values are provided in an array of 24 values, each representing a time interval of 1 hour and the provided information starts at hour 0 (midnight).

The unit here describes how to interpret the duration of the time interval on which each value of the array is provided.

Thanks,
Sabine

Hi Sabine,

Thanks!

Richard

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

   {

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

      {

  {

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

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

[     ]
Regards,
Peng

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[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]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, October 21, 2013 2:08 PM
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-wu-alto-te-metrics-00.txt

Abstract: