Bruce, See inline.
>-----Original Message----- >From: Bruce Lowekamp [mailto:[EMAIL PROTECTED] >Sent: Thursday, November 13, 2008 3:17 AM >To: Song Haibin >Cc: [email protected] >Subject: Re: [P2PSIP] P2PSIP diagnostics: PING discussion > >I don't think it's a good idea to have Ping extensible by multiple >drafts. Implementing that would require much more complex encoding >and parsing to deal with the combination of extensions supported by a >particular implementation. The overlay methods are extensible, but >only by whichever overlay algorithm is currently being used, so there >is exactly one encoding. I am not quite sure here. >With that said, the ttl response might be a reasonable addition to the >base Ping response. I have the same thought. >I don't understand the purpose of UnderlayTTL, >however. There may be the requirement that one may want to limit each hop underlay TTL from the initiator to the destination, if the underlay TTL expires somewhere, one may think that the link there is not of good quality. It is an optional function, because you can clear the value so that the intermediate peer will ignore it. I don't know if this is often be used, if many guys think this parameter is of no use, I will delete it for the next revision. BR Song >Bruce > >On Tue, Nov 11, 2008 at 3:53 AM, Song Haibin <[EMAIL PROTECTED]> wrote: >> 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: [EMAIL PROTECTED] >> Skype: alexsonghw >> >> >> >> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip >> _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
