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: > 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 > _______________________________________________ > P2PSIP mailing list > [email protected] > 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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
