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

["Y. Richard Yang" <[e-mail]>]

Hi Michael,

Good comments!

On Mon, Jun 30, 2014 at 5:43 AM, Scharf, Michael (Michael) <
[e-mail]> 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:[e-mail]] *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) <[e-mail]> wrote:
>
> Hi Richard,
>
> Thank you very much for your comments, please see inline.
>
> From: alto [mailto:[e-mail]] 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 <
> [e-mail]> 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: [e-mail] [mailto:[e-mail]]
> > 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
>
>