[P2PSIP] comments on draft-maenpaa-p2psip-self-tuning

"Roni Even" <ron.even.tlv@gmail.com> Mon, 23 February 2009 06:59 UTC

Return-Path: <ron.even.tlv@gmail.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 192DE28C0DC for <p2psip@core3.amsl.com>; Sun, 22 Feb 2009 22:59:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 nIYnGvI6fX9U for <p2psip@core3.amsl.com>; Sun, 22 Feb 2009 22:59:13 -0800 (PST)
Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 778863A677C for <p2psip@ietf.org>; Sun, 22 Feb 2009 22:59:12 -0800 (PST)
Received: by bwz5 with SMTP id 5so4406058bwz.13 for <p2psip@ietf.org>; Sun, 22 Feb 2009 22:59:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=udiyfbA86kwGYv+SE/11tuYinOOVW+Y0rgYp/d594yw=; b=tlempMPHy7s4oSBozch0P5lm3eyyqSSJAO5WZY5zFRfLuYL6w9UT/+1KNWhR9MA2wF OUojyQ1omapvIjq9xhIP4xEJek/D5CxMI1IxtfYEbv8Y7bf4qOcU4/7SOjY0ywhLfZc5 dfxrx9D1rcfc02OnEUcCiy2kD18ByqyB23yRg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=Lu9jaBD7LR5rD65YH6F70mtcB9WccSwOcZkydfpftcM5R1x6IJX96fvWnIiiZltJWX T8fyOmw8OH6GopoYrCH0tgpc8kgQBxk5XdmFSMyHduaWd06wBN65Fk1gUKV459jXuiHz IYZOpTsjdeJjNPWdx8E8y6a6mE4xIJ3yi0iHE=
Received: by 10.103.102.17 with SMTP id e17mr3087533mum.119.1235372368360; Sun, 22 Feb 2009 22:59:28 -0800 (PST)
Received: from windows8d787f9 (bzq-79-182-130-108.red.bezeqint.net [79.182.130.108]) by mx.google.com with ESMTPS id i5sm2992440mue.43.2009.02.22.22.59.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 22:59:28 -0800 (PST)
From: Roni Even <ron.even.tlv@gmail.com>
To: p2psip@ietf.org
Date: Mon, 23 Feb 2009 08:57:35 +0200
Message-ID: <49a24950.05a0660a.670e.2b86@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01C99594.C74E84C0"
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcmVhAGhOrQLD8zBSx2T8dAd0YvG+g==
Content-Language: en-us
Subject: [P2PSIP] comments on draft-maenpaa-p2psip-self-tuning
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: Mon, 23 Feb 2009 06:59:14 -0000

Hi,

I read the draft and think the approach is good.

 

The first comment I have is related to the periodic and reactive
stabilization.  The reload base draft is section 10.2 discuss the topic and
mention that the current approach in the reload base draft is for reactive
and that more input is needed. Yet section 10.7.2 describes periodic
stabilization. I think that we need to decide on the approach for the base
reload and if it is periodic we need to see if the text from the self tuning
draft should fold to the base draft.

 

Other comments

 

1.       In section 4.1 the update message includes the send-id. I am not
sure why it is needed since the sender is attached to the receiving peer and
I assume the receiver of the updates knows this information. This parameter
is not part of the update message in the reload base draft.

2.       In section 4.1 the update answer has an option to send the
predecessor or successor lists. What is the benefit for it since the
receiver is also part of the periodic stabilization and will need to send it
anyhow, so this may be a duplicate of messages. I can see the use case for
the message in the reactive stabilization case.

3.       I am not sure how a peer knows which topology is used in the
overlay, is this a different overlay algorithm type that need to be
registered in the IANA section.

4.       This draft defines  different parameters for update and update
answer but uses the same message code name and I assume the same code value.
Is that the approach and the peer knows the parameters based on the overlay
algorithm type or should we have another code name and code value.

 

Regards

Roni Even