Re: [alto] Review for draft-ietf-alto-performance-metrics-12

[Jensen Zhang]

Hi Qin,

I agree with you that the constraints checking should rely on the
implementation. I'm OK that it is not in the scope of this document.

For other comments, I have checked v-13. I think most of them have been
addressed, except for the following one.

Section 2.2., paragraph 16:



>If a metric has no  (and hence no - as well), the metric MUST



  recommend adding " surrounding -, or using dash character instead;

  if possible, giving the precise BNF grammar will be better, as I

  see some metrics names also include the dash character ("-").

>be considered as the 50 percentile (median).  Since this scheme is

>common for all metrics defined in this document, below we only

>specify the base identifier.

Although I can understand this sentence, I still think it should be better
clarified.
I would suggest giving the BNF grammar at the beginning of this section,
e.g.,

   ... Hence, each performance metric's identifier
   should indicate the statistic (i.e., an aggregation operation), to
   become


   ::=  [ '-'  ]


   where  MUST be one of the following:


And changing the last paragraph of the section to:

   If '-'  is not present in , the metric MUST

   be considered as the 50 percentile (median).


Thanks,
Jensen


On Tue, Jan 12, 2021 at 2:22 PM Qin Wu  wrote:

> Hi, Jensen:
>
> Speak as individual, My answer to your following question is false as
> well, even based on RFC7285, defining hopecount as float point value seem
> also weird.
>
> I think we can rely on implementation or some automation tools for
> constraints checking, but it is not scope of this document.
>
> For other comments, I think Richard have addressed in v-13. Please double
> check it. Thanks
>
>
>
> -Qin
>
> [alto] Review for draft-ietf-alto-performance-metrics-12
>
> Jensen Zhang  Tue, 13 October 2020 04:17 UTCShow
> header
> 
>
> Dear ALTOers and authors of draft-ietf-alto-performance-metrics-12,
>
>
>
> Below is my review for draft-ietf-alto-performance-metrics-12.
>
>
>
> Best regards,
>
> Jensen
>
>
>
> ==
>
> General issue:
>
>
>
> The document is well written. I only have one question about the design
>
> part:
>
>
>
> the base ALTO protocol only uses the cost-mode to infer the value format,
>
> e.g., "numerical" infers the cost value MUST be a floating-point value; but
>
> this document requires different value formats for different cost-metrics,
>
> e.g., "delay-ow" requires the non-negative floating-point value, and
>
> "hopcount" requires the non-negative integer value. But based on
>
> Sec 11.3.2.3 of RFC7285, in the "constraints" field, "ALTO servers SHOULD
>
> use at least IEEE 754 double-precision floating point [IEEE.754.2008] to
>
> store the cost value". I wonder if a test constraint expression like "eq
>
> 3.1" for the cost-metric "hopcount" is valid. Should the ALTO server reject
>
> such a request? According to RFC7285, it should be valid. But according to
>
> this document, it is clearly always false.
>
>
>
> ==
>
>
>
> Nits and writing suggestions:
>
>
>
> Section 1., paragraph 5:
>
>
>
> >The purpose of this document is to ensure proper usage of the
>
> >performance metrics defined in Table 1; it does not claim novelty of
>
> >the metrics.  The Origin column of Table 1 gives the RFC which
>
> >defines each metric.
>
>
>
>   Origin -> Origin Example (to be consistent with the table)
>
> >We can rough classify the performance metrics into two categories:
>
> >those derived from the performance of individual packets (i.e., one-
>
> >way delay, round-trip delay, delay variation, hop count, and loss
>
> >rate), and those related with bandwidth (TCP throughput, residue
>
> >bandwidth and max reservable bandwidth).  These two categories are
>
> >defined in Section 3 and Section 4 respectively.  Note that all
>
> >metrics except round trip delay are unidirectional.  Hence, a client
>
> >will need to query both directions if needed.
>
>
>
>
>
> Section 2., paragraph 1:
>
>
>
> >When defining the metrics in Table 1, this document considers the
>
> >guidelines specified in [RFC6390], which requires fine-grained
>
> >specification of (i) Metric Name, (ii) Metric Description, (iii)
>
> >Method of Measurement or Calculation, (iv) Units of Measurement, (v)
>
> >Measurement Points, and (vi) Measurement Timing.  In particular, for
>
> >each metric, this document defines (i) Metric Name, (ii) Metric
>
> >Description, and (iv) Units of Measurement.  The Measurement Points
>
> >are always specified by the specific ALTO services; for example,
>
> >endpoint cost service is between the two end points.
>
>
>
>   end points -> endpoints
>
>
>
>
>
> Section 2.1., paragraph 11:
>
>
>
> >A particular type of "estimation is direct "import", which indicates
>
> 

Re: [alto] Fwd: I-D Action: draft-ietf-alto-cdni-request-routing-alto-15.txt

[Qin Wu]

Hi, Jensen：
IDnits tool shows two errors:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-alto-cdni-request-routing-alto-15.txt
  ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259)
  ** The abstract seems to contain references ([RFC8008], [RFC7336],
 [RFC6707]), which it shouldn't.  Please replace those with straight
 textual mentions of the documents in question.

Please fix them.

-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Jensen Zhang
发送时间: 2021年1月12日 14:36
收件人: IETF ALTO 
主题: [alto] Fwd: I-D Action: draft-ietf-alto-cdni-request-routing-alto-15.txt

Hi all,

We just submitted version -15 of the ALTO CDNI document to address the 
following issues:

- Replaced the deprecated term "unified properties" with "entity property map" 
to be consistent with draft-ietf-alto-unified-props-new-15
- Moved I-D.ietf-alto-unified-props-new into the normative references 
(suggested by Qin [1])

[1] https://mailarchive.ietf.org/arch/msg/alto/clLDN-B7nDlIKN3Tq4qxug83tic/

Best regards,
Jensen

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Tue, Jan 12, 2021 at 2:16 PM
Subject: [alto] I-D Action: draft-ietf-alto-cdni-request-routing-alto-15.txt
To: mailto:i-d-annou...@ietf.org>>
Cc: mailto:alto@ietf.org>>



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of 
the IETF.

Title   : Content Delivery Network Interconnection (CDNI) 
Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO
Authors : Jan Seedorf
  Y.R. Yang
  Kevin J. Ma
  Jon Peterson
  Jingxuan Jensen Zhang
Filename: draft-ietf-alto-cdni-request-routing-alto-15.txt
Pages   : 41
Date: 2021-01-11

Abstract:
   The Content Delivery Networks Interconnection (CDNI) framework
   [RFC6707] defines a set of protocols to interconnect CDNs, to achieve
   multiple goals such as extending the reach of a given CDN to areas
   that are not covered by that particular CDN.  One component that is
   needed to achieve the goal of CDNI described in [RFC7336] is the CDNI
   Request Routing Footprint & Capabilities Advertisement interface
   (FCI).  [RFC8008] defines precisely the semantics of FCI and provides
   guidelines on the FCI protocol, but the exact protocol is explicitly
   outside the scope of that document.  This document defines an FCI
   protocol using the Application-Layer Traffic Optimization (ALTO)
   protocol, following the guidelines defined in [RFC8008].



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-15
https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cdni-request-routing-alto-15


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/


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Normative References in draft-ietf-alto-performance-metrics-12

[Qin Wu]

Hi, Jan and authors of draft-ietf-alto-performance-metrics:
-邮件原件-
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Jan Seedorf
发送时间: 2020年11月12日 6:32
收件人: alto@ietf.org
主题: [alto] Normative References in draft-ietf-alto-performance-metrics-12

Dear authors of draft-ietf-alto-performance-metrics-12,

while reviewing the document, I notices the following issues with normative 
references:

1)    [I-D.ietf-idr-te-pm-bgp]
   Previdi, S., Wu, Q., Gredler, H., Ray, S.,
   jefft...@gmail.com, j., Filsfils, C., and L. Ginsberg,
   "BGP-LS Advertisement of IGP Traffic Engineering
   Performance Metric Extensions", draft-ietf-idr-te-pm-
   bgp-03 (work in progress), May 2016.

--> This is an RFC by now, so please fix the ref
[Qin]: I think [I-D.ietf-idr-te-pm-bgp] has already been replaced by RFC8571 in 
the v-12 or earlier version.

2)    [I-D.ietf-ippm-initial-registry]
   Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
   "Initial Performance Metric Registry Entries", draft-ietf-
   ippm-initial-registry-01 (work in progress), July 2016.

--> this draft is in version -016 by now, and also not a normative
reference; so please update the ref and move it to informative references

[Qin]: Agree, I have checked the reference, I found 
[I-D.ietf-ippm-initial-registry] has been quoted four times but I didn't find 
this reference section 9.1 or section 9.2, I think this issues should be fixed.
Also IDnits should be fixed as well,
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-alto-performance-metrics-13.txt
There are 3 nits errors which should be fixed.

Can you please address these issues as well when you address the WGLC 
comments received (see below)?

Thanks,

Jan

Am 08.11.20 um 22:56 schrieb Jan Seedorf:
> Dear all,
>
> this ends the WGLC for draft-ietf-alto-performance-metrics-12. No 
> objections on this document have been raised. Three individual reviews 
> have been done, the respective comments have each been posted on the 
> ALTO mailing list by Kai (Oct 10), Denny (Oct 12), and Jensen (Oct 
> 13). May I kindly ask the authors of the document to address these 
> comments ASAP and post a new version of the document?
>
> Thanks,
>
> Jan
>
> Am 28.09.20 um 18:42 schrieb Jan Seedorf:
>> Dear all,
>>
>> as discussed during the ALTO session at IETF-108, we are moving 
>> forward with all the remaining milestones.
>>
>> Thus, this email starts a WGLC for 
>> draft-ietf-alto-performance-metrics-12. The WGLC will run two weeks, 
>> so from today, Monday, September 28, until Monday, Oktober 12, 2020.
>>
>> We would like to have two individual reviews of this document as part 
>> of the WGLC. Please send us an email if you are willing review the 
>> draft as part of WGLC. We really need these reviews to make progress.
>>
>>  - Vijay and Jan
>>
>> ___
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Fwd: I-D Action: draft-ietf-alto-cdni-request-routing-alto-15.txt

[Jensen Zhang]

Hi all,

We just submitted version -15 of the ALTO CDNI document to address the
following issues:

- Replaced the deprecated term "unified properties" with "entity property
map" to be consistent with draft-ietf-alto-unified-props-new-15
- Moved I-D.ietf-alto-unified-props-new into the normative references
(suggested by Qin [1])

[1] https://mailarchive.ietf.org/arch/msg/alto/clLDN-B7nDlIKN3Tq4qxug83tic/

Best regards,
Jensen


-- Forwarded message -
From: 
Date: Tue, Jan 12, 2021 at 2:16 PM
Subject: [alto] I-D Action: draft-ietf-alto-cdni-request-routing-alto-15.txt
To: 
Cc: 



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Application-Layer Traffic Optimization WG
of the IETF.

Title   : Content Delivery Network Interconnection (CDNI)
Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO
Authors : Jan Seedorf
  Y.R. Yang
  Kevin J. Ma
  Jon Peterson
  Jingxuan Jensen Zhang
Filename: draft-ietf-alto-cdni-request-routing-alto-15.txt
Pages   : 41
Date: 2021-01-11

Abstract:
   The Content Delivery Networks Interconnection (CDNI) framework
   [RFC6707] defines a set of protocols to interconnect CDNs, to achieve
   multiple goals such as extending the reach of a given CDN to areas
   that are not covered by that particular CDN.  One component that is
   needed to achieve the goal of CDNI described in [RFC7336] is the CDNI
   Request Routing Footprint & Capabilities Advertisement interface
   (FCI).  [RFC8008] defines precisely the semantics of FCI and provides
   guidelines on the FCI protocol, but the exact protocol is explicitly
   outside the scope of that document.  This document defines an FCI
   protocol using the Application-Layer Traffic Optimization (ALTO)
   protocol, following the guidelines defined in [RFC8008].



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-15
https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cdni-request-routing-alto-15


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/


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Review for draft-ietf-alto-performance-metrics-12

[Qin Wu]

Hi, Jensen:
Speak as individual, My answer to your following question is false as well, 
even based on RFC7285, defining hopecount as float point value seem also weird.
I think we can rely on implementation or some automation tools for constraints 
checking, but it is not scope of this document.
For other comments, I think Richard have addressed in v-13. Please double check 
it. Thanks

-Qin
[alto] Review for draft-ietf-alto-performance-metrics-12

Jensen Zhang  Tue, 13 October 2020 04:17 UTCShow 
header
Dear ALTOers and authors of draft-ietf-alto-performance-metrics-12,

Below is my review for draft-ietf-alto-performance-metrics-12.

Best regards,
Jensen

==
General issue:

The document is well written. I only have one question about the design
part:

the base ALTO protocol only uses the cost-mode to infer the value format,
e.g., "numerical" infers the cost value MUST be a floating-point value; but
this document requires different value formats for different cost-metrics,
e.g., "delay-ow" requires the non-negative floating-point value, and
"hopcount" requires the non-negative integer value. But based on
Sec 11.3.2.3 of RFC7285, in the "constraints" field, "ALTO servers SHOULD
use at least IEEE 754 double-precision floating point [IEEE.754.2008] to
store the cost value". I wonder if a test constraint expression like "eq
3.1" for the cost-metric "hopcount" is valid. Should the ALTO server reject
such a request? According to RFC7285, it should be valid. But according to
this document, it is clearly always false.

==

Nits and writing suggestions:

Section 1., paragraph 5:

>The purpose of this document is to ensure proper usage of the
>performance metrics defined in Table 1; it does not claim novelty of
>the metrics.  The Origin column of Table 1 gives the RFC which
>defines each metric.

  Origin -> Origin Example (to be consistent with the table)
>We can rough classify the performance metrics into two categories:
>those derived from the performance of individual packets (i.e., one-
>way delay, round-trip delay, delay variation, hop count, and loss
>rate), and those related with bandwidth (TCP throughput, residue
>bandwidth and max reservable bandwidth).  These two categories are
>defined in Section 3 and Section 4 respectively.  Note that all
>metrics except round trip delay are unidirectional.  Hence, a client
>will need to query both directions if needed.


Section 2., paragraph 1:

>When defining the metrics in Table 1, this document considers the
>guidelines specified in [RFC6390], which requires fine-grained
>specification of (i) Metric Name, (ii) Metric Description, (iii)
>Method of Measurement or Calculation, (iv) Units of Measurement, (v)
>Measurement Points, and (vi) Measurement Timing.  In particular, for
>each metric, this document defines (i) Metric Name, (ii) Metric
>Description, and (iv) Units of Measurement.  The Measurement Points
>are always specified by the specific ALTO services; for example,
>endpoint cost service is between the two end points.

  end points -> endpoints


Section 2.1., paragraph 11:

>A particular type of "estimation is direct "import", which indicates
>that the value of the metric is imported directly from a specific
>existing protocol or system.  Specifying "import" as source instead

  source -> the source
>of the more generic "estimation" may allow better tracing of
>information flow.  For an "import" metric, it is RECOMMENDED that the
>"parameters" field provides details to the system from which raw data
>is imported.  In particular, one may notice that the set of end-to-
>end metrics defined in Table 1 has large overlap with the set defined
>in [RFC8571], in the setting of IGP traffic engineering performance
>metrics for each link (i.e., unidirectional link delay, min/max
>unidirectional link delay, unidirectional delay variation,
>unidirectional link loss, unidirectional residual bandwidth,
>unidirectional available bandwidth, unidirectional utilized
>bandwidth).  Hence, an ALTO server may use "import" to indicate that
>its end-to-end metrics are computed from link metrics imported from
>[RFC8571].


Section 2.2., paragraph 2:

>percentile, with letter p followed by a number p:

  a number p -> a number


Section 2.2., paragraph 16:

>If a metric has no  (and hence no - as well), the metric MUST

  recommend adding " surrounding -, or using dash character instead;
  if possible, giving the precise BNF grammar will be better, as I
  see some metrics names also include the dash character ("-").
>be considered as the 50 percentile (median).  Since this scheme is
>common for all metrics defined in this document, below we only
>specify the 

[alto] I-D Action: draft-ietf-alto-cdni-request-routing-alto-15.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of 
the IETF.

Title   : Content Delivery Network Interconnection (CDNI) 
Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO
Authors : Jan Seedorf
  Y.R. Yang
  Kevin J. Ma
  Jon Peterson
  Jingxuan Jensen Zhang
Filename: draft-ietf-alto-cdni-request-routing-alto-15.txt
Pages   : 41
Date: 2021-01-11

Abstract:
   The Content Delivery Networks Interconnection (CDNI) framework
   [RFC6707] defines a set of protocols to interconnect CDNs, to achieve
   multiple goals such as extending the reach of a given CDN to areas
   that are not covered by that particular CDN.  One component that is
   needed to achieve the goal of CDNI described in [RFC7336] is the CDNI
   Request Routing Footprint & Capabilities Advertisement interface
   (FCI).  [RFC8008] defines precisely the semantics of FCI and provides
   guidelines on the FCI protocol, but the exact protocol is explicitly
   outside the scope of that document.  This document defines an FCI
   protocol using the Application-Layer Traffic Optimization (ALTO)
   protocol, following the guidelines defined in [RFC8008].



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-cdni-request-routing-alto/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-cdni-request-routing-alto-15
https://datatracker.ietf.org/doc/html/draft-ietf-alto-cdni-request-routing-alto-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-cdni-request-routing-alto-15


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/


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting Info for Jan 12, 2021

[Qin Wu]

Hi, Richard:
Thanks for the update on performance metrics draft in v-13, you missed the 
review comments from Kai
https://mailarchive.ietf.org/arch/msg/alto/PQy-QNz6UfTI6GxOPWCzc0VkHRo/
Checking Kai’s comments, I found some of them have been addressed, some of them 
not, e. g.,
1.Page 15,Example 3
s/delay-var/delay-variation
2.Page 8
s/with letter p /with letter "p"
3 Page 6, sec 2.1
remove "and" before sla
s/latency typically do /latency typically does
For Jensen’s comments, I see one issue is newly introduced, i.e., the term 
“metric value” and “metric’s value”
Are used inconsistently, I suggest to change metric’s value into metric value.
I hope these comments can be addressed before being moved forward.

-Qin
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Y. Richard Yang
发送时间: 2021年1月12日 13:36
收件人: Kai Gao 
抄送: alto-weekly-meet...@googlegroups.com; IETF ALTO 
主题: Re: [alto] Meeting Info for Jan 12, 2021

Hi all,

I have to skip the meeting this morning.

One quick update is on the first agenda item: an updated version of performance 
metrics is just posted and we believe that it has addressed all of the review 
comments by Danny and Jensen.

Richard


On Mon, Jan 11, 2021 at 10:36 AM mailto:kai...@scu.edu.cn>> 
wrote:

Dear all,



This is a friendly reminder that we will have an ALTO weekly meeting at 9:00 am 
US EST (3:00 pm CET, 10:00 pm Beijing Time) on Jan 12, 2021.



Agenda:



- IETF 110: Working group drafts and individual drafts

- NAI workshop



If anyone wants to put other topics on the agenda, please let me know or use 
the agenda bash in the beginning of the meeting.



Bridge: https://yale.zoom.us/my/yryang



Best,

Kai
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Meeting Info for Jan 12, 2021

[Y. Richard Yang]

Hi all,

I have to skip the meeting this morning.

One quick update is on the first agenda item: an updated version of
performance metrics is just posted and we believe that it has addressed all
of the review comments by Danny and Jensen.

Richard


On Mon, Jan 11, 2021 at 10:36 AM  wrote:

> Dear all,
>
>
> This is a friendly reminder that we will have an ALTO weekly meeting at *9:00
> am US EST (3:00 pm CET, 10:00 pm Beijing Time) on Jan 12, 2021*.
>
>
> Agenda:
>
>
> - IETF 110: Working group drafts and individual drafts
>
> - NAI workshop
>
>
> If anyone wants to put other topics on the agenda, please let me know or
> use the agenda bash in the beginning of the meeting.
>
>
> Bridge: https://yale.zoom.us/my/yryang
>
>
> Best,
>
> Kai
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] I-D Action: draft-ietf-alto-performance-metrics-13.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of 
the IETF.

Title   : ALTO Performance Cost Metrics
Authors : Qin Wu
  Y. Richard Yang
  Young Lee
  Dhruv Dhody
  Sabine Randriamasy
  Luis Miguel Contreras
Filename: draft-ietf-alto-performance-metrics-13.txt
Pages   : 32
Date: 2021-01-11

Abstract:
   Cost metric is a basic concept in Application-Layer Traffic
   Optimization (ALTO), and different applications may use different
   cost metrics.  Since the ALTO base protocol [RFC7285] defines only a
   single cost metric (i.e., the generic "routingcost" metric), if an
   application wants to issue a cost map or an endpoint cost request to
   determine the resource provider that offers better delay performance,
   the base protocol does not define the cost metric to be used.

   This document addresses the issue by introducing network performance
   metrics, including network delay, jitter, packet loss rate, hop
   count, and bandwidth.

   There are multiple sources (e.g., estimation based on measurements or
   service-level agreement) to derive a performance metric.  This
   document introduces an additional "cost-context" field to the ALTO
   "cost-type" field to convey the source of a performance metric.

   

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-performance-metrics/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-performance-metrics-13
https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-performance-metrics-13


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/


___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] Shepherd writeup for path-vector (draft)

[Qin Wu]

Hi, authors of path-vector:
I haven’t seen you addressed IDnits errors raised by Vijay below:
https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-alto-path-vector-13.txt
Please reply to Vijay and confirm whether there are anything missing or open 
issues which haven’t been closed.

-Qin (With chair hat on)
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Vijay Gurbani
发送时间: 2020年12月2日 1:36
收件人: IETF ALTO 
主题: [alto] Shepherd writeup for path-vector (draft)

All: I have started the shepherd review of path-vector  The review is below.
The token is with me to do a chair/shepherd review of the draft.  With the 
semester coming to a close and grading to do, etc., I have reserved the week 
starting Dec-16 to do the shepherd review of the draft.

In the meantime, please go through the draft shepherd writeup and let me know 
if I have erred anywhere.

Thanks,

- vijay
-
Shepherd writeup for draft-ietf-alto-path-vector-13

1. Summary.

The document shepherd is Vijay K. Gurbani, and the responsible area director is 
Martin Duke.

The document is a Standards Track document, targeted as a Proposed Standard.  
The WG has chosen the requested publication type since this draft extends the 
base ALTO protocol in a normative manner.  Specifically, the document seeks to 
extend the base ALTO protocol (RFC 7285) to provide the concept of "Abstract 
Network Elements" (ANE).  ANEs are an abstraction of physical network 
components --- routers, etc. --- that handle (switch) packets.  An application 
whose performance may be impacted by a particular traversal path in the network 
may wish to consult the ANEs to determine an optimized path to the destination.

This draft is a major conceptual advance in the abstractions provided by the 
base ALTO protocol.

2. Review and consensus.
This work is mature.  It started off as an individual submission in March 2015, 
and was adopted as a WG deliverable in May 2017.  A detailed review of this 
draft was provided early on by Sabine Randriamasy [1,2,3] shortly after it was 
adopted.  Version -04 was further reviewed by Danny Perez [4] and Qiao Xiang 
[5] in 2018, and the work progressed appreciably between 2018 and 2019, 
resulting in the release of -09 in November 2019.

A WGLC was initiated on Sep-28-2020, and a review was provided by Qiao Xiang 
[6] and Luis Contreras [7] on version -11.  Version -12 included the comments 
from Qiao and Luis, with version -13 following with some minor revisions.

Earlier versions of path-vector have been implemented (without the integration 
of unified-props); the implementation was used in a super computing conference 
demonstration for OpenFlow-based networks [8].  The latest version of 
path-vector is being implemented and will be open-sourced on GitHub [9].

The shepherd has an action item to review version -13.

3. Intellectual property
All of the authors have confirmed with the shephered that they are not aware of 
any IPR filed with respect to the draft.

4. Other points
IDNits reports 1 error, 7 warnings, and 2 comments.

[1] https://mailarchive.ietf.org/arch/msg/alto/IQ0WwgWewFKJkvzZSIQRhkiN-hc/
[2] https://mailarchive.ietf.org/arch/msg/alto/4wa_kXE4GUrigZ33TBCVVuwBuiw/
[3] https://mailarchive.ietf.org/arch/msg/alto/GGroJgfL5XGuH1ydWOLmISCPMKY/
[4] https://mailarchive.ietf.org/arch/msg/alto/HSGkZ2o4JvneiiYiVSGcCZjDVSQ/
[5] https://mailarchive.ietf.org/arch/msg/alto/qnIBXzFEiYxMDm9kvHLH53qbn_Y/
[6] https://mailarchive.ietf.org/arch/msg/alto/uwFNjekGcc3zMdSKleHU7eIdsW4/
[7] https://mailarchive.ietf.org/arch/msg/alto/D5jkRGws2c75paw6yP8_5_40ViY/
[8] https://github.com/openalto/mercator-setup
[9] https://github.com/openalto/sextant
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] Meeting Info for Jan 12, 2021

[kaigao]

Dear all,




This is a friendly reminder that we will have an ALTO weekly meeting at 9:00 am 
US EST (3:00 pm CET, 10:00 pm Beijing Time) on Jan 12, 2021.




Agenda:




- IETF 110: Working group drafts and individual drafts

- NAI workshop




If anyone wants to put other topics on the agenda, please let me know or use 
the agenda bash in the beginning of the meeting.




Bridge: https://yale.zoom.us/my/yryang




Best,

Kai___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto