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

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Tue, 24 Jun 2014 09:36:56 +0800

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: [email-masked] [mailto:[email-masked]]
> 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

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 26 Jun 2014 12:25:32 +0200

Hi Lingli and Haibin,

> 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?

**********

---

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Thu, 26 Jun 2014 19:27:01 +0800

Hi Sebastian,

Thanks for your review and comments.
More inline.

Thanks,
Lingli

> From: Sebastian Kiesel [mailto:[email-masked]]
> Sent: Thursday, June 26, 2014 6:26 PM
> To: ?????????/Lingli Deng
> Cc: [email-masked]
> Subject: Re: [alto] FW: New Version Notification for
> draft-deng-alto-p2p-ext-01.txt
> 
> 
> Abstract:
> 
[邓灵莉/Lingli Deng] Agreed.
[邓灵莉/Lingli Deng] Boolean looks better.
> technology names instead of Mbps.
[邓灵莉/Lingli Deng] Yes, we just got feedback from Michael on this one.
> 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.
[邓灵莉/Lingli Deng] This is interesting. We are doing the same thing in China. 
I agree we can have an additional endpoint property for it.

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 27 Jun 2014 12:40:55 -0400

On Thu, Jun 26, 2014 at 7:27 AM, 邓灵莉/Lingli Deng <[email-masked]
> wrote:

> [yry] I support both, instead of only one, as appeared in -02. Please see
below.

> [邓灵莉/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

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================