[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07

ALTO Working Group                                               L. Deng
INTERNET-DRAFT                                              China Mobile
Intended Status: Standard Track                                  H. Song
Expires: Febuary 5, 2015                                          Huawei
                                                               S. Kiesel
                                                 University of Stuttgart
                                                            July 4, 2014


                End Point Properties for Peer Selection
                       draft-deng-alto-p2p-ext-03

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 the peering node.  In this document, we define
   additional endpoint properties.



Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.



Deng, et al.              Expires Feb 5, 2015                     Page 1

INTERNET DRAFT     <EP Extensions for Peer Selection>        Jul 4, 2014


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4  End Point Extensions  . . . . . . . . . . . . . . . . . . . . .  5
     4.1 location-related properties  . . . . . . . . . . . . . . . .  6
     4.2 network-related properties . . . . . . . . . . . . . . . . .  6
       4.2.1 Endpoint Property Type: network_access . . . . . . . . .  6
       4.2.2 Endpoint Property Type: access_preference  . . . . . . .  6
     4.3 node-related properties  . . . . . . . . . . . . . . . . . .  6
       4.3.1 Endpoint Property Type: participating_role . . . . . . .  6
       4.3.2 Endpoint Property Type: battery_limited  . . . . . . . .  7
     4.4 subscription-related properties  . . . . . . . . . . . . . .  7
       4.4.1 Endpoint Property Type: volume_limited . . . . . . . . .  7
       4.4.2 Endpoint Property Type: provisioned_bandwidth  . . . . .  7
   5  Security Considerations . . . . . . . . . . . . . . . . . . . .  8
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  8
   7  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  8
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1  Normative References  . . . . . . . . . . . . . . . . . . .  9
     8.2 Informative References . . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
















Deng, et al.              Expires Feb 5, 2015                     Page 2

INTERNET DRAFT     <EP Extensions for Peer Selection>        Jul 4, 2014


1  Introduction

   The initial purpose for ALTO protocol is to provide better than
   random peer selection for p2p networks.  In this document, we define
   extended endpoint property extensions that will provide guidance for
   both p2p and other applications.

2  Overview

   It is expected that EP properties from the following aspects can be
   useful for an ALTO client to provide better user experience or avoid
   performance degradation due to the ignorance of these EP specific
   information:

   o location related properties, the information about the geographic
   location of the end point;

   o network related properties, the information about the accessing
   network of the end point, such as the type or configuration of the
   access network (e.g. 2G/3G/4G, WLAN, DSL, etc.);

   o node related information, the information about the end point's
   local features, such as software/hardware configuration and the
   participating role of the end point (e.g. as a end user, or a CDN
   server, or a P2P cache, etc.);

   o subscription related properties, the information about the service
   provision agreement between the end point's owner (i.e. the
   subscriber) and the network provider.

   2.1 Guidelines and Methodology

   The most basic principle would be to maintain the EP property set to
   a minimum, which in turn implies two guidelines: non-redundancy and
   generality.

   o Non-redundancy, refers to the guideline that there is no complete
   coverage between any two properties.

   o Generality, refers to the guideline that any property defined
   should be generally applicable to a group of settings. It is not
   economic to define a property which is bounded to be used only by a
   single type of applications or for EPs within a single deployment
   scenarios.

   In order to make sure that the properties as defined in this document
   fulfill the above principle and guidelines, we intend to justify each
   property's definition using the following methodology:



Deng, et al.              Expires Feb 5, 2015                     Page 3

INTERNET DRAFT     <EP Extensions for Peer Selection>        Jul 4, 2014


   Firstly, (usefulness) there should be clear motivation and
   application scenarios that justify the necessity and value for
   providing such EP property for peer selection.

   Secondly, (non-redundancy) to ensure non-redundancy, whenever a new
   property is defined, it should be analyzed that whether there is any
   overlap with any pre-defined EP property or can it be deduced from
   one or multiple pre-defined EP properties. We should avoid defining
   such redundant properties, but keep the discussion and suggestions
   for substitution or construction from other defined properties in the
   document.

   Thirdly, (case-independency) when designing the concrete information
   model for the properties, it is suggested to group
   application/deployment specific information into more general
   property definition (with different value for different
   applications/scenarios).


   2.2 Privacy considerations

   Privacy considerations is especially critical to EP property
   information exposure in ALTO, as they are by definition more
   stationary information regarding the subscriber of a specific end
   point.

   However, each user may have different concerns or sensitive
   preference over a specific EP property. For example, endpoint
   property regarding to the service role of the endpoint, such like P2P
   caching server, or CDN node. Therefore, it may be necessary to
   provide a mechanism to accommodate this type of individual
   customization by providing a channel for an end point to explicitly
   indicate this information based on its own preference.

   Fortunately, there are generally applicable schemes to be used to
   address the privacy protection concerns, which may be applicable to a
   group of EP properties and can be configured by the ISP or the EP
   subscriber.

   On the one hand, the privacy concern is unnecessary if the specific
   endpoint property can also be measured/disclosed in another way. The
   privacy concern regarding to the accurate information of the endpoint
   would be alleviated if using relative numbers to rank them. For
   deployment considerations, it is also possible for each endpoint to
   make the choice whether to disclose the relative information or not,
   but an incentive could be used to encourage the disclosure when it is
   beneficial to the application.




Deng, et al.              Expires Feb 5, 2015                     Page 4

INTERNET DRAFT     <EP Extensions for Peer Selection>        Jul 4, 2014


   On the other hand, access control to sensitive property information
   may also be used to mitigate the privacy concern of a defined
   property. Even greater flexibility can be delivered by access control
   at the discretion of both the network operator and the individual
   subscriber, which is out of scope for this document.

   2.3 Relation with other properties

   Endpoint information can be extremely dynamic or relatively static.
   Currently, this specification does not intend to provide any real-
   time properties such like the available bandwidth from the endpoint
   [I-D.draft-wu-alto-te-metrics], which is extremely hard to measure
   and change frequently. But some relatively static properties could be
   provided, for example, by defining the available bandwidth from the
   endpoint to be green, yellow and red, such information can be
   disclosed and be useful when other endpoints consider to connect to
   it.

   The basic end point properties as defined in this document, may in
   turn be used to derive PID properties [I-D.draft-roome-alto-pid-
   properties] for the corresponding peer group, which can also be used
   as one of the alternatives for the ALTO serve to directly expose
   sensitive end point information to distrusted applications.

   2.4 Information flow

   Endpoint properties can be retrieved and aggregated into the ALTO
   server in two ways, one is from the endpoint itself, and the other is
   from the service provider which provides network service to the
   endpoint. An endpoint can discover the ALTO server with ALTO
   discovery mechanisms, and then setup a communication channel with its
   ALTO server, and after that the endpoint property from the endpoint
   itself can be reported. The ALTO server can also be configured to
   access the Network Management System server or other similar servers
   provided by the network service provider for the subscription
   information and etc.

3  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document makes use of the ALTO terminology defined in RFC 5693
   [RFC5693].

4  End Point Extensions




Deng, et al.              Expires Feb 5, 2015                     Page 5

INTERNET DRAFT     <EP Extensions for Peer Selection>        Jul 4, 2014


   This document defines new endpoint property types for the ALTO
   protocol [RFC 7285].

4.1 location-related properties TBA.

4.2 network-related properties

4.2.1 Endpoint Property Type: network_access

   One important endpoint property that will impact peer selection is
   the node access type.  If it is a node owned by a home subscriber,
   the access type can be DSL, FTTB, or FTTH.  If it is deployed in a
   data center, one may prefer to specify a special access type for it,
   because it is likely to be more robust, and have more network
   resources than home users.  A p2p application may have its own
   algorithm for peer selection if the node access type information can
   be provided.

   The value for this property can be enumerated as "adsl", "ftth",
   "fttb", "dc", and etc.

4.2.2 Endpoint Property Type: access_preference

   In case that the end point has its own privacy concerns in revealing
   its access network type directly to potentially distrusted
   applications through ALTO, another indirect way of exposing the
   similar information can be used by "access_preference".

   The value for this property (defined as integer) can be set by the
   ISP of the ALTO server, based on its own relative preference to
   different network access types. A peer with the higher value is more
   preferable than another peer with the lower value.

   For example, an ISP could use the following setting for now:

    1 = DSL; 10 = FTTB; 12 = FTTH; 50 = DC;

   and add "100=new_technology", when some new technology better than
   FTTH appears later.

4.3 node-related properties

4.3.1 Endpoint Property Type: participating_role

   Different types of end points have different roles or participating
   policies for a given application, which can be explored in making a
   better decision when choosing a serving node. For example, as
   described in [I-D.draft-deng-alto-p2pcache], P2P caching node can



Deng, et al.              Expires Feb 5, 2015                     Page 6

INTERNET DRAFT     <EP Extensions for Peer Selection>        Jul 4, 2014


   also act as p2p peers in a p2p network.  If a p2p caching peer is
   located near the edge of the network, it will reduce the backbone
   traffic, as well as the uploading traffic.  [RFC7069] provides one
   example of such caching nodes.  P2P caching peers are usually
   expected to be given higher priority than the ordinary peers for
   serving a content request so as to optimize the network traffic.  So
   it's necessary for the endpoint property to support this indication.

   In general, the end points which belong to different participating
   parties (subscriber, ISP, or ICP) within an application's service
   transaction demonstrate different role/policies.

   The value for this property can be enumerated as "user", "p2pcache",
   "super-node", etc.

4.3.2 Endpoint Property Type: battery_limited

   Another important endpoint property that will impact peer selection
   is what kind of power supply the peer has.  It can be either the
   electric power or the battery supply.  And for most of the time, it
   is safe to bet that electric power supplied nodes would stay online
   longer than those battery supplied nodes.  And most of the nowadays
   intelligent equipments are aware of their power supply type.  But it
   is necessary that the power supply of a peer can be queried through
   some method no matter whether or not it is limited by its battery.

   The value for this property (defined as a boolean) is either "true"
   or "false". If the peer in question is actually battery-limited, the
   value of this property wrt the peer is set to "true".

4.4 subscription-related properties

4.4.1 Endpoint Property Type: volume_limited

   Many wireless operators offer low-cost plans, which limit the amount
   of data to be transmitted within a month to some gigabytes. After
   that they will throttle the subscriber's bandwidth or charge extra
   money. Hosts with such a tariff, could be tagged by another endpoint
   property "volume_limited" and should be avoided for peer selection.

   The value for this property (defined as a boolean) is either "true"
   or "false". If a peer is constrained by such a subscription plan, the
   value of this property wrt the peer is set to "true".


4.4.2 Endpoint Property Type: provisioned_bandwidth TBA.





Deng, et al.              Expires Feb 5, 2015                     Page 7

INTERNET DRAFT     <EP Extensions for Peer Selection>        Jul 4, 2014


5  Security Considerations

   TBA.


6  IANA Considerations

   This document adds the following new endpoint property types to the
   existing registry created by ALTO protocol [RFC7285].

      +----------------------+---------------------------------------+
      |Identifier            |Intended Semantics                     |
      +----------------------+---------------------------------------+
      |geo-location          |TBA.                                   |
      +----------------------+---------------------------------------+
      |participating_role    |The type of end point's role, value    |
      |(string)              |is enumerated as "user", "p2pcache"    |
      |                      |"super-node", etc. in ASCII.           |
      +----------------------+---------------------------------------+
      |battery_limited       |Whether the peer is battery-limited,   |
      |(boolean)             |value is "true" or "false".            |
      +----------------------+---------------------------------------+
      |network_access        |The type of access network of the peer,|
      |(string)              |value is enumerated as "adsl", "ftth", |
      |                      |"fttb", "dc", in ASCII.                |
      +----------------------+---------------------------------------+
      |link_preference       |The relative preference from the ISP's |
      |(number)              |point of view based on the type of     |
      |                      |network access of the peer, value is   |
      |                      |a integer.                             |
      +----------------------+---------------------------------------+
      |volume_limited        |Whether the peer's plan is constrained,|
      |(boolean)             |value is "true" or "false".            |
      +----------------------+---------------------------------------+
      |provisioned_bandwidth |TBA.                                   |
      +----------------------+---------------------------------------+

7  Acknowledgements

   The authors would like to thank Richard Yang, Michael Scarf, Vijay
   Gurbani, Reinaldo Penno and Sabine Randriamsy for their review and
   valuable comments.









Deng, et al.              Expires Feb 5, 2015                     Page 8

INTERNET DRAFT     <EP Extensions for Peer Selection>        Jul 4, 2014


8  References

8.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


   [RFC7285] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
              RFC7285, March 2014.

8.2 Informative References

   [I-D.draft-deng-alto-p2pcache] Deng, L., Chen, W., and Q. Yi,
              "Considerations for ALTO with network-deployed P2P
              caches", draft-deng-alto-p2pcache-03 (work in progress),
              February 2014.

   [RFC7069]  Alimi, R., Rahman, A., Kutscher, D., Yang, Y., Song, H.,
              and K. Pentikousis, "DECoupled Application Data Enroute
              (DECADE)", RFC 7069, November 2013.

   [I-D.draft-roome-alto-pid-properties] Roome, W. and Yang, R., "PID
              Property Extension for ALTO Protocol", draft-roome-alto-
              pid-properties-01 (work in progress), February 2014.

   [I-D.draft-wu-alto-te-metrics] Wu, Q., Yang, R., Lee, Y., and
              Randriamasy, S., "ALTO Traffic Engineering Cost Metrics",
              draft-wu-alto-te-metrics-03 (work-in-progress), June 2014.






















Deng, et al.              Expires Feb 5, 2015                     Page 9

INTERNET DRAFT     <EP Extensions for Peer Selection>        Jul 4, 2014


Authors' Addresses


   Lingli Deng
   China Mobile
   China

   Email: denglingli@chinamobile.com



   Haibin Song
   Huawei
   China

   Email: haibin.song@huawei.com



   Sebastian Kiesel
   University of Stuttgart, Computing Center
   Germany

   Email: ietf-alto@skiesel.de



























Deng, et al.              Expires Feb 5, 2015                    Page 10


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/