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