Re: [P2PSIP] DRAFT minutes have been uploaded

Cullen Jennings <fluffy@cisco.com> Sun, 15 November 2009 06:48 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: p2psip@core3.amsl.com
Delivered-To: p2psip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D27B3A676A for <p2psip@core3.amsl.com>; Sat, 14 Nov 2009 22:48:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.556
X-Spam-Level:
X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JREsNT1RLZci for <p2psip@core3.amsl.com>; Sat, 14 Nov 2009 22:48:22 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 53EF93A6767 for <p2psip@ietf.org>; Sat, 14 Nov 2009 22:48:22 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApoEAKMz/0pAaHte/2dsb2JhbAC7BJZvhDwEgm0
X-IronPort-AV: E=Sophos;i="4.44,745,1249257600"; d="scan'208";a="104209817"
Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2009 06:48:53 +0000
Received: from tky-vpn-client-231-77.cisco.com (tky-vpn-client-231-77.cisco.com [10.70.231.77]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nAF6mpxE010390; Sun, 15 Nov 2009 06:48:52 GMT
Mime-Version: 1.0 (Apple Message framework v1076)
Content-Type: text/plain; charset="windows-1252"; format="flowed"; delsp="yes"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <8b2769930911141403k11eaabb6p99240c454d60f982@mail.gmail.com>
Date: Sun, 15 Nov 2009 15:48:52 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E433DB6-D712-4E3F-8ECA-B9B7C3C17302@cisco.com>
References: <8b2769930911141403k11eaabb6p99240c454d60f982@mail.gmail.com>
To: "David A. Bryan" <dbryan@ethernot.org>
X-Mailer: Apple Mail (2.1076)
Cc: P2PSIP WG <p2psip@ietf.org>, "Peterson, Jon" <jon.peterson@neustar.biz>
Subject: Re: [P2PSIP] DRAFT minutes have been uploaded
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Nov 2009 06:48:28 -0000

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:

> 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)
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> 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.