Re: [alto] FW: New Version Notification for draft-deng-alto-p2p-ext-01.txt
Hi Sebastian, Thanks for your review and comments. More inline. Thanks, Lingli > -Original Message- > From: Sebastian Kiesel [mailto:ietf-a...@skiesel.de] > Sent: Thursday, June 26, 2014 6:26 PM > To: ?/Lingli Deng > Cc: alto@ietf.org > Subject: Re: [alto] FW: New Version Notification for > draft-deng-alto-p2p-ext-01.txt > > > Abstract: > > "In this document, we define endpoint property extensions besides peer > location that will impact peer selection." > > -> the ALTO core spec (RFC-to-be 7285) does not define peer location. > > Maybe better just say "In this document, we define additional endpoint > properties." [邓灵莉/Lingli Deng] Agreed. > > > ** > > > 3.1. Endpoint Property Type: p2p_caching > > looks good. > > only the encoding of true/false in JSON should be double-checked... is > an ASCII string the best way to do it? [邓灵莉/Lingli Deng] Boolean looks better. > > > 3.3. Endpoint Property Type: network_access > > Sorry to say, but frankly, I don't like this idea. > > I have two ideas how we could move forward, and we could to only one of > them or even both: > > 1.) define encodings for well-defined properties, e.g. provisioned > access link bandwidth in bps, or average RTT in idle network. > > Expect some pushback from the IETF community - we have been discussing > this for a while and there where many critics. But I don't think they > will accept a proposal that tries to camouflage its true spirit by using > technology names instead of Mbps. [邓灵莉/Lingli Deng] Yes, we just got feedback from Michael on this one. > > > and/or > > 2.) define a pure numerical "relative access link type preference", > similar to what we did with the "routingcost" property in the base > document. Just say that "higher number is better", and leave it up > to the opoerator of the ALTO server to define what the numbers mean. > > For example, you could use for now > > 1 = DSL > 10 = FTTB > 12 = FTTH > 50 = DC > > and if, in some years, some new technology better than FTTH appears, you > could say 100=new_technology without changing any spec. [邓灵莉/Lingli Deng] Good point. We would be happy to revise the draft and go this way. > > > ** > > > Additional idea: at least in Europe, many wireless operators offer some > low-cost plans, which limit the amount of data to be transmitted within > a month to some gigabytes. After that they will throttle your bandwidth > or charge extra money. similar to battery powered devices, hosts with > such a tariff should be avoided. Maybe define an additional property? [邓灵莉/Lingli Deng] This is interesting. We are doing the same thing in China. I agree we can have an additional endpoint property for it. > > > ** ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] FW: New Version Notification for draft-deng-alto-p2p-ext-01.txt
Hi Lingli and Haibin, On Tue, Jun 24, 2014 at 09:36:56AM +0800, ?/Lingli Deng wrote: > Hi all, > > A revision to the endpoint property extension draft for P2P networks is newly > submitted for your discussion. > http://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-01.txt > It discusses three types of property extensions for better guided peer > selection. > > You review and comments would be highly appreciated. here is a review of your draft. I hope this is helpful to you. Sebastian ** Abstract: "In this document, we define endpoint property extensions besides peer location that will impact peer selection." -> the ALTO core spec (RFC-to-be 7285) does not define peer location. Maybe better just say "In this document, we define additional endpoint properties." ** 3.1. Endpoint Property Type: p2p_caching looks good. only the encoding of true/false in JSON should be double-checked... is an ASCII string the best way to do it? ** 3.2. Endpoint Property Type: battery_limited I like this one! again, think about the encoding of true/false. ** 3.3. Endpoint Property Type: network_access Sorry to say, but frankly, I don't like this idea. First, because it enumerates specific technologies (DSL, FTTx, ...). Technologies will become obsolete sooner or later, while RFCs live forver (or they need to be updated, which is difficult). What would you do now if someone had written down this as an RFC, say, some 15 years ago? Then there would be "analog modem" , "ISDN", and "DSL". How would you use that today? Second, when someone reads that section, I think everybody will get the idea that FTTH is "better" than FTTB, which is "better" than DSL. But is this always true? Might depend what your most important criterion is, e.g. bandwidth, delay, jitter, reliability. The performance of a link that is shared by many users depends on the number of the users - if there are only few other users, your share of the overall capacity might be higher than in a system which gives you some guaranteed exclusive capacity for you. Another example: in some rural areas I have experienced that 3G wireless connectivity is in reality much better than the "up to 50 Mbps" DSL which gives you in reality only very little throughput due to long and bad copper wires. I have two ideas how we could move forward, and we could to only one of them or even both: 1.) define encodings for well-defined properties, e.g. provisioned access link bandwidth in bps, or average RTT in idle network. Expect some pushback from the IETF community - we have been discussing this for a while and there where many critics. But I don't think they will accept a proposal that tries to camouflage its true spirit by using technology names instead of Mbps. and/or 2.) define a pure numerical "relative access link type preference", similar to what we did with the "routingcost" property in the base document. Just say that "higher number is better", and leave it up to the opoerator of the ALTO server to define what the numbers mean. For example, you could use for now 1 = DSL 10 = FTTB 12 = FTTH 50 = DC and if, in some years, some new technology better than FTTH appears, you could say 100=new_technology without changing any spec. ** Additional idea: at least in Europe, many wireless operators offer some low-cost plans, which limit the amount of data to be transmitted within a month to some gigabytes. After that they will throttle your bandwidth or charge extra money. similar to battery powered devices, hosts with such a tariff should be avoided. Maybe define an additional property? ** ___ 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?
Hi Michael, Thank you very much for your comments and sending the comment to the list! And in my memory, this was debate in this working group about the privacy of network access type. But I do not remember there was a consensus. Thank you very much for pointing it out. I think even some people may have concern on it, but those properties could be used in some constraint environment. Or use it in another way. Sebastian gave an idea that we can use relative numbers to indicate the endpoint's provisioned bandwidth instead of access type, which is similar to what we have used to indicate the cost in the alto protocol. I think this is more useful than access type, and can also in somewhat relief the privacy concern? BR, -Haibin -Original Message- From: Scharf, Michael (Michael) [mailto:michael.sch...@alcatel-lucent.com] Sent: Thursday, June 26, 2014 5:59 PM To: IETF ALTO Cc: Songhaibin (A) Subject: Potential privacy issue in draft-deng-alto-p2p-ext-01? 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. Michael ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
[alto] Potential privacy issue in draft-deng-alto-p2p-ext-01?
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. Michael ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
