draft-ietf-p2psip-self-tuning-13.txt   draft-ietf-p2psip-self-tuning-14.txt 
P2PSIP Working Group J. Maenpaa P2PSIP Working Group J. Maenpaa
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: December 16, 2014 June 14, 2014 Expires: December 18, 2014 June 16, 2014
Self-tuning Distributed Hash Table (DHT) for REsource LOcation And Self-tuning Distributed Hash Table (DHT) for REsource LOcation And
Discovery (RELOAD) Discovery (RELOAD)
draft-ietf-p2psip-self-tuning-13.txt draft-ietf-p2psip-self-tuning-14.txt
Abstract Abstract
REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P) REsource LOcation And Discovery (RELOAD) is a peer-to-peer (P2P)
signaling protocol that provides an overlay network service. Peers signaling protocol that provides an overlay network service. Peers
in a RELOAD overlay network collectively run an overlay algorithm to in a RELOAD overlay network collectively run an overlay algorithm to
organize the overlay, and to store and retrieve data. This document organize the overlay, and to store and retrieve data. This document
describes how the default topology plugin of RELOAD can be extended describes how the default topology plugin of RELOAD can be extended
to support self-tuning, that is, to adapt to changing operating to support self-tuning, that is, to adapt to changing operating
conditions such as churn and network size. conditions such as churn and network size.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 16, 2014. This Internet-Draft will expire on December 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 15 skipping to change at page 2, line 15
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction to Stabilization in DHTs . . . . . . . . . . . . 5 3. Introduction to Stabilization in DHTs . . . . . . . . . . . . 5
3.1. Reactive vs. Periodic Stabilization . . . . . . . . . . . 5 3.1. Reactive vs. Periodic Stabilization . . . . . . . . . . . 5
3.2. Configuring Periodic Stabilization . . . . . . . . . . . 6 3.2. Configuring Periodic Stabilization . . . . . . . . . . . 6
3.3. Adaptive Stabilization . . . . . . . . . . . . . . . . . 7 3.3. Adaptive Stabilization . . . . . . . . . . . . . . . . . 8
4. Introduction to Chord . . . . . . . . . . . . . . . . . . . . 8 4. Introduction to Chord . . . . . . . . . . . . . . . . . . . . 8
5. Extending Chord-reload to Support Self-tuning . . . . . . . . 9 5. Extending Chord-reload to Support Self-tuning . . . . . . . . 9
5.1. Update Requests . . . . . . . . . . . . . . . . . . . . . 10 5.1. Update Requests . . . . . . . . . . . . . . . . . . . . . 10
5.2. Neighbor Stabilization . . . . . . . . . . . . . . . . . 10 5.2. Neighbor Stabilization . . . . . . . . . . . . . . . . . 11
5.3. Finger Stabilization . . . . . . . . . . . . . . . . . . 11 5.3. Finger Stabilization . . . . . . . . . . . . . . . . . . 11
5.4. Adjusting Finger Table Size . . . . . . . . . . . . . . . 11 5.4. Adjusting Finger Table Size . . . . . . . . . . . . . . . 11
5.5. Detecting Partitioning . . . . . . . . . . . . . . . . . 11 5.5. Detecting Partitioning . . . . . . . . . . . . . . . . . 12
5.6. Leaving the Overlay . . . . . . . . . . . . . . . . . . . 12 5.6. Leaving the Overlay . . . . . . . . . . . . . . . . . . . 12
6. Self-tuning Chord Parameters . . . . . . . . . . . . . . . . 12 6. Self-tuning Chord Parameters . . . . . . . . . . . . . . . . 12
6.1. Estimating Overlay Size . . . . . . . . . . . . . . . . . 12 6.1. Estimating Overlay Size . . . . . . . . . . . . . . . . . 12
6.2. Determining Routing Table Size . . . . . . . . . . . . . 13 6.2. Determining Routing Table Size . . . . . . . . . . . . . 13
6.3. Estimating Failure Rate . . . . . . . . . . . . . . . . . 13 6.3. Estimating Failure Rate . . . . . . . . . . . . . . . . . 13
6.3.1. Detecting Failures . . . . . . . . . . . . . . . . . 14 6.3.1. Detecting Failures . . . . . . . . . . . . . . . . . 14
6.4. Estimating Join Rate . . . . . . . . . . . . . . . . . . 15 6.4. Estimating Join Rate . . . . . . . . . . . . . . . . . . 15
6.5. Estimate Sharing . . . . . . . . . . . . . . . . . . . . 15 6.5. Estimate Sharing . . . . . . . . . . . . . . . . . . . . 15
6.6. Calculating the Stabilization Interval . . . . . . . . . 17 6.6. Calculating the Stabilization Interval . . . . . . . . . 17
7. Overlay Configuration Document Extension . . . . . . . . . . 18 7. Overlay Configuration Document Extension . . . . . . . . . . 18
skipping to change at page 3, line 19 skipping to change at page 3, line 19
routine to counter the undesirable effects of churn on routing. To routine to counter the undesirable effects of churn on routing. To
configure the parameters of a DHT, some characteristics such as churn configure the parameters of a DHT, some characteristics such as churn
rate and network size need to be known in advance. These rate and network size need to be known in advance. These
characteristics are then used to configure the DHT in a static characteristics are then used to configure the DHT in a static
fashion by using fixed values for parameters such as the size of the fashion by using fixed values for parameters such as the size of the
successor set, size of the routing table, and rate of maintenance successor set, size of the routing table, and rate of maintenance
messages. The problem with this approach is that it is not possible messages. The problem with this approach is that it is not possible
to achieve a low failure rate and a low communication overhead by to achieve a low failure rate and a low communication overhead by
using fixed parameters. Instead, a better approach is to allow the using fixed parameters. Instead, a better approach is to allow the
system to take into account the evolution of network conditions and system to take into account the evolution of network conditions and
adapt to them. This document extends the mandatory-to-implement adapt to them.
chord-reload algorithm by making it self-tuning. Two main advantages
of self-tuning are that users no longer need to tune every DHT This document extends the mandatory-to-implement chord-reload
parameter correctly for a given operating environment and that the algorithm by making it self-tuning. The use of the self-tuning
system adapts to changing operating conditions. feature is optional. However, when used, it needs to be supported by
all peers in the RELOAD overlay network. Two main advantages of
self-tuning are that users no longer need to tune every DHT parameter
correctly for a given operating environment and that the system
adapts to changing operating conditions.
The remainder of this document is structured as follows: Section 2 The remainder of this document is structured as follows: Section 2
provides definitions of terms used in this document. Section 3 provides definitions of terms used in this document. Section 3
discusses alternative approaches to stabilization operations in DHTs, discusses alternative approaches to stabilization operations in DHTs,
including reactive stabilization, periodic stabilization, and including reactive stabilization, periodic stabilization, and
adaptive stabilization. Section 4 gives an introduction to the Chord adaptive stabilization. Section 4 gives an introduction to the Chord
DHT algorithm. Section 5 describes how this document extends the DHT algorithm. Section 5 describes how this document extends the
stabilization routine of the chord-reload algorithm. Section 6 stabilization routine of the chord-reload algorithm. Section 6
describes how the stabilization rate and routing table size are describes how the stabilization rate and routing table size are
calculated in an adaptive fashion. calculated in an adaptive fashion.
 End of changes. 7 change blocks. 
11 lines changed or deleted 15 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/