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 <yry@cs.yale.edu>   |

| Professor of Computer Science       |

| http://www.cs.yale.edu/~yry/        |

 =====================================