Subject: [P2PSIP] P2PSIP diagnosis

From: Song Yongchao <[email-masked]>
Date: Sat, 29 Mar 2008 15:27:51 +0800

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-masked]

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 29 Mar 2008 10:26:05 -0700

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-masked] [mailto:[email-masked]] 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

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Sat, 29 Mar 2008 19:02:38 +0100

Song,

On Sat, Mar 29, 2008 at 6:26 PM, Henry Sinnreich <[email-masked]> wrote:
>  p2p network diagnostics are required.

<keeping p2psip clients in mind>
IMO, different application scenarios (degree of heterogeneity, node
mobility and so on) will require different numbers of peers (few,
many). The point is to design a peer/client turning criteria
(performance, operator policy, etc) which optimizes the performance
while it prevents free-riding

Could this diagnosis be useful to evaluate the performance and serve
as an input for the turning criteria?

Cheers,
-- 
Victor Pascual Ávila

---

From: Song Yongchao <[email-masked]>
Date: Mon, 31 Mar 2008 10:41:26 +0800

Victor,

>From: Victor Pascual ávila Sent: Sunday, March 30, 2008 2:03 AM
>To: Henry Sinnreich
>Cc: Song Yongchao; P2PSIP Mailing List
>Subject: Re: [P2PSIP] P2PSIP diagnosis
>
>Song,
>

I think this turning criteria is needed. IMO, there will not be one general
criteria for it. It will be different for various application scenarios. 

>as an input for the turning criteria?

Yes, with the diagnostics, you can evaluate the average performance of the
overlay through the diagnostic information gathered from different peers at
different time (Traceroute mode of Echo request can get all the diagnostic
information of the intermediate peers).  By comparing with the diagnostic
information from the specific peer/client (Ping mode of the Echo request can
be used to get only the diagnostic information of the destination peer), and
then you can use the turning criteria to make the decision. 

-BR
-Song

>Victor Pascual ávila

---

From: Song Yongchao <[email-masked]>
Date: Mon, 31 Mar 2008 12:00:05 +0800

Henry,

>From: Henry Sinnreich 
>Sent: Sunday, March 30, 2008 1:26 AM
>To: Song Yongchao; P2PSIP Mailing List
>Subject: RE: [P2PSIP] P2PSIP diagnosis
>

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:
>

The distributed storage and transport service, and the heterogeneity of
peers and clients make the diagnostic function desirable. 

>- Are they meant to be used in the routing protocol as in the references
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.

>are some interesting papers on STUN usage that can be used as
IMHO, we can separate the diagnostics and NAT/FW traversal.

>A section on usage scenarios would be of great help.

Thanks for reminding again.