draft-ietf-p2psip-self-tuning-12.txt   draft-ietf-p2psip-self-tuning-13.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 10, 2014 June 8, 2014 Expires: December 16, 2014 June 14, 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-12.txt draft-ietf-p2psip-self-tuning-13.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 10, 2014. This Internet-Draft will expire on December 16, 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 3, line 42 skipping to change at page 3, line 42
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.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
This document uses the terminology and definitions from the Concepts This document uses terminology and definitions from the RELOAD base
and Terminology for Peer to Peer SIP [I-D.ietf-p2psip-concepts] specification [RFC6940].
draft.
numBitsInNodeId: Specifies the number of bits in a RELOAD Node-ID. numBitsInNodeId: Specifies the number of bits in a RELOAD Node-ID.
DHT: Distributed Hash Tables (DHTs) are a class of decentralized DHT: Distributed Hash Tables (DHTs) are a class of decentralized
distributed systems that provide a lookup service similar to a distributed systems that provide a lookup service similar to a
regular hash table. Given a key, any peer participating in the regular hash table. Given a key, any peer participating in the
system can retrieve the value associated with that key. The system can retrieve the value associated with that key. The
responsibility for maintaining the mapping from keys to values is responsibility for maintaining the mapping from keys to values is
distributed among the peers. distributed among the peers.
skipping to change at page 14, line 19 skipping to change at page 14, line 19
failure at the current time. It has been shown that an estimate failure at the current time. It has been shown that an estimate
calculated in a similar manner is accurate within 17% of the real calculated in a similar manner is accurate within 17% of the real
value of U [ghinita2006]. value of U [ghinita2006].
The size of the failure history K affects the accuracy of the The size of the failure history K affects the accuracy of the
estimate of U. One can increase the accuracy by increasing K. estimate of U. One can increase the accuracy by increasing K.
However, this has the side effect of decreasing responsiveness to However, this has the side effect of decreasing responsiveness to
changes in the failure rate. On the other hand, a small history size changes in the failure rate. On the other hand, a small history size
may cause a peer to overreact each time a new failure occurs. In may cause a peer to overreact each time a new failure occurs. In
[ghinita2006], K is set to 25% of the routing table size. Use of [ghinita2006], K is set to 25% of the routing table size. Use of
this approach is RECOMMENDED. this value is RECOMMENDED.
6.3.1. Detecting Failures 6.3.1. Detecting Failures
A new failure MUST be inserted to the failure history in the A new failure MUST be inserted to the failure history in the
following cases: following cases:
1. A Leave request is received from a neigbhor. 1. A Leave request is received from a neigbhor.
2. A peer fails to reply to a Ping request sent in the situation 2. A peer fails to reply to a Ping request sent in the situation
explained below. If no packets have been received on a explained below. If no packets have been received on a
skipping to change at page 19, line 26 skipping to change at page 19, line 26
+------------------+-------+---------------+ +------------------+-------+---------------+
The contents of the extension are defined in Section 6.5. The contents of the extension are defined in Section 6.5.
Note to RFC Editor: please replace AAAA with the RFC number for this Note to RFC Editor: please replace AAAA with the RFC number for this
specification. specification.
9.2. A New IETF XML Registry 9.2. A New IETF XML Registry
This document registers one new URI for the self-tuning namespace in This document registers one new URI for the self-tuning namespace in
the IETF XML registry defined in [RFC3688]. the "ns" subregistry of the IETF XML registry defined in [RFC3688].
URI: urn:ietf:params:xml:ns:p2p:self-tuning URI: urn:ietf:params:xml:ns:p2p:self-tuning
Registrant Contact: The IESG Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace XML: N/A, the requested URI is an XML namespace
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Jani Hautakorpi for his contributions The authors would like to thank Jani Hautakorpi for his contributions
to the document. The authors would also like to thank Carlos to the document. The authors would also like to thank Carlos
Bernardos and Martin Durst for their comments on the document. Bernardos, Martin Durst, Alissa Cooper, Tobias Gondrom, and Barry
Leiba for their comments on the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
2010. 2010.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and [RFC6940] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
skipping to change at page 20, line 32 skipping to change at page 20, line 27
Proceedings of the 2001 Conference on Applications, Proceedings of the 2001 Conference on Applications,
Technologies, Architectures and Protocols for Computer Technologies, Architectures and Protocols for Computer
Communications pp. 161-172, August 2001. Communications pp. 161-172, August 2001.
[Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., [Chord] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D.,
Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A
Scalable Peer-to-peer Lookup Service for Internet Scalable Peer-to-peer Lookup Service for Internet
Applications", IEEE/ACM Transactions on Networking Volume Applications", IEEE/ACM Transactions on Networking Volume
11, Issue 1, pp. 17-32, February 2003. 11, Issue 1, pp. 17-32, February 2003.
[I-D.ietf-p2psip-concepts]
Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
Dawkins, "Concepts and Terminology for Peer to Peer SIP",
draft-ietf-p2psip-concepts-05 (work in progress), July
2013.
[Pastry] Rowstron, A. and P. Druschel, "Pastry: Scalable, [Pastry] Rowstron, A. and P. Druschel, "Pastry: Scalable,
Decentralized Object Location and Routing for Large-Scale Decentralized Object Location and Routing for Large-Scale
Peer-to-Peer Systems", In Proceedings of the IFIP/ACM Peer-to-Peer Systems", In Proceedings of the IFIP/ACM
International Conference on Distribued Systems Platforms International Conference on Distribued Systems Platforms
pp. 329-350, November 2001. pp. 329-350, November 2001.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[binzenhofer2006] [binzenhofer2006]
Binzenhofer, A., Kunzmann, G., and R. Henjes, "A Scalable Binzenhofer, A., Kunzmann, G., and R. Henjes, "A Scalable
Algorithm to Monitor Chord-Based P2P Systems at Runtime", Algorithm to Monitor Chord-Based P2P Systems at Runtime",
In Proceedings of the 20th IEEE International Parallel and In Proceedings of the 20th IEEE International Parallel and
Distributed Processing Symposium (IPDPS) pp. 1-8, April Distributed Processing Symposium (IPDPS) pp. 1-8, April
2006. 2006.
[ghinita2006] [ghinita2006]
Ghinita, G. and Y. Teo, "An Adaptive Stabilization Ghinita, G. and Y. Teo, "An Adaptive Stabilization
Framework for Distributed Hash Tables", In Proceedings of Framework for Distributed Hash Tables", In Proceedings of
 End of changes. 10 change blocks. 
18 lines changed or deleted 12 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/