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

[Qin Wu]

A minor update to v(-02) to fix some nits.
http://tools.ietf.org/html/draft-wu-alto-te-metrics-03

Regards!
-Qin
-邮件原件-
发件人: alto [mailto:alto-boun...@ietf.org] 代表 Qin Wu
发送时间: 2014年6月28日 11:20
收件人: alto@ietf.org
主题: Re: [alto] I-D Action: draft-wu-alto-te-metrics-02.txt

Hi, all:
Here is the update to draft-wu-alto-te-metrics
http://tools.ietf.org/html/draft-wu-alto-te-metrics-02
The diff is:
http://www.ietf.org/rfcdiff?url2=draft-wu-alto-te-metrics-02
The main changes are
1. Remove the Cost Mode part as these metrics are intended to be used in 
various cost modes.
2. Move Collection method part to new section(i.e., section 2) since they are 
common part for these metrics.
3. Other editorial changes, e.g., remove duplicated part in each new defined 
metrics.

There is one remaining issue in this draft, i.e., do we need to specify the 
measurement interval for each metrics In details in this draft.  

In the current draft, we assume using a fixed, small measurement interval.
However this may be not enough for ALTO setting. we may need to support more 
complicated use case,e.g., bandwidth calendaring.

In the last IETF meeting, we gave an example to show how bandwidth calendaring 
look like.
We may need to specify the more semantics for calendaring attribute, e.g., 
measurement period.
We may need to extend bandwidth calendaring to other metrics, e.g., delay.

After a few discussion, authors feels we may need to split calendaring part 
from this draft and put it into the separate draft.
Let us know what do you think about this?

Regards!
-Qin
 
Calendaring and multicost metrics should be defined in a separate document. 
Hence, we have a more modular approach. What do you think?
- We, as as the metrics are intended to be used in various cost modes. 
- It looks to me that the Collection Method part is common. Hence, we can move 
them to be common.
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2014年6月28日 10:57
收件人: i-d-annou...@ietf.org
主题: I-D Action: draft-wu-alto-te-metrics-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : ALTO Traffic Engineering Cost Metrics
Authors : Qin Wu
  Y. Richard Yang
  Young Lee
  Dhruv Dhody
  Sabine Randriamasy
Filename: draft-wu-alto-te-metrics-02.txt
Pages   : 26
Date: 2014-06-27

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 delay 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 eleven 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 (TE).  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-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-wu-alto-te-metrics-02


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
i-d-annou...@ietf.org
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
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] Potential privacy issue in draft-deng-alto-p2p-ext-01?

[Songhaibin (A)]

Hi Reinaldo,

Thank you and I think you raised a very good question. I totally agree that 
available bandwidth is more useful than provisioned bandwidth. But available 
bandwidth is rather dynamic, and it is very hard to measure it and provide the 
real-time status to ALTO clients.

With providing provisioned bandwidth, it can be seen with a high probability a 
client can select a "better" peer. It is better than random IMO. But if there 
is an easy method to rank the available bandwidth of a peer list, I will be 
very interested.

BR,
-Haibin

> -Original Message-
> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Reinaldo Penno
> (repenno)
> Sent: Saturday, June 28, 2014 1:33 AM
> To: Vijay K. Gurbani; alto@ietf.org
> Subject: Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
> 
> Another point is how¹s the provisioned access bandwidth really help decide
> which peers are better. Today most P2P software allow caps to be put for
> upload/download and people use it. Some come with a default based on the %
> of the detect access speed. So, saying a user has 1Gb/s does not really mean
> you will get better performance when connecting to him(er). I mean, it would
> more inline with better than random to get the actual bandwidth allowed.
> 
> 
> On 6/27/14, 10:26 AM, "Vijay K. Gurbani"  wrote:
> 
> >[Still as individual.]
> >
> >On 06/26/2014 05:10 AM, Songhaibin (A) wrote:
> >> Sebastian gave an idea that we can use relative numbers to indicate
> >> the endpoint's provisioned bandwidth instead of access type, which is
> >> similar to what we have used to indicate the cost in the alto
> >> protocol.
> >
> >The difference, of course, being that the ISP in some manner consented
> >to having a normalized value of cost to be distributed in order to
> >allow for better than random selections to improve network performance.
> >
> >In the case under discussion, the issue is does the subscriber consent
> >to having their provisioned bandwidth be part of ALTO calculations?
> >
> >Remember, if the WG decides to go ahead and use provisioned bandwidth
> >anyway, it could always do so.  But then we'd better be prepared to
> >deal with the eventuality on when (and if) the IESG challenges us on
> >this privacy leak.  If that happens, we'd better have a good response.
> >
> >Perhaps a midway could be to see if we can use the provisioned
> >bandwidth for a set of (anonymous) subscribers instead of singleton
> subscribers.
> >That way, the larger herd provides some modicum of anonymity to an
> >individual subscriber who is part of the herd.
> >
> >Cheers,
> >
> >- vijay
> >--
> >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> >Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
> >Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
> >
> >___
> >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

Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?

[Songhaibin (A)]

Hi Vijay,

Thanks again,

> -Original Message-
> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Vijay K. Gurbani
> Sent: Saturday, June 28, 2014 1:27 AM
> To: alto@ietf.org
> Subject: Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
> 
> [Still as individual.]
> 
> On 06/26/2014 05:10 AM, Songhaibin (A) wrote:
> > Sebastian gave an idea that we can use relative numbers to indicate
> > the endpoint's provisioned bandwidth instead of access type, which is
> > similar to what we have used to indicate the cost in the alto
> > protocol.
> 
> The difference, of course, being that the ISP in some manner consented to
> having a normalized value of cost to be distributed in order to allow for 
> better
> than random selections to improve network performance.
> 
> In the case under discussion, the issue is does the subscriber consent to 
> having
> their provisioned bandwidth be part of ALTO calculations?
> 
> Remember, if the WG decides to go ahead and use provisioned bandwidth
> anyway, it could always do so.  But then we'd better be prepared to deal with
> the eventuality on when (and if) the IESG challenges us on this privacy leak. 
>  If
> that happens, we'd better have a good response.
> 
> Perhaps a midway could be to see if we can use the provisioned bandwidth for a
> set of (anonymous) subscribers instead of singleton subscribers.
> That way, the larger herd provides some modicum of anonymity to an individual
> subscriber who is part of the herd.

So just ranking a list of endpoints from the perspective of provisioned 
bandwidth will alleviate the privacy issue. I think it is possible to do it in 
this way.

BR,
-Haibin

> Cheers,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
> 
> ___
> 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] I-D Action: draft-wu-alto-te-metrics-02.txt

[Qin Wu]

发件人: yang.r.y...@gmail.com [mailto:yang.r.y...@gmail.com] 代表 Y. Richard Yang
发送时间: 2014年6月28日 11:47
收件人: Qin Wu
抄送: alto@ietf.org; RANDRIAMASY, SABINE (SABINE)
主题: Re: I-D Action: draft-wu-alto-te-metrics-02.txt

Thanks for posting the new version. Let me add my view on the issue when 
defining the metrics. Please see below.

On Fri, Jun 27, 2014 at 11:20 PM, Qin Wu 
mailto:bill...@huawei.com>> wrote:
Hi, all:
Here is the update to draft-wu-alto-te-metrics
http://tools.ietf.org/html/draft-wu-alto-te-metrics-02
The diff is:
http://www.ietf.org/rfcdiff?url2=draft-wu-alto-te-metrics-02
The main changes are
1. Remove the Cost Mode part as these metrics are intended to be used in 
various cost modes.
2. Move Collection method part to new section(i.e., section 2) since they are 
common part for these metrics.
3. Other editorial changes, e.g., remove duplicated part in each new defined 
metrics.

There is one remaining issue in this draft, i.e., do we need to specify the 
measurement interval for each metrics
In details in this draft.

In the current draft, we assume using a fixed, small measurement interval.
However this may be not enough for ALTO setting. we may need to support more 
complicated use case,e.g., bandwidth calendaring.

I like it that you raise the issue on defining the semantics of revealed 
metrics. For example, when an ALTO sever says that routingcost = 10 (or delay = 
10 ms using a new metric defined in the document), what does it mean?  The 
charter of ALTO is that it does not deal with round-trip level dynamic 
information. Hence, one should interpret the number as a longer-time scale 
number. But how long? Does it reflect diurnal pattern? Does it mean that the 
value is 10 in the last 15 sec, 30 sec, 1 min, 1 hour, 1 day, 1 week, etc.

[Qin]:  I realized we should distinguish measure interval from how often the 
value is reported from the server to the client
Usually the value is measured at fixed measurement interval. When the server 
receive these values, they can do aggregation and report in the array of 
several measured value or report the latest value.

Given the increasing interest in handling calendaring (e.g., there is a paper 
in the coming SIGCOMM on WAN Calendaring), I feel that it is time to be 
slightly more explicit. Long-term is not equivalent to be fuzzy.

Specifically, I feel that a reasonable metric should include the following:

- measurement start time, measurement finish time, the statistics operator 
(e.g., avg, vs mean, vs x-percentile) or

- measurement window (assuming finish time is around the query time) and the 
statistics operator.

[Qin]: These are very closed to what we proposed in last London meeting when we 
presented this draft.
What is different, the measurement period is replaced with measurement window 
and you add a lot of statistics operators which looks good to me.

Declaring such info can be tricky, as it may need to expand the grammar of the 
IRD capabilities, but it adds clarify.

[Qin]: Agree.
Make sense?

[Qin]: Yes. So we address this issue in the separate calendaring document. Do 
we need to add reference to calendaring document in this draft?

Richard

In the last IETF meeting, we gave an example to show how bandwidth calendaring 
look like.
We may need to specify the more semantics for calendaring attribute, e.g., 
measurement period.
We may need to extend bandwidth calendaring to other metrics, e.g., delay.

After a few discussion, authors feels we may need to split calendaring part 
from this draft and put it into the separate draft.
Let us know what do you think about this?

Regards!
-Qin

Calendaring and multicost metrics should be defined in a separate document. 
Hence, we have a more modular approach. What do you think?
- We, as as the metrics are intended to be used in various cost modes.
- It looks to me that the Collection Method part is common. Hence, we can move 
them to be common.
-邮件原件-
发件人: I-D-Announce 
[mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2014年6月28日 10:57
收件人: i-d-annou...@ietf.org
主题: I-D Action: draft-wu-alto-te-metrics-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : ALTO Traffic Engineering Cost Metrics
Authors : Qin Wu
  Y. Richard Yang
  Young Lee
  Dhruv Dhody
  Sabine Randriamasy
Filename: draft-wu-alto-te-metrics-02.txt
Pages   : 26
Date: 2014-06-27

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

Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?

[Songhaibin (A)]

Hi Vijay,

Thank you very much for your comment.

> -Original Message-
> From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Vijay K. Gurbani
> Sent: Saturday, June 28, 2014 1:16 AM
> To: Scharf, Michael (Michael); IETF ALTO
> Subject: Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
> 
> On 06/26/2014 04:58 AM, Scharf, Michael (Michael) wrote:
> > Haibin asked me to send the following comment from a private
> > discussion also to the list:
> >
> > Section 3.3 of draft-deng-alto-p2p-ext-01 suggest a new Endpoint
> > Property Type "network_access" for P2P peer selection. As far as I
> > recall, this type of ALTO guidance was discussed in the past quite a
> > bit, and there may have been privacy concerns. For instance,
> > draft-ietf-alto-deployments-09 Section 3.2.4. includes the following
> > statement:
> >
> > o  Performance metrics that raise privacy concerns.  For instance, it
> > has been questioned whether an ALTO service could publicly expose the
> > provisioned access bandwidth, e.g. of cable / DSL customers, because
> > this could enables identification of "premium" customers.
> >
> > That text was already in draft-ietf-alto-deployments before I started
> > to edit this document.
> >
> > For P2P use cases, I wonder whether that concern might (still) apply
> > to endpoint properties such as DSL vs. FTTH as currently suggested
> > draft-deng-alto-p2p-ext-01.
> 
> [As individual, of course.]
> 
> I suspect the type of network access (DSL, cable, FTTH, satellite) is probably
> okay.  Commercial companies often publicly tout the deployment of certain
> access technologies in neighbourhoods.
> 
Ok.

> However, I also suspect that the privacy concerns on *provisioned* access
> bandwidth are still intact since they will tend to point to subscribers that 
> are
> outliers.

I'm not sure I understand this sentence due to my poor English. By "outlier" do 
you mean some exceptional/abnormal provisioned bandwidth value bound to an 
endpoint property? If the endpoints with higher provisioned access bandwidth 
would be pointed more often than other endpoints, you imply the privacy concern 
is: those endpoints do not want to be recognized?

BR,
-Haibin

> Thanks,
> 
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
> Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
> 
> ___
> 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] I-D Action: draft-wu-alto-te-metrics-02.txt

[Y. Richard Yang]

Thanks for posting the new version. Let me add my view on the issue when
defining the metrics. Please see below.

On Fri, Jun 27, 2014 at 11:20 PM, Qin Wu  wrote:

> Hi, all:
> Here is the update to draft-wu-alto-te-metrics
> http://tools.ietf.org/html/draft-wu-alto-te-metrics-02
> The diff is:
> http://www.ietf.org/rfcdiff?url2=draft-wu-alto-te-metrics-02
> The main changes are
> 1. Remove the Cost Mode part as these metrics are intended to be used in
> various cost modes.
> 2. Move Collection method part to new section(i.e., section 2) since they
> are common part for these metrics.
> 3. Other editorial changes, e.g., remove duplicated part in each new
> defined metrics.
>
> There is one remaining issue in this draft, i.e., do we need to specify
> the measurement interval for each metrics
> In details in this draft.
>
> In the current draft, we assume using a fixed, small measurement interval.

However this may be not enough for ALTO setting. we may need to support
> more complicated use case,e.g., bandwidth calendaring.
>
>
I like it that you raise the issue on defining the semantics of revealed
metrics. For example, when an ALTO sever says that routingcost = 10 (or
delay = 10 ms using a new metric defined in the document), what does it
mean?  The charter of ALTO is that it does not deal with round-trip level
dynamic information. Hence, one should interpret the number as a
longer-time scale number. But how long? Does it reflect diurnal pattern?
Does it mean that the value is 10 in the last 15 sec, 30 sec, 1 min, 1
hour, 1 day, 1 week, etc.

Given the increasing interest in handling calendaring (e.g., there is a
paper in the coming SIGCOMM on WAN Calendaring), I feel that it is time to
be slightly more explicit. Long-term is not equivalent to be fuzzy.

Specifically, I feel that a reasonable metric should include the following:

- measurement start time, measurement finish time, the statistics operator
(e.g., avg, vs mean, vs x-percentile) or

- measurement window (assuming finish time is around the query time) and
the statistics operator.

Declaring such info can be tricky, as it may need to expand the grammar of
the IRD capabilities, but it adds clarify.

Make sense?

Richard


> In the last IETF meeting, we gave an example to show how bandwidth
> calendaring look like.
> We may need to specify the more semantics for calendaring attribute, e.g.,
> measurement period.
> We may need to extend bandwidth calendaring to other metrics, e.g., delay.
>
> After a few discussion, authors feels we may need to split calendaring
> part from this draft and put it into the separate draft.
> Let us know what do you think about this?
>
> Regards!
> -Qin
>
> Calendaring and multicost metrics should be defined in a separate
> document. Hence, we have a more modular approach. What do you think?
> - We, as as the metrics are intended to be used in various cost modes.
> - It looks to me that the Collection Method part is common. Hence, we can
> move them to be common.
> -邮件原件-
> 发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表
> internet-dra...@ietf.org
> 发送时间: 2014年6月28日 10:57
> 收件人: i-d-annou...@ietf.org
> 主题: I-D Action: draft-wu-alto-te-metrics-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> Title   : ALTO Traffic Engineering Cost Metrics
> Authors : Qin Wu
>   Y. Richard Yang
>   Young Lee
>   Dhruv Dhody
>   Sabine Randriamasy
> Filename: draft-wu-alto-te-metrics-02.txt
> Pages   : 26
> Date: 2014-06-27
>
> 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 delay 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 eleven 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 (TE).  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-02
>
> A diff from the previous version is 

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

[Qin Wu]

Hi, all:
Here is the update to draft-wu-alto-te-metrics
http://tools.ietf.org/html/draft-wu-alto-te-metrics-02
The diff is:
http://www.ietf.org/rfcdiff?url2=draft-wu-alto-te-metrics-02
The main changes are
1. Remove the Cost Mode part as these metrics are intended to be used in 
various cost modes.
2. Move Collection method part to new section(i.e., section 2) since they are 
common part for these metrics.
3. Other editorial changes, e.g., remove duplicated part in each new defined 
metrics.

There is one remaining issue in this draft, i.e., do we need to specify the 
measurement interval for each metrics
In details in this draft.  

In the current draft, we assume using a fixed, small measurement interval.
However this may be not enough for ALTO setting. we may need to support more 
complicated use case,e.g., bandwidth calendaring.

In the last IETF meeting, we gave an example to show how bandwidth calendaring 
look like.
We may need to specify the more semantics for calendaring attribute, e.g., 
measurement period.
We may need to extend bandwidth calendaring to other metrics, e.g., delay.

After a few discussion, authors feels we may need to split calendaring part 
from this draft and put it into the separate draft.
Let us know what do you think about this?

Regards!
-Qin
 
Calendaring and multicost metrics should be defined in a separate document. 
Hence, we have a more modular approach. What do you think?
- We, as as the metrics are intended to be used in various cost modes. 
- It looks to me that the Collection Method part is common. Hence, we can move 
them to be common.
-邮件原件-
发件人: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] 代表 
internet-dra...@ietf.org
发送时间: 2014年6月28日 10:57
收件人: i-d-annou...@ietf.org
主题: I-D Action: draft-wu-alto-te-metrics-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : ALTO Traffic Engineering Cost Metrics
Authors : Qin Wu
  Y. Richard Yang
  Young Lee
  Dhruv Dhody
  Sabine Randriamasy
Filename: draft-wu-alto-te-metrics-02.txt
Pages   : 26
Date: 2014-06-27

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 delay 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 eleven 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 (TE).  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-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-wu-alto-te-metrics-02


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
i-d-annou...@ietf.org
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
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] FW: New Version Notification for draft-deng-alto-p2p-ext-02.txt

[Songhaibin (A)]

Hi Richard,

Thank you very much for your comments, please see inline.

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang
Sent: Friday, June 27, 2014 11:46 PM
To: 邓灵莉/Lingli Deng
Cc: IETF ALTO
Subject: Re: [alto] FW: New Version Notification for 
draft-deng-alto-p2p-ext-02.txt

Hi Lingli, Sebastian, Haibin,

Interesting doc!  I am wondering the possibility of you adding an overview 
section to discuss the potential types of end point properties and your design 
guidelines so that we have a better understanding of the design:

- For example, I do not have a feeling that the properties that the current 
draft defined are relatively complete. What is the potential set of properties 
and why you choose the ones?

[Haibin] This is a very interesting question and should be seriously 
considered. We chose the ones in the draft due to people usually consider them 
for peer selection, and they were discussed during the early stage of ALTO 
working group.

- One can convey the properties in multiple ways. For example, the current 
draft defines p2p_caching as a boolean. Another design possibility is to define 
a generic type with values including "p2p_cache", "super_peer", ...

[Haibin] Yes. We need to choose one representation type. If several properties 
can be classified into one class, I agree one generic type name for the class 
(and then define the values) would be better. 

As another example we consider volume related property. The current draft 
defines a boolean. Another alternative is to use an numeric value of the exact 
cap.

[Haibin] I'm not sure on this one. A user with 1G bytes and another user with 
100M bytes mobile traffic quota might  have the same strong will to not use his 
upload traffic.

Another example is access network type. I saw the previous discussion on issues 
that technology types become obsolete and hence the change to avoid use them. 
One comment is that knowing network type can provide information about 
behaviors that an application may use -- Sebastian's comment has alluded to 
this as well. For example, by knowing that the end point is on an UMTS network, 
an application can understand that it will have the RRC statement machine 
running (DCH to FACH after 5 sec idle and FACH to IDLE after 12 sec idle) and 
hence the implications on power consumption as well as techniques to reduce 
energy (e.g., http://web.eecs.umich.edu/~fengqian/paper/thesis.pdf). 

[Haibin] Interesting idea, one question is, how can we assume that each 
application endpoint will easily understand that network type? IMHO, an 
application endpoint might prefer to choose sources with one access type than 
another. But if we want that endpoint to deeply understand that access type 
behaviors, it will be complicated?

Is there a guiding principal that guides the selection and the approach of you 
define the properties (e.g., minimal information, no redundancy)?

[Haibin] Now mainly choose the common properties that were discussed, but will 
think about it.

Also, the updated charter defines a set of 4 questions that one may evaluate. 
It can be helpful if you discuss them when defining each property.

[Haibin] Good suggestion. We will analyze them in the next revision.

Thank you again, Richard!
-Haibin


Richard



On Fri, Jun 27, 2014 at 6:32 AM, 邓灵莉/Lingli Deng  
wrote:
Hi all,

We just submitted a new version of the end point property draft.
Hope it addresses the comments from the list discussion.

Your comments and suggestions would be appreciated.

Thanks,
Lingli

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Friday, June 27, 2014 6:28 PM
> To: Haibin Song; Haibin Song; Deng Lingli; Sebastian Kiesel; Lingli Deng;
> Sebastian Kiesel
> Subject: New Version Notification for draft-deng-alto-p2p-ext-02.txt
>
>
> A new version of I-D, draft-deng-alto-p2p-ext-02.txt
> has been successfully submitted by Lingli Deng and posted to the
> IETF repository.
>
> Name:         draft-deng-alto-p2p-ext
> Revision:     02
> Title:                End Point Properties for Peer Selection
> Document date:        2014-06-27
> Group:                Individual Submission
> Pages:                7
> URL:
> http://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
> Htmlized:       http://tools.ietf.org/html/draft-deng-alto-p2p-ext-02
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-02
>
> Abstract:
>    The initial purpose for ALTO protocol is to provide better than
>    random peer selection for p2p networks.  The peer selection method
>    does not only depend on the peer location, but also on other
>    properties of a peering node.  In this document, we define additional
>    endpoint properties.
>
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at to

Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?

[Reinaldo Penno (repenno)]

Another point is how¹s the provisioned access bandwidth really help decide
which peers are better. Today most P2P software allow caps to be put for
upload/download and people use it. Some come with a default based on the %
of the detect access speed. So, saying a user has 1Gb/s does not really
mean you will get better performance when connecting to him(er). I mean,
it would more inline with better than random to get the actual bandwidth
allowed. 


On 6/27/14, 10:26 AM, "Vijay K. Gurbani"  wrote:

>[Still as individual.]
>
>On 06/26/2014 05:10 AM, Songhaibin (A) wrote:
>> Sebastian gave an idea that we can use relative numbers to indicate
>> the endpoint's provisioned bandwidth instead of access type, which
>> is similar to what we have used to indicate the cost in the alto
>> protocol.
>
>The difference, of course, being that the ISP in some manner consented
>to having a normalized value of cost to be distributed in order to allow
>for better than random selections to improve network performance.
>
>In the case under discussion, the issue is does the subscriber consent
>to having their provisioned bandwidth be part of ALTO calculations?
>
>Remember, if the WG decides to go ahead and use provisioned bandwidth
>anyway, it could always do so.  But then we'd better be prepared to deal
>with the eventuality on when (and if) the IESG challenges us on this
>privacy leak.  If that happens, we'd better have a good response.
>
>Perhaps a midway could be to see if we can use the provisioned bandwidth
>for a set of (anonymous) subscribers instead of singleton subscribers.
>That way, the larger herd provides some modicum of anonymity to an
>individual subscriber who is part of the herd.
>
>Cheers,
>
>- vijay
>-- 
>Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
>Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
>Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
>
>___
>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] Potential privacy issue in draft-deng-alto-p2p-ext-01?

[Vijay K. Gurbani]

[Still as individual.]

On 06/26/2014 05:10 AM, Songhaibin (A) wrote:

Sebastian gave an idea that we can use relative numbers to indicate
the endpoint's provisioned bandwidth instead of access type, which
is similar to what we have used to indicate the cost in the alto
protocol.


The difference, of course, being that the ISP in some manner consented
to having a normalized value of cost to be distributed in order to allow
for better than random selections to improve network performance.

In the case under discussion, the issue is does the subscriber consent
to having their provisioned bandwidth be part of ALTO calculations?

Remember, if the WG decides to go ahead and use provisioned bandwidth
anyway, it could always do so.  But then we'd better be prepared to deal
with the eventuality on when (and if) the IESG challenges us on this
privacy leak.  If that happens, we'd better have a good response.

Perhaps a midway could be to see if we can use the provisioned bandwidth
for a set of (anonymous) subscribers instead of singleton subscribers.
That way, the larger herd provides some modicum of anonymity to an
individual subscriber who is part of the herd.

Cheers,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

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

Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?

[Vijay K. Gurbani]

On 06/26/2014 04:58 AM, Scharf, Michael (Michael) wrote:

Haibin asked me to send the following comment from a private
discussion also to the list:

Section 3.3 of draft-deng-alto-p2p-ext-01 suggest a new Endpoint
Property Type "network_access" for P2P peer selection. As far as I
recall, this type of ALTO guidance was discussed in the past quite a
bit, and there may have been privacy concerns. For instance,
draft-ietf-alto-deployments-09 Section 3.2.4. includes the following
statement:

o  Performance metrics that raise privacy concerns.  For instance,
it has been questioned whether an ALTO service could publicly expose
the provisioned access bandwidth, e.g. of cable / DSL customers,
because this could enables identification of "premium" customers.

That text was already in draft-ietf-alto-deployments before I started
to edit this document.

For P2P use cases, I wonder whether that concern might (still) apply
to endpoint properties such as DSL vs. FTTH as currently suggested
draft-deng-alto-p2p-ext-01.


[As individual, of course.]

I suspect the type of network access (DSL, cable, FTTH, satellite) is
probably okay.  Commercial companies often publicly tout the deployment
of certain access technologies in neighbourhoods.

However, I also suspect that the privacy concerns on *provisioned*
access bandwidth are still intact since they will tend to point to
subscribers that are outliers.

Thanks,

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

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

Re: [alto] FW: New Version Notification for draft-deng-alto-p2p-ext-01.txt

[Y. Richard Yang]

On Thu, Jun 26, 2014 at 7:27 AM, 邓灵莉/Lingli Deng  wrote:

> Hi Sebastian,
>
> Thanks for your review and comments.
> More inline.
>
> Thanks,
> Lingli
>
> > -Original Message-
> > From: Sebastian Kiesel [mailto:ietf-a...@skiesel.de]
> > Sent: Thursday, June 26, 2014 6:26 PM
> > To: ?/Lingli Deng
> > Cc: alto@ietf.org
> > Subject: Re: [alto] FW: New Version Notification for
> > draft-deng-alto-p2p-ext-01.txt
> >
> >
> > Abstract:
> >
> > "In this document, we define endpoint property extensions besides peer
> > location that will impact peer selection."
> >
> > -> the ALTO core spec (RFC-to-be 7285) does not define peer location.
> >
> > Maybe better just say "In this document, we define additional endpoint
> > properties."
> [邓灵莉/Lingli Deng] Agreed.
> >
> >
> > **
> >
> >
> > 3.1.  Endpoint Property Type: p2p_caching
> >
> > looks good.
> >
> > only the encoding of true/false in JSON should be double-checked... is
> > an ASCII string the best way to do it?
> [邓灵莉/Lingli Deng] Boolean looks better.
> >
> >
> > 3.3.  Endpoint Property Type: network_access
> >
> > Sorry to say, but frankly, I don't like this idea.
> >
> > I have two ideas how we could move forward, and we could to only one of
> > them or even both:
>
> [yry] I support both, instead of only one, as appeared in -02. Please see
below.


> > 1.) define encodings for well-defined properties,  e.g.  provisioned
> > access link bandwidth in bps,  or average RTT in idle network.
> >
> > Expect some pushback from the IETF community - we have been discussing
> > this for a while and there where many critics. But I don't think they
> > will accept a proposal that tries to camouflage its true spirit by using
> > technology names instead of Mbps.
> [邓灵莉/Lingli Deng] Yes, we just got feedback from Michael on this one.
>

This is a very good and interesting discussion.

Here is one perspective on considering technology name and provisioned
bandwidth. One guideline that one may use is non-dominant. Specifically,
for a given set of metrics of concern (e.g., throughput, energy
efficiency), and two pieces of information items i1 and i2, if knowing i1
implies i2 completely, then i1 dominates i2 and hence i2 is redundant. In
our setting, I see neither technology name dominating provisioned bandwidth
nor provisioned bandwidth dominating technology name (e.g., the radio
resource control example I mentioned in the previous email). Hence, I see
value in exporting both, depending on the broad setting.

One issue of using non-dominant is that life is complex and few dominant
cases happen :-) One idea is to consider impact levels. For example,
experimental design evaluates the impacts of multiple parameters and
assigns a weight to the contribution level of each parameter. Then a system
uses only those with the highest weight levels. Using this guideline, I do
see that provisioned bandwidth may provide more value than technology name
in many settings. Hence, I agree that if we have to choose one, it is the
provisioned bandwidth.

Richard



> >
> >
> > and/or
> >
> > 2.)  define a pure numerical "relative access link type preference",
> > similar to what we did with the "routingcost" property in the base
> > document.  Just say that "higher number is better", and leave it up
> > to the opoerator of the ALTO server to define what the numbers mean.
> >
> > For example, you could use for now
> >
> > 1 = DSL
> > 10 = FTTB
> > 12 = FTTH
> > 50 = DC
> >
> > and if, in some years, some new technology better than FTTH appears, you
> > could say  100=new_technology  without changing any spec.
> [邓灵莉/Lingli Deng] Good point. We would be happy to revise the draft and go
> this way.
> >
> >
> > **
> >
> >
> > Additional idea:  at least in Europe, many wireless operators offer some
> > low-cost plans, which limit the amount of data to be transmitted within
> > a month to some gigabytes. After that they will throttle your bandwidth
> > or charge extra money.  similar to battery powered devices, hosts with
> > such a tariff should be avoided. Maybe define an additional property?
> [邓灵莉/Lingli Deng] This is interesting. We are doing the same thing in
> China.
> I agree we can have an additional endpoint property for it.
> >
> >
> > **
>
>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>



-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] FW: New Version Notification for draft-deng-alto-p2p-ext-02.txt

[Y. Richard Yang]

Hi Lingli, Sebastian, Haibin,

Interesting doc!  I am wondering the possibility of you adding an overview
section to discuss the potential types of end point properties and your
design guidelines so that we have a better understanding of the design:

- For example, I do not have a feeling that the properties that the current
draft defined are relatively complete. What is the potential set of
properties and why you choose the ones?

- One can convey the properties in multiple ways. For example, the current
draft defines p2p_caching as a boolean. Another design possibility is to
define a generic type with values including "p2p_cache", "super_peer", ...

As another example we consider volume related property. The current draft
defines a boolean. Another alternative is to use an numeric value of the
exact cap.

Another example is access network type.  I saw the previous discussion on
issues that technology types become obsolete and hence the change to avoid
use them. One comment is that knowing network type can provide information
about behaviors that an application may use -- Sebastian's comment has
alluded to this as well. For example, by knowing that the end point is on
an UMTS network, an application can understand that it will have the RRC
statement machine running (DCH to FACH after 5 sec idle and FACH to IDLE
after 12 sec idle) and hence the implications on power consumption as well
as techniques to reduce energy (e.g.,
http://web.eecs.umich.edu/~fengqian/paper/thesis.pdf).

Is there a guiding principal that guides the selection and the approach of
you define the properties (e.g., minimal information, no redundancy)?

Also, the updated charter defines a set of 4 questions that one may
evaluate. It can be helpful if you discuss them when defining each property.

Richard




On Fri, Jun 27, 2014 at 6:32 AM, 邓灵莉/Lingli Deng  wrote:

> Hi all,
>
> We just submitted a new version of the end point property draft.
> Hope it addresses the comments from the list discussion.
>
> Your comments and suggestions would be appreciated.
>
> Thanks,
> Lingli
>
> > -Original Message-
> > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> > Sent: Friday, June 27, 2014 6:28 PM
> > To: Haibin Song; Haibin Song; Deng Lingli; Sebastian Kiesel; Lingli Deng;
> > Sebastian Kiesel
> > Subject: New Version Notification for draft-deng-alto-p2p-ext-02.txt
> >
> >
> > A new version of I-D, draft-deng-alto-p2p-ext-02.txt
> > has been successfully submitted by Lingli Deng and posted to the
> > IETF repository.
> >
> > Name: draft-deng-alto-p2p-ext
> > Revision: 02
> > Title:End Point Properties for Peer Selection
> > Document date:2014-06-27
> > Group:Individual Submission
> > Pages:7
> > URL:
> > http://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-02.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
> > Htmlized:   http://tools.ietf.org/html/draft-deng-alto-p2p-ext-02
> > Diff:
> http://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-02
> >
> > Abstract:
> >The initial purpose for ALTO protocol is to provide better than
> >random peer selection for p2p networks.  The peer selection method
> >does not only depend on the peer location, but also on other
> >properties of a peering node.  In this document, we define additional
> >endpoint properties.
> >
> >
> >
> >
> >
> >
> > 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.
> >
> > The IETF Secretariat
>
>
>
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>



-- 
-- 
 =
| Y. Richard Yang|
| Professor of Computer Science   |
| http://www.cs.yale.edu/~yry/|
 =
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] FW: New Version Notification for draft-deng-alto-p2p-ext-02.txt

[邓灵莉/Lingli Deng]

Hi all,

We just submitted a new version of the end point property draft.
Hope it addresses the comments from the list discussion.

Your comments and suggestions would be appreciated.

Thanks,
Lingli

> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Friday, June 27, 2014 6:28 PM
> To: Haibin Song; Haibin Song; Deng Lingli; Sebastian Kiesel; Lingli Deng;
> Sebastian Kiesel
> Subject: New Version Notification for draft-deng-alto-p2p-ext-02.txt
> 
> 
> A new version of I-D, draft-deng-alto-p2p-ext-02.txt
> has been successfully submitted by Lingli Deng and posted to the
> IETF repository.
> 
> Name: draft-deng-alto-p2p-ext
> Revision: 02
> Title:End Point Properties for Peer Selection
> Document date:2014-06-27
> Group:Individual Submission
> Pages:7
> URL:
> http://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-02.txt
> Status: https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
> Htmlized:   http://tools.ietf.org/html/draft-deng-alto-p2p-ext-02
> Diff:   http://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-02
> 
> Abstract:
>The initial purpose for ALTO protocol is to provide better than
>random peer selection for p2p networks.  The peer selection method
>does not only depend on the peer location, but also on other
>properties of a peering node.  In this document, we define additional
>endpoint properties.
> 
> 
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat




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