Antoine, Sorry to take so long to respond to this. Responses below:
On Thu, Dec 4, 2008 at 9:10 AM, Antoine Roly <[email protected]> wrote: > Hi, > > I have some questions about the draft Reload-Base: > > - Usage of Probes before Attaches: in section 10.5, the > point 2 is "JP uses a series of Probes to populate its routing > table." but in section 3.5.2 and callflows in section 12 there is no > Probe message. I know Section 10 is specific for Chord-Reload, and > section 3.5.2 is generic, but as it is currently described, it is > not clear if Probes should be really used or not. Is Probe useful > just only when using Chord? If yes, I assume these Probes are sent > with an empty list of info, and so, should'nt Ping be used instead? > Section 12 should show at least one Probe. The Probes are useful so that the new peer knows which peers to send its Attach requests to. (you could, in theory, do a lot without them, but there are various problems with that, such as sending multiple attaches to the same peer when it will fill multiple entries in your finger table) Probes are intended for be extensible by the overlay algorithm, although the Chord in Section 10 doesn't make use of that feature. Probe is likely to be more useful for other overlay algorithms. In chord you could replace several of the Probes with Ping, but they're intended for separate purposes, and I think it's better to be consistent doing overlay maintentance with the same method, even though Chord doesn't do much with the contents of Probe. > - Could you clarify point 10.6 on source routing? It is said that > source-routing Attaches through the peer from which a node learned > the new peer's Node-ID "allows the overlay to recover from > instability". This latest statement probably requires a more detailed > explanation. Additional question: why is the source-routing of > Attaches mandatory ONLY for peer in the neighborhood's table. If the > peer crashes, I assume Attaches are routed "conventionally" > through the overlay. > If you learn about peer C from peer B, you know peer B can reach peer C. If the overlay is unstable, you may not be able to reach peer C directly. Therefore source routing through B will allow the overlay to stabilize (at least by adding C). Finger table entries are an optimization. The correctness of the overlay is ultimately dependent on the successor entries being correct. Therefore, more effort is expended to make the neighborhood correct than for the finger table entries (which will ultimately be corrected, anyway) > - Must we add a byte "on the wire" just before ResourceId (as > described in section 5.2.1.1) or even before every structure of > variable length? If we must add one before every structure of > variable length, why not explicitly include it while describing the > message fields? For example, for the payload length, since the > signature has a variable length, it seems necessary to explicitely > add a 3 bytes message field representing the length before the > payload, isn't it? > I'm not sure what you're asking here. The benefit of defining types in one place is that we don't need to break out every element of that type for every message it's used in. Some payloads are fixed-length. > - section 10.7.3: "To determine if its finger table is sufficiently > large, one an hour the peer should perform a Probe to determine > whether growing its finger table by four entries would result in it > learning at least two peers that it does not already have in its > neighbor table.". This last sentence is not easy to follow: to which > node should the Probe be addressed? (By the way, it could maybe be > a Ping too). > I just answered this question in another thread. I will try to add an example to that text. Bruce > Thanks > > Antoine > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
