This is an interesting and useful method, though I believe the I-D should have a section "Usage Scenarios" to make it clear why and when p2p network diagnostics are required. It would be helpful to explain some points such as:
"Considering the complexity of service provisioning in the overlay network, a diagnostics system is more desirable for the overlay network than the usual network adopting Client/Server mode." (service provisioning?) We are used with the concept that p2p networks are (2) self organizing, (2) can handle churn, (3) can route around failed nodes and (4) "failed nodes" can be recovered as part of the routing protocols and using additional routing state as well as additional gateways into the p2p overlay. http://srhea.net/papers/opendht-worlds05.pdf http://srhea.net/papers/bamboo-usenix-talk.ppt It is not clear who should do what with the proposed diagnostics: - Are they meant to serve some maintenance staff or in the customer support center? - Are they meant for an application available to the user? - Are they meant to be used in the routing protocol as in the references above? Last but not least, the most frequent failure may be due to some NAT/Firewall scenario or some non-transitive connectivity. This may be out of scope for this paper but is worth mentioning IMO anyway. There are some interesting papers on STUN usage that can be used as references. A section on usage scenarios would be of great help. Henry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Song Yongchao Sent: Saturday, March 29, 2008 2:28 AM To: 'P2PSIP Mailing List' Subject: [P2PSIP] P2PSIP diagnosis Hi folks! There is little discussion about the topic of p2psip diagnosis for a long time. So I entitle this mail "P2PSIP diagnosis", those who are interested in this topic can discuss it now. In p2psip diagnostics draft http://tools.ietf.org/wg/p2psip/draft-zheng-p2psip-diagnose-01.txt We provide a separated diagnostic message "Echo" which routes the overlay to gather useful diagnostic information. Various information (e.g. hop counter, uptime, RTT time, etc.) can be gathered to the source peer according to its requirement. Recursive, semi-recursive, iterative routing modes are supported. There are two modes to get the diagnostic information, i.e. "Ping" mode and "Traceroute" mode. The message format is compatible to SEP, but it can be modified to be compatible to other peer protocol as well. You can discuss the p2psip diagnostics in the mailing list or discuss with me via email individually. Thanks! Best Regards, Song Yongchao Email: [EMAIL PROTECTED] _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
