Henry, >-----Original Message----- >From: Henry Sinnreich >Sent: Sunday, March 30, 2008 1:26 AM >To: Song Yongchao; P2PSIP Mailing List >Subject: RE: [P2PSIP] P2PSIP diagnosis > >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.
Thanks. IMO, the p2p network diagnostics can be the behavior of an individual peer to check the diagnostic information of other peer(s) for its own policy requirement, or can be the behaviors according to the requirement of an operator to gather the information of the overlay, and then check if he needs to deploy more powerful machines to act as P2P peers. >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?) The distributed storage and transport service, and the heterogeneity of peers and clients make the diagnostic function desirable. >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? > It is just a proposed method (Echo method) for P2P layer diagnostics. It is not an application. IMO, the specific usage scenario will define who should do what. The method mainly serves for the overlay maintenance. >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. > IMHO, we can separate the diagnostics and NAT/FW traversal. >A section on usage scenarios would be of great help. Thanks for reminding again. >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
