Re: [alto] FW: New Version Notification for draft-deng-alto-p2p-ext-01.txt
> > 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: [yry] I support both, instead of only one, as appeared in -02. Please see below. > 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. This is a very good and interesting discussion. Here is one perspective on considering technology name and provisioned bandwidth. One guideline that one may use is non-dominant. Specifically, for a given set of metrics of concern (e.g., throughput, energy efficiency), and two pieces of information items i1 and i2, if knowing i1 implies i2 completely, then i1 dominates i2 and hence i2 is redundant. In our setting, I see neither technology name dominating provisioned bandwidth nor provisioned bandwidth dominating technology name (e.g., the radio resource control example I mentioned in the previous email). Hence, I see value in exporting both, depending on the broad setting. [邓灵莉/Lingli Deng] This is an interesting reasoning and very useful way of designing. As long as people see value in other information that can be derived from the access technology besides provisioned bandwidth, the two should not be bounded together. One issue of using non-dominant is that life is complex and few dominant cases happen :-) One idea is to consider impact levels. For example, experimental design evaluates the impacts of multiple parameters and assigns a weight to the contribution level of each parameter. Then a system uses only those with the highest weight levels. Using this guideline, I do see that provisioned bandwidth may provide more value than technology name in many settings. Hence, I agree that if we have to choose one, it is the provisioned bandwidth. Richard > > > 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 -- -- = | Y. Richard Yang| | Professor of Computer Science | | http://www.cs.yale.edu/~yry/| = ___ 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
On Thu, Jun 26, 2014 at 7:27 AM, 邓灵莉/Lingli Deng wrote: > 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: > > [yry] I support both, instead of only one, as appeared in -02. Please see below. > > 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. > This is a very good and interesting discussion. Here is one perspective on considering technology name and provisioned bandwidth. One guideline that one may use is non-dominant. Specifically, for a given set of metrics of concern (e.g., throughput, energy efficiency), and two pieces of information items i1 and i2, if knowing i1 implies i2 completely, then i1 dominates i2 and hence i2 is redundant. In our setting, I see neither technology name dominating provisioned bandwidth nor provisioned bandwidth dominating technology name (e.g., the radio resource control example I mentioned in the previous email). Hence, I see value in exporting both, depending on the broad setting. One issue of using non-dominant is that life is complex and few dominant cases happen :-) One idea is to consider impact levels. For example, experimental design evaluates the impacts of multiple parameters and assigns a weight to the contribution level of each parameter. Then a system uses only those with the highest weight levels. Using this guideline, I do see that provisioned bandwidth may provide more value than technology name in many settings. Hence, I agree that if we have to choose one, it is the provisioned bandwidth. Richard > > > > > > 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 > -- -- = | Y. Richard Yang| | Professor of Computer Science | | http://www.cs.yale.edu/~yry/| = ___ 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 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
[alto] FW: New Version Notification for draft-deng-alto-p2p-ext-01.txt
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. Many thanks, Lingli > -Original Message- > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > Sent: Tuesday, June 24, 2014 9:20 AM > To: Deng Lingli; Haibin Song; Lingli Deng; Haibin Song > Subject: New Version Notification for draft-deng-alto-p2p-ext-01.txt > > > A new version of I-D, draft-deng-alto-p2p-ext-01.txt > has been successfully submitted by Lingli Deng and posted to the > IETF repository. > > Name: draft-deng-alto-p2p-ext > Revision: 01 > Title:End Point Properties for Peer Selection > Document date:2014-06-24 > Group:Individual Submission > Pages:7 > URL: > http://www.ietf.org/internet-drafts/draft-deng-alto-p2p-ext-01.txt > Status: https://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/ > Htmlized: http://tools.ietf.org/html/draft-deng-alto-p2p-ext-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-deng-alto-p2p-ext-01 > > 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 endpoint >property extensions besides peer location that will impact peer >selection. > > > > > > 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
