Subject: [P2PSIP] Estimate sharing in draft-ietf-p2psip-self-tuning

From: Jouni Mäenpää <[email-masked]>
Date: Tue, 09 Feb 2010 09:54:54 +0200

Hi,

In the draft “Self-tuning DHT for RELOAD”
(http://www.ietf.org/id/draft-ietf-p2psip-self-tuning-00.txt), which is
nowadays a WG item, we specify how a P2PSIP overlay can adapt to
changing operating conditions. The main idea is that each peer collects
statistical data about the network and dynamically adjusts its
stabilization rate, neighborhood set size, and finger table size based
on the analysis of the data. In order to do this, each peer produces an
estimate of the current network size, leave rate, and join rate. In the
simulations we (the authors of the draft) have run, we have observed
that an easy way to improve the accuracy of these estimates is to allow
peers to share their estimates. We can imagine at least two ways to do this:

(1) Peers piggyback their estimates in RELOAD messages.

(2) Each peer asks a subset or all of the peers in its routing table to
return their current estimates.

In alternative (1), a new ForwardingOption could be used for instance in
messages sent as part of the Chord stabilization routines (e.g., Ping).
Every peer forwarding such a request or response could add a new
ForwardingOption containing its current estimates to the message. The
source node, intermediate nodes, and the destination node would store
all estimates carried in the ForwardingOptions structures. When the
stabilization timer fires, each peer would calculate the final estimate
by taking an average (or median) over the estimates received during the
stabilization interval and its own estimate.

In alternative (2), when the stabilization timer fires, every peer sends
a request (e.g., Probe or Inspect) to all or a subset of the peers in
its routing table (e.g., to all fingers), asking them to return their
current estimates. This would require extending the Probe/Inspect
messages. Again, the average or median of the received estimates and the
peer's own estimate would be used to calculate the final estimate.

Any opinions on which alternative would be the preferred one? We would
like to propose using (1) since it does not add any additional messages
to the overlay. Also, if using (1), peers can most likely obtain more
shared values and thus be able to produce more accurate estimates than
by using (2). However, it might also be interesting to allow both
approaches.

Cheers,
Jouni

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 17 Feb 2010 15:36:45 -0700

Two thoughts:

A) Doing 2 should be easy using the new MessageExtensions in a PING or PROBE. 

B) I think that 1 might run into serious problems as the messages growing and all the fragmentation issues around something in the forwarding header growing. 

On Feb 9, 2010, at 12:54 AM, Jouni Mäenpää wrote:

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

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Jouni Mäenpää <[email-masked]>
Date: Thu, 18 Feb 2010 12:42:09 +0200

Hi,

> A) Doing 2 should be easy using the new MessageExtensions in a PING or 

Yes, this should be pretty straightforward.

> B) I think that 1 might run into serious problems as the messages 
> growing and all the fragmentation issues around something in the 
> forwarding header growing.

Perhaps this problem could be avoided if one placed a limit for the
maximum number of ForwardingOption entries (containing shared estimates)
that can be included in the message.

Cheers,
Jouni