Re: [alto] Welcome Qin Wu

[Lingli Deng]

Thank you Martin.

Big welcome to Qin.

Look forward to working with both of you.

 

Lingli

 

On Mon, Nov 9, 2020 at 10:48 PM Martin Duke mailto:martin.h.d...@gmail.com> > wrote:

Hello ALTO,

 

I'm pleased to welcome Qin Wu as the newest working group chair, effective 
immediately. Qin is and active participant in ALTO and an experienced chair.

 

We will have three chairs at IETF 109. Shortly afterwards, one of the current 
chairs will step down. As we complete the current milestones, I will appoint a 
second chair to free both Jan and Vijay to move on to other things.

 

See you next week,

Martin

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




 

-- 

-- 

 =

| Y. Richard Yang mailto:y...@cs.yale.edu> >   |

| 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] Comments on draft-deng-alto-p2p-ext

[Lingli Deng]

Hi Kai,
 
Thanks a lot for your review and comments. See my reply inline below. 
Regards,
Lingli
 
Date: Mon, 20 Jul 2015 20:51:14 +0800
From: gao...@mails.tsinghua.edu.cn
To: alto@ietf.org
Subject: [alto] Comments on draft-deng-alto-p2p-ext


  

  
  
Hi all,



  I found all these new endpoint properties very useful and I
  can't help notice many are specialized for mobile and data
  center scenarios.  However I still have doubts on
some issues and here

  are some comments:

  

  1. I understand that the "precision" field is introduced to
  indicate the type of the
  content.  However, in 5 cases
  out of 8 the field is left empty, in other 2 the only
  difference is between an exact value and the ranking.  In the
  last case, "geolocation", the "precision" field can be chosen
  from four different values, but according to my understanding,
  an endpoint can have a geolocation for each one of them.  What
  if the ALTO server wants to provide all kinds of them?  Since
  they all share the property name "geolocation", it can lead to
  conflicts when the data are encapsulated in a JSON object.

  

  So instead of using "precision", I think it is better to
  provide 4 different geolocation properties.  The same idea can
  apply to "network_access" and "provisioned_bandwidth": use
  "-rank" suffix in the name to indicate the value is a ranking.

  

  At the same time, introducing
  "geolocation-type"/"network-access-type"/"provisioned-bandwidth-type"
  to indicate what "precision"s are supported looks like a good
  idea to me.[dll] Sounds reasonable.

  

  2. The names are using underscores instead of hyphens. 
  However I think it is better to keep it compatible with RFC
  7285 in which property names use hyphens to concatenate words.[dll] 
OK. We can work on that.

  

  3. Why not use strings to represent the bandwidth?  Such as "1
  Gbps".  It's more compact.  I'd also like to know if there are
  some other considerations why the metric and value are
  separated.[dll] Simple strings could work to convey the information, 
but it could be helpful keeping them separate when the server is doing 
filtering based on the value of a given metric per client's request or ISP's 
policy. Does it make sense to you?



==

  

Regards,

  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] FW: New Version Notification for draft-deng-alto-p2p-ext-06.txt

[Lingli Deng]

Date: Thu, 11 Jun 2015 09:19:47 +0800
From: denglin...@chinamobile.com
To: lingli.d...@outlook.com; lingli.d...@139.com
Subject: Fw:New Version Notification for draft-deng-alto-p2p-ext-06.txt

Hi all,
We posted a new revision for extended endpoint properties, which is updated 
according to suggestions and comments gathered in Dallas.  Please refer to the 
following remarks to the discussion minutes for further clarifications.Your 
review and comments would be more than welcome.
Regards,Lingli
**from alto@ietf92 minutes**draft-deng-alto-p2p-ext-05JS: should we hold 
information that changes frequently (like 2G/3G/4G)?[dll]: 06 version updated 
and use cellular for 2G/3G/4G instead of 2G, 3G and 4G, which can be 
subject to frequent changes.VG (Vijay Gurbani): How to prevent revealing 
private information?[dll]: There is a dedicated section describing the privacy 
protection mechanism that might be used by ALTO for endpoint property.In a 
word, the privacy protection requirement is considered to be an 
application-specific, property-specific and operator-specific,which can be 
addressed by introduction of privacy protection mapping in property definition 
and policy configuration.Where the general mechanism for privacy protectionJS: 
Max bandwidth / best technology for a given endpoint may be more stable.[dll] 
Bandwidth related information has been defined as one of the subscription 
related property provisioned_bandwidth in Section 4.4.2.JS: Who has read a 
document? 2 hands raised.RY: Document touches dynamics and privacy.JS: This 
topic is returning. According to IESG, ALTO is not for TE and avoiding 
congestions, information changing within seconds are out of scope. Daily - in 
scope.[dll] In the text, it is clearly stated that dynamic congestion related 
information is out of scope for endpoint properties. However, there is no clear 
boundary between which is in scope and which is not.RY: What is too dynamic, 
what is not?JS (as indiv.): 3G/4G is too dynamic.[dll] Changed into cellular in 
the latest version.JS: Rich Woundy was always concerned about disclosing 
business information.RY: Privacy is a serious issue.[dll] Privacy is an 
honoured requirement. General considerations and guidelines are stated in 
Section 3.3.And for each property specified afterwards, property-specific 
privacy considerations are stated respectively.Take network_access for 
instance: There is concern about undesirable privacy leakage via network_access 
properties to distrusted ALTO clients. In such cases, according to the 
definitions above, either the endpoint itself or the ISP who is running the 
ALTO server can either specify an access control policy to prevent undesirable 
exposure to specific ALTO clients or use a privacy preserving mapping from the 
raw description of access technologies to a number of abstract relative ranking 
information instead. Moreover, the endpoint or the ISP might choose to use 
another subscription related property provisioned_bandwidth (defined later in 
Section 4.4.2) instead of network_access.SS (Sergey Slovetskiy): What defines 
what is in scope / out of scope?JS: ALTO Prolem StatementSS: Fast-changing 
properties may be important for CDNs.[dll]: Would be happy to hear more about 
this consideration, and let the WG decide if they are suitable to be defined as 
endpoint properties.


-
邓灵莉

中国移动通信研究院

denglin...@chinamobile.com
邮件原文
发件人：internet-drafts internet-dra...@ietf.org
收件人：Haibin Song haibin.s...@huawei.com,Qin Wu sunse...@huawei.com,Wenson Wu 
sunse...@huawei.com,Richard Yang y...@cs.yale.edu,Haibin Song 
haibin.s...@huawei.com,Deng Lingli denglin...@chinamobile.com,Sebastian 
Kiesel ietf-a...@skiesel.de,Yang Yang y...@cs.yale.edu,Lingli Deng 
denglin...@chinamobile.com,Sebastian Kiesel ietf-a...@skiesel.de
抄　送: (无)
发送时间：2015-06-11 09:09:45
主题：New Version Notification for draft-deng-alto-p2p-ext-06.txt



A new version of I-D, draft-deng-alto-p2p-ext-06.txt

has been successfully submitted by Lingli Deng and posted to the

IETF repository.



Name:   draft-deng-alto-p2p-ext

Revision:   06

Title:  Extended End Point Properties for Application-Layer Traffic 
Optimization

Document date:  2015-06-10

Group:  Individual Submission

Pages:  18

URL: https://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-06.txt

Status: https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/

Htmlized: https://tools.ietf.org/html/draft-deng-alto-p2p-ext-06

Diff: https://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-06



Abstract:

 The purpose of the Application-Layer Traffic Optimization (ALTO)

 protocol is to provide better-than-random peer selection for P2P

 networks. The base ALTO protocol focuses, only on providing network

 topological location information (i.e., network maps and cost maps).

 However, the peer selection method of an endpoint may also use other

 properties, such as geographic location. This document

[alto] Question about unified framework for properties

[Lingli Deng]

Hi Wendy,
I am currently working on a revision for draft on Extended endpoint properties 
(I.D-draft-deng-alto-p2p-ext),  and noticed there is concern about potential 
overlap during last meeting with your proposal on a unified framework for 
properties.I am afraid that I was not there for the onsite discussion, but 
after reading your slides, I feel it seems to be orthogonal with endpoint 
properties. What do you think?BTW, I could not find any draft for the proposed 
framework. Are you working on such a document or is there anybody else doing 
this? If so, I would be happy to read it and double check its relevance with or 
effect on our work on endpoint properties.
Regards,Lingli___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] 答复: 答复: New Version Notification for draft-fu-alto-nfv-usecase-04.txt

[Lingli Deng]

Hi Qiao,
Yes, it does. But I believe the current definition already covers the case.  A 
statement might be helpful in clarifying the usage for ingress VM location of a 
VNF instance. What do you think?
Lingli
From: fuq...@chinamobile.com
To: lingli.d...@outlook.com
CC: alto@ietf.org
Subject: 答复: 答复: New Version Notification for draft-fu-alto-nfv-usecase-04.txt
Date: Tue, 12 May 2015 10:17:55 +0800

Hi, Lingli. Thank you for the work. I think the extension you address makes 
sense to me. There is another usecase where there could be multiple VMs in one 
VNF. Therefore in this scenario we can hardly define the geo-location of the 
VNF. In such case, I think maybe we can use the geo-location of the ingress VM 
as the geo-location of the whole VNF. I don’t know if this makes sense to you? 
发件人: Lingli Deng [mailto:lingli.d...@outlook.com] 
发送时间: 2015年5月8日 19:23
收件人: fuq...@chinamobile.com
抄送: alto@ietf.org
主题: RE: 答复: New Version Notification for draft-fu-alto-nfv-usecase-04.txt  Hi 
Qiao,
 
I am planning working on the endpoint extensions that you proposed for NFV 
usecases in March.
Would be happy to have a further discussion before getting started.
 
As discussed earlier,  I propose extensions to the current geolocation EP 
property as follows (also useful for other datacenter scenario I suppose): 
 
Extending the geolocation_precision_set = [countrycode, boundingbox, 
circle, DC]
If the precision attribute of the geolocation property of an endpoint is 
DC, the following content attribute is defined as a four-element JSON 
object DC:

   DC = {
rack-id : number, 
server-id : number
}
 
Would the this address your usecase for VNF migration?
 
Lingli
 
-邮件原件-
From: Qiao Fu fuqiao1 at outlook.com・  To: '邓灵莉/Lingli Deng' denglingli at 
chinamobile.com, alto at ietf.org・  Cc: zhencao.ietf at gmail.com・  Date: 
Wed, 11 Mar 2015 18:20:26 +0800・  In-reply-to: 
008d01d05a17$08f5d2a0$1ae177e0$@com・  References: 
snt146-ds20a7790df96d11d711cb7ce8...@phx.gbl 
008d01d05a17$08f5d2a0$1ae177e0$@com  Hi, Lingli. Thank you for the comments.A 
usecase I can think of within the DC is the sfc (service function chaining). In 
the sfc, there is a sff (service function forwarder) responsible for forwarding 
certain flow to the specific sf (service function). When the flow finished in 
the sf, it will get back to the sff and will be directed to the next sf on the 
sfp (service function path). Therefore, the sff may need information to know 
which sf is located at which rack so that it can optimize the sfp and reduce 
latency between the sf and itself. I think a wise choice is for the sff to ask 
auto server for this info. In such usecase, rack ID or even server ID is 
important information for the sff. I don't know if this scenario makes sense to 
you?Thank you and looking forward to your feedback:)   -邮件原件-发件人: 
邓灵莉/Lingli Deng [mailto:denglingli at chinamobile.com] 发送时间: 2015年3月9日 
11:14收件人: 'Qiao Fu'; alto at ietf.org抄送: zhencao.ietf at gmail.com; 'Songhaibin 
(A)'主题: RE: New Version Notification for draft-fu-alto-nfv-usecase-04.txt Hi 
Qiao, Thanks for the interesting discussion around endpoint property for VNFs. 
In terms of VNF migration and its impact on endpoint geo-location property 
design, I see there are two potential cases: inter-DC migration and intra-DC 
migration.As you can see from the current design for endpoint geo-location 
property, the intra-DC migration might not be reflected by the current design 
unless we introduce something like server-id or rack-id?But such information is 
too low-level I suspect and maybe considered sensitive or lose its practical 
meaning once the ALTO client is located outside the DC domain in question.While 
within the DC, who would be the ALTO client for such information? 
Regards,Lingli  -Original Message- From: Qiao Fu [mailto:fuqiao1 at 
outlook.com] Sent: Monday, March 09, 2015 10:35 AM To: alto at ietf.org Cc: 
zhencao.ietf at gmail.com; 'Songhaibin (A)'; '邓灵莉/Lingli Deng' Subject: 转发: 
New Version Notification for draft-fu-alto-nfv-usecase-04.txt  Hi, all. I 
have just updated the following draft. This draft proposes a usecase of ALTO 
in the NFV scenario. And possible property extension is added and discussed in 
this update. Such extension may be included in another draft: 
http://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/ Your comments and 
suggestions are more than welcome. Thank you!   -邮件原件- 发件人: 
internet-drafts at ietf.org [mailto:internet-drafts at ietf.org] 发送时间: 
2015年3月9日 10:27 收件人: Haibin Song; Qiao Fu; Qiao Fu; Haibin Song; Zhen Cao; 
Zehn Cao 主题: New Version Notification for draft-fu-alto-nfv-usecase-04.txt  
 A new version of I-D, draft-fu-alto-nfv-usecase-04.txt has been successfully 
submitted by Qiao Fu and posted to the IETF repository.  Name:
draft-fu-alto-nfv-usecase Revision:04 Title:   What's the 
Impact of Virtualization on Application-Layer Traffic

Re: [alto] 答复: New Version Notification for draft-fu-alto-nfv-usecase-04.txt

[Lingli Deng]

 Hi Qiao,
 
I am planning working on the endpoint extensions that you proposed for NFV 
usecases in March.
Would be happy to have a further discussion before getting started.
 
As discussed earlier,  I propose extensions to the current geolocation EP 
property as follows (also useful for other datacenter scenario I suppose): 
 
Extending the geolocation_precision_set = [countrycode, boundingbox, 
circle, DC]
If the precision attribute of the geolocation property of an endpoint is 
DC, the following content attribute is defined as a four-element JSON 
object DC:

   DC = {
rack-id : number, 
server-id : number
}
 
Would the this address your usecase for VNF migration?
 
Lingli
 
-邮件原件-
From: Qiao Fu fuqiao1 at outlook.com
To: '邓灵莉/Lingli Deng' denglingli at chinamobile.com,  alto at ietf.orgCc: 
zhencao.ietf at gmail.comDate: Wed, 11 Mar 2015 18:20:26 +0800In-reply-to: 
008d01d05a17$08f5d2a0$1ae177e0$@comReferences: 
snt146-ds20a7790df96d11d711cb7ce8...@phx.gbl 
008d01d05a17$08f5d2a0$1ae177e0$@com  
  
Hi, Lingli. Thank you for the comments.
A usecase I can think of within the DC is the sfc (service function chaining). 
In the sfc, there is a sff (service function forwarder) responsible for 
forwarding certain flow to the specific sf (service function). When the flow 
finished in the sf, it will get back to the sff and will be directed to the 
next sf on the sfp (service function path). Therefore, the sff may need 
information to know which sf is located at which rack so that it can optimize 
the sfp and reduce latency between the sf and itself. I think a wise choice is 
for the sff to ask auto server for this info. 
In such usecase, rack ID or even server ID is important information for the 
sff. I don't know if this scenario makes sense to you?
Thank you and looking forward to your feedback:)



-邮件原件-
发件人: 邓灵莉/Lingli Deng [mailto:denglingli at chinamobile.com] 
发送时间: 2015年3月9日 11:14
收件人: 'Qiao Fu'; alto at ietf.org
抄送: zhencao.ietf at gmail.com; 'Songhaibin (A)'
主题: RE: New Version Notification for draft-fu-alto-nfv-usecase-04.txt

Hi Qiao,

Thanks for the interesting discussion around endpoint property for VNFs.

In terms of VNF migration and its impact on endpoint geo-location property 
design, I see there are two potential cases: inter-DC migration and intra-DC 
migration.
As you can see from the current design for endpoint geo-location property, the 
intra-DC migration might not be reflected by the current design unless we 
introduce something like server-id or rack-id?
But such information is too low-level I suspect and maybe considered sensitive 
or lose its practical meaning once the ALTO client is located outside the DC 
domain in question.
While within the DC, who would be the ALTO client for such information?

Regards,
Lingli

 -Original Message-
 From: Qiao Fu [mailto:fuqiao1 at outlook.com]
 Sent: Monday, March 09, 2015 10:35 AM
 To: alto at ietf.org
 Cc: zhencao.ietf at gmail.com; 'Songhaibin (A)'; '邓灵莉/Lingli Deng'
 Subject: 转发: New Version Notification for draft-fu-alto-nfv-usecase-04.txt
 
 Hi, all. I have just updated the following draft. This draft proposes a 
 usecase of
 ALTO in the NFV scenario. And possible property extension is added and
 discussed in this update. Such extension may be included in another draft:
 http://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
 Your comments and suggestions are more than welcome. Thank you!
 
 
 -邮件原件-
 发件人: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org]
 发送时间: 2015年3月9日 10:27
 收件人: Haibin Song; Qiao Fu; Qiao Fu; Haibin Song; Zhen Cao; Zehn Cao
 主题: New Version Notification for draft-fu-alto-nfv-usecase-04.txt
 
 
 A new version of I-D, draft-fu-alto-nfv-usecase-04.txt
 has been successfully submitted by Qiao Fu and posted to the
 IETF repository.
 
 Name: draft-fu-alto-nfv-usecase
 Revision: 04
 Title:What's the Impact of Virtualization on 
 Application-Layer Traffic
 Optimization (ALTO)?
 Document date:2015-03-08
 Group:Individual Submission
 Pages:9
 URL:
 http://www.ietf.org/internet-drafts/draft-fu-alto-nfv-usecase-04.txt
 Status: https://datatracker.ietf.org/doc/draft-fu-alto-nfv-usecase/
 Htmlized:   http://tools.ietf.org/html/draft-fu-alto-nfv-usecase-04
 Diff:   http://www.ietf.org/rfcdiff?url2=draft-fu-alto-nfv-usecase-04
 
 Abstract:
This documentation presents a use case of Application-Layer Traffic
Optimization (ALTO) with the emergence of Network Function
Virtualization (NFV).  The Application-Layer Traffic Optimization
(ALTO) Service provides 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 emerging NFV, which is
currently being in progress in ETSI NFV

Re: [alto] New Version Notification for draft-fu-alto-nfv-usecase-04.txt

[邓灵莉/Lingli Deng]

Hi Qiao,

Thanks for the interesting discussion around endpoint property for VNFs.

In terms of VNF migration and its impact on endpoint geo-location property 
design, I see there are two potential cases: inter-DC migration and intra-DC 
migration.
As you can see from the current design for endpoint geo-location property, the 
intra-DC migration might not be reflected by the current design unless we 
introduce something like server-id or rack-id?
But such information is too low-level I suspect and maybe considered sensitive 
or lose its practical meaning once the ALTO client is located outside the DC 
domain in question.
While within the DC, who would be the ALTO client for such information?

Regards,
Lingli

 -Original Message-
 From: Qiao Fu [mailto:fuqi...@outlook.com]
 Sent: Monday, March 09, 2015 10:35 AM
 To: alto@ietf.org
 Cc: zhencao.i...@gmail.com; 'Songhaibin (A)'; '邓灵莉/Lingli Deng'
 Subject: 转发: New Version Notification for draft-fu-alto-nfv-usecase-04.txt
 
 Hi, all. I have just updated the following draft. This draft proposes a 
 usecase of
 ALTO in the NFV scenario. And possible property extension is added and
 discussed in this update. Such extension may be included in another draft:
 http://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
 Your comments and suggestions are more than welcome. Thank you!
 
 
 -邮件原件-
 发件人: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
 发送时间: 2015年3月9日 10:27
 收件人: Haibin Song; Qiao Fu; Qiao Fu; Haibin Song; Zhen Cao; Zehn Cao
 主题: New Version Notification for draft-fu-alto-nfv-usecase-04.txt
 
 
 A new version of I-D, draft-fu-alto-nfv-usecase-04.txt
 has been successfully submitted by Qiao Fu and posted to the
 IETF repository.
 
 Name: draft-fu-alto-nfv-usecase
 Revision: 04
 Title:What's the Impact of Virtualization on 
 Application-Layer Traffic
 Optimization (ALTO)?
 Document date:2015-03-08
 Group:Individual Submission
 Pages:9
 URL:
 http://www.ietf.org/internet-drafts/draft-fu-alto-nfv-usecase-04.txt
 Status: https://datatracker.ietf.org/doc/draft-fu-alto-nfv-usecase/
 Htmlized:   http://tools.ietf.org/html/draft-fu-alto-nfv-usecase-04
 Diff:   http://www.ietf.org/rfcdiff?url2=draft-fu-alto-nfv-usecase-04
 
 Abstract:
This documentation presents a use case of Application-Layer Traffic
Optimization (ALTO) with the emergence of Network Function
Virtualization (NFV).  The Application-Layer Traffic Optimization
(ALTO) Service provides 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 emerging NFV, which is
currently being in progress in ETSI NFV, leverages standard IT
virtualisation technology to consolidate many network equipment types
onto industry standard high-volume servers, switches, and storage.
The use case presented in this document discusses the impact of
virtualization on the ALTO protocol.  An architecture is proposed for
the interface between NFV MANO and ALTO server.  And possible end
point property extention is also discussed for such usecase.
 
 
 
 
 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

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

[邓灵莉/Lingli Deng]

Hi all,

We've uploaded a new revision on endpoint property extension draft.
The technical content in this revision is not changed and consistent with the 
slides we presented last week, and all the changes are editorial. 
For those not present last week or familiar with our draft, please refer to the 
slides: http://www.ietf.org/proceedings/91/slides/slides-91-alto-7.pdf 

Due to the time limit, we was not able to solicit feedback from the group as we 
would wanted.
Any review and comments from the list would be highly appreciated.

LingliHaibinSebastianRichardQin

 -Original Message-
 From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
 Sent: Friday, November 21, 2014 10:19 AM
 To: Haibin Song; Qin Wu; Wenson Wu; Richard Yang; Haibin Song; Deng Lingli;
 Sebastian Kiesel; Yang Yang; Lingli Deng; Sebastian Kiesel
 Subject: New Version Notification for draft-deng-alto-p2p-ext-05.txt
 
 
 A new version of I-D, draft-deng-alto-p2p-ext-05.txt
 has been successfully submitted by Lingli Deng and posted to the
 IETF repository.
 
 Name: draft-deng-alto-p2p-ext
 Revision: 05
 Title:Extended End Point Properties for Application-Layer 
 Traffic
 Optimization
 Document date:2014-11-17
 Group:Individual Submission
 Pages:17
 URL:
 http://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-05.txt
 Status: https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
 Htmlized:   http://tools.ietf.org/html/draft-deng-alto-p2p-ext-05
 Diff:   http://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-05
 
 Abstract:
The purpose of the Application-Layer Traffic Optimization (ALTO)
protocol is to provide better-than-random peer selection for P2P
networks. The base ALTO protocol focuses, only on providing network
topological location information (i.e., network maps and cost maps).
However, the peer selection method of an endpoint may also use other
properties, such as geographic location. This document defines a
framework and an extended set of End Point properties (EP properties)
to extend the base ALTO protocol.
 
 
 
 
 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

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

[邓灵莉/Lingli Deng]

Hi all,

We just submitted a revision on extended EP properties draft trying to address 
the comments from recent discussion on the list.
Some of issues remains unaddressed and welcome for further comments and 
discussion.

Cheers,
Lingli

 -Original Message-
 From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
 Sent: Friday, July 04, 2014 12:08 PM
 To: Haibin Song; Haibin Song; Deng Lingli; Sebastian Kiesel; Lingli Deng;
 Sebastian Kiesel
 Subject: New Version Notification for draft-deng-alto-p2p-ext-03.txt
 
 
 A new version of I-D, draft-deng-alto-p2p-ext-03.txt
 has been successfully submitted by Lingli Deng and posted to the
 IETF repository.
 
 Name: draft-deng-alto-p2p-ext
 Revision: 03
 Title:End Point Properties for Peer Selection
 Document date:2014-07-04
 Group:Individual Submission
 Pages:10
 URL:
 http://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-03.txt
 Status: https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
 Htmlized:   http://tools.ietf.org/html/draft-deng-alto-p2p-ext-03
 Diff:   http://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-03
 
 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 the 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

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

[邓灵莉/Lingli Deng]

 

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang
Sent: Tuesday, July 01, 2014 8:23 PM
To: Scharf, Michael (Michael)
Cc: IETF ALTO
Subject: Re: [alto] FW: New Version Notification for 
draft-deng-alto-p2p-ext-02.txt

 

Hi Michael,

 

Good comments!

 

On Mon, Jun 30, 2014 at 5:43 AM, Scharf, Michael (Michael) 
michael.sch...@alcatel-lucent.com wrote:

Regarding geo-location, which is mentioned below: Yes, indeed, I’ve argued many 
times that there are a number of important concepts that ALTO extensions should 
support. Geo-location is one of them.

 

In general, geo-location  can either be a property of a PID 
(draft-roome-alto-pid-properties) or of an endpoint. The former is possibly 
less privacy sensitive and sufficient in some cases, but since the mechanisms 
would be similar, possibly both can be achieved in the same way (and the same 
document).

 

 

This is a good comment. I see that the relationship between PID properties and 
endpoint properties as the following: assume that a PID pid1 consists of a set 
of endpoints, ep1, ep2, ... epn. For a given property prop: we obtain pid1.prop 
through an aggregation function on ep1.prop, ep2.prop, ..., epn.prop, and 
operated through the inheritance mechanism that Wendy proposed and I liked a 
lot. Hence, a final format of the endpoint property WG item can be that:

te-metrics and other define basic types of properties, and pid-properties 
provides the aggregation/inheritance framework.

[邓灵莉/Lingli Deng] IMHO, the basic end point properties as defined in this 
document, may in turn be used to derive PID properties for the corresponding 
peer group, which can also be used as one of the alternatives for the ALTO 
server to avoid directly exposing sensitive end point information to distrusted 
applications.

 

My own thinking is to try to keep standardized ALTO extensions as generic as 
possible so that they are useful for different use cases of ALTO.  I’d favor 
generic extensions instead of mechanisms that are specific to some P2P 
deployment scenarios. For instance, the metrics in draft-wu-alto-te-metrics are 
fairly generic and applicably in different scenarios – this seems to me a 
useful approach that we should aim for regarding ALTO properties as well.

 

 

I will chime in to say that I totally agree with the 
resuable-for-multiple-use-cases design approach.

[邓灵莉/Lingli Deng] Agreed. Another useful guideline for designing EP properties.

 

Richard

 

 

 

Michael

 

 

 

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang
Sent: Saturday, June 28, 2014 9:35 AM
To: Songhaibin (A)


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

 

Hi Haibin,

 

Please see below.

On Saturday, June 28, 2014, Songhaibin (A) haibin.s...@huawei.com wrote:

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.

 

[yry] Two comments. One, I feel that ALTO can and should go beyond only peer 
selection for P2P. Hence, it will be interesting to consider other endpoint 
properties. 

 

One reason I ask is that I see geo-location as a quite useful property, but it 
is missing in your draft. I am traveling right now, and it is common for apps 
trying to determine my location. We discussed so e other use cases on location 
as well. It could even be virtual location, such as rack id. Using ALTO to 
provide this natural. Hence, I suggest that the WG in general and your team 
(Sebastian, Lingli, you) in particular, given that your team is leading the 
endpoint property effort, conducts the exercise, so that we get a sense of the 
general set. Then we follow the charter to prune the list. I feel that Michael 
will have opinions as well.

 


- 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

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

[邓灵莉/Lingli Deng]

 

 

From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang
Sent: Tuesday, July 01, 2014 8:09 PM
To: Sebastian Kiesel
Cc: IETF ALTO
Subject: Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?

 

 

On Mon, Jun 30, 2014 at 10:35 AM, Sebastian Kiesel ietf-a...@skiesel.de wrote:

On Fri, Jun 27, 2014 at 12:16:16PM -0500, Vijay K. Gurbani wrote:
 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.

I know some neighborhoods where FTTH is available, but at very high
prices.  Consequently, many people there prefer to keep their existing
xDSL or cable based Internet service.  If we used ALTO to announce who
decided to pay the high price for FTTH, I would consider this as a
potential privacy concern, because this would be some kind of list of
households with better-than-average income and/or computer professionals
or enthusiasts living there.

 

This is an interesting example, and provides a case where access control may be 
used. I always expect that there should be an access control mechanism, in 
given settings, to limit the information exposure of ALTO info. I can imagine 
that this can be endhost opt-in, or provider control (e.g., only certain 
trusted entities can access the URL).

[邓灵莉/Lingli Deng] Good idea. Greater flexibility can be delivered by access 
control at the discretion of both the network operator and the individual 
subscriber. 

 

Richard

 


Sebastian


___
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] FW: New Version Notification for draft-deng-alto-p2p-ext-02.txt

[邓灵莉/Lingli Deng]

Hi Richard,

 

Thanks for your review and comments.

We are currently working on another revision with hope that it would address at 
least some of the issues here.

More inline.

 

Lingli

 

From: yang.r.y...@gmail.com [mailto:yang.r.y...@gmail.com] 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:

[邓灵莉/Lingli Deng] Good idea. I shall try to incorporate this discussion in the 
next revision.

 

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

[邓灵莉/Lingli Deng] Indeed, we may stick to a general principle and derived 
certain guidelines to be used when selecting and defining such properties.

 

 

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 denglin...@chinamobile.com 
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 y...@cs.yale.edu   |

| 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-01.txt

[邓灵莉/Lingli Deng]

 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.

[邓灵莉/Lingli Deng] This is an interesting reasoning and very useful way of 
designing. 

As long as people see value in other information that can be derived from the 
access technology besides provisioned bandwidth, the two should not be bounded 
together.

 

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 y...@cs.yale.edu   |

| 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] Potential privacy issue in draft-deng-alto-p2p-ext-01?

[邓灵莉/Lingli Deng]

 -Original Message-
 From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Reinaldo Penno
 (repenno)
 Sent: Saturday, June 28, 2014 7:55 PM
 To: Songhaibin (A); Vijay K. Gurbani; alto@ietf.org
 Subject: Re: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
 
 I'm not talking about on-demand available bandwidth,
 
 It is the bandwidth configured in the application. It is a configured value. 
 Just
 take a look at any utorrent client.
[邓灵莉/Lingli Deng] I am a little bit confused here. If the cap is configured in 
the app, then why would the app's tracker bother to query a ALTO server for 
this value?
It seems to me that ALTO should be providing more general information that 
would assist a group of applications, rather than a single one. Make sense?
 
 A utorrent client will never use more than that amount of bandwidth, no
 matter your provisioned bandwidth.
 
 
 
 From: Songhaibin (A) [haibin.s...@huawei.com]
 Sent: Friday, June 27, 2014 11:09 PM
 To: Reinaldo Penno (repenno); Vijay K. Gurbani; alto@ietf.org
 Subject: RE: [alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
 
 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 v...@bell-labs.com 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



___
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

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

[邓灵莉/Lingli Deng]

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

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

[邓灵莉/Lingli Deng]

Hi all,

A revision to the endpoint property extension draft for P2P networks is newly 
submitted for your discussion.
http://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-01.txt 
It discusses three types of property extensions for better guided peer 
selection.

You review and comments would be highly appreciated.

Many thanks,
Lingli

 -Original Message-
 From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
 Sent: Tuesday, June 24, 2014 9:20 AM
 To: Deng Lingli; Haibin Song; Lingli Deng; Haibin Song
 Subject: New Version Notification for draft-deng-alto-p2p-ext-01.txt
 
 
 A new version of I-D, draft-deng-alto-p2p-ext-01.txt
 has been successfully submitted by Lingli Deng and posted to the
 IETF repository.
 
 Name: draft-deng-alto-p2p-ext
 Revision: 01
 Title:End Point Properties for Peer Selection
 Document date:2014-06-24
 Group:Individual Submission
 Pages:7
 URL:
 http://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-01.txt
 Status: https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
 Htmlized:   http://tools.ietf.org/html/draft-deng-alto-p2p-ext-01
 Diff:   http://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-01
 
 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 endpoint
property extensions besides peer location that will impact peer
selection.
 
 
 
 
 
 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

Re: [alto] alto Digest, Vol 63, Issue 7

[lingli deng]

Hi all,

I support all the 7 items.

However, some of them are not clearly stated I think.
For example, item #4.
While it is straightforward that migration to HTTP2.0 brings higher
performance without affecting the semantic layer, it is not so clear why we
need to migrate to websockets, since it may bring substantial change to the
application layer.

BR
Lingli


Date: Thu, 23 Jan 2014 13:11:14 -0600
 From: Vijay K. Gurbani v...@bell-labs.com
 To: alto alto@ietf.org
 Subject: [alto] Work items for re-chartering
 Message-ID: 52e16952.8040...@bell-labs.com
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 Folks: Over the last few IETFs, Enrico and I have solicited feedback
 during face-to-face meetings, WG sessions, hallway conversations, ALTO
 mailing list and private conversations on how to move ahead with respect
 to adopting new work items.

 As we begin the charter discussions, we have identified seven
 work items to propose as additions to the charter.  The first four of
 these work items are fairly uncontroversial.  The last three are work
 items that have a monumental mind share in the ALTO working group and
 have been found to be extremely useful in controlled networks (e.g.,
 VPNs).  However, we have to take some care in defining these such that
 we do not duplicate the functionality available elsewhere (e.g., general
 routing) in ALTO, nor do we take on an aspect that the working group
 does not fully understand.

 Here are the seven items up for discussion:

 1. Anycast-based server discovery
 (Presented by Reinaldo Penno in IETF 86 and appears to have
 some support for adoption.)

 2. Third-party server discovery
 (Sebastian Kiesel et al. have been driving this work and it
 also appears to have support.)

 3. Incremental ALTO map updates
 (Side meeting held during IETF 86; two proposals have been
 studied.  One way forward is to use an ALTO-specific incremental
 update that may be more efficient, and the second approach is to
 simply use JSON patch.)

 4. Server-initiated update notifications
 (Jan Seedorf and Enrico Marocco have suggested the use of
 Websockets; HTTP/2.0 may provide some mitigation as well.)

 5. Extensions to annotate PIDs with properties (e.g., geographical
 locations).
 (Useful as an extension in controlled environments, e.g., VPNs
 where IP addresses are not the only form of identification.
 Some drafts, including draft-roome-alto-pid-properties
 has already started work in this direction.)

 6. Extensions for cost metrics.
 (Some drafts, including draft-wu-alto-json-te, have started work
 in this direction.)

 7. An ALTO format for encoding graphs.
 (draft-ietf-alto-protocol already recognizes the need to provide
 topology details that are useful in controlled environments.
 Richard Yang, Greg Bernstein and others have been working on the
 need and use cases for such an encoding.  draft-yang-alto-topology
 is a good start.  Projects like OpenDayLight and NetworkX (Python)
 have JSON models for graph representation.  Some concrete examples
 of how we envision encoding graphs will be useful during list
 discussion.)

 We will like to understand whether the working group believe such
 additional deliverables, if included in an updated charter proposal,
 would allow people to do the extension work that has been repeatedly
 proposed. (Clarification: we are explicitly asking whether people could
 find such an update acceptable. We understand that anyone will have a
 preferred flavor of the above.)

 We are at a point where show of support by whoever is interested is
 essential for moving forward. If it turns out to be positive, Enrico
 and I will subsequently circulate actual text, including milestones, for
 a rechartering request.

 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




-- 
邓灵莉/Lingli Deng
中国移动通信研究院/China Mobile Research Institute
e-mail: denglin...@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148
___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] ***SPAM*** 7.258 (5) 答复: 转发: New Version Notification for draft-deng-alto-p2pcache-00.txt

[邓灵莉/Lingli Deng]

Hi Richard,

 

Thank you for your suggestions and comments. Plz see the replies inline.

BTW. I have just uploaded a revised version of this draft.
http://www.ietf.org/id/draft-deng-alto-p2pcache-02.txt 

 

Further comments are welcome.

 

BR

Lingli

 

发件人: yang.r.y...@gmail.com [mailto:yang.r.y...@gmail.com] 代表 Y. Richard
Yang
发送时间: 2013年7月28日 6:21
收件人: 邓灵莉/Lingli Deng
抄送: alto@ietf.org
主题: Re: [alto] 转发: New Version Notification for
draft-deng-alto-p2pcache-00.txt

 

Hi Lingli,

 

A very interesting document, and the idea of using cache locations and types
to compute network map and cost map is novel.

 

Here are some early comments:

 

- page 1 Abstract: it can be helpful to add a sentence or two on the terms
forward caching and transparent caching, as they are not complex
concepts, but many readers may not always remember their definitions.

[dll] You are right. I added a new “terminology” section to the updated
draft. 

 

- page 1: DIPs are typos of PIDs?

[dll] I am afraid to say yes. Sorry for the confusion. Thank you for
pointing it out.

 

- page 2: 80% traffic is P2P in China Mobile WLANs?! Do you have a more
detailed breakdown which you can share? This can help with our understanding
of the problem.

[dll] I am sorry to say I don’t have the first-handed data at hand. I will
get contact with my colleagues and see if we may have a more informative
description about this problem.

 

- page 3: characteristics of the DCF model in 802.11 ... downlink
congestion It is not clear to me which DCF properties are at play here. For
ChinaMobile public WLANs, both downlink and uplink are scheduled by DCF? 

[dll] There is basic indication under the current DCF model, that in order
to achieve fairness among mobile stations, in the long run, each stations
has a equal chance of getting the wireless slot given they all have a
sustainable long traffic to send. In other words, there is an implicit
unfairness between uplink and downlink traffic under the BSS model, where
the AP holds the throat of all the downlink traffic and competing with the
uplink traffic from potentially a large group of other user mobile devices.

 

-page 3: at AC: AC is introduced later in the document. It can be helpful
to define it first before use.

[dll] Thank you for the suggestion. It’s been added into the new
“terminology” section in the updated draft.

 

- page 3: suboptimal to use network type as dividers for different PIDs...
Can you please elaborate some more here on why suboptimal? Is it consistent
with the rest?

[dll] It is referring to the recommendations provided by the deployment
draft in terms of wireless scenarios. By suboptimal, I mean if we consider
the effect of caches in the domain, we would see that their existence do
have an impact to cost between nodes in the same PID. But if we stick to
using network types as dividers for PIDs, there is no chance that cost map
would ever grasp this kind of information.

 

- page 5/Sec. 3.2-3.3 It seems that you may use the general Distributed
System/BSS/ESS concept of 802.11. Does it help to use the terms of 802.11?
Your architecture appears to extend beyond different types of networks, 

[dll] Yes, the reverse/bidirectional caches are proposed for 802.11
networks, but it seems to me that similar problem may exist in other
networks, as long as there’s layers of caches deployed.

 

- page 7/Sec. 4.1: other local peers outside ... Remove local? My
understanding is that the details of Sec. 4.1 are important for others to
understand your messages; hence, will it be better if you elaborate a bit on
the process.

[dll] Yes, it’s confusing here. What I meant to say is “other peers
outside AN1 but within ISP2”. Changes have been made to the updated draft
to clarify this.

 

In more details, is it possible to derive a quantitive model to compute
normalized cost maps, based on location of caches, as you mentioned, as well
as cache hit rations?

[dll] That’s a bit of implementation question to me concerning how to
compute a reasonable cost map, with considerations of local caching
facilities. But yes, why not?

 

Just some initial comments.

 

Thanks!

 

Richard

 



On Thursday, July 4, 2013, 邓灵莉/Lingli Deng wrote:

Hi all,

We have just submitted a draft proposing to take considerations on the
locations of operator-deployed P2Pcaches in the formation of network
topology abstraction.
http://www.ietf.org/internet-drafts/draft-deng-alto-p2pcache-00.txt

Your comments are welcome. Thank you~

BR
Lingli

-邮件原件-
发件人: internet-dra...@ietf.org javascript:;
[mailto:internet-dra...@ietf.org javascript:; ]
发送时间: 2013年7月4日 12:00
收件人: Deng Lingli; Lingli Deng; Yan Zhang
主题: New Version Notification for draft-deng-alto-p2pcache-00.txt


A new version of I-D, draft-deng-alto-p2pcache-00.txt
has been successfully submitted by Lingli Deng and posted to the
IETF repository.

Filename:draft-deng-alto-p2pcache
Revision:00
Title:   Considerations for ALTO