Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Deng Lingli , Haibin Song , Sebastian Kiesel
Last updated 2014-06-27
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-deng-alto-p2p-ext-02
LMAP Working Group                                               L. Deng
INTERNET-DRAFT                                              China Mobile
Intended Status: Standard Track                                  H. Song
Expires: January 28, 2015                                         Huawei
                                                               S. Kiesel
                                                 University of Stuttgart
                                                           June 27, 2014

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

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 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 January 28, 2015                [Page 1]
INTERNET DRAFT     <EP Extensions for Peer Selection>      June 27, 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  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3 End Point Extensions . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Endpoint Property Type: p2p_caching  . . . . . . . . . . .  3
     3.2.  Endpoint Property Type: battery_limited  . . . . . . . . .  3
     3.3.  Endpoint Property Type: access_preference  . . . . . . . .  4
     3.4.  Endpoint Property Type: volume_limited . . . . . . . . . .  4
   4 Security Considerations  . . . . . . . . . . . . . . . . . . . .  4
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
   6. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . .  5
   7  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     7.1  Normative References  . . . . . . . . . . . . . . . . . . .  6
     7.2 Informative References . . . . . . . . . . . . . . . . . . .  6
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7

 

<Deng, et al.>          Expires January 28, 2015                [Page 2]
INTERNET DRAFT     <EP Extensions for Peer Selection>      June 27, 2014

1  Introduction

   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 extended
   endpoint property extensions that will impact peer selection.

2  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].

3 End Point Extensions

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

3.1.  Endpoint Property Type: p2p_caching

   As described in [I-D.draft-deng-alto-p2pcache], P2P caching node can
   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.

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

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 whether or not the power supply of a peer is
   limited by its battery can be queried through some method.

 

<Deng, et al.>          Expires January 28, 2015                [Page 3]
INTERNET DRAFT     <EP Extensions for Peer Selection>      June 27, 2014

   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".

3.3.  Endpoint Property Type: access_preference

   The third 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 (Digital Subscriber Line), FTTB (Fiber To
   The Building), or FTTH (Fiber To The Home).  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 (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.

3.4.  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 Security Considerations

   The indication of new endpoint properties to the ALTO clients may set
   targets for the malicious nodes to hack.

 

<Deng, et al.>          Expires January 28, 2015                [Page 4]
INTERNET DRAFT     <EP Extensions for Peer Selection>      June 27, 2014

5.  IANA Considerations

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

   +-----------------+---------------------------------------+
   |Identifier       |Intended Semantics                     |
   +-----------------+---------------------------------------+
   |p2p_caching      |Whether the peer is a network cache,   |
   |(boolean)        |value is "true" or "false".            |
   +-----------------+---------------------------------------+
   |battery_limited  |Whether the peer is battery-limited,   |
   |(boolean)        |value is "true" or "false".            |
   +-----------------+---------------------------------------+
   |link_preference  |The relative preference from the ISP's |
   |(integer)        |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".            |
   +-----------------+---------------------------------------+

6. Acknowledgements

   The authors would like to thank Michael Scarf and Sabine Randriamsy
   for their review and valuable comments.

 

<Deng, et al.>          Expires January 28, 2015                [Page 5]
INTERNET DRAFT     <EP Extensions for Peer Selection>      June 27, 2014

7  References

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

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

 

<Deng, et al.>          Expires January 28, 2015                [Page 6]
INTERNET DRAFT     <EP Extensions for Peer Selection>      June 27, 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 January 28, 2015                [Page 7]