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 class, I agree one generic type name for the class (and then define the values) would be better. [yry] It depends on the setting. In other words, do you need a type or types (set)... As another example we consider volume related property. The current draft defines a boolean. Another alternative is to use a 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. [yry] interesting point! I often set a limit on my android, when I am traveling and using a data plan with a cap that I may exceed quickly. This leads to the following question: such info comes from endpoint itself, instead of the provider. Hence, I see two protocol flow possibilities: Option 1: provider provides its set of info (say ALTO on data plan cap) to app + endpoint provides its set of info to app directly; vs Option 2: endpoint sends such info to provider, and ALTO sever aggregates all info to allow app access. In both cases endpoint can inject policy on access control. Option 1 appears to allow more fine-grained access control (user approval on per app basis). 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? [yry] I am thinking of going beyond p2p but more advanced app. The paper I cited showed that some advanced apps can benefit from knowing the properties, inherent in technology type. 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. [yry] Good idea. You have a good head start, and I am looking forward to reading the next version which discusses some of the preceding issues in more details! Richard Thank you again, Richard! -Haibin 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
