Subject: Re: [P2PSIP] P2PSIP diagnostics: PING discussion

From: "Das, Saumitra" <[email-masked]>
Date: Wed, 12 Nov 2008 01:31:26 -0800

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

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

---

From: Song Haibin <[email-masked]>
Date: Thu, 13 Nov 2008 10:14:38 +0800

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-masked]
Skype: alexsonghw

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Das, Saumitra
Sent: Wednesday, November 12, 2008 5:31 PM
To: [email-masked]
Cc: [email-masked]
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,

 

Best Regards,
Song Haibin

---

From: "Roni Even" <[email-masked]>
Date: Thu, 13 Nov 2008 16:24:28 +0200

Hi,

I am not sure what you mean NTP refresh, if the test was using the system
clock than you would expect in XP that it will be updated every tick which
is 10 or 15 msec which can account for the error. NTP is used in RTP (RFC
3550) for synchronization and the RTP time is using the system clock which
may add skew but it is not because of NTP.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Das,
Saumitra
Sent: Wednesday, November 12, 2008 11:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [P2PSIP] P2PSIP diagnostics: PING discussion

Hi Song,

Thanks
Saumitra
 
www.saumitra.info

===============
 
Dear all,

 

Best Regards,
Song Haibin

---

From: "Das, Saumitra" <[email-masked]>
Date: Thu, 13 Nov 2008 10:45:06 -0800

Hi Roni,

  What I mean is that typical machines on the planetlab testbed (linux based) show this drift. This may be alleviated with xp boxes since they may sync silently with time.windows.com when a network connection is up. In linux, clock drift problems have been known to exist because ntpdate may not be setup to work often enough.

Thanks
Saumitra

From: Roni Even [mailto:[email-masked]]
Sent: Thursday, November 13, 2008 6:24 AM
To: Das, Saumitra; [email-masked]
Cc: [email-masked]
Subject: RE: [P2PSIP] P2PSIP diagnostics: PING discussion

Hi,
I am not sure what you mean NTP refresh, if the test was using the system clock than you would expect in XP that it will be updated every tick which is 10 or 15 msec which can account for the error. NTP is used in RTP (RFC 3550) for synchronization and the RTP time is using the system clock which may add skew but it is not because of NTP.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Das, Saumitra
Sent: Wednesday, November 12, 2008 11:31 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [P2PSIP] P2PSIP diagnostics: PING discussion

Hi Song,

Thanks

Saumitra

www.saumitra.info

===============

Dear all,

time. Any comments?

Best Regards,

Song Haibin

Skype: alexsonghw

---

From: Colin Perkins <[email-masked]>
Date: Thu, 13 Nov 2008 14:34:15 -0500

On 13 Nov 2008, at 09:24, Roni Even wrote:
> I am not sure what you mean NTP refresh, if the test was using the  
> system clock than you would expect in XP that it will be updated  
> every tick which is 10 or 15 msec which can account for the error.  
> NTP is used in RTP (RFC 3550) for synchronization and the RTP time  
> is using the system clock which may add skew but it is not because  
> of NTP.
>

One minor clarification: RTP uses an NTP format timestamp, but it  
doesn't require the use of NTP.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 13 Nov 2008 14:44:26 -0500

Neither XP nor Mac OS X can be relied on to have accurate time sync,
although they in theory come with time syncing enabled by default.
Unfortunately, you just can't rely on synchronized clocks in all but
the most controlled of circumstances (and I think it's almost always a
poor idea, even then).

Bruce

On Thu, Nov 13, 2008 at 1:45 PM, Das, Saumitra <[email-masked]> wrote:
> Hi Roni,
>
>
>
>   What I mean is that typical machines on the planetlab testbed (linux
> based) show this drift. This may be alleviated with xp boxes since they may
> sync silently with time.windows.com when a network connection is up. In
> linux, clock drift problems have been known to exist because ntpdate may not
> be setup to work often enough.
>
>
>
> Thanks
>
> Saumitra
>
>
>

---

From: Song Haibin <[email-masked]>
Date: Fri, 14 Nov 2008 14:57:22 +0800

Colin,

In the p2psip diagnostics draft, we also say that we use the "NTP format"
time. 

Best Regards,
Song Haibin

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Colin Perkins
Sent: Friday, November 14, 2008 3:34 AM
To: Roni Even
Cc: [email-masked]; [email-masked]
Subject: Re: [P2PSIP] P2PSIP diagnostics: PING discussion

One minor clarification: RTP uses an NTP format timestamp, but it doesn't
require the use of NTP.

-- 

Colin Perkins

http://csperkins.org/

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 18 Nov 2008 11:19:19 -0600

On Mon, Nov 17, 2008 at 1:10 AM, Song Haibin <[email-masked]> wrote:
> Bruce,
>
>>-----Original Message-----
>>Bruce Lowekamp
>>Sent: Friday, November 14, 2008 3:44 AM
>>To: Das, Saumitra
> But one way delay (OWD) measurement is useful according to the motivations
> in section 2.1 of RFC2679. It is also useful in P2P networks, e.g. when the
> p2p network is used as a tunnel for data transfer. Clock synchronization is
> hard for ordinary host, but that depends on what precision you want to
> achieve.
>

Song,

No dispute that it's useful, it's just that what you need to do
anything useful with OWD is an order of magnitude beyond what you can
expect on any p2p overlay not specifically designed for measuring it.
In 2679, Section 3.5, 2nd bullet the requirement is described as
having a GPS receiver on each host or maybe each host being
synchronized directly with multiple gps-provided NTP servers, though
they didn't test whether that was good enough.

Bruce