Hi Salman, > > It is necessary to clarify the scope of the problems that are > being > addressed and to precisly define what 'diagnostics' mean. > Currently, it is > very open ended and includes: > > -routing diagnostics > -detecting malfunctioning or badly behaving peers > -checking the health of overlay
Yes, the draft now has the consideration of routing diagnostics and detecting malfunctioning peers. However, checking the health of the overlay has not been considered in the draft at present, although we have some thought on it. > Overlay maintenance is central to any p2p system. How is that > different > from diagnostics? I am not quite sure about that. But I think the diagnostic information can be used for overlay maintenance. They are a little different. > > The suggested solution incorporates two new methods. I think we > need a > bit more clarity on what is that existing methods cannot achieve, > for > which new methods are required. As an example, one can easily > implement > Path_Track using RouteQuery and [Node]Fetch. > > What is indeed required is a mechanism to obtain the state > [routing/storage] of a node. This can be done using NodeFetch and > may also > be accomplished using Fetch. > The draft now is lack of consideration for storage state. It is a good suggestion to add that as one type of diagnostic information. It is very helpful in the enviroment where the peer storage is limited or hot spot. Haibin > -salman > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
