Subject: [P2PSIP] DRAFT minutes have been uploaded

From: "David A. Bryan" <[email-masked]>
Date: Sat, 14 Nov 2009 17:03:14 -0500

I've posted DRAFT minutes for the P2PSIP meeting at IETF-76. Please
take a look, comment, and provide any suggestions/corrections or
additions:

http://www.ietf.org/proceedings/09nov/minutes/p2psip.htm

There are a few hums from the meeting that we will be taking to list
shortly for WG list discussion as well.

Thanks,

David (as chair)

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 15 Nov 2009 15:48:52 +0900

My recollection may be wrong - I did not go back and listen to the  
minutes but I seem to recall that at the end of the reload base spec  
discussion, the people in the meeting felt it was ready for  WGLC  
after the updates discussed in the meeting were made. I think that  
should be in the minutes.

Thanks, Cullen in my individual contributor roll.

On Nov 15, 2009, at 7:03 , David A. Bryan wrote:

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

Adding the notes in the link above to email below so they are in the  
email archive

-----------------------

IETF-76 P2PSIP Meeting notes (DRAFT)

Note takers Jim McEachern and Spencer Dawkins. Edited/compared with  
audio by David Bryan.

REsource LOcation And Discovery (RELOAD) Base Protocol,
Cullen Jennings,
draft-ietf-p2psip-base-05

Most points for discussion on slides are cosmetic/minor editorial,  
with a few exceptions.

The draft is completely wrong  for calculating the signatures.   
Proposal to use Michael Chen’s suggested change.  Group indicated that  
this path was supported.

Turn density.  The system needs an algorithm for this to work, and  
this approach works, even though it is almost trivial.  Propose to  
just leave it as is since the system is not very sensitive to this  
(see below).  However, he will update the draft to document some of  
the limitations of this approach and to point to better algorithms  
that might be considered in future work. David Bryan asked from Jabber  
room about the slide stating it should be used since studies and  
experiments indicated it worked well enough and was robust if you got  
it wrong.

David noted this assertion had been controversial before, and asked  
where he could find these studies indicating it worked, and Cullen  
indicated that the authors had not shared them publicly and felt it  
was too much work to publish the results. Indicated that there was an  
opportunity for more work in this area for a general service discovery  
algorithm.

Self Tuning:  Proposal to include information on successors and  
predecessors in Leave messages as it is very helpful for the work in  
the self tuning draft.  Cullen was interested in what the group  
thought.  Comment in favor of including this as a should.  Cullen will  
do that for the next draft.

Other Issues.  None

Robert raised “open issues” in the document.
Reactive recovery.  People keep suggesting they will provide input,  
but they don’t provide anything.  Cullen is therefore proposing to  
delete this as an open issue.
Cullen’s view is that once he updates this document with these changes  
and there is time to review, this will be ready to go to a WG last  
call. Consensus of the room was to do so.

David Bryan asked substitute chairs to get a list of reviewers who  
would do a full review of the document:

Looking for detailed reviewers
	• John Buford
	• Robert Sparks
	• Jouni Maenpaa

P2PSIP Security Overview and Risk Analysis
Song Haibin
draft-matuszewski-p2psip-security-overview-01

Presentation outlined the two changes that were made to the  
presentation.  Asked if there were any additional comments.

Cullen said that he had trouble commenting because he was unclear as  
to exactly what the purpose of this document was.  Without that, it is  
hard to comment.

 From Jabber room David mentioned that in an earlier meeting the  
consensus was for this to provide guidance to people new to P2P about  
the unique security issues and implications.

An extension to RELOAD to support Direct Response and Relay Peer routing
Ning Zong
draft-jiang-p2psip-relay-03

Comparison of DRR/RPR vs. SRR and the number of messages and hops.   
Questions from Cullen about exactly what is being analyzed since the  
number of messages seems low to him, especially if they include the  
entire TLS handshake.  Roni Even says that it does include the TLS  
handshake.  Cullen is unconvinced.  Agreed to take this offline to  
investigate further.

The authors feel they have addressed the comments and that it is an  
optional method for particular deployment scenarios.

Load balancing models for DHT-based Peer-to-Peer Networks
Erikki Harjula
draft-harjula-p2psip-loadbalancing-survey-00

Load balancing is critical, but DHT does not achieve acceptable load  
balancing. Therefore more analysis is needed.
Most techniques use:
-       measure load
-       distribute load information
-       balance the load

Of the many methods, they focus on four.
	• Virtual servers:
	• Controlling object location
	• controlling node location
	• address space balancing

Summarized a brief analysis of the attributes of each method,  
including cost in that analysis.  This analysis is very tentative, and  
they plan to extend the analysis to provide significantly more detail.

Only two people have read the draft

A Self-tuning Distributed Hash Table (DHT) for REsource LOcation And  
Discovery (RELOAD),
Jouni Mäenpää,
draft-maenpaa-p2psip-self-tuning-01,

Previous version did self tuning and load balancing. Current version  
is self tuning only.

With static parameters approach it is not possible to have both low  
stabilization overhead and low failure rate.

Self tuning allows parameters to change.  Each peer collects data and  
uses this to dynamically adjust parameters.

Question to the group as to whether or not the group would be  
interested in having a milestone related to self tuning. Support was  
expressed for this work, but not that many people have read it.  Jon  
encouraged the work to continue, but with such limited audience, was  
reluctant to adopt it as a work group.  Jouni countered that we had  
that situation at the last meeting and that if it became a WG item,  
then perhaps more people would actually read it.  Extended discussion,  
with everyone generally supporting this work.
Jon asked how many people understood the problem that this  
addressing.  About 20-30 people raised their hands.

Poll:  How many people think that the WG should have a charter item to  
address this problem?  Result - Audible support and no objections.

Poll: Should this draft be used as input into that charter item?  
Result - Audible support and no objections.

Jon said they would pass this along to the ADs for consideration.

Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
Jouni Mäenpää,
draft-maenpaa-p2psip-service-discovery-00

Outlines a proposal for a generic service discovery mechanism

Poll: Should we be defining a generic service discovery mechanism for  
p2psip?  Result – lukewarm interest, with no objections.

Conclusion.  Encouraged to continue working on this and bring it to  
the list to continue generating interest.

---

From: "David A. Bryan" <[email-masked]>
Date: Sun, 15 Nov 2009 13:56:11 -0500

Yep. That's what I recall too. It's already in the minutes (see the
text you posted below):

"Cullen’s view is that once he updates this document with these
changes and there is time to review, this will be ready to go to a WG
last call. Consensus of the room was to do so."

David (as chair)

On Sun, Nov 15, 2009 at 1:48 AM, Cullen Jennings <[email-masked]> wrote:
>
> My recollection may be wrong - I did not go back and listen to the minutes
> but I seem to recall that at the end of the reload base spec discussion, the
> people in the meeting felt it was ready for  WGLC after the updates
> discussed in the meeting were made. I think that should be in the minutes.
>
> Adding the notes in the link above to email below so they are in the email
> archive
>
> -----------------------
>
>
> Note takers Jim McEachern and Spencer Dawkins. Edited/compared with audio by
> David Bryan.
>
> Most points for discussion on slides are cosmetic/minor editorial, with a
> few exceptions.
>
> The draft is completely wrong  for calculating the signatures.  Proposal to
> use Michael Chen’s suggested change.  Group indicated that this path was
> supported.
>
> Turn density.  The system needs an algorithm for this to work, and this
> approach works, even though it is almost trivial.  Propose to just leave it
> as is since the system is not very sensitive to this (see below).  However,
> he will update the draft to document some of the limitations of this
> approach and to point to better algorithms that might be considered in
> future work. David Bryan asked from Jabber room about the slide stating it
> should be used since studies and experiments indicated it worked well enough
> and was robust if you got it wrong.
>
> David noted this assertion had been controversial before, and asked where he
> could find these studies indicating it worked, and Cullen indicated that the
> authors had not shared them publicly and felt it was too much work to
> publish the results. Indicated that there was an opportunity for more work
> in this area for a general service discovery algorithm.
>
> Self Tuning:  Proposal to include information on successors and predecessors
> in Leave messages as it is very helpful for the work in the self tuning
> draft.  Cullen was interested in what the group thought.  Comment in favor
> of including this as a should.  Cullen will do that for the next draft.
>
> Other Issues.  None
>
> Reactive recovery.  People keep suggesting they will provide input, but they
> don’t provide anything.  Cullen is therefore proposing to delete this as an
> open issue.
> Cullen’s view is that once he updates this document with these changes and
> there is time to review, this will be ready to go to a WG last call.
> Consensus of the room was to do so.
>
> David Bryan asked substitute chairs to get a list of reviewers who would do
> a full review of the document:
>
> Presentation outlined the two changes that were made to the presentation.
>  Asked if there were any additional comments.
>
> Cullen said that he had trouble commenting because he was unclear as to
> exactly what the purpose of this document was.  Without that, it is hard to
> comment.
>
> From Jabber room David mentioned that in an earlier meeting the consensus
> was for this to provide guidance to people new to P2P about the unique
> security issues and implications.
>
>  Questions from Cullen about exactly what is being analyzed since the number
> of messages seems low to him, especially if they include the entire TLS
> handshake.  Roni Even says that it does include the TLS handshake.  Cullen
> is unconvinced.  Agreed to take this offline to investigate further.
>
> The authors feel they have addressed the comments and that it is an optional
> method for particular deployment scenarios.
>
> Summarized a brief analysis of the attributes of each method, including cost
> in that analysis.  This analysis is very tentative, and they plan to extend
> the analysis to provide significantly more detail.
>
> Previous version did self tuning and load balancing. Current version is self
> tuning only.
>
> Self tuning allows parameters to change.  Each peer collects data and uses
> this to dynamically adjust parameters.
>
> Question to the group as to whether or not the group would be interested in
> having a milestone related to self tuning. Support was expressed for this
> work, but not that many people have read it.  Jon encouraged the work to
> continue, but with such limited audience, was reluctant to adopt it as a
> work group.  Jouni countered that we had that situation at the last meeting
> and that if it became a WG item, then perhaps more people would actually
> read it.  Extended discussion, with everyone generally supporting this work.
> Jon asked how many people understood the problem that this addressing.
>  About 20-30 people raised their hands.
>
> Poll: Should this draft be used as input into that charter item? Result -
> Audible support and no objections.
>
> Conclusion.  Encouraged to continue working on this and bring it to the list
> to continue generating interest.
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 16 Nov 2009 13:47:56 -0700

Clearly I need more sleep at IETF :-) Thanks.

On Nov 15, 2009, at 11:56 AM, David A. Bryan wrote:

> minutes
> with a
> Proposal to
> this
> predecessors
> presentation.
> consensus
> including cost
> interested in