Vijay K. Gurbani | 5 Sep 22:18 2014

Building ALTO maps from public data

Folks: Some of you may be interested in the following paper on how to
build ALTO maps from public data:

Making historical connections: Building Application Layer Traffic
Optimization (ALTO) network and cost maps from public broadband data
    Vijay K. Gurbani, David Goergen, Radu State and Thomas Engel

Abstract: The Application Traffic Layer Optimization (ALTO) protocol
allows network service providers (NSP) to make available a pair of maps
to applications such that the applications can intelligently (compared
to randomly) connect to a desired resource. The network map aggregates
the service provider network into provider defined identifiers (PID)
and the cost map provides a pair-wise link cost between each PID.
Clearly, a NSP has an authoritative view of its network and is able to
provide an ALTO server that distributes such maps. However, ALTO also
envisions third-parties as being able to provide such maps. In this
paper, we demonstrate how a third-party ALTO server can provide maps
by mining public information. Specifically, we build our maps from the
United States Federal Communications Commission public broadband data
set, which contains an expressive (multi-tier wireline broadband
measurements) and rich (measurements for specific application uses)
dataset. In all, we examined over 1 billion records spread over 90
GBytes as part of our analysis. We borrow concepts from financial
engineering and social network analysis to show how network topology
and cost maps can be created, and furthermore, how peer-to-peer systems
can insulate themselves from going dark by choosing supernodes
effectively from mining historical data.

Until the paper is available in the IEEE archives, email me if you'd
like a copy.
(Continue reading)

Y. Richard Yang | 5 Sep 21:44 2014
Picon

ALTO Protocol (RFC7285) published!

Dear ALTOnians,

The base ALTO protocol has been published !! 


The link to the published RFC: https://www.rfc-editor.org/rfc/rfc7285.txt

RFC7285 is the hard work of a lot of people, including the authors, the WG chairs (Enrico, Vijay), the ADs (Spencer, Martin), the RFC editor (Megan), the IESG, multiple people that deserve a lot more recognition that currently (Jan, Ben, Michael, Sabine, Young, Greg, Haibin, ...)

The editors and authors learned much and will apply the learned when working on the extensions (e.g., more streamlined).

Cheers,

Richard
<div><div dir="ltr">Dear ALTOnians,<div><br></div>
<div>The base ALTO protocol has been published !!&nbsp;</div>
<div><br></div>
<div>The RFC announcement link:&nbsp;<a href="http://www.rfc-editor.org/pipermail/rfc-dist/2014-September/004110.html">http://www.rfc-editor.org/pipermail/rfc-dist/2014-September/004110.html</a>
</div>
<div><br></div>
<div>The link to the published RFC:&nbsp;<a href="https://www.rfc-editor.org/rfc/rfc7285.txt">https://www.rfc-editor.org/rfc/rfc7285.txt</a>
</div>
<div><br></div>
<div>RFC7285 is the hard work of a lot of people, including the authors, the WG chairs (Enrico, Vijay), the ADs (Spencer, Martin), the RFC editor (Megan), the IESG, multiple people that deserve a lot more recognition that currently (Jan, Ben, Michael, Sabine, Young, Greg, Haibin, ...)<br><div><br></div>
</div>
<div>The editors and authors learned much and will apply the learned when working on the extensions (e.g., more streamlined).</div>
<div><br></div>
<div>Cheers,</div>
<div><br></div>
<div>Richard</div>
</div></div>
rfc-editor | 5 Sep 21:28 2014

RFC 7285 on Application-Layer Traffic Optimization (ALTO) Protocol

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7285

        Title:      Application-Layer Traffic Optimization (ALTO) Protocol 
        Author:     R. Alimi, Ed.,
                    R. Penno, Ed.,
                    Y. Yang, Ed.,
                    S. Kiesel, 
                    S. Previdi,
                    W. Roome, 
                    S. Shalunov, 
                    R. Woundy
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2014
        Mailbox:    ralimi <at> google.com, 
                    repenno <at> cisco.com, 
                    yry <at> cs.yale.edu,  
                    ietf-alto <at> skiesel.de, 
                    sprevidi <at> cisco.com,  
                    w.roome <at> alcatel-lucent.com, 
                    shalunov <at> shlang.com,  
                    Richard_Woundy <at> cable.comcast.com
        Pages:      91
        Characters: 194499
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-alto-protocol-27.txt

        URL:        https://www.rfc-editor.org/rfc/rfc7285.txt

Applications using the Internet already have access to some topology
information of Internet Service Provider (ISP) networks.  For
example, views to Internet routing tables at Looking Glass servers
are available and can be practically downloaded to many network
application clients.  What is missing is knowledge of the underlying
network topologies from the point of view of ISPs.  In other words,
what an ISP prefers in terms of traffic optimization -- and a way to
distribute it.

The Application-Layer Traffic Optimization (ALTO) services defined in
this document provide network information (e.g., basic network
location structure and preferences of network paths) with the goal of
modifying network resource consumption patterns while maintaining or
improving application performance.  The basic information of ALTO is
based on abstract maps of a network.  These maps provide a simplified
view, yet enough information about a network for applications to
effectively utilize them.  Additional services are built on top of
the maps.

This document describes a protocol implementing the ALTO services.
Although the ALTO services would primarily be provided by ISPs, other
entities, such as content service providers, could also provide ALTO
services.  Applications that could use the ALTO services are those
that have a choice to which end points to connect.  Examples of such
applications are peer-to-peer (P2P) and content delivery networks.

This document is a product of the Application-Layer Traffic Optimization Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

Wendy Roome | 28 Aug 19:27 2014

Proposed extension: Advisory information to IRD resources

This list has been quiet for a while, so I thought I'd shake it up.

While an IRD does define an ALTO server's resources, it leaves a lot of
questions unanswered. For example, before retrieving a cost map, a client
might like to know whether the map has 200 costs or 2,000,000 costs. Or
whether a network map has 50 PIDs and 200 CIDRs, or 2,000 PIDs and 200,000
CIDRs.

So what do you think of adding an "advice" field to IRD entries? Like
"capabilities", it would be a JSON object with attributes specific to the
resource type. The values would be approximate guidelines, not exact
values. For example, sizes should be ranges, with the implication that no
matter how much the map changes, it SHOULD stay within that range. E.g.,
rather than saying that a network map has exactly 78 PIDs and 363 PIDs,
the advice might be that the map has between 50 and 100 PIDs, and 250 to
500 CIDRs.

For network maps, another advisory would be the set of endpoint addresses
for which this map is authoritative (for want of a better word). While it
would be wonderful if an ALTO server had detailed PIDs for every endpoint
in the network, and had costs to and from every PID, it is very unlikely
that will happen. Instead, most ALTO servers will be run by ISPs. The
server will have detailed PIDs for the ISP's customers, and will have
source and destination costs between its customer's PIDs and the rest of
the network. But as you get farther from the ISP's coverage area, the PIDs
get less detailed, and the cost maps will be unlikely to have costs
between those PIDs.

If a P2P tracker knows about (say) a dozen different different ALTO
servers, the tracker can use their "authoritative sets" to select the
appropriate ALTO server. E.g., if a peer at address X asks for a set of
peers, the tracker would use the ALTO server whose set covers X to
evaluate the costs from the other peers to X. Similarly, if an ALTO server
offers several network maps, a client could use this to distinguish
between those maps.

Before I develop this as a formal proposal, I have two questions for y'all:

1. Do you think this extension is useful?

2. How would this fit into the update charter? My take is that it could
come under the heading of "server discovery." True, it doesn't allow a
client discover a server from scratch. But it does allow a client to
select the appropriate server from a set of twisty little ALTO servers,
all alike.

      - Wendy Roome

Y. Richard Yang | 8 Aug 06:04 2014
Picon

Request for comments on two changes for RFC7285-to-be

Dear ALTOnians,

The authors of the ALTO Protocol are finalizing the final version, to be published as RFC 7285. We seek your comments/feedback on two non-editorial changes.


A summary of the key changes is listed below:
E1: the change from MUST to MAY in Section 7.1.1
E2: update from "misses" to "omits" in Section 8.5.2
E3: the addition of MUST and text addition to Section 10.8.1
E4: update from "both" to "either...or" in Section 11.2.3.6
E5: text update to Section 11.4.1.3, paragraph 1
E6: text deletion from Section 11.4.1.4. The deleted text is "In particular, the information resource closure MUST provide the look up of pid for every ALTO network map defined."

The AD has approved all changes except E1 and E6, which are non-editorial.

There are two reasons for E1 and E6:
 
(1) Make the document consistent. Specifically, the first paragraph of Section 11.4.1 states that "An endpoint property resource provides information about properties for individual endpoints.  It MAY be provided by an ALTO server." Without E1 and E6, the document will imply that at least one endpoint properties service (i.e., one to provide pid) must be provided. Hence, one way to achieve consistency is to change the MAY in the first para of 11.4.1 to be  MUST.

(2) However, some authors feel that we should not enforce too strong a requirement to make deployment harder. Hence, instead of changing the aforementioned MAY to MUST, these authors feel that it is better to make the pid endpoint property optional. Hence, we make the two changes of E1 and E6.

Your comments and feedback will be greatly appreciated. We will wait for one week for any feedback.

Thanks a lot.

Richard
<div><div dir="ltr">Dear ALTOnians,
<div><br></div>
<div>The authors of the ALTO Protocol are finalizing the final version, to be published as RFC 7285. We seek your comments/feedback on two non-editorial changes.</div>
<div><br></div>
<div>
<div>But first, the text, XML, and comprehensive diff files are available at:</div>
<div><a href="http://www.rfc-editor.org/authors/rfc7285.txt">http://www.rfc-editor.org/authors/rfc7285.txt</a></div>
<div><a href="http://www.rfc-editor.org/authors/rfc7285.xml">http://www.rfc-editor.org/authors/rfc7285.xml</a></div>
<div><a href="http://www.rfc-editor.org/authors/rfc7285-diff.html">http://www.rfc-editor.org/authors/rfc7285-diff.html</a></div>
</div>
<div><br></div>
<div>A summary of the key changes is listed below:</div>
<div>
<div>E1: the change from MUST to MAY in Section 7.1.1</div>
<div>E2: update from "misses" to "omits" in Section 8.5.2</div>
<div>E3: the addition of MUST and text addition to Section 10.8.1</div>
<div>
E4: update from "both" to "either...or" in Section 11.2.3.6</div>
<div>E5: text update to Section 11.4.1.3, paragraph 1</div>
<div>E6: text deletion from Section 11.4.1.4. The deleted text is "In particular, the information resource closure MUST provide the look up of pid for every ALTO network map defined."</div>
</div>
<div><br></div>
<div>The AD has approved all changes except E1 and E6, which are non-editorial.</div>
<div><br></div>
<div>There are two reasons for E1 and E6:</div>
<div>&nbsp;</div>
<div>(1) Make the document consistent. Specifically, the first paragraph of Section 11.4.1 states that "An endpoint property resource provides information about properties for individual endpoints. &nbsp;It MAY be provided by an ALTO server." Without E1 and E6, the document will imply that at least one endpoint properties service (i.e., one to provide pid) must be provided. Hence, one way to achieve consistency is to change the MAY in the first para of 11.4.1 to be &nbsp;MUST.</div>
<div><br></div>
<div>(2) However, some authors feel that we should not enforce too strong a requirement to make deployment harder. Hence, instead of changing the aforementioned MAY to MUST, these authors feel that it is better to make the pid endpoint property optional. Hence, we make the two changes of E1 and E6.</div>
<div><br></div>
<div>Your comments and feedback will be greatly appreciated. We will wait for one week for any feedback.</div>
<div><br></div>
<div>Thanks a lot.</div>
<div><br></div>
<div>Richard</div>
</div></div>
Y. Richard Yang | 31 Jul 21:54 2014
Picon

A YANG model of ALTO base protocol?

Hi all,

A "fashion" in IETF lately appears to be using YANG to express data models. A formal mechanism to specify design precisely always helps. The target of ALTO data is application programmers, and hence first YANG and then JSON may not be necessary. But given the "fashion", I feel that it may help if we give a YANG model of the existing spec (i.e., a kind of reverse-engineering). The ALTO protocol already specifies data types precisely, using a C-like struct we invented. Hence, I do not anticipate a lot of work. But it can be a good item that the WG finishes.

Any comments?

Thanks.
Richard
<div><div dir="ltr">Hi all,<div>
<div><br></div>
<div>A "fashion" in IETF lately appears to be using YANG to express data models. A formal mechanism to specify design precisely always helps. The target of ALTO data is application programmers, and hence first YANG and then JSON may not be necessary. But given the "fashion", I feel that it may help if we give a YANG model of the existing spec (i.e., a kind of reverse-engineering). The ALTO protocol already specifies data types precisely, using a C-like struct we invented. Hence, I do not anticipate a lot of work. But it can be a good item that the WG finishes.</div>
<div><br></div>
<div>Any comments?</div>
<div><br></div>
<div>Thanks.</div>
<div>Richard</div>
</div>
</div></div>
Adrian Farrel | 25 Jul 20:02 2014
Picon

Call for review draft-farrkingel-pce-abno-architecture

Hi,

The authors of draft-farrkingel-pce-abno-architecture are in the process of
requesting AD-sponsored publication of draft-farrkingel-pce-abno-architecture

This I-D is a bit of an architecture and a bit an applicability statement. It
spans quite a lot of IETF technology including ALTO.

The last call will obviously pop out sometime, but it would be nice to have
review comments before then.

Thanks,
Adrian

Enrico Marocco | 22 Jul 20:38 2014
Picon

Meeting materials

Hi all,

in order to accommodate remote participation for the Friday meeting, the 
chairs are requested to upload meeting materials by Thursday night.

If you have been assigned a slot on the agenda, please send your slides 
and the name of the presenter by Thrusday, 6pm.

Enrico

Attachment (smime.p7s): application/pkcs7-signature, 5795 bytes
Hi all,

in order to accommodate remote participation for the Friday meeting, the 
chairs are requested to upload meeting materials by Thursday night.

If you have been assigned a slot on the agenda, please send your slides 
and the name of the presenter by Thrusday, 6pm.

Enrico

Qin Wu | 20 Jul 04:18 2014

Re: [ALTO] Statistics operators for TE metrics

 

发件人: yang.r.yang <at> gmail.com [mailto:yang.r.yang <at> gmail.com] 代表 Y. Richard Yang
发送时间: 2014719 8:12
收件人: Leeyoung
抄送: Qin Wu; Sabine Randriamasy; Dhruv Dhody; Qin Wu
主题: Re: TE metrics slides

 

Hi Young,

 

Good question. The intention of the question is whether to use ALTO to expose various statistics of the metrics, not limited to only mean/avg. Increasingly more networks care about higher percentile than standard mean/avg. Hence, an extensible design should allow such easy extensibility. What do you think?

 

[Qin]: I think not all TE metrics needs to use percentile, e.g., delay, I think still stick to use mean and delayjitter will still stick to use variance.

But for bandwidth related metrics, I think maximum bandwidth, maximum reservable bandwidth,unreserved  bandwith can keep on using bytes per sec as measurement unit,

But residue bandwidth, available bandwidth and utilized bandwidth can use percentile.

 

Richard

 

On Fri, Jul 18, 2014 at 11:39 AM, Leeyoung <leeyoung <at> huawei.com> wrote:

Hi Qin and Richard,

 

Thanks for putting a good quality slide together. I think it is good with this version.

 

On one question:

      Do we allow more flexible statistics operators (e.g., mean, avg, x-percentile, variance)

       In current draft, delay and delay jitter are both on delay, with one reflect mean and the other variance

 

Do you mean, “Do we allow more flexible statistics for/from/?? operator?” Not sure what you mean. If the network operators are the ones that provide these stats to ALTO application, then we may say, “Do we need more flexible statistics for some applications?” for instance. May be I am missing something here.

 

Flexible stat such as percentile and variance are all good, yet there might be scaling issues and usability of such data and the networks that provide such data do not normally have in their TED  except jitter variance. This could imply an overhead for networks.

 

Thanks,

Young

 

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<div>
<p class="MsoNormal"><span>&#21457;&#20214;&#20154;<span lang="EN-US">:</span></span><span lang="EN-US"> yang.r.yang <at> gmail.com [mailto:yang.r.yang <at> gmail.com]
</span><span>&#20195;&#34920; </span><span lang="EN-US">Y. Richard Yang<br></span><span>&#21457;&#36865;&#26102;&#38388;<span lang="EN-US">:</span></span><span lang="EN-US"> 2014</span><span>&#24180;<span lang="EN-US">7</span>&#26376;<span lang="EN-US">19</span>&#26085;<span lang="EN-US"> 8:12<br></span>&#25910;&#20214;&#20154;<span lang="EN-US">:</span><span lang="EN-US"> Leeyoung<br></span>&#25220;&#36865;<span lang="EN-US">:</span><span lang="EN-US"> Qin Wu; Sabine Randriamasy; Dhruv Dhody; Qin Wu<br></span>&#20027;&#39064;<span lang="EN-US">:</span><span lang="EN-US"> Re: TE metrics slides<p></p></span></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi Young,<p></p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Good question. The intention of the question is whether to use ALTO to expose various statistics of the metrics, not limited to only mean/avg. Increasingly more networks care about higher percentile than standard mean/avg.
 Hence, an extensible design should allow such easy extensibility. What do you think?<p></p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">[Qin]: I think not all TE metrics needs to use percentile, e.g., delay, I think still stick to use mean and delayjitter will still stick to use
 variance.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">But for bandwidth related metrics, I think maximum bandwidth, maximum reservable bandwidth,unreserved &nbsp;bandwith can keep on using bytes per sec
 as measurement unit,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">But residue bandwidth, available bandwidth and utilized bandwidth can use percentile.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Richard<p></p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Fri, Jul 18, 2014 at 11:39 AM, Leeyoung &lt;<a href="mailto:leeyoung <at> huawei.com" target="_blank">leeyoung <at> huawei.com</a>&gt; wrote:<p></p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US">Hi Qin and Richard,</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks for putting a good quality slide together. I think it is good with this version.
</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">On one question:
</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal">
<span lang="EN-US">&ndash;</span><span lang="EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang="EN-US">Do we allow more flexible statistics operators (e.g., mean, avg, x-percentile, variance)</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal">
<span lang="EN-US">&bull;</span><span lang="EN-US">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang="EN-US">In current draft, delay and delay jitter are both on delay, with one reflect mean and the other variance</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Do you mean, &ldquo;Do we allow more flexible statistics
for/from/?? operator?&rdquo; Not sure what you mean. If the network operators are the ones that provide these stats to ALTO application, then we may say, &ldquo;Do we need more flexible statistics for some applications?&rdquo; for instance. May be I am missing something
 here. </span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Flexible stat such as percentile and variance are all good, yet there might be scaling
 issues and usability of such data and the networks that provide such data do not normally have in their TED &nbsp;except jitter variance. This could imply an overhead for networks.
</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks,</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Young</span><span lang="EN-US"><p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">&nbsp;</span><span lang="EN-US"><p></p></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
Qin Wu | 18 Jul 14:17 2014

Measurement timing for cost metric

Hi,

We talked about measurement timing for cost metric for several times.

In the current draft, we use fixed measurement interval for each cost metrics.

Is it too much restrictive? Shall we allow multiple fixed Measurement Timing specification

That will be conveyed in IRD to relax such restriction?

Comments or opinions?

 

Regards!

-Qin

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">We talked about measurement timing for cost metric for several times.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">In the current draft, we use fixed measurement interval for each cost metrics.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Is it too much restrictive? Shall we allow multiple fixed Measurement Timing specification<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">That will be conveyed in IRD to relax such restriction?<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Comments or opinions?<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Regards!<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">-Qin<p></p></span></p>
</div>
</div>
Qin Wu | 18 Jul 14:13 2014

statistics operators for ALTO cost metrics

Hi,

Motivated by RFC3630 and draft-ietf-isis-te-metric-extensions, we define 11 alto cost metrics,

The value of these alto cost metrics are high aggregated value, we may have several statistics operators, e.g.,

Mean, variance, avg, percentile).

In the current draft, delay and delay jitter are both on delay, we use mean

For delay and use variance for delayjitter.

It is not clear these statistics operator are appropriate for them? E.g., should we use percentile for bandwidth related cost metric?

Any opinion?

 

Regards!

-Qin

<div>
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Motivated by RFC3630 and draft-ietf-isis-te-metric-extensions, we define 11 alto cost metrics,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">The value of these alto cost metrics are high aggregated value, we may have several statistics operators, e.g.,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Mean, variance, avg, percentile).<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">In the current draft, delay and delay jitter are both on delay, we use mean<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">For delay and use variance for delayjitter.
<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">It is not clear these statistics operator are appropriate for them? E.g., should we use percentile for bandwidth related cost metric?<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">Any opinion?<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">Regards!<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">-Qin<p></p></span></p>
</div>
</div>

Gmane