[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
- [P2PSIP] comments on draft-maenpaa-p2psip-self-tu… Roni Even
- Re: [P2PSIP] comments on draft-maenpaa-p2psip-sel… Jouni Mäenpää