Re: [alto] FW: New Version Notification for draft-deng-alto-p2p-ext-02.txt
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). 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. 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.commailto:haibin.s...@huawei.com wrote: Hi Richard, Thank you very much for your comments, please see inline. From: alto [mailto:alto-boun...@ietf.orgjavascript:;] 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
Re: [alto] I-D Action: draft-wu-alto-te-metrics-02.txt
Hi Qin, Richard, Thank you for this discussion and the ALTO Cost value description attributes. Please see below, Best regards Sabine De : Qin Wu [mailto:bill...@huawei.com] Envoyé : samedi 28 juin 2014 07:59 À : Y. Richard Yang Cc : alto@ietf.org; RANDRIAMASY, SABINE (SABINE) Objet : RE: I-D Action: draft-wu-alto-te-metrics-02.txt 发件人: yang.r.y...@gmail.commailto:yang.r.y...@gmail.com [mailto:yang.r.y...@gmail.com] 代表 Y. Richard Yang 发送时间: 2014年6月28日 11:47 收件人: Qin Wu 抄送: alto@ietf.orgmailto:alto@ietf.org; RANDRIAMASY, SABINE (SABINE) 主题: Re: I-D Action: draft-wu-alto-te-metrics-02.txt Thanks for posting the new version. Let me add my view on the issue when defining the metrics. Please see below. On Fri, Jun 27, 2014 at 11:20 PM, Qin Wu bill...@huawei.commailto:bill...@huawei.com wrote: Hi, all: Here is the update to draft-wu-alto-te-metrics http://tools.ietf.org/html/draft-wu-alto-te-metrics-02 The diff is: http://www.ietf.org/rfcdiff?url2=draft-wu-alto-te-metrics-02 The main changes are 1. Remove the Cost Mode part as these metrics are intended to be used in various cost modes. 2. Move Collection method part to new section(i.e., section 2) since they are common part for these metrics. 3. Other editorial changes, e.g., remove duplicated part in each new defined metrics. There is one remaining issue in this draft, i.e., do we need to specify the measurement interval for each metrics In details in this draft. In the current draft, we assume using a fixed, small measurement interval. However this may be not enough for ALTO setting. we may need to support more complicated use case,e.g., bandwidth calendaring. I like it that you raise the issue on defining the semantics of revealed metrics. For example, when an ALTO sever says that routingcost = 10 (or delay = 10 ms using a new metric defined in the document), what does it mean? The charter of ALTO is that it does not deal with round-trip level dynamic information. Hence, one should interpret the number as a longer-time scale number. But how long? Does it reflect diurnal pattern? Does it mean that the value is 10 in the last 15 sec, 30 sec, 1 min, 1 hour, 1 day, 1 week, etc. [Qin]: I realized we should distinguish measure interval from how often the value is reported from the server to the client Usually the value is measured at fixed measurement interval. When the server receive these values, they can do aggregation and report in the array of several measured value or report the latest value. [SR ] [ SR ] Indeed, each ALTO Server may decide to aggregate measured values over intervals that it specifies and are usually longer than the RFC6390 « measurement timing ». At least because ALTO is no real time information service and will unveil TE metric information only if abstracted. On the other hand, TE values implicitly call for some reliability and accuracy and an ALTO Client does not want to make too frequent requests and should be able to evaluate the level of accuracy and reliability of the provided ALTO TE values. This positions « ALTO TE metric” w.r.t classical « TE metrics » specified e.g. in other [RFC3630], [RFC3784] or [BGP-LS]. Given the increasing interest in handling calendaring (e.g., there is a paper in the coming SIGCOMM on WAN Calendaring), I feel that it is time to be slightly more explicit. Long-term is not equivalent to be fuzzy. Specifically, I feel that a reasonable metric should include the following: - measurement start time, measurement finish time, the statistics operator (e.g., avg, vs mean, vs x-percentile) or - measurement window (assuming finish time is around the query time) and the statistics operator. [Qin]: These are very closed to what we proposed in last London meeting when we presented this draft. What is different, the measurement period is replaced with measurement window and you add a lot of statistics operators which looks good to me. [ ] [ ] agree, this is necessary for the ALTO Client to interpret the value it gets. In addition to such information, I would like to propose the following to the list and ask for feedback: Each metric described in the draft has a set of sections on Metric Description Fields (MDF for short): name, string, description, unit etc... I suggest to add for each metric, a MDF field called for example ALTO sample interval. This field would give a clue on the accuracy of the measurement. Some text to start with could be for example: ALTO Sample interval: The ALTO Server may collect values from the sources measurements done e.g. every 1 second over a period of 30 seconds. The ALTO Server may then aggregate these values over ALTO Sample intervals of at least 30 seconds and provide updates every hour. The ALTO Client may then assume that the ALTO TE values provided in an ALTO Sample interval are stationary.. For values with “ short stationarity” and also to minimize ALTO transactions, an alternative may be that the
[alto] Agenda requests for IETF90
Hi all, the chairs are now collecting proposals for allocating live meeting slots at the upcoming IETF-90. Please send your requests -- resend, if you have sent them already -- by Friday, July 4th. A draft agenda will be posted next Monday for everyone to comment. Enrico smime.p7s Description: S/MIME Cryptographic Signature ___ 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?
On 06/28/2014 01:00 AM, Songhaibin (A) wrote:
Perhaps a midway could be to see if we can use the provisioned
bandwidth for a set of (anonymous) subscribers instead of singleton
subscribers. That way, the larger herd provides some modicum of
anonymity to an individual subscriber who is part of the herd.
So just ranking a list of endpoints from the perspective of
provisioned bandwidth will alleviate the privacy issue. I think it is
possible to do it in this way.
Haibin: Yes, that is one potential way to alleviate the privacy issue
if a provisioned bandwidth is necessary for an ALTO service. Reinaldo
has provided some input as well; my preference would be to start
thinking of such privacy issues right at the onset so we have a
reasonable idea of the pros and cons of any solution that the WG
comes up with.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
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?
On 06/28/2014 12:55 AM, Songhaibin (A) wrote:
However, I also suspect that the privacy concerns on *provisioned*
access bandwidth are still intact since they will tend to point to
subscribers that are outliers.
I'm not sure I understand this sentence due to my poor English. By
outlier do you mean some exceptional/abnormal provisioned bandwidth
value bound to an endpoint property?
Haibin: Your English is excellent, and yes, that is what I meant.
If the endpoints with higher provisioned access bandwidth would be
pointed more often than other endpoints, you imply the privacy
concern is: those endpoints do not want to be recognized?
It's more than those endpoints don't want to be recognized, the question
is: has the subscriber corresponding to the endpoint provided consent
to allow his/her provisioned bandwidth to be distributed by ALTO?
Thanks,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
___
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?
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. Sebastian ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
