Re: [P2PSIP] Notes on section 9: chord

Jouni Mäenpää <jouni.maenpaa@ericsson.com> Wed, 25 March 2009 14:42 UTC

Return-Path: <jouni.maenpaa@ericsson.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 32CDB3A690A for <p2psip@core3.amsl.com>; Wed, 25 Mar 2009 07:42:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.655
X-Spam-Level:
X-Spam-Status: No, score=-5.655 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 G+zwA6HuBzl3 for <p2psip@core3.amsl.com>; Wed, 25 Mar 2009 07:42:39 -0700 (PDT)
Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 19B1F3A68F6 for <p2psip@ietf.org>; Wed, 25 Mar 2009 07:42:38 -0700 (PDT)
Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9BBB520F19; Wed, 25 Mar 2009 15:43:29 +0100 (CET)
X-AuditID: c1b4fb3c-ab75abb000003f6e-c4-49ca43119ecc
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 58B5B20F76; Wed, 25 Mar 2009 15:43:29 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 15:43:27 +0100
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Mar 2009 15:43:26 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B84DC245B; Wed, 25 Mar 2009 16:43:26 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7D59E219E5; Wed, 25 Mar 2009 16:43:26 +0200 (EET)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9F27A219E4; Wed, 25 Mar 2009 16:43:25 +0200 (EET)
Message-ID: <49CA430B.2090206@ericsson.com>
Date: Wed, 25 Mar 2009 07:43:23 -0700
From: Jouni Mäenpää <jouni.maenpaa@ericsson.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: "Das, Saumitra" <saumitra@qualcomm.com>
References: <2D06DE445C2ADE44890118C3F449B9636D582E32@NASANEXMB12.na.qualcomm.com>
In-Reply-To: <2D06DE445C2ADE44890118C3F449B9636D582E32@NASANEXMB12.na.qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-OriginalArrivalTime: 25 Mar 2009 14:43:26.0878 (UTC) FILETIME=[0E8033E0:01C9AD58]
X-Brightmail-Tracker: AAAAAA==
Cc: "p2psip@ietf.org" <p2psip@ietf.org>
Subject: Re: [P2PSIP] Notes on section 9: chord
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: Wed, 25 Mar 2009 14:42:40 -0000

Hi,

> 2. Are there further thoughts on defining reactive versus proactive
> repair for the base topology plugin? As Rhea2004 showed, it may be
> useful to have a periodic repair in stead of reactive. This could be
> set statically and configurable through the overlay configuration
> document based on the overlay deployment scale and expected churn.

Just wanted to point out that the Self-tuning DHT draft uses periodic
repair:

http://tools.ietf.org/html/draft-maenpaa-p2psip-self-tuning-00

-Jouni


Das, Saumitra wrote:
> I had some small comments on Section 9.
> 
> 1. Why do we wait for replies from the replicas to send back STORE Response. This will increase the amount of state on originating nodes from waiting around for all this to get done. A STORE should be deemed complete when the owning node has received and stored the data itself
> 
> 2. Are there further thoughts on defining reactive versus proactive repair for the base topology plugin? As Rhea2004 showed, it may be useful to have a periodic repair in stead of reactive. This could be set statically and configurable through the overlay configuration document based on the overlay deployment scale and expected churn.
> 
> 3. The section says that every time a connection is lost, the peer should remove the entry from the neighbor table and replace with best match from the routing table. Shouldn't we try to re-establish connection or give some guidelines on when to remove an entry after some number of re-establishes don't work?
> 
> Thanks
> Saumitra
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www.ietf.org/mailman/listinfo/p2psip