Subject: Re: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item

From: "Bruce Lowekamp" <[email-masked]>
Date: Sun, 4 Jan 2009 16:02:57 -0500

I've been in favor of adoption, and I am not going to change my opinion now.

However, I have some serious concerns about this draft, and the
revisions have not addressed them.  When the revision was posted, it
should have been announced on the list and the changes made to it
brought to the attention of the wg members for discussion.

I have technical concerns with this draft that have been mentioned
before (OWD can't be measured the way this draft proposes, and I don't
believe the multiple-responses-for-an-echo-request technique should be
supported).

There are also some issues with duplication of functionality between
base methods and the new methods defined.  I think this is something
we can address later as a working group.

I don't understand why the "diagnostic server" material was added to
this revision.  I think it should be removed.  If something like this
is desired, it should be entirely separate.

Bruce

On Fri, Dec 26, 2008 at 5:13 PM, David A. Bryan <[email-masked]> wrote:
> Looking for objections, since we had consensus in the room in Minneapolis.
>
> Thanks for clarifying!
>
> David (as chair)
>
> On Fri, Dec 26, 2008 at 3:49 PM, Dan York <[email-masked]> wrote:
>> David,
>>
>> Are you expecting us to send messages to the list agreeing with this?  Or
>> are you taking the lack of *dissenting* messages as a sign of consensus?
>>
>> Dan
>>
>> P.S. I agree with this action, by the way, and did hum to adopt in the room
>> in Minneapolis.
>>
>> On Dec 26, 2008, at 10:08 AM, David A. Bryan wrote:
>>
>>> In Minneapolis, there was a hum taken which indicated rough consensus
>>> to move towards adopting the P2PSIP diagnostics draft as a working
>>> group item. Since there were also a number of corrections/changes
>>> requested, the chairs asked the authors to iterate the draft and post
>>> it, and then we would verify the consensus on list.
>>>
>>> The authors posted the revisions to the draft a few weeks ago:
>>>
>>> http://tools.ietf.org/id/draft-zheng-p2psip-diagnose-04.txt
>>>
>>> I'd like to ask for list consensus to verify the consensus from the
>>> meeting in favor of adopting this work as a WG item.
>>>
>>> David (as chair)
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/p2psip
>>
>> --
>> Dan York, CISSP, Director of Emerging Communication Technology
>> Office of the CTO    Voxeo Corporation     [email-masked]
>> Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
>> Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com
>>
>> Build voice applications based on open standards.
>> Find out how at http://www.voxeo.com/free
>>
>>
>>
>>
>>
>>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Salman Abdul Baset <[email-masked]>
Date: Sun, 4 Jan 2009 17:21:53 -0500 (EST)

I agree with Bruce. In addition:

Diagnostics are a combination of techniques. The methods specified in the 
draft are one of them. They may well be other approaches such as state 
acquisition of a node and overlay crawl through overlay operator managed 
nodes. A node regularly needs to perform overlay maintenance operations. 
It may need to be specified when does a node switch to a 'diagnostic mode'.

An overlay operator may be interested in gathering a 'health report' of 
the overlay. When the overlay size is 'small', such information can easily 
be overlayed on a geographical map (we used this approach in our OpenVoIP 
system). Diagnostics may play a role here.

As a procedural comment, I think the diagnostic document track should be 
'Experimental' or 'Informational' until we have gained sufficient 
understanding of the protocol methods and required information from 
practical deployments.

-salman

---

From: "Roni Even" <[email-masked]>
Date: Mon, 5 Jan 2009 08:16:37 +0200

Hi Bruce, 

I agree with you about that we need to address any duplication between the
base draft and this draft. The consensus in the last meeting was to define
separate methods in the diagnostics draft and leave the ones in the base
draft simple.

As for the parameters in diagnostics information there was some discussion
in the past on the list and I also think we need to look at them.

Regards
Roni Even

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bruce Lowekamp
Sent: Sunday, January 04, 2009 11:03 PM
To: David A. Bryan
Cc: [email-masked]
Subject: Re: [P2PSIP] List consensus call to adopt
draft-zheng-p2psip-diagnose-04 as a WG item

Bruce

---

From: "Das, Saumitra" <[email-masked]>
Date: Mon, 5 Jan 2009 18:15:50 -0800

I agree with Bruce that this needs work. I have the following comments

1. Why does the introduction of the draft specifically target p2p service providers crawling the overlay for diagnostic information. We should be trying to develop a general mechanism to diagnose nodes and links between nodes. Whether this is used by the service provider or between two nodes in the p2p overlay is not important. An overlay node may use diagnosis to detect problems, make choices etc.

2. We need a way for the p2p overlay operator to cause diagnosis between nodes in the overlay and not just retrieve information about the node itself. For example, the operator may wish to figure out the latencies observed between superpeers in the overlay to make a usage specific optimization

3. Some of the items discussed on the list are not reflected in the document specifically the discussions on node specific metrics like cpu and bw. We should look at what has been useful for PlanetLab in this context since it is a long running overlay. The node metrics are routinely used in planetlab by overlay deployers.

4. The diagnostic server should be out of scope for this draft. Rather we should think about a mechanism for the overlay operator/(maybe the enrollment server or some other entity) to trigger a specific diagnosis between two overlay nodes. What is done with the diagnostic information obtained need not be standardized atleast in this draft.

Thanks
Saumitra

www.saumitra.info 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni Even
Sent: Sunday, January 04, 2009 10:17 PM
To: 'Bruce Lowekamp'; 'David A. Bryan'
Cc: [email-masked]
Subject: Re: [P2PSIP] List consensus call to adopt draft-zheng-p2psip-diagnose-04 as a WG item

Hi Bruce, 

Regards
Roni Even

-----Original Message-----

Bruce

---

From: Song Haibin <[email-masked]>
Date: Tue, 06 Jan 2009 10:34:21 +0800

Hi Salman,

>From: Salman Abdul Baset
>Sent: Monday, January 05, 2009 6:22 AM

>nodes. 

It is true if you have operator managed nodes, just as we did in our early
SEP prototype. However, the methods defined in the diagnostics draft can
accommodate different scenarios. E.g. you can use the Echo method defined in
the diagnostics draft with the destination list set to a list of overlay
managed nodes to retrieve the diagnostic information of them (or use the
Path_Track iteratively) and only accept the Echo responses from the
authorized nodes.

>A node regularly needs to perform overlay maintenance operations.

I agree what you mentioned here is needed. IMHO, it is related to the usage
scenarios of the diagnostics, especially that when does a node need to
perform diagnostic operation. The diagnostic operation may be generated from
the operator (that is part of the reason why we optionally need a diagnostic
server) or from an overlay node itself due to some connectivity problem or
other reasons.

>system). Diagnostics may play a role here.

Yes, I agree that diagnostics can be used to gather proper information and
do the connectivity monitoring for such a "health report". By the way, some
coordinate system or an ALTO server can be used for building your
geographical map.

>understanding of the protocol methods and required information from

IMO, it will be "standard track", although it is not perfect at the moment,
we still have a lot of work to do until we output the final revision.

BR
Haibin

---

From: Song Haibin <[email-masked]>
Date: Tue, 06 Jan 2009 10:52:17 +0800

Hi Das,

Thank you for your response.

The method Inspect is defined for the purpose of (1) and (2).  And because
of limited time, we could take more time to look at the parameters you
mentioned in (3) such as bw and cpu later as a workgroup item.

Best Regards,
Haibin
Email: [email-masked]
Skype: alexsonghw

>Das, Saumitra
>Sent: Tuesday, January 06, 2009 10:16 AM
>To: Roni Even; 'Bruce Lowekamp'; 'David A. Bryan'
>Cc: [email-masked]
>Subject: Re: [P2PSIP] List consensus call to
>adoptdraft-zheng-p2psip-diagnose-04 as a WG item
>
>1. Why does the introduction of the draft specifically target p2p service
>providers crawling the overlay for diagnostic information. We should be
trying
>to develop a general mechanism to diagnose nodes and links between nodes.
Whether
>this is used by the service provider or between two nodes in the p2p
overlay
>is not important. An overlay node may use diagnosis to detect problems,
make
>choices etc.
>
>2. We need a way for the p2p overlay operator to cause diagnosis between
nodes
>in the overlay and not just retrieve information about the node itself. For
>example, the operator may wish to figure out the latencies observed between
>superpeers in the overlay to make a usage specific optimization
>
>3. Some of the items discussed on the list are not reflected in the
document
>specifically the discussions on node specific metrics like cpu and bw. We
should
>look at what has been useful for PlanetLab in this context since it is a
long
>running overlay. The node metrics are routinely used in planetlab by
overlay
>deployers.
>
>4. The diagnostic server should be out of scope for this draft. Rather we
should
>think about a mechanism for the overlay operator/(maybe the enrollment
server
>or some other entity) to trigger a specific diagnosis between two overlay
nodes.
>What is done with the diagnostic information obtained need not be
standardized
>atleast in this draft.

---

From: Song Haibin <[email-masked]>
Date: Tue, 06 Jan 2009 11:14:35 +0800

Hi Bruce,

>I've been in favor of adoption, and I am not going to change my opinion
now.

Many thanks!

>When the revision was posted, it

I announced the new revision in the p2psip mailing list on Dec 17th.

>believe the multiple-responses-for-an-echo-request technique should be

There is an editor note in section 6.1 which indicates OWD measurement will
need more discussion. Echo method has been limited to be used in some
trusted overlay network where it works.

>is desired, it should be entirely separate.

This section will be removed.

BR
Haibin

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 6 Jan 2009 07:56:27 -0500

> I announced the new revision in the p2psip mailing list on Dec 17th.

You're right, my apologies.  I somehow entirely missed that.  In that
case, I really wish everyone else (such as myself) on the list had
read it and responded more quickly...

> trusted overlay network where it works.

Measuring OWD of a multi-hop path around an overlay is entirely
possible if all the peers are synchronized to NTP servers.  It's just
that it can't be used for a single hop, and it's hard to confirm all
the peers are properly synchronized.  However, that timestamp is
useful regardless of whether it can be used for OWD.  So I would leave
the timestamp the way it is, but just add some discussion that careful
consideration needs to be given to how it's used.

While differentiating "trusted" and "untrusted" overlays is useful for
discussion points, I don't know how to apply the terms to real
networks.  Real networks are going to have a lot of shades of gray.
All you're going to wind up with is a flag in the config file saying
whether the overlay allows that multiple response echo method or not.
 However, my biggest concern is the difficulty of implementing it.
There's both a problem that it's two different ways of implementing
the same concept (which makes the implementation hard) and that this
is the only case we have for a request that gets multiple responses
each of which has meaning (much more complex than a normal
request/response).  Considering all of this, think there just needs to
be a standard one-response-at-a-time method.

Bruce

---

From: "David A. Bryan" <[email-masked]>
Date: Fri, 9 Jan 2009 09:07:01 -0500

Since we've given this two weeks, and haven't seen any objections to
the adoption of draft-zheng-p2psip-diagnose-04 as a WG item, the
diagnostic draft is now a WG item.

There were obviously many technical comments and concerns, so I expect
this item will be a very active one in the WG going forward. Please
keep the comments and discussion going -- I'm sure the authors will
appreciate the feedback.

David (as chair)