Hi Richard, Thank you very much for your comments, please see inline.
From: alto [mailto:alto-boun...@ietf.org] On Behalf Of Y. Richard Yang Sent: Friday, June 27, 2014 11:46 PM To: 邓灵莉/Lingli Deng Cc: IETF ALTO Subject: Re: [alto] FW: New Version Notification for draft-deng-alto-p2p-ext-02.txt Hi Lingli, Sebastian, Haibin, Interesting doc! I am wondering the possibility of you adding an overview section to discuss the potential types of end point properties and your design guidelines so that we have a better understanding of the design: - For example, I do not have a feeling that the properties that the current draft defined are relatively complete. What is the potential set of properties and why you choose the ones? [Haibin] This is a very interesting question and should be seriously considered. We chose the ones in the draft due to people usually consider them for peer selection, and they were discussed during the early stage of ALTO working group. - One can convey the properties in multiple ways. For example, the current draft defines p2p_caching as a boolean. Another design possibility is to define a generic type with values including "p2p_cache", "super_peer", ... [Haibin] Yes. We need to choose one representation type. If several properties can be classified into one class, I agree one generic type name for the class (and then define the values) would be better. As another example we consider volume related property. The current draft defines a boolean. Another alternative is to use an numeric value of the exact cap. [Haibin] I'm not sure on this one. A user with 1G bytes and another user with 100M bytes mobile traffic quota might have the same strong will to not use his upload traffic. Another example is access network type. I saw the previous discussion on issues that technology types become obsolete and hence the change to avoid use them. One comment is that knowing network type can provide information about behaviors that an application may use -- Sebastian's comment has alluded to this as well. For example, by knowing that the end point is on an UMTS network, an application can understand that it will have the RRC statement machine running (DCH to FACH after 5 sec idle and FACH to IDLE after 12 sec idle) and hence the implications on power consumption as well as techniques to reduce energy (e.g., http://web.eecs.umich.edu/~fengqian/paper/thesis.pdf). [Haibin] Interesting idea, one question is, how can we assume that each application endpoint will easily understand that network type? IMHO, an application endpoint might prefer to choose sources with one access type than another. But if we want that endpoint to deeply understand that access type behaviors, it will be complicated? Is there a guiding principal that guides the selection and the approach of you define the properties (e.g., minimal information, no redundancy)? [Haibin] Now mainly choose the common properties that were discussed, but will think about it. Also, the updated charter defines a set of 4 questions that one may evaluate. It can be helpful if you discuss them when defining each property. [Haibin] Good suggestion. We will analyze them in the next revision. Thank you again, Richard! -Haibin Richard On Fri, Jun 27, 2014 at 6:32 AM, 邓灵莉/Lingli Deng <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
