[alto] fwd: I-D Action: draft-kiesel-alto-ip-based-srv-disc-03.txt
Dear ALTO WG members, this draft is a candidate for our charter item: One or more alternatives to the base ALTO server discovery mechanism (RFC-to-be) to accommodate environments where (1) timely deployment of existing mechanisms, including the base ALTO server discovery mechanism, is unlikely,. IP anycasting is a concept that is already in broad use, e.g., for DNS root servers. So this document falls into the category If such discovery mechanisms can be reused, the WG will produce one or more documents to specify how they may be adopted as additional or alternative ALTO server discovery mechanisms. Comments welcome. Thanks Sebastian - Forwarded message from internet-dra...@ietf.org - Date: Tue, 01 Jul 2014 09:40:51 -0700 From: internet-dra...@ietf.org To: i-d-annou...@ietf.org Subject: I-D Action: draft-kiesel-alto-ip-based-srv-disc-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Application-Layer Traffic Optimization (ALTO) Anycast Address Authors : Sebastian Kiesel Reinaldo Penno Filename: draft-kiesel-alto-ip-based-srv-disc-03.txt Pages : 15 Date: 2014-07-01 Abstract: The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. This document establishes a well-known IP address for the ALTO service and specifies how ALTO clients embedded in the resource consumer can use it to access the ALTO service. Terminology and Requirements Language This document makes use of the ALTO terminology defined in RFC 5693 [RFC5693]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kiesel-alto-ip-based-srv-disc/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-kiesel-alto-ip-based-srv-disc-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-kiesel-alto-ip-based-srv-disc-03 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 - End forwarded message - ___ 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?
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
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
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
[alto] ALTO topology/graph representation (Fwd: New Version Notification for draft-yang-alto-topology-03.txt)
Dear all, We have submitted an update of the net-graph draft below. The goal of the draft is to study the graph representation WG item. Here is a quick summary of some key components of the draft and related issues: 1. A parallel draft by Michael Scharf (who is a co-author of this draft) as well will be posted soon. Michael's draft will emphasize more on the scope of the work, to avoid conflict with the Routing Area. 2. The draft uses a simple multi-flow scheduling use case to argue that we need an path-vector + X representation. We do not have a formal proof that path-vector must be used, but we do not see an alternative without using path-vectors to convey network policies. This is important given that ALTO targets applications and hence needs to convey network policy constraints. If you have a counter-argument (i.e., solution), or a more formal argument, we are eager to listen to your point of view. 3. The draft gives two possibilities for the aforementioned X to complete the design: (1) X is an unstructured hash from network element to element properties, and (2) X is a node-edge graph representation. In (1), there is actually no need to distinguish between nodes and edges. From the multi-flow use case alone, we cannot make a convincing argument that we need the more structured case of (2). To finish the argument for using X = node-edge graph, we feel that we will have to need an application-layer guided network-layer routing (e.g., SDN) use case. Any insightful input/comments on this aspect will be highly interesting and appreciated! Richard -- Forwarded message -- From: internet-dra...@ietf.org Date: Wed, Jul 2, 2014 at 12:58 AM Subject: New Version Notification for draft-yang-alto-topology-03.txt To: Greg Bernstein gr...@grotto-networking.com, Michael Scharf michael.sch...@alcatel-lucent.com, Y. Richard Yang y...@cs.yale.edu, Young Lee leeyo...@huawei.com, Wendy Roome w.ro...@alcatel-lucent.com A new version of I-D, draft-yang-alto-topology-03.txt has been successfully submitted by Y. Richard Yang and posted to the IETF repository. Name: draft-yang-alto-topology Revision: 03 Title: ALTO Topology Extensions Document date: 2014-07-01 Group: Individual Submission Pages: 16 URL: http://www.ietf.org/internet-drafts/draft-yang-alto-topology-03.txt Status: https://datatracker.ietf.org/doc/draft-yang-alto-topology/ Htmlized: http://tools.ietf.org/html/draft-yang-alto-topology-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-yang-alto-topology-03 Abstract: The Application-Layer Traffic Optimization (ALTO) Service has defined Network and Cost maps to provide basic network information. In this document, we discuss an initial design to provide abstracted graph representations of network topology, motivated by a basic application use case of multi-flow scheduling. The design is based on the ALTO WG discussions at IETF 89. 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 -- -- = | 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
