Hi, > A) Doing 2 should be easy using the new MessageExtensions in a PING or > PROBE.
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 > 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
