Hi Das,
The slides you provided are interesting. As for the RTT, we may not need the timestamp. However, from the overlay management perspective, one may want to measure the one way delay from an initiator node to the destination node. Then do you have any suggestions for that? Best Regards, Song Haibin Email: [EMAIL PROTECTED] Skype: alexsonghw _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Das, Saumitra Sent: Wednesday, November 12, 2008 5:31 PM To: [EMAIL PROTECTED] Cc: ietf@ietf.org Subject: Re: [P2PSIP] P2PSIP diagnostics: PING discussion Hi Song, Even in the planetlab testbed, the following paper at PAM 2008 ( http://pam2008.cs.wpi.edu/slides/pathak.ppt ) shows that more than 40% of nodes have more than 20ms NTP error. In a general overlay we are likely to find a larger fraction of nodes with error in their NTP time (since the planetlab testbed is managed by the people who own the machines while general overlay nodes are unlikely to be that well maintained). Unless NTP refresh is made mandatory within a p2psip implementation, relying on ntp would be unlikely to be helpful to diagnostics Thanks Saumitra www.saumitra.info =============== Dear all, In P2PSIP base protocol, Ping is used to test connectivity along a path. However, connectivity quality can not be measured well without some useful information, such as the timestamp and HopCounter. In p2psip diagnostics draft version 03 http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-03.txt we extend the Ping message payloads with a few kinds of useful information for connectivity quality check purposes. The initiator node receiving the Ping response should compute the overlay hops to the destination peer for the statistics of connectivity quality from the perspective of overlay hops. About the Timestamp, we are not sure if the NTP time is a good candidate for it, or we have other ways to describe it, or we don't need the timestamp at all. But if NTP time is used in the overlay, then it is a good choice, because every peer along the message path will know when the message is generated, and it is easy for the peer along the path to calculate the message latency. However many overlays may not be synchronized with the NTP time. Any comments? Best Regards, Song Haibin Email: melodysong at huawei.com Skype: alexsonghw
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf