From erkkih@ee.oulu.fi Sun Nov 1 22:54:44 2009 Return-Path: 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 840443A682D for ; Sun, 1 Nov 2009 22:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 u6IQvdZcNKCQ for ; Sun, 1 Nov 2009 22:54:43 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by core3.amsl.com (Postfix) with ESMTP id 6A3E93A6877 for ; Sun, 1 Nov 2009 22:54:43 -0800 (PST) Received: from stekt1 (stekt1 [130.231.60.41]) by ee.oulu.fi (8.14.3/8.14.3) with ESMTP id nA26stE0007538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Nov 2009 08:54:56 +0200 (EET) Date: Mon, 2 Nov 2009 08:54:55 +0200 (EET) From: Erkki Harjula X-X-Sender: erkkih@stekt1 To: p2psip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [P2PSIP] Load balancing survey draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2009 06:54:44 -0000 Hi all, We have submitted a survey draft on different technology options for load balancing in structured P2P networks (including P2PSIP). The draft provides a survey of the existing and proposed load balancing mechanisms, categorizes them into four fundamental models, and briefly analyzes the main characteristics of each fundamental model. The goal is to provide background information on different possible load balancing options for P2PSIP. The draft can be found at http://www.ietf.org/id/draft-harjula-p2psip-loadbalancing-survey-00.txt. Please accept our apologies for the unfinished layout (for some reason, the submission tool did not allow us to update the draft with an improved version). Comments are welcome! Thanks, -Erkki From lucyyong@huawei.com Wed Nov 4 00:30:09 2009 Return-Path: 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 DF74A28C150 for ; Wed, 4 Nov 2009 00:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.612 X-Spam-Level: *** X-Spam-Status: No, score=3.612 tagged_above=-999 required=5 tests=[AWL=1.733, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 XZD6ud+IbfoZ for ; Wed, 4 Nov 2009 00:30:08 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6367B3A67F7 for ; Wed, 4 Nov 2009 00:30:08 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSK00N75SSL2R@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 04 Nov 2009 16:26:46 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KSK00K7WSSL37@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 04 Nov 2009 16:26:45 +0800 (CST) Received: from j53016H ([10.164.12.52]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KSK00FMASSL5V@szxml06-in.huawei.com> for p2psip@ietf.org; Wed, 04 Nov 2009 16:26:45 +0800 (CST) Date: Wed, 04 Nov 2009 16:26:45 +0800 From: lucy yong To: p2psip@ietf.org, 'Brian Rosen' Message-id: <009d01ca5d28$8b8d9ff0$340ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_8zU8jNs1dqqyyB+5hfQIjQ)" Thread-index: AcpdKItPnBiMpqypRpaMjKGYVf/hCA== Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 08:30:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_8zU8jNs1dqqyyB+5hfQIjQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Brian, My response has been lost. Do you mean that once we finish this document, WG task will complete? Regards, Lucy Having dealt with both kinds, I lean towards one document with everything. I really don't like having to refer back to other documents to get the picture, and I can always skim through the parts I don't care about. I find that I retain parts of the "skim" which keeps the big picture in my head better. I just did this over in ecrit (-framework and -phonebcp). It was a mistake: we should have had one document. Brian --Boundary_(ID_8zU8jNs1dqqyyB+5hfQIjQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable 
Hi =
Brian,
 
My response has been =
lost.
 
Do you mean that once we finish this =
document, WG task will =
complete?
 
Regards,
Lucy
<as an =
individual>
Having dealt with both kinds, I lean towards =
one document with everything.
I really don't like having to refer back to =
other documents to get the
picture, and I can always skim through the =
parts I don't care about.  I =
find
that I retain parts of the "skim" =
which keeps the big picture in my =
head
better.
 
I just did this over in ecrit (-framework and =
-phonebcp).  It was a =
mistake:
we should have had one =
document.
 
Brian

 

--Boundary_(ID_8zU8jNs1dqqyyB+5hfQIjQ)-- From br@brianrosen.net Wed Nov 4 06:01:34 2009 Return-Path: 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 599633A68B4 for ; Wed, 4 Nov 2009 06:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 A1nTCg+ELWxg for ; Wed, 4 Nov 2009 06:01:32 -0800 (PST) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 9A0263A67AF for ; Wed, 4 Nov 2009 06:01:32 -0800 (PST) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.96]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1N5gQi-0002aU-T4; Wed, 04 Nov 2009 08:01:46 -0600 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 04 Nov 2009 09:01:46 -0400 From: Brian Rosen To: lucy yong , Message-ID: Thread-Topic: [P2PSIP] New version of draft-ietf-p2psip-base Thread-Index: AcpdKItPnBiMpqypRpaMjKGYVf/hCAALs0VW In-Reply-To: <009d01ca5d28$8b8d9ff0$340ca40a@china.huawei.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3340170111_30879469" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2009 14:01:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3340170111_30879469 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable One major milestone will be complete. The WG won=B9t be done with it=B9s current charter items. It=B9s a very big step however. Brian On 11/4/09 4:26 AM, "lucy yong" wrote: > Hi Brian, > =20 > My response has been lost. > =20 > Do you mean that once we finish this document, WG task will complete? > =20 > Regards, > Lucy > > Having dealt with both kinds, I lean towards one document with everything= . > I really don't like having to refer back to other documents to get the > picture, and I can always skim through the parts I don't care about. I f= ind > that I retain parts of the "skim" which keeps the big picture in my head > better. > =20 > I just did this over in ecrit (-framework and -phonebcp). It was a mista= ke: > we should have had one document. > =20 > Brian > =20 >=20 --B_3340170111_30879469 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [P2PSIP] New version of draft-ietf-p2psip-base One major milestone will be complete.  The WG won’t be done wit= h it’s current charter items.  It’s a very big step however= .

Brian


On 11/4/09 4:26 AM, "lucy yong" <lucyyong@huawei.com> wrote:

<= SPAN STYLE=3D'font-size:12pt'>Hi Brian,
 
My response has been lost.
 
Do you mean that once we finish this document, WG task will complete?
 
Regards,
Lucy
<as an individual>
Having dealt with both kinds, I lean towards one document with everything.<= BR> I really don't like having to refer back to other documents to get the
picture, and I can always skim through the parts I don't care about.  = I find
that I retain parts of the "skim" which keeps the big picture in = my head
better.
 
I just did this over in ecrit (-framework and -phonebcp).  It was a mi= stake:
we should have had one document.
 
Brian

--B_3340170111_30879469-- From spencer@wonderhamster.org Thu Nov 5 14:02:20 2009 Return-Path: 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 6663F3A6807; Thu, 5 Nov 2009 14:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 mZ3jOTXSAbxi; Thu, 5 Nov 2009 14:02:19 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 28A443A6885; Thu, 5 Nov 2009 14:02:19 -0800 (PST) Received: from S73602b ([58.247.8.178]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Mg4yb-1Mkwcs2ttt-00O1NI; Thu, 05 Nov 2009 17:02:37 -0500 Message-ID: From: "Spencer Dawkins" To: "SIP-CLF Mailing List" , , Date: Fri, 6 Nov 2009 06:02:19 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_105A_01CA5EA6.B334E250" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Provags-ID: V01U2FsdGVkX1/ylTngMv1BHTUZZRpbCBN3X5lypRdT3JqzGuL YoOYBLWErK32p+JsrrvVPEUYhWrFCseCbO7p2kPW6T78tiWi1Q qo9/1OQExUA3vOues/xJUw0TaOkKCR5lHo4u2FRgoQ= Cc: Jon Peterson Subject: [P2PSIP] Preparing for Hiroshima meeting - SIPCLF, MEDIACTRL, P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2009 22:02:20 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_105A_01CA5EA6.B334E250 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Just to provide some guidance for the meetings I'm co-chairing (or, in = the case of P2PSIP, guest co-chairing with Jon Peterson) at IETF 76: SIPCLF, P2PSIP and MEDIACTRL are all scheduled back to back on Monday = afternoon (at 1300, 1520, and 1740 respectively - all are two-hour = timeslots).=20 Agendas for all of these have been uploaded (thanks, David and Brian for = taking care of the P2PSIP agenda), and are at = http://tools.ietf.org/agenda/76/#2009-11-07_0930.=20 The best coordinates I can provide for remote participants are=20 For SIPCLF: = http://www.timeanddate.com/worldclock/fixedtime.html?month=3D11&day=3D9&y= ear=3D2009&hour=3D13&min=3D0&sec=3D0&p1=3D248 For P2PSIP: = http://www.timeanddate.com/worldclock/fixedtime.html?month=3D11&day=3D9&y= ear=3D2009&hour=3D15&min=3D20&sec=3D0&p1=3D248 For MEDIACTRL: = http://www.timeanddate.com/worldclock/fixedtime.html?month=3D11&day=3D9&y= ear=3D2009&hour=3D17&min=3D40&sec=3D0&p1=3D248 The tools-style agenda pages also include pointers to the jabber rooms = and to the audio feeds. I know that we will have some key participants attending remotely for = all three groups, and ask that you consider volunteering as jabber = scribe before the meeting starts - we'll get much more accomplished if = we have good support for remote participants, AND if we don't spend time = waiting for someone to be inspired to volunteer during the meeting, that = will help, too! Thanks, and see you in Hiroshima! Spencer ------=_NextPart_000_105A_01CA5EA6.B334E250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Just to provide some guidance for the meetings I'm = co-chairing=20 (or, in the case of P2PSIP, guest co-chairing with Jon Peterson) at = IETF=20 76:
 
SIPCLF, P2PSIP and MEDIACTRL are all scheduled back = to back on=20 Monday afternoon (at 1300, 1520, and 1740 respectively - all are = two-hour=20 timeslots).
 
Agendas for all of these have been uploaded (thanks, = David and=20 Brian for taking care of the P2PSIP agenda), and are at http://tools.ie= tf.org/agenda/76/#2009-11-07_0930.=20
 
The best coordinates I can provide for remote participants are=20
 
For SIPCLF: http://www.timeanddate.com/worldclock/fixedtime.html?month=3D11&= day=3D9&year=3D2009&hour=3D13&min=3D0&sec=3D0&p1=3D24= 8
 
For P2PSIP: http://www.timeanddate.com/worldclock/fixedtime.html?month=3D11&= day=3D9&year=3D2009&hour=3D15&min=3D20&sec=3D0&p1=3D2= 48
 
For MEDIACTRL: http://www.timeanddate.com/worldclock/fixedtime.html?month=3D11&= day=3D9&year=3D2009&hour=3D17&min=3D40&sec=3D0&p1=3D2= 48
 
The tools-style agenda pages also include pointers = to the=20 jabber rooms and to the audio feeds.
 
I know that we will have some key participants = attending=20 remotely for all three groups, and ask that you consider = volunteering as=20 jabber scribe before the meeting starts - we'll get much more = accomplished if we=20 have good support for remote participants, AND if we don't spend time = waiting=20 for someone to be inspired to volunteer during the meeting, that will = help,=20 too!
 
Thanks, and see you in Hiroshima!
 
Spencer
------=_NextPart_000_105A_01CA5EA6.B334E250-- From michaelc@IDSSOFTWARE.COM Thu Nov 5 19:27:09 2009 Return-Path: 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 53BD53A6A26 for ; Thu, 5 Nov 2009 19:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.611 X-Spam-Level: * X-Spam-Status: No, score=1.611 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, SARE_SUB_ENC_UTF8=0.152] 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 q6uONihm3uqF for ; Thu, 5 Nov 2009 19:27:08 -0800 (PST) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by core3.amsl.com (Postfix) with SMTP id 9B31F3A6867 for ; Thu, 5 Nov 2009 19:27:08 -0800 (PST) Received: (qmail 30870 invoked from network); 6 Nov 2009 03:27:24 -0000 Received: from unknown (HELO gem-wbe20.prod.mesa1.secureserver.net) (64.202.189.175) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 6 Nov 2009 03:27:24 -0000 Received: (qmail 18607 invoked by uid 99); 6 Nov 2009 03:27:24 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.1.24 Message-Id: <20091105202724.61e8c06078a3b23a733c71e914c0b9df.d5e9797fe4.wbe@email.secureserver.net> From: To: p2psip@ietf.org Date: Thu, 05 Nov 2009 20:27:24 -0700 Mime-Version: 1.0 Subject: [P2PSIP] =?utf-8?q?That_is_SipRegistrationData=2Econtact=5Fprefs?= =?utf-8?q?=3F?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Nov 2009 03:27:09 -0000
Hi,

In the current draft-ietf-p2psip= -sip-03, there is no definition for field:

  = SipRegistration.SipRegistrationData.contact_prefs

=    o  If the registration is of type "sip_registration_route= ", then the
      contents are an opaque string= containing the callee's contact
      preferen= ces and a destination list for the peer.

What is contact = preferences?

Thanks

--Michael
 From fluffy@cisco.com Sat Nov 7 16:11:25 2009 Return-Path: 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 894503A67D3 for ; Sat, 7 Nov 2009 16:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.417 X-Spam-Level: X-Spam-Status: No, score=-106.417 tagged_above=-999 required=5 tests=[AWL=0.182, 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 FOfQezFMtNjV for ; Sat, 7 Nov 2009 16:11:24 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DB2903A67A2 for ; Sat, 7 Nov 2009 16:11:23 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAOua9UqrR7H+/2dsb2JhbADDC5cZhD4EgmA X-IronPort-AV: E=Sophos;i="4.44,701,1249257600"; d="scan'208";a="66926249" Received: from sj-core-2.cisco.com ([171.71.177.254]) by rtp-iport-2.cisco.com with ESMTP; 08 Nov 2009 00:11:47 +0000 Received: from tky-vpn-client-231-209.cisco.com (tky-vpn-client-231-209.cisco.com [10.70.231.209]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA80BkEo025017 for ; Sun, 8 Nov 2009 00:11:47 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sun, 8 Nov 2009 09:10:31 +0900 Message-Id: <3A99BE99-2CAB-4D7F-B997-63C665B7B457@cisco.com> To: P2PSIP WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [P2PSIP] Comments on draft-maenpaa-p2psip-service-discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 00:11:26 -0000 This looks excellent. I'd like to implement it and see what I find but at first read, I really like it. Cullen From fluffy@cisco.com Sat Nov 7 16:11:48 2009 Return-Path: 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 AE1523A67A7 for ; Sat, 7 Nov 2009 16:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.421 X-Spam-Level: X-Spam-Status: No, score=-106.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 FofPRvvXBWCW for ; Sat, 7 Nov 2009 16:11:47 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4CA263A67A2 for ; Sat, 7 Nov 2009 16:11:47 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANub9UqrR7H+/2dsb2JhbADDDZcZhD4EgmA X-IronPort-AV: E=Sophos;i="4.44,701,1249257600"; d="scan'208";a="66877436" Received: from sj-core-2.cisco.com ([171.71.177.254]) by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2009 00:12:11 +0000 Received: from tky-vpn-client-231-209.cisco.com (tky-vpn-client-231-209.cisco.com [10.70.231.209]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id nA80BkEp025017 for ; Sun, 8 Nov 2009 00:12:10 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sun, 8 Nov 2009 09:12:10 +0900 Message-Id: <268D74B9-DE7A-4F55-9874-5B276B1FEE22@cisco.com> To: P2PSIP WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) Subject: [P2PSIP] draft-maenpaa-p2psip-self-tuning-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 00:11:48 -0000 I like this draft and would love to seem some experimental data from operational networks playing with it. I'm not sure what anyone else things, but I think it would be worth considering moving just one small part of to the base draft - namely Section 5.6.1. On the Pro side for doing this: It's really easy to implement and it would provide some interesting options for future things such as this self tuning draft. On the Con side for doing this: in many DHT, a large percentage of nodes leave without sending nay signaling that they are going to Leave so specifying what goes in a Leave message might be a little optimistic Cullen From jouni.maenpaa@ericsson.com Sat Nov 7 17:11:55 2009 Return-Path: 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 D61573A68EC for ; Sat, 7 Nov 2009 17:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Gh-TQhpMnCV4 for ; Sat, 7 Nov 2009 17:11:53 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 27E463A68DD for ; Sat, 7 Nov 2009 17:11:52 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-b0-4af61af0d8c1 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 82.2D.31706.0FA16FA4; Sun, 8 Nov 2009 02:12:16 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 02:12:16 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 02:12:15 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BC4B824F7; Sun, 8 Nov 2009 03:12:15 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 876E021A2A; Sun, 8 Nov 2009 03:12:15 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5D8A7219B8; Sun, 8 Nov 2009 03:12:14 +0200 (EET) Message-ID: <4AF61AED.50606@ericsson.com> Date: Sun, 08 Nov 2009 10:12:13 +0900 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Cullen Jennings References: <268D74B9-DE7A-4F55-9874-5B276B1FEE22@cisco.com> In-Reply-To: <268D74B9-DE7A-4F55-9874-5B276B1FEE22@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 08 Nov 2009 01:12:16.0034 (UTC) FILETIME=[8299C820:01CA6010] X-Brightmail-Tracker: AAAAAA== Cc: P2PSIP WG Subject: Re: [P2PSIP] draft-maenpaa-p2psip-self-tuning-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 01:11:55 -0000 Hi Cullen, Thanks for your comments. See inline for my answers. Regards, Jouni Cullen Jennings wrote: > I'm not sure what anyone else things, but I think it would be worth > considering moving just one small part of to the base draft - namely > Section 5.6.1. I see no problem with doing that. > On the Pro side for doing this: It's really easy to implement and it > would provide some interesting options for future things such as this > self tuning draft. The nice thing about self-tuning is that it automatically determines appropriate values for the DHT parameters that are otherwise very difficult to configure manually. An example is the stabilization rate. > On the Con side for doing this: in many DHT, a large percentage of nodes > leave without sending nay signaling that they are going to Leave so > specifying what goes in a Leave message might be a little optimistic I agree that many nodes may leave without sending any Leave messages (i.e., crash). The mechanism works even without the data included in Leave messages; including data in them is just an optimization that speeds up recovery from peer departures in those cases in which peers send explicit leave signaling. Section 6.3.1 of the draft deals with failure detection (e.g., how for instance crashed peers are detected). From jouni.maenpaa@ericsson.com Sat Nov 7 17:21:16 2009 Return-Path: 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 66DA13A6836 for ; Sat, 7 Nov 2009 17:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[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 nvXRobrxs9m5 for ; Sat, 7 Nov 2009 17:21:15 -0800 (PST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B4E7A3A6808 for ; Sat, 7 Nov 2009 17:21:13 -0800 (PST) X-AuditID: c1b4fb3c-b7b3fae00000105f-fb-4af61d217688 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 9E.46.04191.12D16FA4; Sun, 8 Nov 2009 02:21:37 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 02:21:37 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Nov 2009 02:21:36 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id AAE4C25B6; Sun, 8 Nov 2009 03:21:36 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6E59621A2B; Sun, 8 Nov 2009 03:21:36 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D9A8D21A2A; Sun, 8 Nov 2009 03:21:34 +0200 (EET) Message-ID: <4AF61D1D.2040003@ericsson.com> Date: Sun, 08 Nov 2009 10:21:33 +0900 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Cullen Jennings References: <3A99BE99-2CAB-4D7F-B997-63C665B7B457@cisco.com> In-Reply-To: <3A99BE99-2CAB-4D7F-B997-63C665B7B457@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 08 Nov 2009 01:21:36.0947 (UTC) FILETIME=[D0EE5030:01CA6011] X-Brightmail-Tracker: AAAAAA== Cc: P2PSIP WG Subject: Re: [P2PSIP] Comments on draft-maenpaa-p2psip-service-discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 01:21:16 -0000 Hi, > I'd like to implement it and see what I find The ReDiR service discovery mechanism used in the draft has actually been used in OpenDHT. Some data about its performance is available in [1]. The main findings include that the increase in latency is rather small when compared to the use of well-known keys for finding services. The mechanism can also tolerate churn and uses only a low amount of bandwidth. Regards, Jouni [1] Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J., Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu, "OpenDHT: A Public DHT and its Uses", SIGCOMM'05. Cullen Jennings wrote: > > This looks excellent. I'd like to implement it and see what I find but > at first read, I really like it. > > Cullen > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From fluffy@cisco.com Sat Nov 7 20:32:29 2009 Return-Path: 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 2C07D3A6942 for ; Sat, 7 Nov 2009 20:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.378 X-Spam-Level: X-Spam-Status: No, score=-106.378 tagged_above=-999 required=5 tests=[AWL=0.221, 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 R+VaLIWI-Dk5 for ; Sat, 7 Nov 2009 20:32:28 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3D9FD3A6837 for ; Sat, 7 Nov 2009 20:32:28 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJjY9UpAaHte/2dsb2JhbADCYZcGgj+BfwSCYA X-IronPort-AV: E=Sophos;i="4.44,702,1249257600"; d="scan'208";a="48461083" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 08 Nov 2009 04:32:52 +0000 Received: from tky-vpn-client-231-209.cisco.com (tky-vpn-client-231-209.cisco.com [10.70.231.209]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id nA84WokN028991; Sun, 8 Nov 2009 04:32:51 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=iso-8859-1; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: <4AE6CC62.5070200@ericsson.com> Date: Sun, 8 Nov 2009 13:32:50 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <62E2541C-A6BD-44DC-845B-D089C7E7979F@cisco.com> References: <052001ca56e9$15b7dba0$1d0ca40a@china.huawei.com> <4AE6CC62.5070200@ericsson.com> To: Song Haibin X-Mailer: Apple Mail (2.1076) Cc: P2PSIP WG Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 04:32:29 -0000 So the turnDensity is not dynamic in the sense that each node needs an =20= algorithm to figure it out. It is changeable in that whoever can =20 update the configuration file for the overlay can change the value in =20= the configuration file. I think the key issue here is that the discovery mechanism in base is =20= a minimal approach - it does work fine, but it is far from optimal and =20= not appropriate for complex discover situation. I imagine that =20 services other than basic turn need something more advanced, such as =20 draft-maenpaa-p2psip-service. That said, I still think the base draft =20= need to describe something that can be used for minimal discover of =20 TURN servers. On Oct 27, 2009, at 19:33 , Jouni M=E4enp=E4=E4 wrote: > Hi Haibin, > >> In that case, the turnDensity is really dynamic, especially in an >> overlay with high churn rate and there are few TURN servers in the >> overlay. A TURN server has to register its information to the overlay >> with different times when the turnDensity changes. Does it need to >> delete some copies of its information or register more copies when =20= >> the >> turnDensity changes? I don't think this discovery mechanism in the >> document is mature to implement. > > In the following draft that we submitted last week: > > http://www.ietf.org/id/draft-maenpaa-p2psip-service-discovery-00.txt > > we are proposing a generic service discovery mechanism for RELOAD. As > indicated in the RELOAD base draft, RELOAD currently defines a > TURN-specific service discovery mechanism, but is lacking a generic > mechanism for service discovery. So if you are interested in an > alternative, more generic service discovery mechanism, you could =20 > have a > look at our draft. > > Regards, > Jouni From fluffy@cisco.com Sat Nov 7 20:48:33 2009 Return-Path: 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 427C83A69B7 for ; Sat, 7 Nov 2009 20:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 OmATy8v8KhAV for ; Sat, 7 Nov 2009 20:48:32 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 359AA3A69B4 for ; Sat, 7 Nov 2009 20:48:32 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMbc9UqrRN+K/2dsb2JhbADCWJcGgjmCBQSBaHg X-IronPort-AV: E=Sophos;i="4.44,702,1249257600"; d="scan'208";a="427369489" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 08 Nov 2009 04:48:57 +0000 Received: from tky-vpn-client-231-209.cisco.com (tky-vpn-client-231-209.cisco.com [10.70.231.209]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nA84muRN014864; Sun, 8 Nov 2009 04:48:56 GMT Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Cullen Jennings In-Reply-To: <4AEB62C4.9050009@idssoftware.com> Date: Sun, 8 Nov 2009 13:48:55 +0900 Content-Transfer-Encoding: 7bit Message-Id: <08D5F35B-9FB0-4E2A-B178-338E46EDD384@cisco.com> References: <4AEB62C4.9050009@idssoftware.com> To: Michael Chen , jc jc X-Mailer: Apple Mail (2.1076) Cc: P2PSIP WG Subject: Re: [P2PSIP] StoredData and its Signature X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2009 04:48:33 -0000 Yep, good catch. There is something wrong here and we need to fix it. I think this happened as we cut and pasted too much text as the data models got extended. It seems to me that when we went from having just StoredData to having a StoredDataValue inside the storedData, we forgot to update the signature. But before we figure out how to fix this, we need to talk about the lifetime and storage_time fields work. Say you have 2 nodes that can both write to the same location in the DHT. The way we deal with merges of partitioned networks is to take whatever value was written last. This is done using the storage_time field. Unfortunately, this means these two nodes need to have synchronized time for this to work. This does not seem all bad as the nodes that fail to have synchronized time only hurt their own data. So in many usage only one node can write to given location so no synchronized time is required at all. The result so this is when a node goes to sign something that it wants to store, it needs to include it's idea of what the absolute time is in the storage_time. Now consider things from the point of view of the nodes actually storing the data. They don't want to all have synchronized time. So they use the relative times in the lifetime field. Say the usage says the data will be stored for 1 hour. Initially the lifetime is set to 3600 seconds. But after half an hour, a new node joins the network and becomes responsible for the data. At this point the currently storing node needs to transfer the data to new node, but the 30 minutes have already gone by so it needs to transfer the data with lifetime of 1800 seconds. This allows all the nodes storing data to use only relative time so no global time synchronization is needed. However, the storing node needs to update the lifetime when it transfers the data to a new node so the lifetime can't be in the signature. Now you might say that not having it in the signatures allows the storing node to delete it early but this is always true - the storing node can always "loose" the data. It's not one of the security invariants of the DHT that your data won't be "lost" - we only guarantee it won't be modified if it is not lost. So I'm proposing the fix to this is Where we have the signature computed over > resource_id + kind + StoredData (with lifetime set to 0) + > SignerIdentity This is clearly silly as the StoredData includes the Signature. It should be closer > resource_id + kind + StoredDataValue + SignerIdentity However, this changes looses the storage_time so I think it needs to become > resource_id + kind + storage_time + StoredDataValue + > SignerIdentity I think this is exactly what you suggested. The other possibility is to include the lifetime but set it to zero (that's what the spec says now but that seems wacky) More inline ..... On Oct 31, 2009, at 7:03 , Michael Chen wrote: > Cullen, > > The definition of StoredData the opening of Section 6 and its > Signature in Section 6.1 are confusing: > > struct { > uint32 length; > uint64 storage_time; > uint32 lifetime; > StoredDataValue value; > Signature signature; > } StoredData; > > The contents of this structure are as follows: > > length > The length of the rest of the structure in octets. > ... > > value > The data value itself, as described in Section 6.2. > > signature > A signature over the data value. Section 6.1 describes the > signature computation. The element is formatted as described in > Section 5.3.4 > > 6.1. Data Signature Computation > > Each StoredData .... The input to the signature algorithm is: > > resource_id + kind + StoredData + SignerIdentity > > Where these values are: > ... > > StoredData > The contents of the stored data value, as described in the > previous sections, with the lifetime set to 0. > > 1) "length" seems to suggest it equals (sizeof(StoredData) - sizeof > (length)), which means the size of StoredDataValue and Signature > must be obtained before signing. No big deal, but the text should > more explicit and precise. Suggestion: > > length > The size of the StoredData structure in octets excluding the size > of length itself. sure - I read it to sort of say that but if this change makes it clearer, well I like it being clearer so I put you text in. > > 2) The big problem is the signature input. In Section 6 the term > "data value" appears in both the definition of "value" and > "signature", seems to suggest that the 3rd input block for the > signature only refer to the "value" field. In Section 6.1, the > instruction of setting "lifetime" to 0 before signing suggest the > signature includes the rest of the fields PLUS the signature itself > (the 3rd input block is "+ StoredData +"). > > If I am not mistaken, the correct definition for the signature input > should be: > > resource_id + kind + storage_time + lifetime + value + > SignerIdentity > > The fact that "length" includes the size of the signature is > somewhat awkward to be in the input. Excluding it does not degrade > the security of the signature. If it is up to me, instead of > setting "lifetime" to 0 before signing, why not exclude it all > together? totally agree (BTW, when I looked at our code, we were doing the above with lifetime set to zero but I agree removing lifetime makes sense). > > 3) "SignerIdentity" in this section should refer to its definition > in Section 5.3.4 to prevent people from reading it as simply a 20- > byte SHA1 hash value. > > SignerIdentity > The signer identity as defined in Section 5.3.4, which MUST > include > a hash of the signer's certificate. yep makes sense - thanks for text > > > Thanks > > --Michael > From erkkih@ee.oulu.fi Sun Nov 8 18:09:30 2009 Return-Path: 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 9B3403A68DB for ; Sun, 8 Nov 2009 18:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] 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 uziOuU2m3JUo for ; Sun, 8 Nov 2009 18:09:30 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by core3.amsl.com (Postfix) with ESMTP id 963763A68D6 for ; Sun, 8 Nov 2009 18:09:29 -0800 (PST) Received: from stekt1 (stekt1 [130.231.60.41]) by ee.oulu.fi (8.14.3/8.14.3) with ESMTP id nA929oXG007960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 04:09:50 +0200 (EET) Date: Mon, 9 Nov 2009 04:09:50 +0200 (EET) From: Erkki Harjula X-X-Sender: erkkih@stekt1 To: Cullen Jennings In-Reply-To: <3A99BE99-2CAB-4D7F-B997-63C665B7B457@cisco.com> Message-ID: References: <3A99BE99-2CAB-4D7F-B997-63C665B7B457@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: P2PSIP WG Subject: Re: [P2PSIP] Comments on draft-maenpaa-p2psip-service-discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 02:09:30 -0000 I like the draft too. Service discovery is indeed one of the most important features of a P2P network, and so far we have not seen any advanced solutions for it in P2PSIP WG. Implementing a prototype seems straightforward, as it does not require any special functionality from the base protocol. -Erkki On Sun, 8 Nov 2009, Cullen Jennings wrote: > > This looks excellent. I'd like to implement it and see what I find but at > first read, I really like it. > > Cullen > From jouni.maenpaa@ericsson.com Sun Nov 8 19:07:30 2009 Return-Path: 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 647C93A67E2 for ; Sun, 8 Nov 2009 19:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[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 OOoliNsqTTmY for ; Sun, 8 Nov 2009 19:07:29 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 23E053A689A for ; Sun, 8 Nov 2009 19:07:28 -0800 (PST) X-AuditID: c1b4fb24-b7b12ae000007bda-a3-4af787899877 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A6.81.31706.98787FA4; Mon, 9 Nov 2009 04:07:53 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 04:07:53 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Nov 2009 04:07:53 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 14BCF24F7; Mon, 9 Nov 2009 05:07:53 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C338721A2A; Mon, 9 Nov 2009 05:07:52 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 870FC21A21; Mon, 9 Nov 2009 05:07:51 +0200 (EET) Message-ID: <4AF78786.3030004@ericsson.com> Date: Mon, 09 Nov 2009 12:07:50 +0900 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Erkki Harjula References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 09 Nov 2009 03:07:53.0392 (UTC) FILETIME=[D4005B00:01CA60E9] X-Brightmail-Tracker: AAAAAA== Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Load balancing survey draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 03:07:30 -0000 Hi, I think this draft provides a nice summary of different load balancing models. One thing that might be good to add to the next revision is a table summarizing the pros and cons of each model. You could also consider the additional load some of the models place on a central enrollment server that may be used by the overlay (e.g., if peers need to obtain new Node-IDs to relocate themselves). Regards, Jouni Erkki Harjula wrote: > Hi all, > > We have submitted a survey draft on different technology options for > load balancing in structured P2P networks (including P2PSIP). The draft > provides a survey of the existing and proposed load balancing > mechanisms, categorizes them into four fundamental models, and briefly > analyzes the main characteristics of each fundamental model. The goal is > to provide background information on different possible load balancing > options for P2PSIP. > > The draft can be found at > http://www.ietf.org/id/draft-harjula-p2psip-loadbalancing-survey-00.txt. > Please accept our apologies for the unfinished layout (for some reason, > the submission tool did not allow us to update the draft with an > improved version). > > Comments are welcome! > > Thanks, > -Erkki > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From enrico.marocco@telecomitalia.it Sun Nov 8 20:33:47 2009 Return-Path: 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 62CFF28C144 for ; Sun, 8 Nov 2009 20:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 RBxsNp3QhY0m for ; Sun, 8 Nov 2009 20:33:46 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 339013A67CF for ; Sun, 8 Nov 2009 20:33:46 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 Nov 2009 05:34:09 +0100 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 Nov 2009 05:34:08 +0100 Message-ID: <4AF79BB8.9000404@telecomitalia.it> Date: Mon, 9 Nov 2009 13:34:00 +0900 From: Enrico Marocco User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Cullen Jennings References: <268D74B9-DE7A-4F55-9874-5B276B1FEE22@cisco.com> In-Reply-To: <268D74B9-DE7A-4F55-9874-5B276B1FEE22@cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090209060606050200050608" Cc: P2PSIP WG Subject: Re: [P2PSIP] draft-maenpaa-p2psip-self-tuning-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:33:47 -0000 --------------ms090209060606050200050608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > I like this draft and would love to seem some experimental data from > operational networks playing with it. > > I'm not sure what anyone else things, but I think it would be worth > considering moving just one small part of to the base draft - namely > Section 5.6.1. > > On the Pro side for doing this: It's really easy to implement and it > would provide some interesting options for future things such as this > self tuning draft. > > On the Con side for doing this: in many DHT, a large percentage of > nodes leave without sending nay signaling that they are going to Leave > so specifying what goes in a Leave message might be a little optimistic Considering also detected failures other than bye messages seems a pretty straightforward next step. I don't have an opinion whether this should be in the base specs or defined as an extension, but totally agree that a self-configuration mechanism is definitely worth having in any real DHT deployment. -- Ciao, Enrico --------------ms090209060606050200050608 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC AvgwggJhoAMCAQICEBtZixsKeF4i2Os0viEP+ncwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMyOTE2Mjg1OVoX DTEwMDMyOTE2Mjg1OVowUTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALhn5sIqd2hv7B6UBs4823vUHLamD/+tFSXZKQ4Yw5oQ 5hOdPUoJazGMDOyB9tWcqXdJxt0WqHxdgeCeAS0zV85Uf6cQcvkSe//umVkZvPuAYTKWRBJw 8rLfVuYhk9t2KraXyVfWIdoceZP0/v4eIoLyPw2/wQS3AvxujvkyL2N94S7IOmPCP6WXZmmW zNRzabSLLl50UA2jKbcYcWpKfQUFma9B1S3hAZTDiQTvXIJVmRdwYmnuwId9QTsm+7RB7oiy EC7+zeOORQk1Y6NjKinZmLb/C0tq40NIIPpBqNaZ+V6UmQ0jtYIlBQrlG6OpSPgjAS9IWsMg 7mbratVpsNkCAwEAAaM8MDowKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0 YWxpYS5pdDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADfh68XGwHIccDd0a+Fw D7LEP2QxLEqgP/gR73fsvT6y1COD7vGZY4BkYvryiU5sPkW4ulizN1ASSMJJIVMkQdzzKS+H e4dR5CpiPqz8b1LJdae8G7CUsBZ9KHYN4n6pGpdcq9YsGtfELp1W25MMppJcpKniscResCQF BWmw3EsAMIIC+DCCAmGgAwIBAgIQG1mLGwp4XiLY6zS+IQ/6dzANBgkqhkiG9w0BAQUFADBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDkwMzI5 MTYyODU5WhcNMTAwMzI5MTYyODU5WjBRMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt YmVyMS4wLAYJKoZIhvcNAQkBFh9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuGfmwip3aG/sHpQGzjzbe9QctqYP/60V JdkpDhjDmhDmE509SglrMYwM7IH21Zypd0nG3RaofF2B4J4BLTNXzlR/pxBy+RJ7/+6ZWRm8 +4BhMpZEEnDyst9W5iGT23YqtpfJV9Yh2hx5k/T+/h4igvI/Db/BBLcC/G6O+TIvY33hLsg6 Y8I/pZdmaZbM1HNptIsuXnRQDaMptxhxakp9BQWZr0HVLeEBlMOJBO9cglWZF3Biae7Ah31B Oyb7tEHuiLIQLv7N445FCTVjo2MqKdmYtv8LS2rjQ0gg+kGo1pn5XpSZDSO1giUFCuUbo6lI +CMBL0hawyDuZutq1Wmw2QIDAQABozwwOjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAN+HrxcbA chxwN3Rr4XAPssQ/ZDEsSqA/+BHvd+y9PrLUI4Pu8ZljgGRi+vKJTmw+Rbi6WLM3UBJIwkkh UyRB3PMpL4d7h1HkKmI+rPxvUsl1p7wbsJSwFn0odg3ifqkal1yr1iwa18QunVbbkwymklyk qeKxxF6wJAUFabDcSwAwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20CAQEwdjBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBtZixsKeF4i 2Os0viEP+ncwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDkxMTA5MDQzNDAwWjAjBgkqhkiG9w0BCQQxFgQUJOtrPYoc8lqpT59z t4UCYD5rWFEwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6dzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6 dzANBgkqhkiG9w0BAQEFAASCAQCg9ei5j+P1CW3UmJv54ZiHTEO8JE8sJFyn7uA01ikRiXsC EaJM+UMFf2lbFK8B54pDX8ws70Rgw1qwU4JCppw9FC9KvYGGS1c5rTm3gazUEi6HoyOxS3sN Sz3UMjdvn/oUg6aux3kx5f83U+YaJHAe/moLS6m2o4kbNFfsd1VdzMeyn7bRixHanlA1nqRo VU09ey5RXJFjJx/XAOMKUBszwTeHiOPOU1fB6tzdRuZN8GTxR+xGHa9UjKnafG5OTPNulajO VtL8Kd9hlUc0u17Ke1N9qOyYXRwC7POwvz38iW1Gf/PASjKS0MsrWhs/VnV7Qe8rJJCNhKBS Zqmgv2xzAAAAAAAA --------------ms090209060606050200050608-- From erkkih@ee.oulu.fi Sun Nov 8 20:39:40 2009 Return-Path: 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 EBEB33A6936 for ; Sun, 8 Nov 2009 20:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.984 X-Spam-Level: X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 xFOSDWwCCnIw for ; Sun, 8 Nov 2009 20:39:40 -0800 (PST) Received: from ee.oulu.fi (ee.oulu.fi [130.231.61.23]) by core3.amsl.com (Postfix) with ESMTP id DBB5B3A6932 for ; Sun, 8 Nov 2009 20:39:39 -0800 (PST) Received: from stekt1 (stekt1 [130.231.60.41]) by ee.oulu.fi (8.14.3/8.14.3) with ESMTP id nA94e2D9020340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 06:40:02 +0200 (EET) Date: Mon, 9 Nov 2009 06:40:01 +0200 (EET) From: Erkki Harjula X-X-Sender: erkkih@stekt1 To: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= In-Reply-To: <4AF78786.3030004@ericsson.com> Message-ID: References: <4AF78786.3030004@ericsson.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1804928587-1257741601=:26224" Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Load balancing survey draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 04:39:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1804928587-1257741601=:26224 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Hi, you are right, the draft should include a table summarizing the main characteristics - pros and cons. In a matter of fact, it is already included in the new version of the draft (which I was not able to update to the IETF database due to technical problems). We are planning to extend the draft with more detailed feature/cost analysis. -Erkki On Mon, 9 Nov 2009, Jouni Mäenpää wrote: > Hi, > > I think this draft provides a nice summary of different load balancing > models. One thing that might be good to add to the next revision is a > table summarizing the pros and cons of each model. You could also > consider the additional load some of the models place on a central > enrollment server that may be used by the overlay (e.g., if peers need > to obtain new Node-IDs to relocate themselves). > > Regards, > Jouni > > Erkki Harjula wrote: >> Hi all, >> >> We have submitted a survey draft on different technology options for >> load balancing in structured P2P networks (including P2PSIP). The draft >> provides a survey of the existing and proposed load balancing >> mechanisms, categorizes them into four fundamental models, and briefly >> analyzes the main characteristics of each fundamental model. The goal is >> to provide background information on different possible load balancing >> options for P2PSIP. >> >> The draft can be found at >> http://www.ietf.org/id/draft-harjula-p2psip-loadbalancing-survey-00.txt. >> Please accept our apologies for the unfinished layout (for some reason, >> the submission tool did not allow us to update the draft with an >> improved version). >> >> Comments are welcome! >> >> Thanks, >> -Erkki >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > ---559023410-1804928587-1257741601=:26224-- From root@core3.amsl.com Mon Nov 9 00:00:01 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 841B73A688A; Mon, 9 Nov 2009 00:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091109080001.841B73A688A@core3.amsl.com> Date: Mon, 9 Nov 2009 00:00:01 -0800 (PST) Cc: p2psip@ietf.org Subject: [P2PSIP] I-D Action:draft-ietf-p2psip-base-06.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2009 08:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Peer-to-Peer Session Initiation Protocol Working Group of the IETF. Title : REsource LOcation And Discovery (RELOAD) Base Protocol Author(s) : C. Jennings, et al. Filename : draft-ietf-p2psip-base-06.txt Pages : 149 Date : 2009-11-08 In this document the term BCP 78 and BCP 79 refer to RFC 3978 and RFC 3979 respectively. They refer only to those RFCs and not to any documents that update or supersede them. This document defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-p2psip-base-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-11-08234716.I-D@ietf.org> --NextPart-- From hocs@itri.org.tw Mon Nov 9 23:01:53 2009 Return-Path: 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 685273A693C for ; Mon, 9 Nov 2009 23:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.787 X-Spam-Level: *** X-Spam-Status: No, score=3.787 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_TW=1.335, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] 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 YZAU5zWhrZ1d for ; Mon, 9 Nov 2009 23:01:52 -0800 (PST) Received: from maillog2.itri.org.tw (maillog.itri.org.tw [61.61.254.20]) by core3.amsl.com (Postfix) with ESMTP id 010103A6905 for ; Mon, 9 Nov 2009 23:01:51 -0800 (PST) Received: from mail.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by maillog2.itri.org.tw with ESMTP id nAA72EaM070624; Tue, 10 Nov 2009 15:02:14 +0800 (CST) (envelope-from hocs@itri.org.tw) Received: from mail.itri.org.tw (localhost [127.0.0.1]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id nAA72Ecf022548; Tue, 10 Nov 2009 15:02:14 +0800 (CST) Received: from ms22.itri.org.tw (ms22.itri.org.tw [140.96.151.74]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id nAA72EGT022544; Tue, 10 Nov 2009 15:02:14 +0800 (CST) Received: from 52092035394 ([140.96.151.160]) by ms22.itri.org.tw (Lotus Domino Release 7.0.3FP1) with ESMTP id 2009111015021318-30330 ; Tue, 10 Nov 2009 15:02:13 +0800 From: "JeffreyHo" To: "'World'" , References: <944745.54325.qm@web72303.mail.tp2.yahoo.com> Date: Tue, 10 Nov 2009 15:02:13 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AcpThWJkni0kZaUQRg6Hr2vL1tR2WwOTc7lA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 In-Reply-To: <944745.54325.qm@web72303.mail.tp2.yahoo.com> X-MIMETrack: Itemize by SMTP Server on ms22/ITRI(Release 7.0.3FP1|February 24, 2008) at 2009-11-10 15:02:13, Serialize by Router on ms22/ITRI(Release 7.0.3FP1|February 24, 2008) at 2009-11-10 15:02:14, Serialize complete at 2009-11-10 15:02:14 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01CA6216.CC001340" X-MAIL: maillog2.itri.org.tw nAA72EaM070624 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] RELOAD implementation performance becnchmark X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2009 07:01:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A8_01CA6216.CC001340 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="big5" Dear there, =0D It seems there is not any response on the point of performance? Any= comment, suggestion and advice are welcome. Thanks a lot. =0D Jeffrey =0D _____ =0D From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On Behalf Of World Sent: Friday, October 23, 2009 10:06 AM To: p2psip@ietf.org Cc: p2psip@ietf.org Subject: [P2PSIP] RELOAD implementation performance becnchmark Dear all, =0D We are developing the P2PSIP RELOAD protocol using modified Chord as topology algorithm. Now it's time for us to verify our performance on this implementation. Could someone conduct me how to do the performance test and which items should be verified like lookup time, join time, etc? Are there any performance benchmarking for reference and comparison? Hope to get= your guidance soon. Thanks a lot in advance. =0D BR, Jeffrey ___________________________________________________=0D =B1z=AA=BA=A5=CD=AC=A1=A7Y=AE=C9=B3q =A1=D0 =B7=BE=B3q=A1B=AET=BC=D6=A1B=A5= =CD=AC=A1=A1B=A4u=A7@=A4@=A6=B8=B7d=A9w=A1I=0D http://messenger.yahoo.com.tw/ =A5=BB=ABH=A5=F3=A5i=AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE=F7=B1K=B8=EA=B0T=A1A= =ABD=AB=FC=A9w=A4=A7=A6=AC=A5=F3=AA=CC=A1A=BD=D0=A4=C5=A8=CF=A5=CE=A9=CE=B4= =A6=C5S=A5=BB=ABH=A5=F3=A4=BA=AEe=A1A=A8=C3=BD=D0=BEP=B7=B4=A6=B9=ABH=A5=F3= =A1C This email may contain confidential information. Please do not use or= disclose it in any way and delete it if you are not the intended= recipient. ------=_NextPart_000_00A8_01CA6216.CC001340 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="big5"
Dear= there,
 
It seems there is not=0D any response on the point of performance? Any comment,= suggestion and=0D advice are welcome.
Thanks a= lot.
 
Jeffrey   

From: p2psip-bounces@ietf.org=0D [mailto:p2psip-bounces@ietf.org] On Behalf Of World
Sent:= =0D Friday, October 23, 2009 10:06 AM
To:= p2psip@ietf.org
Cc:=0D p2psip@ietf.org
Subject: [P2PSIP] RELOAD implementation= performance=0D becnchmark

Dear all,
 
We are developing the= P2PSIP RELOAD=0D protocol using modified Chord as topology algorithm. Now it's=0D time for us to verify our performance on this=0D implementation. Could someone conduct me how to do the performance= test=0D and which items should be verified like lookup time, join time,=0D etc? Are there any performance benchmarking for reference= and=0D comparison?  Hope to get your guidance soon.=0D Thanks a lot in= advance.
 
BR,
Jeffrey
=
___________________________________________________=0D
=B1z=AA=BA=A5=CD=AC=A1=A7Y=AE=C9=B3q =A1=D0 =B7=BE=B3q=A1B=AET=BC=D6= =A1B=A5=CD=AC=A1=A1B=A4u=A7@=A4@=A6=B8=B7d=A9w=A1I=
http://messenger.yahoo.com.tw/
=A5=BB=ABH=A5=F3=A5i= =AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE=F7=B1K=B8=EA=B0T=A1A=ABD=AB=FC=A9w=A4=A7=A6= =AC=A5=F3=AA=CC=A1A=BD=D0=A4=C5=A8=CF=A5=CE=A9=CE=B4=A6=C5S=A5=BB=ABH=A5=F3= =A4=BA=AEe=A1A=A8=C3=BD=D0=BEP=B7=B4=A6=B9=ABH=A5=F3=A1C
This email may contain confidential information. Please do not use or= disclose it in any way and delete it if you are not the intended= recipient.
------=_NextPart_000_00A8_01CA6216.CC001340-- From davidbryan@gmail.com Sat Nov 14 14:02:47 2009 Return-Path: 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 7DF303A6832 for ; Sat, 14 Nov 2009 14:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 rBRyhLCzy4m0 for ; Sat, 14 Nov 2009 14:02:46 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id A5EBC3A682A for ; Sat, 14 Nov 2009 14:02:46 -0800 (PST) Received: by yxe30 with SMTP id 30so4731897yxe.29 for ; Sat, 14 Nov 2009 14:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=puNmPGcbZRmuUmoUSrK0Vw5lrnLP0TepjVXXVVbi/Do=; b=hkhGFuMGEYrtaMtqkfOwITKz1pwRrk6bmY7iblN4GApODj6HRBxWYKcsD4UHZ6Nu0T zVy+Z56mAXa85Cm4T9lNNCcwq0HMzk/PnApaIOFro94WAMdU1jqWOxcNVHZ5YumPNZ2+ muTgVcMKqMmmVaYTHPhpuKsKx2RTjWUHsgItw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=srjY5xU7Zk1BodMhFPmreOfZd9u1aYooWvNlGGovbimetQ27DWyJwFfRqHZQWBwhBh 3h4b60LNEFV9hpe0S1YlOQx0F0txl1+feFNixANLFSVoxCx8f7j35YQuUjUoLLMh9Q5X UPKhnaCsGSHi1lBeUQwNHRHLWsI+cWN/pj2aI= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.17.5 with SMTP id 5mr1167106ybq.195.1258236194086; Sat, 14 Nov 2009 14:03:14 -0800 (PST) Date: Sat, 14 Nov 2009 17:03:14 -0500 X-Google-Sender-Auth: ddb03e7fb30ea28d Message-ID: <8b2769930911141403k11eaabb6p99240c454d60f982@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Cc: "Peterson, Jon" Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2009 22:02:47 -0000 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 fluffy@cisco.com Sat Nov 14 22:48:28 2009 Return-Path: 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 ; 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 ; 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 ; 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 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" X-Mailer: Apple Mail (2.1076) Cc: P2PSIP WG , "Peterson, Jon" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 =20 minutes but I seem to recall that at the end of the reload base spec =20 discussion, the people in the meeting felt it was ready for WGLC =20 after the updates discussed in the meeting were made. I think that =20 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 =20 email archive ----------------------- IETF-76 P2PSIP Meeting notes (DRAFT) Note takers Jim McEachern and Spencer Dawkins. Edited/compared with =20 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, =20 with a few exceptions. The draft is completely wrong for calculating the signatures. =20 Proposal to use Michael Chen=92s suggested change. Group indicated that = =20 this path was supported. Turn density. The system needs an algorithm for this to work, and =20 this approach works, even though it is almost trivial. Propose to =20 just leave it as is since the system is not very sensitive to this =20 (see below). However, he will update the draft to document some of =20 the limitations of this approach and to point to better algorithms =20 that might be considered in future work. David Bryan asked from Jabber =20= room about the slide stating it should be used since studies and =20 experiments indicated it worked well enough and was robust if you got =20= it wrong. David noted this assertion had been controversial before, and asked =20 where he could find these studies indicating it worked, and Cullen =20 indicated that the authors had not shared them publicly and felt it =20 was too much work to publish the results. Indicated that there was an =20= opportunity for more work in this area for a general service discovery =20= algorithm. Self Tuning: Proposal to include information on successors and =20 predecessors in Leave messages as it is very helpful for the work in =20 the self tuning draft. Cullen was interested in what the group =20 thought. Comment in favor of including this as a should. Cullen will =20= do that for the next draft. Other Issues. None Robert raised =93open issues=94 in the document. Reactive recovery. People keep suggesting they will provide input, =20 but they don=92t provide anything. Cullen is therefore proposing to =20 delete this as an open issue. Cullen=92s view is that once he updates this document with these changes = =20 and there is time to review, this will be ready to go to a WG last =20 call. Consensus of the room was to do so. David Bryan asked substitute chairs to get a list of reviewers who =20 would do a full review of the document: Looking for detailed reviewers =95 John Buford =95 Robert Sparks =95 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 =20 presentation. Asked if there were any additional comments. Cullen said that he had trouble commenting because he was unclear as =20 to exactly what the purpose of this document was. Without that, it is =20= hard to comment. =46rom Jabber room David mentioned that in an earlier meeting the =20 consensus was for this to provide guidance to people new to P2P about =20= 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. =20 Questions from Cullen about exactly what is being analyzed since the =20 number of messages seems low to him, especially if they include the =20 entire TLS handshake. Roni Even says that it does include the TLS =20 handshake. Cullen is unconvinced. Agreed to take this offline to =20 investigate further. The authors feel they have addressed the comments and that it is an =20 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 =20 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. =95 Virtual servers: =95 Controlling object location =95 controlling node location =95 address space balancing Summarized a brief analysis of the attributes of each method, =20 including cost in that analysis. This analysis is very tentative, and =20= 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 =20 Discovery (RELOAD), Jouni M=E4enp=E4=E4, draft-maenpaa-p2psip-self-tuning-01, Previous version did self tuning and load balancing. Current version =20 is self tuning only. With static parameters approach it is not possible to have both low =20 stabilization overhead and low failure rate. Self tuning allows parameters to change. Each peer collects data and =20= uses this to dynamically adjust parameters. Question to the group as to whether or not the group would be =20 interested in having a milestone related to self tuning. Support was =20 expressed for this work, but not that many people have read it. Jon =20 encouraged the work to continue, but with such limited audience, was =20 reluctant to adopt it as a work group. Jouni countered that we had =20 that situation at the last meeting and that if it became a WG item, =20 then perhaps more people would actually read it. Extended discussion, =20= with everyone generally supporting this work. Jon asked how many people understood the problem that this =20 addressing. About 20-30 people raised their hands. Poll: How many people think that the WG should have a charter item to =20= address this problem? Result - Audible support and no objections. Poll: Should this draft be used as input into that charter item? =20 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=E4enp=E4=E4, 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 =20= p2psip? Result =96 lukewarm interest, with no objections. Conclusion. Encouraged to continue working on this and bring it to =20 the list to continue generating interest. =20= From davidbryan@gmail.com Sun Nov 15 10:56:16 2009 Return-Path: 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 9D2473A69EF for ; Sun, 15 Nov 2009 10:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 wlAvVg39nE60 for ; Sun, 15 Nov 2009 10:56:15 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 6496A3A69FA for ; Sun, 15 Nov 2009 10:56:15 -0800 (PST) Received: by ywh13 with SMTP id 13so5473776ywh.29 for ; Sun, 15 Nov 2009 10:56:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=nxtEUc08ITdnbQiHfKwgC3TpKG2Wrxt3Cw7vXdVh2hg=; b=TzVhCdbMKfU/K3ZNUFRKH1d47dOx0uNu/Vw18wHjkILiLEDeZ7BYHvyRygSBU8KpE8 WWYdSqW8buWz3GfVyUWqYTNlf4jdTJ1GpIKbUPhuhWSA3qJVb3cb0MFWyvB5ca3DaXWT cn3ZMrWGVpgFk+E8U1I86HcUOUzlq8zhjVHW0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=atHKohriPZd2UFq/zlV1cqen6CBHkMB2zuNIaOZUlsaw1Z2WO9IKMEUSV1vkP7xUwj gPAJ7P0Q3IfDbxVHmNmsC3c9K0Br9vCTFOLNOTtNPWY0fhmvO1LeDqL5DwEA6Z2PDrDi rxjkp3C0/xOm3HrCJdlzjgMqGasiCo6GZD8bQ= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.159.6 with SMTP id h6mr3788862ybe.280.1258311371038; Sun, 15 Nov 2009 10:56:11 -0800 (PST) In-Reply-To: <5E433DB6-D712-4E3F-8ECA-B9B7C3C17302@cisco.com> References: <8b2769930911141403k11eaabb6p99240c454d60f982@mail.gmail.com> <5E433DB6-D712-4E3F-8ECA-B9B7C3C17302@cisco.com> Date: Sun, 15 Nov 2009 13:56:11 -0500 X-Google-Sender-Auth: dcf9ecb7a7e4f70e Message-ID: <8b2769930911151056j521e90ajbe16238068f2b0f6@mail.gmail.com> From: "David A. Bryan" To: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: P2PSIP WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 18:56:16 -0000 Yep. That's what I recall too. It's already in the minutes (see the text you posted below): "Cullen=92s 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 wrote: > > My recollection may be wrong - I did not go back and listen to the minute= s > 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 emai= l > 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=92s suggested change. Group indicated that this path wa= s > 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). Howeve= r, > 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 i= t > should be used since studies and experiments indicated it worked well eno= ugh > 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 wor= k > in this area for a general service discovery algorithm. > > Self Tuning: Proposal to include information on successors and predecess= ors > 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 favo= r > of including this as a should. Cullen will do that for the next draft. > > Other Issues. None > > Robert raised =93open issues=94 in the document. > Reactive recovery. People keep suggesting they will provide input, but t= hey > don=92t provide anything. Cullen is therefore proposing to delete this a= s an > open issue. > Cullen=92s 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 > =95 John Buford > =95 Robert Sparks > =95 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 num= ber > of messages seems low to him, especially if they include the entire TLS > handshake. Roni Even says that it does include the TLS handshake. Culle= n > is unconvinced. Agreed to take this offline to investigate further. > > The authors feel they have addressed the comments and that it is an optio= nal > 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. > =95 Virtual servers: > =95 Controlling object location > =95 controlling node location > =95 address space balancing > > Summarized a brief analysis of the attributes of each method, including c= ost > in that analysis. This analysis is very tentative, and they plan to exte= nd > 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=E4enp=E4=E4, > draft-maenpaa-p2psip-self-tuning-01, > > Previous version did self tuning and load balancing. Current version is s= elf > 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 use= s > 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 meeti= ng > and that if it became a WG item, then perhaps more people would actually > read it. Extended discussion, with everyone generally supporting this wo= rk. > 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=E4enp=E4=E4, > 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 =96 lukewarm interest, with no objections. > > Conclusion. Encouraged to continue working on this and bring it to the l= ist > to continue generating interest. > > From edprince_in@yahoo.com Thu Nov 12 22:10:46 2009 Return-Path: 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 677063A694C for ; Thu, 12 Nov 2009 22:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.74 X-Spam-Level: *** X-Spam-Status: No, score=3.74 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DEAR_SOMETHING=1.605, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_46=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_81=0.6] 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 sE5mWl5WshhX for ; Thu, 12 Nov 2009 22:10:45 -0800 (PST) Received: from web111504.mail.gq1.yahoo.com (web111504.mail.gq1.yahoo.com [67.195.15.151]) by core3.amsl.com (Postfix) with SMTP id 7CBEE3A6947 for ; Thu, 12 Nov 2009 22:10:45 -0800 (PST) Received: (qmail 84931 invoked by uid 60001); 13 Nov 2009 06:11:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258092675; bh=s9hG/ONAHt0qqvb4wRad6yg2VZVZeyzky6t1SuorDQM=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HnOtgSKYA0DnRMX5vYynaeS393etDdwRNqlxML9E3vUTdhlBOP2tUG696U+/gRw24SOnm2WyFBv0TehYIdqJjCYU/I35ZB+mW++GV2eCR2LlnAD9Rftnmslfha/ZtlW8EPguiFG7F4ELYYI4kyDHqjNu4dyhiA6q09uJdcUBjFw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mvFvKcBfyzqVeR6oAEA8fWZixx8uKjZTR5Z1MFjTZPLiDCVUM09y/V9vtTYm4BCkVhC61W54Qal6HbZCmqqL6agVmgYyCxroPTGZ6VTkEJI/Sx+c75oKcTZ0SIuF4zfMYpo1Bzzxf/X6C7c+Z/ga8DwNAMR8toCEij1/LjQ2c9o=; Message-ID: <284742.84026.qm@web111504.mail.gq1.yahoo.com> X-YMail-OSG: 5lhnxi4VM1m7H.t2wRkBN7k_fmPXVtwsfQMdUp0RyONwXk8.mw_8jnr.D6gROuKmnD.muhWWMBcx7antQjQmLHlZL.u1ibW_nbJhBgucCBzFPrfubsqDcKnKecZqhwqJqH.r8vB6zIKNazKghmHmcwDKQLdlOdk56.3I1OX9SemOlp4SXXRabO9kIRW4hOMD5snN_9OiccaC5M4aOAKWXRl8nDigjtkmMi20cQo8tXu43is5ncoQaoAHaZ6eTPBTACz90iAHsuRH85AFT1fVLBf1GGdnjfkX6G9QRPTtpQGGwTDWLXMbiHpQXwsX26FWoLDg0YiR00Rao2hhWhD5Jto7tt8IfDlOU8.lr_aY5VmLyluj.aa3EigLqEKm3ltTYqpAWZt9Kg3VImcFMEoGR0n9qOroAbHu5ta9XHY9ot1R2jUM8N4P_ycnq._cwHeocpZ5JDVVtEwmd4.0TQ-- Received: from [118.94.11.62] by web111504.mail.gq1.yahoo.com via HTTP; Thu, 12 Nov 2009 22:11:15 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.8.100.260964 Date: Thu, 12 Nov 2009 22:11:15 -0800 (PST) From: edwin prince To: p2psip@core3.amsl.com MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 15 Nov 2009 11:26:54 -0800 Subject: [P2PSIP] inf X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 06:35:00 -0000 Dear Sir, i am working in handoff management in Wifi/wimax heterogeneous net= works using sip.is it possible to implement p2psip in wimax networks or Wif= i/wimax heterogeneous networks.i thought of working over it since its new a= rea.kindly let me know. With regards, Prof.Prince Edward,India =0A=0A=0A The INTERNET now has a personality. YOURS! See your Yahoo! H= omepage. http://in.yahoo.com/ From davidbryan@gmail.com Sun Nov 15 12:16:12 2009 Return-Path: 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 313F43A68E8 for ; Sun, 15 Nov 2009 12:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 TBlEUtRt2P3r for ; Sun, 15 Nov 2009 12:16:11 -0800 (PST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by core3.amsl.com (Postfix) with ESMTP id 70B6B3A68D9 for ; Sun, 15 Nov 2009 12:16:08 -0800 (PST) Received: by ywh13 with SMTP id 13so5516205ywh.29 for ; Sun, 15 Nov 2009 12:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HLfI0tUJFb99icTY3yaKiWj0Xj2cP4m5NMdnhF8uguM=; b=BzBvFNgcqVb0sbQ41vvs9LUFMUu0xJ1IwMjQ2MxLL5uAY9vSbRh6U+edy4XBk0nMB0 ipJPV+9rm1xzFYLTNrp/OMIP2PlED3/1+mNzlH3n3VtB2+/xM1bsgAsPCaIhLddvCZkt CDQgnGAjLvj/veXJ8k9PFmkJDCfhjS5eikOug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=YilXFT9SG9a2gEkmB8NNu1+3pGCOTDJz8SJHdRCV/6nIzlPEtYA7K/RIrAeBVYLy6m ioQa47jUp4ekmPCIsSg05p0RcFbqDqBaMmsvdh/lcUaBD4eIMOV8kTYmGOzT6fGUpLQS o6j5Y1ntslPwiZD3+KqMk3gJlkv1oTM9hCXyA= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.17.5 with SMTP id 5mr2588049ybq.195.1258315665461; Sun, 15 Nov 2009 12:07:45 -0800 (PST) Date: Sun, 15 Nov 2009 15:07:45 -0500 X-Google-Sender-Auth: 02bc20045ec1ed0b Message-ID: <8b2769930911151207x1b39e74x7a92a6d670cce933@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] List followup of meeting consensus: Take draft-ietf-p2psip-base-06 to WGLC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:16:12 -0000 In the meeting at IETF-76 in Hiroshima, the group was asked to hum on: Proposal that once changes discussed in the meeting were made (the authors state that these are reflected in version -06), that new version goes to WGLC. There was hum to do so. We would like to confirm this consensus on the mailing list. Please comment on this hum. (note this isn't the actual WGLC here, we are asking to confirm the hum to take the draft to WGLC. However if you have comments on the draft, please share them now. Thanks!) David (as chair) From davidbryan@gmail.com Sun Nov 15 12:20:53 2009 Return-Path: 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 7CD543A6849 for ; Sun, 15 Nov 2009 12:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 EtIdoZ8DfWem for ; Sun, 15 Nov 2009 12:20:52 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id B3FA93A6816 for ; Sun, 15 Nov 2009 12:20:52 -0800 (PST) Received: by gxk28 with SMTP id 28so2643955gxk.9 for ; Sun, 15 Nov 2009 12:20:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=u6GBLkI7GqCDFukxp3sDDL8XvbWSkz4WA5q1BB4WLhA=; b=Epp6kw3OrsjOsgcHQvnvbgwlMw7cOPcpGScIlHu9ew8y/xyN0XdzL7/ZNJFgAD+Lts 591t70/CS5+/4eoskX91TQB7OCbzN+DK1k9P2vrKbIJ5hIyVq7C+T3yEY9uBBEU0X21Z Y8zOWMSCFUTTgoNWXbsfQLXGmkBLjggJLPKFk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=UjlVvJ6iDXlvw/vMMonxRss75QdcRPFR55GiJ5fXTo3p5ZqirhRYqZgzOIlEBGxdZn lKsSOG9HKYa0Av2ySgVt4Ewp9h65rVEqBAdU8Xi03EH3eOUxMNAT5RASmOKT8iTOmi0H prSv6hpAB567wKzpXaiMVHOZIox9sq8MSX2w4= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.171.4 with SMTP id t4mr11652360ybe.346.1258316444527; Sun, 15 Nov 2009 12:20:44 -0800 (PST) Date: Sun, 15 Nov 2009 15:20:44 -0500 X-Google-Sender-Auth: 288d39f42fa40401 Message-ID: <8b2769930911151220r372f019es3ea5384eaa999c25@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG , Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] List followup of meeting consensus: Hums on 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:20:53 -0000 In the meeting at IETF-76 in Hiroshima, the group was asked to hum on: Does the group feel there should be a charter deliverable to address the self-tuning problem. There was hum called in support of doing so. A second hum was asked, noting that there were few who had read it and it was preliminary, but to see if there was a feeling that draft draft-maenpaa-p2psip-self-tuning-01 was a good input toward a charter deliverable to work in this area, please hum. There was a quiet but hum in support. We would like to confirm these hums on the mailing list. Please comment on these hums. David (as chair) From davidbryan@gmail.com Sun Nov 15 12:25:13 2009 Return-Path: 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 C0DB13A6827 for ; Sun, 15 Nov 2009 12:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 WORB-nmmDR1W for ; Sun, 15 Nov 2009 12:25:13 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 01F853A6816 for ; Sun, 15 Nov 2009 12:25:12 -0800 (PST) Received: by gxk28 with SMTP id 28so2645690gxk.9 for ; Sun, 15 Nov 2009 12:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=37g2pfZoM0OKJdYDp4ggBVy5U2Ve9DVnYVgkcXESgm8=; b=Y9lIo9sj6jxoVZZa9J7vfHPi1Ug+0BPrsjcoEeCzWzSF0bl4RkM17O/bnE5Gyf+1Je AIkxT4nZUL2dCFP8RAnI5tDPtHGGorzwgzCzCHUYvipmKUQjfhZ+mUIEIYJ5ToTNQ9lP sUGYoxJl0J8Hsy3IQPbdeQ93CAekT46a3yacE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=AeGkIDzjEKScNen1B1l3eMGKaI9mtbN9cG5iXpRKyIMuwvuag+l3kWgxsb0Uo8wb9t x99cZj57qURISY0Fi/TGRHwooQKX/caGjNWDIpxWq2m4ZO1DulvcsBvJhLy8yWgVaFor lepKbd5G7oRqMceFHxixWHQv4+1iJI1T8LO2w= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.151.1.32 with SMTP id d32mr8517174ybi.333.1258316709747; Sun, 15 Nov 2009 12:25:09 -0800 (PST) Date: Sun, 15 Nov 2009 15:25:09 -0500 X-Google-Sender-Auth: 943fc285b8c11242 Message-ID: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG , Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] List followup of meeting consensus: Interest in generic service discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2009 20:25:13 -0000 In the meeting at IETF-76 in Hiroshima, the group was asked to hum on: Should there be a milestone to have a generic service discovery mechanism for the work in P2PSIP? There was some interest, but it was labeled as lukewarm, and not consensus by the guest chairs. However, there was agreement to take this discussion to the list. We would like to discuss this hum on the mailing list. Please comment on this hum. David (as chair) From fluffy@cisco.com Mon Nov 16 12:48:01 2009 Return-Path: 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 C6A913A67EE for ; Mon, 16 Nov 2009 12:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 O-sxab4GdG1E for ; Mon, 16 Nov 2009 12:48:00 -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 916AB3A6991 for ; Mon, 16 Nov 2009 12:48:00 -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: ApoEAF5IAUurRN+K/2dsb2JhbADADZcXhDwE X-IronPort-AV: E=Sophos;i="4.44,753,1249257600"; d="scan'208";a="104815759" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 16 Nov 2009 20:47:59 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAGKlubF020867; Mon, 16 Nov 2009 20:47:57 GMT From: Cullen Jennings To: "David A. Bryan" In-Reply-To: <8b2769930911151056j521e90ajbe16238068f2b0f6@mail.gmail.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <8b2769930911141403k11eaabb6p99240c454d60f982@mail.gmail.com> <5E433DB6-D712-4E3F-8ECA-B9B7C3C17302@cisco.com> <8b2769930911151056j521e90ajbe16238068f2b0f6@mail.gmail.com> Message-Id: <7328E6AD-29E1-4CB2-90B2-5E7B1FF609CA@cisco.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 13:47:56 -0700 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 20:48:01 -0000 Clearly I need more sleep at IETF :-) Thanks. On Nov 15, 2009, at 11:56 AM, David A. Bryan wrote: > Yep. That's what I recall too. It's already in the minutes (see the > text you posted below): > > "Cullen=92s 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 =20= > wrote: > > > > My recollection may be wrong - I did not go back and listen to the =20= > minutes > > but I seem to recall that at the end of the reload base spec =20 > 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 =20= > 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 =20 > 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 =20 > the email > > archive > > > > ----------------------- > > > > > > IETF-76 P2PSIP Meeting notes (DRAFT) > > > > Note takers Jim McEachern and Spencer Dawkins. Edited/compared =20 > 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, =20= > with a > > few exceptions. > > > > The draft is completely wrong for calculating the signatures. =20 > Proposal to > > use Michael Chen=92s suggested change. Group indicated that this =20= > path was > > supported. > > > > Turn density. The system needs an algorithm for this to work, and =20= > this > > approach works, even though it is almost trivial. Propose to just =20= > leave it > > as is since the system is not very sensitive to this (see below). =20= > However, > > he will update the draft to document some of the limitations of this > > approach and to point to better algorithms that might be =20 > considered in > > future work. David Bryan asked from Jabber room about the slide =20 > stating it > > should be used since studies and experiments indicated it worked =20 > well enough > > and was robust if you got it wrong. > > > > David noted this assertion had been controversial before, and =20 > asked where he > > could find these studies indicating it worked, and Cullen =20 > indicated that the > > authors had not shared them publicly and felt it was too much work =20= > to > > publish the results. Indicated that there was an opportunity for =20 > more work > > in this area for a general service discovery algorithm. > > > > Self Tuning: Proposal to include information on successors and =20 > predecessors > > in Leave messages as it is very helpful for the work in the self =20 > tuning > > draft. Cullen was interested in what the group thought. Comment =20= > in favor > > of including this as a should. Cullen will do that for the next =20 > draft. > > > > Other Issues. None > > > > Robert raised =93open issues=94 in the document. > > Reactive recovery. People keep suggesting they will provide =20 > input, but they > > don=92t provide anything. Cullen is therefore proposing to delete =20= > this as an > > open issue. > > Cullen=92s view is that once he updates this document with these =20 > 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 =20= > would do > > a full review of the document: > > > > Looking for detailed reviewers > > =95 John Buford > > =95 Robert Sparks > > =95 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 =20 > presentation. > > Asked if there were any additional comments. > > > > Cullen said that he had trouble commenting because he was unclear =20= > as to > > exactly what the purpose of this document was. Without that, it =20 > is hard to > > comment. > > > > =46rom Jabber room David mentioned that in an earlier meeting the =20= > consensus > > was for this to provide guidance to people new to P2P about the =20 > unique > > security issues and implications. > > > > An extension to RELOAD to support Direct Response and Relay Peer =20 > 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 =20= > the number > > of messages seems low to him, especially if they include the =20 > entire TLS > > handshake. Roni Even says that it does include the TLS =20 > handshake. Cullen > > is unconvinced. Agreed to take this offline to investigate further. > > > > The authors feel they have addressed the comments and that it is =20 > 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. > > =95 Virtual servers: > > =95 Controlling object location > > =95 controlling node location > > =95 address space balancing > > > > Summarized a brief analysis of the attributes of each method, =20 > including cost > > in that analysis. This analysis is very tentative, and they plan =20= > 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=E4enp=E4=E4, > > draft-maenpaa-p2psip-self-tuning-01, > > > > Previous version did self tuning and load balancing. Current =20 > 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 =20= > and uses > > this to dynamically adjust parameters. > > > > Question to the group as to whether or not the group would be =20 > interested in > > having a milestone related to self tuning. Support was expressed =20 > for this > > work, but not that many people have read it. Jon encouraged the =20 > work to > > continue, but with such limited audience, was reluctant to adopt =20 > it as a > > work group. Jouni countered that we had that situation at the =20 > last meeting > > and that if it became a WG item, then perhaps more people would =20 > actually > > read it. Extended discussion, with everyone generally supporting =20= > this work. > > Jon asked how many people understood the problem that this =20 > addressing. > > About 20-30 people raised their hands. > > > > Poll: How many people think that the WG should have a charter =20 > item to > > address this problem? Result - Audible support and no objections. > > > > Poll: Should this draft be used as input into that charter item? =20 > 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=E4enp=E4=E4, > > 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 =20= > for > > p2psip? Result =96 lukewarm interest, with no objections. > > > > Conclusion. Encouraged to continue working on this and bring it =20 > to the list > > to continue generating interest. > > > > > From ari.keranen@nomadiclab.com Tue Nov 17 04:44:52 2009 Return-Path: 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 A8A0428C0CF for ; Tue, 17 Nov 2009 04:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 kb6FfF5hNswU for ; Tue, 17 Nov 2009 04:44:52 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id D69AA3A693C for ; Tue, 17 Nov 2009 04:44:51 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 945A21EF271; Tue, 17 Nov 2009 14:44:48 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuB4suye-jiQ; Tue, 17 Nov 2009 14:44:48 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by n2.nomadiclab.com (Postfix) with ESMTP id 06EFE1EF125; Tue, 17 Nov 2009 14:44:47 +0200 (EET) Message-ID: <4B029ABF.4070806@nomadiclab.com> Date: Tue, 17 Nov 2009 14:44:47 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "David A. Bryan" References: <8b2769930911151220r372f019es3ea5384eaa999c25@mail.gmail.com> In-Reply-To: <8b2769930911151220r372f019es3ea5384eaa999c25@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] List followup of meeting consensus: Hums on 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 12:44:52 -0000 David A. Bryan wrote: > In the meeting at IETF-76 in Hiroshima, the group was asked to hum on: > > Does the group feel there should be a charter deliverable to address > the self-tuning problem. > > There was hum called in support of doing so. > > A second hum was asked, noting that there were few who had read it and > it was preliminary, but to see if there was a feeling that draft > draft-maenpaa-p2psip-self-tuning-01 was a good input toward a charter > deliverable to work in this area, please hum. > > There was a quiet but hum in support. > > We would like to confirm these hums on the mailing list. Please > comment on these hums. +1 for chartering a deliverable for this and adopting draft-maenpaa-p2psip-self-tuning-01 as the starting point. Cheers, Ari From enrico.marocco@telecomitalia.it Tue Nov 17 05:36:15 2009 Return-Path: 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 44A7B3A6BC1 for ; Tue, 17 Nov 2009 05:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.511 X-Spam-Level: * X-Spam-Status: No, score=1.511 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 DDaTYvauP+HF for ; Tue, 17 Nov 2009 05:36:14 -0800 (PST) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id F10683A6BC0 for ; Tue, 17 Nov 2009 05:36:13 -0800 (PST) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 17 Nov 2009 14:36:10 +0100 Received: from [163.162.173.7] (163.162.173.7) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 17 Nov 2009 14:36:07 +0100 Message-ID: <4B02A6EF.90100@telecomitalia.it> Date: Tue, 17 Nov 2009 14:36:47 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: Ari Keranen References: <8b2769930911151220r372f019es3ea5384eaa999c25@mail.gmail.com> <4B029ABF.4070806@nomadiclab.com> In-Reply-To: <4B029ABF.4070806@nomadiclab.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040603060601070203020609" Cc: P2PSIP WG Subject: Re: [P2PSIP] List followup of meeting consensus: Hums on 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 13:36:15 -0000 --------------ms040603060601070203020609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ari Keranen wrote: >> In the meeting at IETF-76 in Hiroshima, the group was asked to hum on: >> >> Does the group feel there should be a charter deliverable to address >> the self-tuning problem. >> >> There was hum called in support of doing so. >> >> A second hum was asked, noting that there were few who had read it and >> it was preliminary, but to see if there was a feeling that draft >> draft-maenpaa-p2psip-self-tuning-01 was a good input toward a charter >> deliverable to work in this area, please hum. >> >> There was a quiet but hum in support. >> >> We would like to confirm these hums on the mailing list. Please >> comment on these hums. > > +1 for chartering a deliverable for this and adopting > draft-maenpaa-p2psip-self-tuning-01 as the starting point. As already said at the mic, +1 also from me. I really think this is an essential functionality for any overlay expected to work in the real work. -- Ciao, Enrico --------------ms040603060601070203020609 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTExMTcxMzM2NDdaMCMG CSqGSIb3DQEJBDEWBBRUJ7hN++vkIZiAhM751/nfq7JPGDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAGtbs/A8Rjs1 b09mI+c1yVFAK7iDo3o0tBAlc/z8QhRNFnrOLHNB38A/r51PledAbdNM6k+I/vtx0WOXHOIL j+e8xhX/KtV4ms+XLbYB+fiBBI9DnA9K6Sjjv3QOrVUdRJt9w1IrD6YoBg4ma4Jz2SGbu4x2 SSwDG74HH16ldqxg2eEMU3RE0ZqeM9cR1KcPO6+7BBjmlmHd4YxV7WtjTIUR1iHiFaFK6und k9mooNmGGQR+zJA/QkPxImhinmtiZIt0LYRf+XgsUvj5r5WC+blVxQbqvux0gDDEfHJ3h86V ZhOhz0lXZlCtprax+5MZKSnXbt0AP+OkAFGaZW8yFrwAAAAAAAA= --------------ms040603060601070203020609-- From fluffy@cisco.com Tue Nov 17 12:32:43 2009 Return-Path: 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 6B2543A6977 for ; Tue, 17 Nov 2009 12:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.141 X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.458, 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 2oE7E1R190bC for ; Tue, 17 Nov 2009 12:32:42 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BAB603A67FA for ; Tue, 17 Nov 2009 12:32:42 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIeXAkurRN+K/2dsb2JhbAC/NpgshDsE X-IronPort-AV: E=Sophos;i="4.44,759,1249257600"; d="scan'208";a="50631953" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Nov 2009 20:32:41 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAHKWeld001571; Tue, 17 Nov 2009 20:32:41 GMT From: Cullen Jennings To: Ari Keranen In-Reply-To: <4B029ABF.4070806@nomadiclab.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <8b2769930911151220r372f019es3ea5384eaa999c25@mail.gmail.com> <4B029ABF.4070806@nomadiclab.com> Message-Id: <449E74B9-3475-4F0F-9A5B-9A5ED58B8ED0@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 13:32:40 -0700 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] List followup of meeting consensus: Hums on 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 20:32:43 -0000 On Nov 17, 2009, at 5:44 AM, Ari Keranen wrote: > > +1 for chartering a deliverable for this and adopting draft-maenpaa- > p2psip-self-tuning-01 as the starting point. +1 Cullen (in my individual contributor role) From fluffy@cisco.com Tue Nov 17 12:33:58 2009 Return-Path: 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 567E33A69FE for ; Tue, 17 Nov 2009 12:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.207 X-Spam-Level: X-Spam-Status: No, score=-106.207 tagged_above=-999 required=5 tests=[AWL=0.392, 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 afHhBtouOVns for ; Tue, 17 Nov 2009 12:33:57 -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 9C3993A6977 for ; Tue, 17 Nov 2009 12:33:57 -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: ApoEAAOYAkurRN+K/2dsb2JhbAC/N5gshDsE X-IronPort-AV: E=Sophos;i="4.44,759,1249257600"; d="scan'208";a="105536010" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2009 20:33:57 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAHKXtBL002687; Tue, 17 Nov 2009 20:33:56 GMT From: Cullen Jennings To: "David A. Bryan" In-Reply-To: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> Impp: xmpp:cullenfluffyjennings@jabber.org References: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> Message-Id: <07DF6458-1CBF-46CF-B094-5C275A5DFB8B@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 13:33:55 -0700 X-Mailer: Apple Mail (2.936) Cc: P2PSIP WG Subject: Re: [P2PSIP] List followup of meeting consensus: Interest in generic service discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 20:33:58 -0000 On Nov 15, 2009, at 1:25 PM, David A. Bryan wrote: > Should there be a milestone to have a generic service discovery > mechanism for the work in P2PSIP? I hummed yes in the meeting so I guess this is a double count but, yes. Cullen (in my individual contributor role) From hsinnrei@adobe.com Tue Nov 17 14:04:48 2009 Return-Path: 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 E27963A6AF6 for ; Tue, 17 Nov 2009 14:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6yDAACTb0izy for ; Tue, 17 Nov 2009 14:04:47 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by core3.amsl.com (Postfix) with ESMTP id 087A03A68D8 for ; Tue, 17 Nov 2009 14:04:42 -0800 (PST) Received: from source ([192.150.8.22]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKSwMd+bngCbaa9cJgyCBIO04pgFkHiYbP@postini.com; Tue, 17 Nov 2009 14:04:46 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id nAHM4cW0005064; Tue, 17 Nov 2009 14:04:39 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id nAHM4Z7q008498; Tue, 17 Nov 2009 14:04:37 -0800 (PST) Received: from nacas03.corp.adobe.com (10.8.189.121) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 17 Nov 2009 13:57:35 -0800 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Tue, 17 Nov 2009 13:57:35 -0800 From: Henry Sinnreich To: Cullen Jennings , Ari Keranen Date: Tue, 17 Nov 2009 13:57:33 -0800 Thread-Topic: [P2PSIP] List followup of meeting consensus: Hums on self-tuning Thread-Index: AcpnxSA9zSgOZu3rQwqBY3oSXbmCsAAC9bf0 Message-ID: In-Reply-To: <449E74B9-3475-4F0F-9A5B-9A5ED58B8ED0@cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C728786D72CDhsinnreiadobecom_" MIME-Version: 1.0 Cc: P2PSIP WG Subject: Re: [P2PSIP] List followup of meeting consensus: Hums on 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 22:04:49 -0000 --_000_C728786D72CDhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Thanks, Henry On 11/17/09 2:32 PM, "Cullen Jennings" wrote: On Nov 17, 2009, at 5:44 AM, Ari Keranen wrote: > > +1 for chartering a deliverable for this and adopting draft-maenpaa- > p2psip-self-tuning-01 as the starting point. +1 Cullen (in my individual contributor role) _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www.ietf.org/mailman/listinfo/p2psip --_000_C728786D72CDhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] List followup of meeting consensus: Hums on self-tuning= +1

Thanks, Henry


On 11/17/09 2:32 PM, "Cullen Jennings" <fluffy@cisco.com> wrote:



On Nov 17, 2009, at 5:44 AM, Ari Keranen wrote:

>
> +1 for chartering a deliverable for this and adopting draft-maenpaa- > p2psip-self-tuning-01 as the starting point.

+1

Cullen (in my individual contributor role)

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.o= rg/mailman/listinfo/p2psip

--_000_C728786D72CDhsinnreiadobecom_-- From brian.rosen@neustar.biz Tue Nov 17 15:29:06 2009 Return-Path: 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 5DE113A6A0A for ; Tue, 17 Nov 2009 15:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 i5yCV5pwFGbo for ; Tue, 17 Nov 2009 15:29:05 -0800 (PST) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 357F53A67DA for ; Tue, 17 Nov 2009 15:29:05 -0800 (PST) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1258500541; x=1258586941; h=From:Date:Subject:Message-ID:Content-type:Content-transfer-encoding; b=Pc0DtqIJH9NADZ4UVV7abZtYK0iXbRPfSxeAl8uG8sPojlbyiZ6sgFj4Q+xQg+NL0u2JladpzeZ3AO P3YOcpXA== Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.26089809; Tue, 17 Nov 2009 18:29:00 -0500 Received: from 192.168.128.96 ([192.168.128.96]) by STNTEXCH11.cis.neustar.com ([10.31.13.50]) with Microsoft Exchange Server HTTP-DAV ; Tue, 17 Nov 2009 23:28:59 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Tue, 17 Nov 2009 18:28:59 -0500 From: "Rosen, Brian" To: Message-ID: Thread-Topic: WGLC on draft-ietf-p2psip-base-06 Thread-Index: Acpn3b0CU4iXXz3f+kW8iRFTFA+WPw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [P2PSIP] WGLC on draft-ietf-p2psip-base-06 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 23:29:06 -0000 This message announces a Working Group Last Call on draft-ietf-p2psip-base-06. Due to the size of the draft and the lack of extensive reviews, the WGLC will run until Dec 11th. Please get your comments in ASAP. Those of you who have committed to review the document in depth, this is your deadline, and we would appreciate your review before the last minute. Brian From davidbryan@gmail.com Wed Nov 18 01:23:23 2009 Return-Path: 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 9FC973A6862 for ; Wed, 18 Nov 2009 01:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 uWixk7UG5IjW for ; Wed, 18 Nov 2009 01:23:22 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 938A03A68B4 for ; Wed, 18 Nov 2009 01:23:22 -0800 (PST) Received: by yxe30 with SMTP id 30so1022678yxe.29 for ; Wed, 18 Nov 2009 01:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=n43VFX3S0OpEzMotcthiAWiSH4EiQNaaXo9a2EW/4Tw=; b=lX+Mz4lqIhWRTYLszH9e6tSKGnB4MFkxRrPysS+5NXY9v+CI6q4J4Jm0tV+l7wCcql /QSWCldSFqTqHhYWx5XtBPn/hwsRbW84JsbAiXaLmlYAk+3H2bhozacOM5qV/TE7yN77 jL4HllCbl3QA2nH0BVW9AGTG56cw6tOs3bYGM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=CLmonirWrXTX86UCwhfCSY5rwBqq0/2Pq96E3q4T1iNJjSvwfWXC4VlkBxuCf0ovsT iD/KGa3FW/oJvaRfC3jDTp5Md/yMXnn8K2qy6VRFGXEdz78GmkaU1xLyNnN/rf/SI4SI lOnjbZFNEgf3P+DGpG07iuHPt2dmltxGWLtdY= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.249.42 with SMTP id w42mr1865717ybh.80.1258536198295; Wed, 18 Nov 2009 01:23:18 -0800 (PST) In-Reply-To: References: Date: Wed, 18 Nov 2009 04:23:18 -0500 X-Google-Sender-Auth: 610161e34bc550ba Message-ID: <8b2769930911180123i5c9d3a16r7c885aeb6e0317c6@mail.gmail.com> From: "David A. Bryan" To: "Rosen, Brian" Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] WGLC on draft-ietf-p2psip-base-06 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 09:23:23 -0000 I know Brian's call here is in response to Cullen formally objecting to Robert about my taking time to confirm the sense of the room on list, but I think we need to apply process rules uniformly here, regardless of who it is that wants the WG to move on their schedule. I think the WG is being pushed to skip a step. I would like to formally ask that the WGLC be started after adequate time has been given to respond to my poll for the sense of the mailing list on wether the document is ready to go to WGLC. This WG just had a very active discussion (started by one of the editors of this draft, actually) about allowing adequate time for the list to review hums. A week was deemed the minimal acceptable time. Hiroshima was a very exceptional meeting. Very few of our regular attendees were there. As far as I know, only one of the authors of this draft was present. Both chairs and many of the other major contributors were not present. In light of these facts, while one could argue the hum was a "sense of the room" question, rather than a consensus call (and therefore needs no list confirmation), I felt it did. I was the chair tasked with the work of listening to the audio, assembling minutes, and confirming hums on list. I didn't feel enough participants were present for the chairs or AD to say the room really reflected the WG. I made a decision to send email asking for list confirmation if we should go to WGLC out of an abundance of caution. One can argue I didn't have to or shouldn't have asked the list for confirmation, but I felt it was the right thing to do, and issued the call for comments as chair. For consistency we should allow time for folks to comment. I understand this is a minor and procedural point. If folks care they can object once we go to WGLC, of course. However, considering how long this document has been on the table, and the long periods of time the editors have sometimes allowed to pass between revisions, waiting five more days to officially start WGLC does not adversely impact the work of the group and is the right thing to do to ensure consistent process is followed. (That said, please folks, start reviewing now!!! The editors need your comments!!!) To make it clear to the WG, I personally support taking this document to WGLC (and have indicated as such before) largely as an impetus to get reviewers and WG participants to comment on the document, which in my opinion still needs some work, but needs reviews to get that work done. However I do not feel all participants have been given adequate time to voice disagreement with taking this to WGLC, and feel we need to allow time for that. David On Tue, Nov 17, 2009 at 6:28 PM, Rosen, Brian wrote: > This message announces a Working Group Last Call on > draft-ietf-p2psip-base-06. Due to the size of the draft and the lack of > extensive reviews, the WGLC will run until Dec 11th. Please get your > comments in ASAP. Those of you who have committed to review the document in > depth, this is your deadline, and we would appreciate your review before the > last minute. > > Brian > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From ari.keranen@nomadiclab.com Wed Nov 18 03:17:03 2009 Return-Path: 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 BBEA53A68DE for ; Wed, 18 Nov 2009 03:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 RJrjXgQoQO7t for ; Wed, 18 Nov 2009 03:17:03 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id E225D3A68CB for ; Wed, 18 Nov 2009 03:17:02 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id B6EE71EF1EF; Wed, 18 Nov 2009 13:16:59 +0200 (EET) X-Virus-Scanned: amavisd-new at nomadiclab.com Received: from n2.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KlOpfOmMVq0; Wed, 18 Nov 2009 13:16:59 +0200 (EET) Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by n2.nomadiclab.com (Postfix) with ESMTP id 5A0231EF125; Wed, 18 Nov 2009 13:16:59 +0200 (EET) Message-ID: <4B03D7AB.6070608@nomadiclab.com> Date: Wed, 18 Nov 2009 13:16:59 +0200 From: Ari Keranen User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "David A. Bryan" References: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> <07DF6458-1CBF-46CF-B094-5C275A5DFB8B@cisco.com> In-Reply-To: <07DF6458-1CBF-46CF-B094-5C275A5DFB8B@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: P2PSIP WG Subject: Re: [P2PSIP] List followup of meeting consensus: Interest in generic service discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 11:17:03 -0000 Cullen Jennings wrote: > On Nov 15, 2009, at 1:25 PM, David A. Bryan wrote: >> Should there be a milestone to have a generic service discovery >> mechanism for the work in P2PSIP? > > I hummed yes in the meeting so I guess this is a double count but, yes. > +1 for a P2PSIP service discovery milestone too. Cheers, Ari From jani.hautakorpi@ericsson.com Wed Nov 18 05:32:50 2009 Return-Path: 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 1B6E73A6A6F for ; Wed, 18 Nov 2009 05:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 vq5wCIOmSvMr for ; Wed, 18 Nov 2009 05:32:47 -0800 (PST) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 75DE53A6956 for ; Wed, 18 Nov 2009 05:32:47 -0800 (PST) X-AuditID: c1b4fb24-b7b67ae000001a2a-58-4b03f77c0956 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id CB.0F.06698.C77F30B4; Wed, 18 Nov 2009 14:32:44 +0100 (CET) To: undisclosed-recipients:; Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 14:32:44 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 14:32:44 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1441C2578 for ; Wed, 18 Nov 2009 15:32:44 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D108421A21 for ; Wed, 18 Nov 2009 15:32:43 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9205621A20 for ; Wed, 18 Nov 2009 15:32:43 +0200 (EET) Message-ID: <4B03F77B.9080209@ericsson.com> Date: Wed, 18 Nov 2009 15:32:43 +0200 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 CC: P2PSIP WG References: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> In-Reply-To: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 18 Nov 2009 13:32:44.0325 (UTC) FILETIME=[9C0E7D50:01CA6853] X-Brightmail-Tracker: AAAAAA== Subject: Re: [P2PSIP] List followup of meeting consensus: Interest in generic service discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 13:32:50 -0000 David A. Bryan wrote: > In the meeting at IETF-76 in Hiroshima, the group was asked to hum on: > > Should there be a milestone to have a generic service discovery > mechanism for the work in P2PSIP? > > There was some interest, but it was labeled as lukewarm, and not > consensus by the guest chairs. However, there was agreement to take > this discussion to the list. > > We would like to discuss this hum on the mailing list. Please comment > on this hum. Yes, I believe generic service discovery should be a milestone. It would be handy when searching e.g. gateways to other networks or voicemail servers. -- Jani From michaelc@IDSSOFTWARE.COM Wed Nov 18 15:56:50 2009 Return-Path: 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 7763C3A69B8 for ; Wed, 18 Nov 2009 15:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 G3W+j9JIznag for ; Wed, 18 Nov 2009 15:56:49 -0800 (PST) Received: from smtpoutwbe03.prod.mesa1.secureserver.net (smtpoutwbe03.prod.mesa1.secureserver.net [208.109.78.114]) by core3.amsl.com (Postfix) with SMTP id BA50628B797 for ; Wed, 18 Nov 2009 15:56:49 -0800 (PST) Received: (qmail 27197 invoked from network); 18 Nov 2009 23:56:47 -0000 Received: from unknown (HELO gem-wbe35.prod.mesa1.secureserver.net) (64.202.189.31) by smtpoutwbe03.prod.mesa1.secureserver.net with SMTP; 18 Nov 2009 23:56:46 -0000 Received: (qmail 14928 invoked by uid 99); 18 Nov 2009 23:56:46 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 12.175.188.225 User-Agent: Web-Based Email 5.1.27 Message-Id: <20091118165646.61e8c06078a3b23a733c71e914c0b9df.9a437fa459.wbe@email.secureserver.net> From: To: "Rosen,Brian" Date: Wed, 18 Nov 2009 16:56:46 -0700 Mime-Version: 1.0 Cc: p2psip@ietf.org Subject: [P2PSIP] Single hop optimization X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2009 23:56:50 -0000
Brian,

I would like the group to reconsider my optimiz= ation proposal discussed in this thread:

  http://www.ietf.o= rg/mail-archive/web/p2psip/current/msg05112.html

In short, the d= raft should allow single hop (direct) communications void of certificates a= nd signatures, because the underlying D/TLS transport layer already guarant= ees the authenticity of the sender and the integrity of the content.
Jouni M=C3=A4enp=C3=A4=C3=A4 who runs apps in PlanetLab (OpenDHT?) has exp= ressed his approval, while Eric dismissed it on the ground of complexity. I= still believe it is well worth it.

Please consider adding the follo= wing text at the end of draft-06 section 5.3.4 Security Block:

=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
If and only if al= l of the following conditions are met, the Security Block MAY contain an em= pty certificate bucket and a null signature.

  1) ForwardingHea= der.ttl is 1.
  2) ForwardingHeader.via_list_length is 0.

An= empty certificate bucket is two octets of zeros, and a null signature is a= lso two octets of zeros. Therefore, the Security Block under the above cond= itions MAY consist of 4 octets of zeros. Further, if the empty security blo= ck is used, the null signature MUST also be used in other parts of the mess= age such as the signature in StoredData of a STORE message (see section 6).=

The above conditions limit the use of empty security block to only = those messages sent between two peers with direct connection to each other.= It relies on the trust already established between the two peers in the D/= TLS transport layer. It serves as an optimization for reducing PDU size, av= oiding fragmentation and improving DHT rebustness.
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Thanks
<= div>
--Michael
 From melodysong@huawei.com Wed Nov 18 18:51:27 2009 Return-Path: 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 89C103A697A for ; Wed, 18 Nov 2009 18:51:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.733 X-Spam-Level: * X-Spam-Status: No, score=1.733 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 41dK70OVtpXx for ; Wed, 18 Nov 2009 18:51:26 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B95FB3A676A for ; Wed, 18 Nov 2009 18:51:26 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTC00FG159ESD@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 19 Nov 2009 10:51:14 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTC00ENS59EK5@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 19 Nov 2009 10:51:14 +0800 (CST) Received: from s64081 ([10.164.12.12]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTC001DY59D6K@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 19 Nov 2009 10:51:14 +0800 (CST) Date: Thu, 19 Nov 2009 10:51:14 +0800 From: Song Haibin In-reply-to: <4B03D7AB.6070608@nomadiclab.com> To: 'Ari Keranen' , "'David A. Bryan'" Message-id: <008001ca68c3$29119510$0c0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcpoQLItue6L26lZQSS0SScNAX1jTgAgnJZQ Cc: 'P2PSIP WG' Subject: Re: [P2PSIP] List followup of meeting consensus: Interest in generic service discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 02:51:27 -0000 +1 Xie Xie, Haibin >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >On Behalf Of Ari Keranen >Sent: Wednesday, November 18, 2009 7:17 PM >To: David A. Bryan >Cc: P2PSIP WG >Subject: Re: [P2PSIP] List followup of meeting consensus: >Interest in generic service discovery > >Cullen Jennings wrote: >> On Nov 15, 2009, at 1:25 PM, David A. Bryan wrote: >>> Should there be a milestone to have a generic service discovery >>> mechanism for the work in P2PSIP? >> >> I hummed yes in the meeting so I guess this is a double >count but, yes. >> > >+1 for a P2PSIP service discovery milestone too. > > >Cheers, >Ari >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > From Even.roni@huawei.com Thu Nov 19 02:57:46 2009 Return-Path: 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 A61143A68B0 for ; Thu, 19 Nov 2009 02:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_SORBS_WEB=0.619] 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 HtL5PXUpZg9h for ; Thu, 19 Nov 2009 02:57:45 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C31683A6833 for ; Thu, 19 Nov 2009 02:57:45 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTC001JMRS6O8@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 19 Nov 2009 18:57:42 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTC00IZVRS69H@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 19 Nov 2009 18:57:42 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-78-53.red.bezeqint.net [79.179.78.53]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTC00FHERRXD5@szxml01-in.huawei.com>; Thu, 19 Nov 2009 18:57:42 +0800 (CST) Date: Thu, 19 Nov 2009 12:56:14 +0200 From: Roni Even In-reply-to: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> To: "'David A. Bryan'" , 'P2PSIP WG' , 'Brian Rosen' Message-id: <02cc01ca6906$f1559b00$d400d100$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcpmMosBlkEHqHN1QJablk/4Cp87TwC0Zfug References: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> Subject: Re: [P2PSIP] List followup of meeting consensus: Interest in generic service discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 10:57:46 -0000 I agree that there is a need for this work and Cullen also mentioned it in his presentation on the base reload draft in order to address the turn server discovery. Roni Even > -----Original Message----- > From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] On > Behalf Of David A. Bryan > Sent: Sunday, November 15, 2009 10:25 PM > To: P2PSIP WG; Brian Rosen > Subject: [P2PSIP] List followup of meeting consensus: Interest in > generic service discovery > > In the meeting at IETF-76 in Hiroshima, the group was asked to hum on: > > Should there be a milestone to have a generic service discovery > mechanism for the work in P2PSIP? > > There was some interest, but it was labeled as lukewarm, and not > consensus by the guest chairs. However, there was agreement to take > this discussion to the list. > > We would like to discuss this hum on the mailing list. Please comment > on this hum. > > David (as chair) > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From joakim.koskela@hiit.fi Thu Nov 19 14:14:51 2009 Return-Path: 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 1D2813A68F3 for ; Thu, 19 Nov 2009 14:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 pMrsqO8G43sA for ; Thu, 19 Nov 2009 14:14:50 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id 4B0E23A6884 for ; Thu, 19 Nov 2009 14:14:50 -0800 (PST) Received: from [10.0.0.10] (a91-153-241-249.elisa-laajakaista.fi [91.153.241.249]) by argo.otaverkko.fi (Postfix) with ESMTP id 45CF625ED13; Fri, 20 Nov 2009 00:14:47 +0200 (EET) From: Joakim Koskela Organization: Helsinki Institute for Information Technology To: p2psip@ietf.org Date: Fri, 20 Nov 2009 00:13:38 +0200 User-Agent: KMail/1.9.9 References: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> In-Reply-To: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911200013.39008.joakim.koskela@hiit.fi> Subject: Re: [P2PSIP] List followup of meeting consensus: Interest in generic service discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 22:14:51 -0000 On Sunday 15 November 2009 22:25:09 David A. Bryan wrote: > Should there be a milestone to have a generic service discovery > mechanism for the work in P2PSIP? .. > We would like to discuss this hum on the mailing list. Please comment > on this hum. +1, There would be a lot of uses for this. br, j From joakim.koskela@hiit.fi Thu Nov 19 14:15:25 2009 Return-Path: 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 A9AD228C101 for ; Thu, 19 Nov 2009 14:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] 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 rxmU6bKKsQFA for ; Thu, 19 Nov 2009 14:15:24 -0800 (PST) Received: from argo.otaverkko.fi (argo.otaverkko.fi [212.68.0.2]) by core3.amsl.com (Postfix) with ESMTP id ABBC33A6884 for ; Thu, 19 Nov 2009 14:15:24 -0800 (PST) Received: from [10.0.0.10] (a91-153-241-249.elisa-laajakaista.fi [91.153.241.249]) by argo.otaverkko.fi (Postfix) with ESMTP id 36B4025ED13; Fri, 20 Nov 2009 00:15:22 +0200 (EET) From: Joakim Koskela Organization: Helsinki Institute for Information Technology To: p2psip@ietf.org Date: Fri, 20 Nov 2009 00:14:18 +0200 User-Agent: KMail/1.9.9 References: <8b2769930911151220r372f019es3ea5384eaa999c25@mail.gmail.com> In-Reply-To: <8b2769930911151220r372f019es3ea5384eaa999c25@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911200014.18203.joakim.koskela@hiit.fi> Subject: Re: [P2PSIP] List followup of meeting consensus: Hums on 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2009 22:15:25 -0000 On Sunday 15 November 2009 22:20:44 David A. Bryan wrote: > A second hum was asked, noting that there were few who had read it and > it was preliminary, but to see if there was a feeling that draft > draft-maenpaa-p2psip-self-tuning-01 was a good input toward a charter > deliverable to work in this area, please hum. +1 for this as well. Afaik something like this will be necessary at some point if this is going to be deployed, and Maenpaas draft seems to be as good a starting point as any. br, j From michaelc@IDSSOFTWARE.COM Sat Nov 21 09:42:27 2009 Return-Path: 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 BE6C63A6960 for ; Sat, 21 Nov 2009 09:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.159 X-Spam-Level: X-Spam-Status: No, score=0.159 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 sC58BVJ16Pu7 for ; Sat, 21 Nov 2009 09:42:27 -0800 (PST) Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by core3.amsl.com (Postfix) with SMTP id DB52E3A6A03 for ; Sat, 21 Nov 2009 09:42:26 -0800 (PST) Received: (qmail 15502 invoked from network); 21 Nov 2009 17:42:22 -0000 Received: from unknown (HELO gem-wbe15.prod.mesa1.secureserver.net) (64.202.189.223) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 21 Nov 2009 17:42:22 -0000 Received: (qmail 24601 invoked by uid 99); 21 Nov 2009 17:42:22 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.1.29 Message-Id: <20091121104222.61e8c06078a3b23a733c71e914c0b9df.3b884edfea.wbe@email.secureserver.net> From: "Michael Chen" To: p2psip@ietf.org Date: Sat, 21 Nov 2009 10:42:22 -0700 Mime-Version: 1.0 Subject: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Nov 2009 17:42:27 -0000
Hi,

Draft-06 Section 9.4 is dated and needs work.
<= br>   2.  JP SHOULD use a series of Pings to populate its ro= uting table.
   3.  JP SHOULD send Attach requests...
=    4.  JP MUST enter all the peers it has contacted into its= routing
       table.

Section 11 p= rovided a better method in which Attach requests are used
(instead of Pi= ng) to discover and populate the routing table.  There is
no need t= o use Ping.  Suggest using the following text:

   1.&= nbsp; JP MUST connect to its chosen bootstrap node.
   2. = ; JP SHOULD send a series of Attach requests to discover and connect
&nb= sp;      to peers that make up its neighbor table = as well as the desired 16
       finger ta= ble entries.  Note that this does not populate their
  &n= bsp;    routing tables, but only their connection tables, so= JP will not
       get messages that it i= s expected to route to other nodes.
   3.  JP MUST enter = all the peers it has contacted into its routing
    =    table and connection table.
   4.  JP SHOULD= send a Join to its immediate successor, the admitting
   = ;    peer (AP) for Node-ID n.  The AP sends the respons= e to the Join.
   5.  AP MUST do a series of Store reques= ts to JP to store the data
       that JP = will be responsible for.
   6.  AP MUST send JP an Update= explicitly labeling JP as its
       pred= ecessor.  At this point, JP is part of the ring and
  &nb= sp;    responsible for a section of the overlay.  AP ca= n now forget any
       data which is assi= gned to JP and not AP.
   7.  AP MUST send an Update to a= ll of its neighbors with the new
       va= lues of its neighbor set (including JP).
   8.  JP SHOULD= send Updates to all the peers in its routing table.

   In= order to populate its neighbor table, JP n sends an Attach via the
&nbs= p;  bootstrap node directed at Node-ID n+1 (directly after its own Nod= e-ID).
   This allows it to discover its own successor.  = Call that node s0.  It
   then sends an Attach (via the b= ootstap peer or s0) to s0+1 to discover
   its second successo= r (s1).  This process can be repeated to discover as
   m= any successors as desired.  The predecessors of JP will be found at a<= br>   later stage when JP receives an Update.

  = In order to set up its finger table entry i, JP simply sends an Attach
=    to peer (n+2^(numBitsInNodeId-i).  This will be routed to= a peer in
   approximately the right location around the ring= .

   The joining peer MUST NOT send any Update message pla= cing itself in
   the overlay until it has successfully comple= ted an Attach with each
   peer that should be in its neighbor= table.


Thanks

--Michael


 From michaelc@IDSSOFTWARE.COM Sat Nov 21 20:16:33 2009 Return-Path: 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 3DE123A67A7 for ; Sat, 21 Nov 2009 20:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.491 X-Spam-Level: X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 dQZVGy61NOdi for ; Sat, 21 Nov 2009 20:16:32 -0800 (PST) Received: from smtpoutwbe01.prod.mesa1.secureserver.net (smtpoutwbe01.prod.mesa1.secureserver.net [208.109.78.112]) by core3.amsl.com (Postfix) with SMTP id 243B93A687D for ; Sat, 21 Nov 2009 20:16:32 -0800 (PST) Received: (qmail 7693 invoked from network); 22 Nov 2009 04:16:28 -0000 Received: from unknown (HELO gem-wbe42.prod.mesa1.secureserver.net) (64.202.189.83) by smtpoutwbe01.prod.mesa1.secureserver.net with SMTP; 22 Nov 2009 04:16:28 -0000 Received: (qmail 15234 invoked by uid 99); 22 Nov 2009 04:16:28 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 75.28.22.59 User-Agent: Web-Based Email 5.1.29 Message-Id: <20091121211628.61e8c06078a3b23a733c71e914c0b9df.122f9e4d29.wbe@email.secureserver.net> From: "Michael Chen" To: "jc" Date: Sat, 21 Nov 2009 21:16:28 -0700 Mime-Version: 1.0 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 04:16:33 -0000
Julian,

Section 9.4 1. already estab= lished that JP has a connection to the bootstrap node. Function-wise, I thi= nk the example in Section 11 is sufficient to join the overlay.
<= br>
As for 9.6.1, when a peer lost all its successors, the overla= y may have been partitioned (the ring is broken). Whether it uses Ping or A= ttach to re-join makes no difference.

Actually, I = made a couple of mistakes in my text. In the paragraph after step 8, "Node-= ID" should be "Resource-ID".  The original text of draft-06 is correct= per section 5.1.1 last paragraph.

--Michael

-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org>
Date: Sat, November 21, 2009 11:16 am
To: Michael Chen <michaelc@idssoftware.com>

Attach messages are routed through the overlay where pings are not.

A ping actually tests the path while Attach does not= .

Also the wording changes break further 9.* secti= ons. For instance 9.6.1 states "this peer should behave as if it is joining= the network and use pings to find a peer and send it a Join".
It's clearly not defined correctly as is however. A ping is er= ror prone unless you've already Attached due to possible NAT. While an Atta= ch will reach any node that is inside the ring a ping will not.
<= br>
Julian

Sent from my iPhone

On Nov= 21, 2009, at 12:42 PM, "Michael Chen" <= michaelc@idssoftware.com> wrote:

Hi,

Draft-06 Section 9.4 is dated = and needs work.

   2.  JP SHOULD use a series of Ping= s to populate its routing table.
   3.  JP SHOULD send At= tach requests...
   4.  JP MUST enter all the peers it ha= s contacted into its routing
       table.=

Section 11 provided a better method in which Attach requests are us= ed
(instead of Ping) to discover and populate the routing table.  T= here is
no need to use Ping.  Suggest using the following text:
=
   1.  JP MUST connect to its chosen bootstrap node.
=    2.  JP SHOULD send a series of Attach requests to discove= r and connect
       to peers that make up= its neighbor table as well as the desired 16
    &n= bsp;  finger table entries.  Note that this does not populate the= ir
       routing tables, but only their c= onnection tables, so JP will not
       ge= t messages that it is expected to route to other nodes.
   3.&= nbsp; JP MUST enter all the peers it has contacted into its routing
&nbs= p;      table and connection table.
  = ; 4.  JP SHOULD send a Join to its immediate successor, the admitting<= br>       peer (AP) for Node-ID n.  The = AP sends the response to the Join.
   5.  AP MUST do a se= ries of Store requests to JP to store the data
    &= nbsp;  that JP will be responsible for.
   6.  AP MU= ST send JP an Update explicitly labeling JP as its
   &nb= sp;   predecessor.  At this point, JP is part of the ring an= d
       responsible for a section of the = overlay.  AP can now forget any
      = ; data which is assigned to JP and not AP.
   7.  AP MUST= send an Update to all of its neighbors with the new
   &= nbsp;   values of its neighbor set (including JP).
  = ; 8.  JP SHOULD send Updates to all the peers in its routing table.
   In order to populate its neighbor table, JP n sends an At= tach via the
   bootstrap node directed at Node-ID n+1 (direct= ly after its own Node-ID).
   This allows it to discover its o= wn successor.  Call that node s0.  It
   then sends = an Attach (via the bootstap peer or s0) to s0+1 to discover
  = its second successor (s1).  This process can be repeated to discover = as
   many successors as desired.  The predecessors of JP= will be found at a
   later stage when JP receives an Update.=

   In order to set up its finger table entry i, JP simply= sends an Attach
   to peer (n+2^(numBitsInNodeId-i).  Th= is will be routed to a peer in
   approximately the right loca= tion around the ring.

   The joining peer MUST NOT send an= y Update message placing itself in
   the overlay until it has= successfully completed an Attach with each
   peer that shoul= d be in its neighbor table.


Thanks

--Michael
_________________________________________= ______
P2PSIP mailing list
P2= PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
 From julian@orchidseed.org Sat Nov 21 22:47:54 2009 Return-Path: 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 754563A6817 for ; Sat, 21 Nov 2009 22:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 DFbb5YFVsW7g for ; Sat, 21 Nov 2009 22:47:53 -0800 (PST) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id 6C8863A659B for ; Sat, 21 Nov 2009 22:47:53 -0800 (PST) Received: from adsl-232-19-226.asm.bellsouth.net ([74.232.19.226]:45024 helo=[172.16.1.230]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NC6Ee-0001qz-GX; Sat, 21 Nov 2009 22:47:50 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: jc In-Reply-To: <20091121211628.61e8c06078a3b23a733c71e914c0b9df.122f9e4d29.wbe@email.secureserver.net> Date: Sun, 22 Nov 2009 01:47:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4DDC7590-2C96-4F24-BFA8-10EF6C31594E@orchidseed.org> References: <20091121211628.61e8c06078a3b23a733c71e914c0b9df.122f9e4d29.wbe@email.secureserver.net> To: "Michael Chen" X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 06:47:54 -0000 On Nov 21, 2009, at 11:16 PM, Michael Chen wrote: > Julian, >=20 > Section 9.4 1. already established that JP has a connection to the = bootstrap node. Function-wise, I think the example in Section 11 is = sufficient to join the overlay. Right. >=20 > As for 9.6.1, when a peer lost all its successors, the overlay may = have been partitioned (the ring is broken). Whether it uses Ping or = Attach to re-join makes no difference. The logical ring wouldn't be broken if it were partitioned. You would = have N overlays that aren't communicating with one another. So the logic = from 9.6.4.4. would be used in that case which states sending a Ping not = an Attach. >=20 > Actually, I made a couple of mistakes in my text. In the paragraph = after step 8, "Node-ID" should be "Resource-ID". The original text of = draft-06 is correct per section 5.1.1 last paragraph. The problem I see is: 1. JP MUST connect to its chosen bootstrap node. 2. JP SHOULD send a series of Attach requests to discover and = connect.... In order to perform 2 you need to know "some" Node-ID's in your neighbor = table. So you MUST send a Join on connection to the bootstrap node and = then you can start forming your Attach requests.=20 It should read something like: 1. JP MUST connect to its chosen bootstrap node (AP). 2. JP Sends a Join request to JP announcing its intention to join. 3. AP sends a Join response. 4. AP does a sequence of Stores to JP to give it the data it will = need. 5. AP does Updates to JP to tell it about its own routing table. 6. JP SHOULD send a series of Attach requests to form connections to = peers that make up its neighbor table as well as the desired 16 finger = table entries. Julian >=20 > --Michael >=20 > -------- Original Message -------- > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work > From: jc > Date: Sat, November 21, 2009 11:16 am > To: Michael Chen >=20 > Attach messages are routed through the overlay where pings are not. >=20 > A ping actually tests the path while Attach does not. >=20 > Also the wording changes break further 9.* sections. For instance = 9.6.1 states "this peer should behave as if it is joining the network = and use pings to find a peer and send it a Join". >=20 > It's clearly not defined correctly as is however. A ping is error = prone unless you've already Attached due to possible NAT. While an = Attach will reach any node that is inside the ring a ping will not. >=20 > Julian >=20 > Sent from my iPhone >=20 > On Nov 21, 2009, at 12:42 PM, "Michael Chen" = wrote: >=20 >> Hi, >>=20 >> Draft-06 Section 9.4 is dated and needs work. >>=20 >> 2. JP SHOULD use a series of Pings to populate its routing table. >> 3. JP SHOULD send Attach requests... >> 4. JP MUST enter all the peers it has contacted into its routing >> table. >>=20 >> Section 11 provided a better method in which Attach requests are used >> (instead of Ping) to discover and populate the routing table. There = is >> no need to use Ping. Suggest using the following text: >>=20 >> 1. JP MUST connect to its chosen bootstrap node. >> 2. JP SHOULD send a series of Attach requests to discover and = connect >> to peers that make up its neighbor table as well as the = desired 16 >> finger table entries. Note that this does not populate their >> routing tables, but only their connection tables, so JP will = not >> get messages that it is expected to route to other nodes. >> 3. JP MUST enter all the peers it has contacted into its routing >> table and connection table. >> 4. JP SHOULD send a Join to its immediate successor, the = admitting >> peer (AP) for Node-ID n. The AP sends the response to the = Join. >> 5. AP MUST do a series of Store requests to JP to store the data >> that JP will be responsible for. >> 6. AP MUST send JP an Update explicitly labeling JP as its >> predecessor. At this point, JP is part of the ring and >> responsible for a section of the overlay. AP can now forget = any >> data which is assigned to JP and not AP. >> 7. AP MUST send an Update to all of its neighbors with the new >> values of its neighbor set (including JP). >> 8. JP SHOULD send Updates to all the peers in its routing table. >>=20 >> In order to populate its neighbor table, JP n sends an Attach via = the >> bootstrap node directed at Node-ID n+1 (directly after its own = Node-ID). >> This allows it to discover its own successor. Call that node s0. = It >> then sends an Attach (via the bootstap peer or s0) to s0+1 to = discover >> its second successor (s1). This process can be repeated to = discover as >> many successors as desired. The predecessors of JP will be found = at a >> later stage when JP receives an Update. >>=20 >> In order to set up its finger table entry i, JP simply sends an = Attach >> to peer (n+2^(numBitsInNodeId-i). This will be routed to a peer = in >> approximately the right location around the ring. >>=20 >> The joining peer MUST NOT send any Update message placing itself = in >> the overlay until it has successfully completed an Attach with = each >> peer that should be in its neighbor table. >>=20 >>=20 >> Thanks >>=20 >> --Michael >>=20 >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip From michaelc@IDSSOFTWARE.COM Sun Nov 22 11:35:01 2009 Return-Path: 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 E80C23A692B for ; Sun, 22 Nov 2009 11:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 ZQ7BCI5eonhm for ; Sun, 22 Nov 2009 11:35:01 -0800 (PST) Received: from smtpoutwbe04.prod.mesa1.secureserver.net (smtpoutwbe04.prod.mesa1.secureserver.net [208.109.78.206]) by core3.amsl.com (Postfix) with SMTP id E3C2C3A6837 for ; Sun, 22 Nov 2009 11:35:00 -0800 (PST) Received: (qmail 20676 invoked from network); 22 Nov 2009 19:34:56 -0000 Received: from unknown (HELO gem-wbe09.prod.mesa1.secureserver.net) (64.202.189.48) by smtpoutwbe04.prod.mesa1.secureserver.net with SMTP; 22 Nov 2009 19:34:55 -0000 Received: (qmail 15314 invoked by uid 99); 22 Nov 2009 19:34:55 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 75.28.22.59 User-Agent: Web-Based Email 5.1.29 Message-Id: <20091122123455.61e8c06078a3b23a733c71e914c0b9df.f482ffa0c4.wbe@email.secureserver.net> From: "Michael Chen" To: "jc" Date: Sun, 22 Nov 2009 12:34:55 -0700 Mime-Version: 1.0 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 19:35:02 -0000
Julian,

Please revisit section 5.1.1= , particularly the last paragraph. The nuance is that for any request (incl= uding Attach), the last Destination entry in the destination-list can be ei= ther a Resource-ID or a Node-ID. Normally, an Attach to a known peer uses a= Node-ID Destination.

However, the example in Sec= tion 11 demonstrates sending an Attach that uses a Resource-ID to discover = an **unknown** peer (JP's successor s0, s1 and finger nodes). This is a cle= ver use of Attach. Since it is sent to the bootstrap node (or other known p= eer, e.g. use s0 to find s1), there is no need to use Ping. Like I said, Se= ction 11 is sound as it is.

Thanks
<= br>
--Michael
-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org>
Date: Sat, November 21, 2009 10:47 pm
To: "Michael Chen" <michaelc@idssoftware.com>
Cc: p2psip@ietf.org


On Nov 21, 2009, at 11:16 PM, Michael Chen wrote:

> Julian,
>
> Section 9.4 1. already established that JP has a connection to the boo= tstrap node. Function-wise, I think the example in Section 11 is sufficient= to join the overlay.

Right.

>
> As for 9.6.1, when a peer lost all its successors, the overlay may hav= e been partitioned (the ring is broken). Whether it uses Ping or Attach to = re-join makes no difference.

The logical ring wouldn't be broken if it were partitioned. You would have = N overlays that aren't communicating with one another. So the logic from 9.= 6.4.4. would be used in that case which states sending a Ping not an Attach= .

>
> Actually, I made a couple of mistakes in my text. In the paragraph aft= er step 8, "Node-ID" should be "Resource-ID". The original text of draft-0= 6 is correct per section 5.1.1 last paragraph.

The problem I see is:

1. JP MUST connect to its chosen bootstrap node.
2. JP SHOULD send a series of Attach requests to discover and connect....=

In order to perform 2 you need to know "some" Node-ID's in your neighbor ta= ble. So you MUST send a Join on connection to the bootstrap node and then y= ou can start forming your Attach requests.

It should read something like:

1. JP MUST connect to its chosen bootstrap node (AP).
2. JP Sends a Join request to JP announcing its intention to join.
3. AP sends a Join response.
4. AP does a sequence of Stores to JP to give it the data it will need. 5. AP does Updates to JP to tell it about its own routing table.
6. JP SHOULD send a series of Attach requests to form connections to peer= s that make up its neighbor table as well as the desired 16 finger table en= tries.

Julian

>
> --Michael
>
> -------- Original Message --------
> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
> From: jc <julian@orchidseed.org>
> Date: Sat, November 21, 2009 11:16 am
> To: Michael Chen <michaelc@idssoftware.com>
>
> Attach messages are routed through the overlay where pings are not. >
> A ping actually tests the path while Attach does not.
>
> Also the wording changes break further 9.* sections. For instance 9.6.= 1 states "this peer should behave as if it is joining the network and use p= ings to find a peer and send it a Join".
>
> It's clearly not defined correctly as is however. A ping is error pron= e unless you've already Attached due to possible NAT. While an Attach will = reach any node that is inside the ring a ping will not.
>
> Julian
>
> Sent from my iPhone
>
> On Nov 21, 2009, at 12:42 PM, "Michael Chen" <michaelc@idssoftware.= com> wrote:
>
>> Hi,
>>
>> Draft-06 Section 9.4 is dated and needs work.
>>
>> 2. JP SHOULD use a series of Pings to populate its routing tab= le.
>> 3. JP SHOULD send Attach requests...
>> 4. JP MUST enter all the peers it has contacted into its routi= ng
>> table.
>>
>> Section 11 provided a better method in which Attach requests are u= sed
>> (instead of Ping) to discover and populate the routing table. The= re is
>> no need to use Ping. Suggest using the following text:
>>
>> 1. JP MUST connect to its chosen bootstrap node.
>> 2. JP SHOULD send a series of Attach requests to discover and = connect
>> to peers that make up its neighbor table as well as the des= ired 16
>> finger table entries. Note that this does not populate the= ir
>> routing tables, but only their connection tables, so JP wil= l not
>> get messages that it is expected to route to other nodes. >> 3. JP MUST enter all the peers it has contacted into its routi= ng
>> table and connection table.
>> 4. JP SHOULD send a Join to its immediate successor, the admit= ting
>> peer (AP) for Node-ID n. The AP sends the response to the = Join.
>> 5. AP MUST do a series of Store requests to JP to store the da= ta
>> that JP will be responsible for.
>> 6. AP MUST send JP an Update explicitly labeling JP as its
>> predecessor. At this point, JP is part of the ring and
>> responsible for a section of the overlay. AP can now forge= t any
>> data which is assigned to JP and not AP.
>> 7. AP MUST send an Update to all of its neighbors with the new=
>> values of its neighbor set (including JP).
>> 8. JP SHOULD send Updates to all the peers in its routing tabl= e.
>>
>> In order to populate its neighbor table, JP n sends an Attach v= ia the
>> bootstrap node directed at Node-ID n+1 (directly after its own = Node-ID).
>> This allows it to discover its own successor. Call that node s= 0. It
>> then sends an Attach (via the bootstap peer or s0) to s0+1 to d= iscover
>> its second successor (s1). This process can be repeated to dis= cover as
>> many successors as desired. The predecessors of JP will be fou= nd at a
>> later stage when JP receives an Update.
>>
>> In order to set up its finger table entry i, JP simply sends an= Attach
>> to peer (n+2^(numBitsInNodeId-i). This will be routed to a pee= r in
>> approximately the right location around the ring.
>>
>> The joining peer MUST NOT send any Update message placing itsel= f in
>> the overlay until it has successfully completed an Attach with = each
>> peer that should be in its neighbor table.
>>
>>
>> Thanks
>>
>> --Michael
>>
>>
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://= www.ietf.org/mailman/listinfo/p2psip

 From julian@orchidseed.org Sun Nov 22 12:06:47 2009 Return-Path: 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 D7ADB3A687F for ; Sun, 22 Nov 2009 12:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 jxE97bh7bkFG for ; Sun, 22 Nov 2009 12:06:46 -0800 (PST) Received: from n26.c05.mtsvc.net (n26.c05.mtsvc.net [70.32.68.26]) by core3.amsl.com (Postfix) with ESMTP id 0CD7E3A6821 for ; Sun, 22 Nov 2009 12:06:46 -0800 (PST) Received: from adsl-232-19-226.asm.bellsouth.net ([74.232.19.226]:35324 helo=[172.16.1.230]) by n26.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NCIhk-0003Gh-6v; Sun, 22 Nov 2009 12:06:42 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-3--707159390 From: jc In-Reply-To: <20091122123455.61e8c06078a3b23a733c71e914c0b9df.f482ffa0c4.wbe@email.secureserver.net> Date: Sun, 22 Nov 2009 15:06:38 -0500 Message-Id: <38489D90-8CDD-4E95-8145-68F4314A86E6@orchidseed.org> References: <20091122123455.61e8c06078a3b23a733c71e914c0b9df.f482ffa0c4.wbe@email.secureserver.net> To: "Michael Chen" X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 20:06:48 -0000 --Apple-Mail-3--707159390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Michael, I understand the discovery of Node-ID's by Resource-ID's. You are = stating that you connect to a bootstrap node and start sending Attach = requests however there is a problem. Where do you obtain the Node-ID's = or Resource-ID's to send the Attach requests to? This is a technical impossibility. You MUST have at least another = Node-ID or Resource-ID other than that of the bootstrap node. You MUST = learn at least a single Node-ID or Resource-ID from the bootstrap node. Julian On Nov 22, 2009, at 2:34 PM, Michael Chen wrote: > Julian, >=20 > Please revisit section 5.1.1, particularly the last paragraph. The = nuance is that for any request (including Attach), the last Destination = entry in the destination-list can be either a Resource-ID or a Node-ID. = Normally, an Attach to a known peer uses a Node-ID Destination. >=20 > However, the example in Section 11 demonstrates sending an Attach that = uses a Resource-ID to discover an **unknown** peer (JP's successor s0, = s1 and finger nodes). This is a clever use of Attach. Since it is sent = to the bootstrap node (or other known peer, e.g. use s0 to find s1), = there is no need to use Ping. Like I said, Section 11 is sound as it is. >=20 > Thanks >=20 > --Michael > -------- Original Message -------- > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work > From: jc > Date: Sat, November 21, 2009 10:47 pm > To: "Michael Chen" > Cc: p2psip@ietf.org >=20 >=20 > On Nov 21, 2009, at 11:16 PM, Michael Chen wrote: >=20 > > Julian, > >=20 > > Section 9.4 1. already established that JP has a connection to the = bootstrap node. Function-wise, I think the example in Section 11 is = sufficient to join the overlay. >=20 > Right. >=20 > >=20 > > As for 9.6.1, when a peer lost all its successors, the overlay may = have been partitioned (the ring is broken). Whether it uses Ping or = Attach to re-join makes no difference. >=20 > The logical ring wouldn't be broken if it were partitioned. You would = have N overlays that aren't communicating with one another. So the logic = from 9.6.4.4. would be used in that case which states sending a Ping not = an Attach. >=20 > >=20 > > Actually, I made a couple of mistakes in my text. In the paragraph = after step 8, "Node-ID" should be "Resource-ID". The original text of = draft-06 is correct per section 5.1.1 last paragraph. >=20 > The problem I see is: >=20 > 1. JP MUST connect to its chosen bootstrap node. > 2. JP SHOULD send a series of Attach requests to discover and = connect.... >=20 > In order to perform 2 you need to know "some" Node-ID's in your = neighbor table. So you MUST send a Join on connection to the bootstrap = node and then you can start forming your Attach requests.=20 >=20 > It should read something like: >=20 > 1. JP MUST connect to its chosen bootstrap node (AP). > 2. JP Sends a Join request to JP announcing its intention to join. > 3. AP sends a Join response. > 4. AP does a sequence of Stores to JP to give it the data it will = need. > 5. AP does Updates to JP to tell it about its own routing table. > 6. JP SHOULD send a series of Attach requests to form connections to = peers that make up its neighbor table as well as the desired 16 finger = table entries. >=20 > Julian >=20 > >=20 > > --Michael > >=20 > > -------- Original Message -------- > > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work > > From: jc > > Date: Sat, November 21, 2009 11:16 am > > To: Michael Chen > >=20 > > Attach messages are routed through the overlay where pings are not. > >=20 > > A ping actually tests the path while Attach does not. > >=20 > > Also the wording changes break further 9.* sections. For instance = 9.6.1 states "this peer should behave as if it is joining the network = and use pings to find a peer and send it a Join". > >=20 > > It's clearly not defined correctly as is however. A ping is error = prone unless you've already Attached due to possible NAT. While an = Attach will reach any node that is inside the ring a ping will not. > >=20 > > Julian > >=20 > > Sent from my iPhone > >=20 > > On Nov 21, 2009, at 12:42 PM, "Michael Chen" = wrote: > >=20 > >> Hi, > >>=20 > >> Draft-06 Section 9.4 is dated and needs work. > >>=20 > >> 2. JP SHOULD use a series of Pings to populate its routing table. > >> 3. JP SHOULD send Attach requests... > >> 4. JP MUST enter all the peers it has contacted into its routing > >> table. > >>=20 > >> Section 11 provided a better method in which Attach requests are = used > >> (instead of Ping) to discover and populate the routing table. There = is > >> no need to use Ping. Suggest using the following text: > >>=20 > >> 1. JP MUST connect to its chosen bootstrap node. > >> 2. JP SHOULD send a series of Attach requests to discover and = connect > >> to peers that make up its neighbor table as well as the desired 16 > >> finger table entries. Note that this does not populate their > >> routing tables, but only their connection tables, so JP will not > >> get messages that it is expected to route to other nodes. > >> 3. JP MUST enter all the peers it has contacted into its routing > >> table and connection table. > >> 4. JP SHOULD send a Join to its immediate successor, the admitting > >> peer (AP) for Node-ID n. The AP sends the response to the Join. > >> 5. AP MUST do a series of Store requests to JP to store the data > >> that JP will be responsible for. > >> 6. AP MUST send JP an Update explicitly labeling JP as its > >> predecessor. At this point, JP is part of the ring and > >> responsible for a section of the overlay. AP can now forget any > >> data which is assigned to JP and not AP. > >> 7. AP MUST send an Update to all of its neighbors with the new > >> values of its neighbor set (including JP). > >> 8. JP SHOULD send Updates to all the peers in its routing table. > >>=20 > >> In order to populate its neighbor table, JP n sends an Attach via = the > >> bootstrap node directed at Node-ID n+1 (directly after its own = Node-ID). > >> This allows it to discover its own successor. Call that node s0. It > >> then sends an Attach (via the bootstap peer or s0) to s0+1 to = discover > >> its second successor (s1). This process can be repeated to discover = as > >> many successors as desired. The predecessors of JP will be found at = a > >> later stage when JP receives an Update. > >>=20 > >> In order to set up its finger table entry i, JP simply sends an = Attach > >> to peer (n+2^(numBitsInNodeId-i). This will be routed to a peer in > >> approximately the right location around the ring. > >>=20 > >> The joining peer MUST NOT send any Update message placing itself in > >> the overlay until it has successfully completed an Attach with each > >> peer that should be in its neighbor table. > >>=20 > >>=20 > >> Thanks > >>=20 > >> --Michael > >>=20 > >>=20 > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www.ietf.org/mailman/listinfo/p2psip >=20 --Apple-Mail-3--707159390 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Julian,

Please revisit = section 5.1.1, particularly the last paragraph. The nuance is that for = any request (including Attach), the last Destination entry in the = destination-list can be either a Resource-ID or a Node-ID. Normally, an = Attach to a known peer uses a Node-ID Destination. =

However, the example in Section 11 = demonstrates sending an Attach that uses a Resource-ID to discover an = **unknown** peer (JP's successor s0, s1 and finger nodes). This is a = clever use of Attach. Since it is sent to the bootstrap node (or other = known peer, e.g. use s0 to find s1), there is no need to use Ping. Like = I said, Section 11 is sound as it = is.

Thanks

--Michael=
-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org>
Date: Sat, November 21, 2009 10:47 pm
To: "Michael Chen" <michaelc@idssoftware.com><= br> Cc: p2psip@ietf.org


On Nov 21, 2009, at 11:16 PM, Michael Chen wrote:

> Julian,
>
> Section 9.4 1. already established that JP has a connection to the = bootstrap node. Function-wise, I think the example in Section 11 is = sufficient to join the overlay.

Right.

>
> As for 9.6.1, when a peer lost all its successors, the overlay may = have been partitioned (the ring is broken). Whether it uses Ping or = Attach to re-join makes no difference.

The logical ring wouldn't be broken if it were partitioned. You would = have N overlays that aren't communicating with one another. So the logic = from 9.6.4.4. would be used in that case which states sending a Ping not = an Attach.

>
> Actually, I made a couple of mistakes in my text. In the paragraph = after step 8, "Node-ID" should be "Resource-ID". The original text of = draft-06 is correct per section 5.1.1 last paragraph.

The problem I see is:

1. JP MUST connect to its chosen bootstrap node.
2. JP SHOULD send a series of Attach requests to discover and = connect....

In order to perform 2 you need to know "some" Node-ID's in your neighbor = table. So you MUST send a Join on connection to the bootstrap node and = then you can start forming your Attach requests.

It should read something like:

1. JP MUST connect to its chosen bootstrap node (AP).
2. JP Sends a Join request to JP announcing its intention to join.
3. AP sends a Join response.
4. AP does a sequence of Stores to JP to give it the data it will = need.
5. AP does Updates to JP to tell it about its own routing table.
6. JP SHOULD send a series of Attach requests to form connections to = peers that make up its neighbor table as well as the desired 16 finger = table entries.

Julian

>
> --Michael
>
> -------- Original Message --------
> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
> From: jc <julian@orchidseed.org>
> Date: Sat, November 21, 2009 11:16 am
> To: Michael Chen <michaelc@idssoftware.com><= br> >
> Attach messages are routed through the overlay where pings are = not.
>
> A ping actually tests the path while Attach does not.
>
> Also the wording changes break further 9.* sections. For instance = 9.6.1 states "this peer should behave as if it is joining the network = and use pings to find a peer and send it a Join".
>
> It's clearly not defined correctly as is however. A ping is error = prone unless you've already Attached due to possible NAT. While an = Attach will reach any node that is inside the ring a ping will not.
>
> Julian
>
> Sent from my iPhone
>
> On Nov 21, 2009, at 12:42 PM, "Michael Chen" <michaelc@idssoftware.com> = wrote:
>
>> Hi,
>>
>> Draft-06 Section 9.4 is dated and needs work.
>>
>> 2. JP SHOULD use a series of Pings to populate its routing = table.
>> 3. JP SHOULD send Attach requests...
>> 4. JP MUST enter all the peers it has contacted into its = routing
>> table.
>>
>> Section 11 provided a better method in which Attach requests = are used
>> (instead of Ping) to discover and populate the routing table. = There is
>> no need to use Ping. Suggest using the following text:
>>
>> 1. JP MUST connect to its chosen bootstrap node.
>> 2. JP SHOULD send a series of Attach requests to discover = and connect
>> to peers that make up its neighbor table as well as the = desired 16
>> finger table entries. Note that this does not populate = their
>> routing tables, but only their connection tables, so JP = will not
>> get messages that it is expected to route to other = nodes.
>> 3. JP MUST enter all the peers it has contacted into its = routing
>> table and connection table.
>> 4. JP SHOULD send a Join to its immediate successor, the = admitting
>> peer (AP) for Node-ID n. The AP sends the response to = the Join.
>> 5. AP MUST do a series of Store requests to JP to store the = data
>> that JP will be responsible for.
>> 6. AP MUST send JP an Update explicitly labeling JP as = its
>> predecessor. At this point, JP is part of the ring = and
>> responsible for a section of the overlay. AP can now = forget any
>> data which is assigned to JP and not AP.
>> 7. AP MUST send an Update to all of its neighbors with the = new
>> values of its neighbor set (including JP).
>> 8. JP SHOULD send Updates to all the peers in its routing = table.
>>
>> In order to populate its neighbor table, JP n sends an = Attach via the
>> bootstrap node directed at Node-ID n+1 (directly after its = own Node-ID).
>> This allows it to discover its own successor. Call that = node s0. It
>> then sends an Attach (via the bootstap peer or s0) to s0+1 = to discover
>> its second successor (s1). This process can be repeated to = discover as
>> many successors as desired. The predecessors of JP will be = found at a
>> later stage when JP receives an Update.
>>
>> In order to set up its finger table entry i, JP simply sends = an Attach
>> to peer (n+2^(numBitsInNodeId-i). This will be routed to a = peer in
>> approximately the right location around the ring.
>>
>> The joining peer MUST NOT send any Update message placing = itself in
>> the overlay until it has successfully completed an Attach = with each
>> peer that should be in its neighbor table.
>>
>>
>> Thanks
>>
>> --Michael
>>
>>
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://www.ietf= .org/mailman/listinfo/p2psip


= --Apple-Mail-3--707159390-- From michaelc@IDSSOFTWARE.COM Sun Nov 22 17:37:32 2009 Return-Path: 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 50B543A67EE for ; Sun, 22 Nov 2009 17:37:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.816 X-Spam-Level: X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 MgUwbBuVsgVm for ; Sun, 22 Nov 2009 17:37:31 -0800 (PST) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by core3.amsl.com (Postfix) with SMTP id 17EB53A672F for ; Sun, 22 Nov 2009 17:37:30 -0800 (PST) Received: (qmail 21931 invoked from network); 23 Nov 2009 01:37:19 -0000 Received: from unknown (HELO gem-wbe15.prod.mesa1.secureserver.net) (64.202.189.223) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 23 Nov 2009 01:37:18 -0000 Received: (qmail 6342 invoked by uid 99); 23 Nov 2009 01:37:18 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 67.58.151.223 User-Agent: Web-Based Email 5.1.29 Message-Id: <20091122183718.61e8c06078a3b23a733c71e914c0b9df.3ff548d2ab.wbe@email.secureserver.net> From: "Michael Chen" To: "jc" Date: Sun, 22 Nov 2009 18:37:18 -0700 Mime-Version: 1.0 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 01:37:32 -0000
Julian,

The last 3 paragraphs of 9.4= explains how this works. Say JP n knows and have connected one and only on= e node in the overlay (the bootstrap node) B. To discover and attach to JP'= s **unknonwn** successor s0, JP do the following calculation:
    n1 =3D n + 1; // simple 128-bit modulo addit= ion

Then construct an Attach request that cont= ains a lone Resource-ID destination entry:

 &= nbsp;  struct Destination {
        Desti= nationType         type;
 &= nbsp;      uint8     &nbs= p;             = length;
        DestinationData =         destination_data;
  = ;  } dest;

    dest.type =3D DestinationType.res= ource; // Not node!!!
    dest.lenght =3D 17;
    dest.destination_data.resource_id.length =3D 16;
    memcpy(dest.destination_data.resource_id.value,= n1, 16);

The ResourceID in dest contains the valu= e of n1. When bootstrap node B receives this Attach request, according to S= ection 5.1.1 it will route the message to JP's immediate successor (n1 or h= igher) s1. In the reply, s1 will include its ICE info, which get forwarded = back to JP. Then JP and s1 will do ICE and connect.

Thanks

--Michael

-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org>
Date: Sun, November 22, 2009 12:06 pm
To: "Michael Chen" <michaelc@idssoftware.com>
Cc: p2psip@ietf.org

Michael,
I understand the discovery of Node-ID's by Resource-ID's. You = are stating that you connect to a bootstrap node and start sending Attach r= equests however there is a problem. Where do you obtain the Node-ID's or Re= source-ID's to send the Attach requests to?

This i= s a technical impossibility. You MUST have at least another Node-ID or Reso= urce-ID other than that of the bootstrap node. You MUST learn at least a si= ngle Node-ID or Resource-ID from the bootstrap node.

Julian

On Nov 22, 2009, at 2:34 PM, Michael Chen= wrote:

Julian,

Please revisit sect= ion 5.1.1, particularly the last paragraph. The nuance is that for any requ= est (including Attach), the last Destination entry in the destination-list = can be either a Resource-ID or a Node-ID. Normally, an Attach to a known pe= er uses a Node-ID Destination.

However, the examp= le in Section 11 demonstrates sending an Attach that uses a Resource-ID to = discover an **unknown** peer (JP's successor s0, s1 and finger nodes). This= is a clever use of Attach. Since it is sent to the bootstrap node (or othe= r known peer, e.g. use s0 to find s1), there is no need to use Ping. Like I= said, Section 11 is sound as it is.

Thanks

--Michael
-------- Origi= nal Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs w= ork
From: jc <julian@orchidseed.org>= ;
Date: Sat, November 21, 2009 10:47 pm
To: "Michael Chen" <michaelc@idssoftware.com>
Cc: p2psip@ietf.org


On Nov 21, 2009, at 11:16 PM, Mic= hael Chen wrote:

> Julian,
>
> Section 9.4 1. al= ready established that JP has a connection to the bootstrap node. Function-= wise, I think the example in Section 11 is sufficient to join the overlay.<= br>
Right.

>
> As for 9.6.1, when a peer lost all = its successors, the overlay may have been partitioned (the ring is broken).= Whether it uses Ping or Attach to re-join makes no difference.

Th= e logical ring wouldn't be broken if it were partitioned. You would have N = overlays that aren't communicating with one another. So the logic from 9.6.= 4.4. would be used in that case which states sending a Ping not an Attach.<= br>
>
> Actually, I made a couple of mistakes in my text. I= n the paragraph after step 8, "Node-ID" should be "Resource-ID". The origin= al text of draft-06 is correct per section 5.1.1 last paragraph.

T= he problem I see is:

1. JP MUST connect to its chosen bootstrap no= de.
2. JP SHOULD send a series of Attach requests to discover and conne= ct....

In order to perform 2 you need to know "some" Node-ID's in = your neighbor table. So you MUST send a Join on connection to the bootstrap= node and then you can start forming your Attach requests.

It sho= uld read something like:

1. JP MUST connect to its chosen bootstra= p node (AP).
2. JP Sends a Join request to JP announcing its intention = to join.
3. AP sends a Join response.
4. AP does a sequence of Stor= es to JP to give it the data it will need.
5. AP does Updates to JP to = tell it about its own routing table.
6. JP SHOULD send a series of Atta= ch requests to form connections to peers that make up its neighbor table as= well as the desired 16 finger table entries.

Julian

>=
> --Michael
>
> -------- Original Message --------<= br> > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
> Fro= m: jc <julian@orchidseed.org>
> = Date: Sat, November 21, 2009 11:16 am
> To: Michael Chen <michaelc@idssoftware.com>
>
>= ; Attach messages are routed through the overlay where pings are not.
&= gt;
> A ping actually tests the path while Attach does not.
>= ;
> Also the wording changes break further 9.* sections. For instan= ce 9.6.1 states "this peer should behave as if it is joining the network an= d use pings to find a peer and send it a Join".
>
> It's cle= arly not defined correctly as is however. A ping is error prone unless you'= ve already Attached due to possible NAT. While an Attach will reach any nod= e that is inside the ring a ping will not.
>
> Julian
&g= t;
> Sent from my iPhone
>
> On Nov 21, 2009, at 12:= 42 PM, "Michael Chen" <michaelc@idssoftw= are.com> wrote:
>
>> Hi,
>>
>>= ; Draft-06 Section 9.4 is dated and needs work.
>>
>> = 2. JP SHOULD use a series of Pings to populate its routing table.
>&= gt; 3. JP SHOULD send Attach requests...
>> 4. JP MUST enter all = the peers it has contacted into its routing
>> table.
>>= ;
>> Section 11 provided a better method in which Attach request= s are used
>> (instead of Ping) to discover and populate the rout= ing table. There is
>> no need to use Ping. Suggest using the fol= lowing text:
>>
>> 1. JP MUST connect to its chosen bo= otstrap node.
>> 2. JP SHOULD send a series of Attach requests to= discover and connect
>> to peers that make up its neighbor table= as well as the desired 16
>> finger table entries. Note that thi= s does not populate their
>> routing tables, but only their conne= ction tables, so JP will not
>> get messages that it is expected = to route to other nodes.
>> 3. JP MUST enter all the peers it has= contacted into its routing
>> table and connection table.
&g= t;> 4. JP SHOULD send a Join to its immediate successor, the admitting >> peer (AP) for Node-ID n. The AP sends the response to the Join.=
>> 5. AP MUST do a series of Store requests to JP to store the d= ata
>> that JP will be responsible for.
>> 6. AP MUST s= end JP an Update explicitly labeling JP as its
>> predecessor. At= this point, JP is part of the ring and
>> responsible for a sect= ion of the overlay. AP can now forget any
>> data which is assign= ed to JP and not AP.
>> 7. AP MUST send an Update to all of its n= eighbors with the new
>> values of its neighbor set (including JP= ).
>> 8. JP SHOULD send Updates to all the peers in its routing t= able.
>>
>> In order to populate its neighbor table, J= P n sends an Attach via the
>> bootstrap node directed at Node-ID= n+1 (directly after its own Node-ID).
>> This allows it to disco= ver its own successor. Call that node s0. It
>> then sends an Att= ach (via the bootstap peer or s0) to s0+1 to discover
>> its seco= nd successor (s1). This process can be repeated to discover as
>>= many successors as desired. The predecessors of JP will be found at a
= >> later stage when JP receives an Update.
>>
>>= In order to set up its finger table entry i, JP simply sends an Attach
= >> to peer (n+2^(numBitsInNodeId-i). This will be routed to a peer i= n
>> approximately the right location around the ring.
>&g= t;
>> The joining peer MUST NOT send any Update message placing = itself in
>> the overlay until it has successfully completed an A= ttach with each
>> peer that should be in its neighbor table.
= >>
>>
>> Thanks
>>
>> --M= ichael
>>
>>
>> ___________________________= ____________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2psip
=

From julian@orchidseed.org Sun Nov 22 21:57:38 2009 Return-Path: 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 15D873A681A for ; Sun, 22 Nov 2009 21:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6] 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 nU6QTXl1SV88 for ; Sun, 22 Nov 2009 21:57:36 -0800 (PST) Received: from n26.c05.mtsvc.net (n26.c05.mtsvc.net [70.32.68.26]) by core3.amsl.com (Postfix) with ESMTP id 5260B3A67B0 for ; Sun, 22 Nov 2009 21:57:36 -0800 (PST) Received: from adsl-232-19-226.asm.bellsouth.net ([74.232.19.226]:33722 helo=[172.16.1.233]) by n26.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NCRvV-00019r-Aa; Sun, 22 Nov 2009 21:57:32 -0800 References: <20091122183718.61e8c06078a3b23a733c71e914c0b9df.3ff548d2ab.wbe@email.secureserver.net> Message-Id: <7E39AD01-45AE-4A45-B112-E47616D39517@orchidseed.org> From: jc To: Michael Chen In-Reply-To: <20091122183718.61e8c06078a3b23a733c71e914c0b9df.3ff548d2ab.wbe@email.secureserver.net> Content-Type: multipart/alternative; boundary=Apple-Mail-1--671712683 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Mon, 23 Nov 2009 00:57:21 -0500 X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 05:57:38 -0000 --Apple-Mail-1--671712683 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Michael, I have a single bootstrap node with zero successors and predecessors. How does this work under that common scenario? It doesn't in my lab. The Attach won't be routed anywhere and JP will never Join nor will any other Node. JP MUST send a Join first and then Attach to the Resource-ID. Julian Sent from my iPhone On Nov 22, 2009, at 8:37 PM, "Michael Chen" wrote: > Julian, > > The last 3 paragraphs of 9.4 explains how this works. Say JP n knows > and have connected one and only one node in the overlay (the > bootstrap node) B. To discover and attach to JP's **unknonwn** > successor s0, JP do the following calculation: > > n1 = n + 1; // simple 128-bit modulo addition > > Then construct an Attach request that contains a lone Resource-ID > destination entry: > > struct Destination { > DestinationType type; > uint8 length; > DestinationData destination_data; > } dest; > > dest.type = DestinationType.resource; // Not node!!! > dest.lenght = 17; > dest.destination_data.resource_id.length = 16; > memcpy(dest.destination_data.resource_id.value, n1, 16); > > The ResourceID in dest contains the value of n1. When bootstrap node > B receives this Attach request, according to Section 5.1.1 it will > route the message to JP's immediate successor (n1 or higher) s1. In > the reply, s1 will include its ICE info, which get forwarded back to > JP. Then JP and s1 will do ICE and connect. > > Thanks > > --Michael > > -------- Original Message -------- > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work > From: jc > Date: Sun, November 22, 2009 12:06 pm > To: "Michael Chen" > Cc: p2psip@ietf.org > > Michael, > I understand the discovery of Node-ID's by Resource-ID's. You are > stating that you connect to a bootstrap node and start sending > Attach requests however there is a problem. Where do you obtain the > Node-ID's or Resource-ID's to send the Attach requests to? > > This is a technical impossibility. You MUST have at least another > Node-ID or Resource-ID other than that of the bootstrap node. You > MUST learn at least a single Node-ID or Resource-ID from the > bootstrap node. > > Julian > > On Nov 22, 2009, at 2:34 PM, Michael Chen wrote: > >> Julian, >> >> Please revisit section 5.1.1, particularly the last paragraph. The >> nuance is that for any request (including Attach), the last >> Destination entry in the destination-list can be either a Resource- >> ID or a Node-ID. Normally, an Attach to a known peer uses a Node-ID >> Destination. >> >> However, the example in Section 11 demonstrates sending an Attach >> that uses a Resource-ID to discover an **unknown** peer (JP's >> successor s0, s1 and finger nodes). This is a clever use of Attach. >> Since it is sent to the bootstrap node (or other known peer, e.g. >> use s0 to find s1), there is no need to use Ping. Like I said, >> Section 11 is sound as it is. >> >> Thanks >> >> --Michael >> -------- Original Message -------- >> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work >> From: jc >> Date: Sat, November 21, 2009 10:47 pm >> To: "Michael Chen" >> Cc: p2psip@ietf.org >> >> >> On Nov 21, 2009, at 11:16 PM, Michael Chen wrote: >> >> > Julian, >> > >> > Section 9.4 1. already established that JP has a connection to >> the bootstrap node. Function-wise, I think the example in Section >> 11 is sufficient to join the overlay. >> >> Right. >> >> > >> > As for 9.6.1, when a peer lost all its successors, the overlay >> may have been partitioned (the ring is broken). Whether it uses >> Ping or Attach to re-join makes no difference. >> >> The logical ring wouldn't be broken if it were partitioned. You >> would have N overlays that aren't communicating with one another. >> So the logic from 9.6.4.4. would be used in that case which states >> sending a Ping not an Attach. >> >> > >> > Actually, I made a couple of mistakes in my text. In the >> paragraph after step 8, "Node-ID" should be "Resource-ID". The >> original text of draft-06 is correct per section 5.1.1 last >> paragraph. >> >> The problem I see is: >> >> 1. JP MUST connect to its chosen bootstrap node. >> 2. JP SHOULD send a series of Attach requests to discover and >> connect.... >> >> In order to perform 2 you need to know "some" Node-ID's in your >> neighbor table. So you MUST send a Join on connection to the >> bootstrap node and then you can start forming your Attach requests. >> >> It should read something like: >> >> 1. JP MUST connect to its chosen bootstrap node (AP). >> 2. JP Sends a Join request to JP announcing its intention to join. >> 3. AP sends a Join response. >> 4. AP does a sequence of Stores to JP to give it the data it will >> need. >> 5. AP does Updates to JP to tell it about its own routing table. >> 6. JP SHOULD send a series of Attach requests to form connections >> to peers that make up its neighbor table as well as the desired 16 >> finger table entries. >> >> Julian >> >> > >> > --Michael >> > >> > -------- Original Message -------- >> > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work >> > From: jc >> > Date: Sat, November 21, 2009 11:16 am >> > To: Michael Chen >> > >> > Attach messages are routed through the overlay where pings are not. >> > >> > A ping actually tests the path while Attach does not. >> > >> > Also the wording changes break further 9.* sections. For instance >> 9.6.1 states "this peer should behave as if it is joining the >> network and use pings to find a peer and send it a Join". >> > >> > It's clearly not defined correctly as is however. A ping is error >> prone unless you've already Attached due to possible NAT. While an >> Attach will reach any node that is inside the ring a ping will not. >> > >> > Julian >> > >> > Sent from my iPhone >> > >> > On Nov 21, 2009, at 12:42 PM, "Michael Chen" > > wrote: >> > >> >> Hi, >> >> >> >> Draft-06 Section 9.4 is dated and needs work. >> >> >> >> 2. JP SHOULD use a series of Pings to populate its routing table. >> >> 3. JP SHOULD send Attach requests... >> >> 4. JP MUST enter all the peers it has contacted into its routing >> >> table. >> >> >> >> Section 11 provided a better method in which Attach requests are >> used >> >> (instead of Ping) to discover and populate the routing table. >> There is >> >> no need to use Ping. Suggest using the following text: >> >> >> >> 1. JP MUST connect to its chosen bootstrap node. >> >> 2. JP SHOULD send a series of Attach requests to discover and >> connect >> >> to peers that make up its neighbor table as well as the desired 16 >> >> finger table entries. Note that this does not populate their >> >> routing tables, but only their connection tables, so JP will not >> >> get messages that it is expected to route to other nodes. >> >> 3. JP MUST enter all the peers it has contacted into its routing >> >> table and connection table. >> >> 4. JP SHOULD send a Join to its immediate successor, the admitting >> >> peer (AP) for Node-ID n. The AP sends the response to the Join. >> >> 5. AP MUST do a series of Store requests to JP to store the data >> >> that JP will be responsible for. >> >> 6. AP MUST send JP an Update explicitly labeling JP as its >> >> predecessor. At this point, JP is part of the ring and >> >> responsible for a section of the overlay. AP can now forget any >> >> data which is assigned to JP and not AP. >> >> 7. AP MUST send an Update to all of its neighbors with the new >> >> values of its neighbor set (including JP). >> >> 8. JP SHOULD send Updates to all the peers in its routing table. >> >> >> >> In order to populate its neighbor table, JP n sends an Attach >> via the >> >> bootstrap node directed at Node-ID n+1 (directly after its own >> Node-ID). >> >> This allows it to discover its own successor. Call that node s0. >> It >> >> then sends an Attach (via the bootstap peer or s0) to s0+1 to >> discover >> >> its second successor (s1). This process can be repeated to >> discover as >> >> many successors as desired. The predecessors of JP will be found >> at a >> >> later stage when JP receives an Update. >> >> >> >> In order to set up its finger table entry i, JP simply sends an >> Attach >> >> to peer (n+2^(numBitsInNodeId-i). This will be routed to a peer in >> >> approximately the right location around the ring. >> >> >> >> The joining peer MUST NOT send any Update message placing itself >> in >> >> the overlay until it has successfully completed an Attach with >> each >> >> peer that should be in its neighbor table. >> >> >> >> >> >> Thanks >> >> >> >> --Michael >> >> >> >> >> >> _______________________________________________ >> >> P2PSIP mailing list >> >> P2PSIP@ietf.org >> >> https://www.ietf.org/mailman/listinfo/p2psip >> > --Apple-Mail-1--671712683 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Michael,

I have a = single bootstrap node with zero successors and predecessors. How does = this work under that common scenario? It doesn't in my lab. The Attach = won't be routed anywhere and JP will never Join nor will any other Node. = JP MUST send a Join first and then Attach to the = Resource-ID.

Julian

Sent from my = iPhone

On Nov 22, 2009, at 8:37 PM, "Michael Chen" <michaelc@idssoftware.com> = wrote:

Julian,

The last 3 = paragraphs of 9.4 explains how this works. Say JP n knows and have = connected one and only one node in the overlay (the bootstrap node) B. = To discover and attach to JP's **unknonwn** successor s0, JP do the = following calculation:

    n1 =3D = n + 1; // simple 128-bit modulo = addition

Then construct an Attach request = that contains a lone Resource-ID destination = entry:

    struct Destination = {
        = DestinationType         = type;
        = uint8           &nb= sp;       = length;
        = DestinationData         = destination_data;
    } = dest;

    dest.type =3D DestinationType.resource; = // Not node!!!
    dest.lenght =3D = 17;
    = dest.destination_data.resource_id.length =3D = 16;
    = memcpy(dest.destination_data.resource_id.value, n1, = 16);

The ResourceID in dest contains the value = of n1. When bootstrap node B receives this Attach request, according to = Section 5.1.1 it will route the message to JP's immediate successor (n1 = or higher) s1. In the reply, s1 will include its ICE info, which get = forwarded back to JP. Then JP and s1 will do ICE and = connect.

Thanks

--Michae= l

-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org>
Date: Sun, November 22, 2009 12:06 pm
To: "Michael Chen" <michaelc@idssoftware.com><= br> Cc: p2psip@ietf.org

Michael,
I understand the discovery of Node-ID's by Resource-ID's. = You are stating that you connect to a bootstrap node and start sending = Attach requests however there is a problem. Where do you obtain the = Node-ID's or Resource-ID's to send the Attach requests = to?

This is a technical impossibility. You MUST = have at least another Node-ID or Resource-ID other than that of the = bootstrap node. You MUST learn at least a single Node-ID or Resource-ID = from the bootstrap = node.

Julian

On Nov 22, = 2009, at 2:34 PM, Michael Chen wrote:

Julian,

Please revisit section = 5.1.1, particularly the last paragraph. The nuance is that for any = request (including Attach), the last Destination entry in the = destination-list can be either a Resource-ID or a Node-ID. Normally, an = Attach to a known peer uses a Node-ID Destination. =

However, the example in Section 11 = demonstrates sending an Attach that uses a Resource-ID to discover an = **unknown** peer (JP's successor s0, s1 and finger nodes). This is a = clever use of Attach. Since it is sent to the bootstrap node (or other = known peer, e.g. use s0 to find s1), there is no need to use Ping. Like = I said, Section 11 is sound as it = is.

Thanks

--Michael=
-------- Original Message --------
Subject: Re: = [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org> Date: Sat, November 21, 2009 10:47 pm
To: "Michael Chen" <michaelc@idssoftware.com&= gt;
Cc: p2psip@ietf.org


On = Nov 21, 2009, at 11:16 PM, Michael Chen wrote:

> Julian,
= >
> Section 9.4 1. already established that JP has a = connection to the bootstrap node. Function-wise, I think the example in = Section 11 is sufficient to join the overlay.

Right.

= >
> As for 9.6.1, when a peer lost all its successors, the = overlay may have been partitioned (the ring is broken). Whether it uses = Ping or Attach to re-join makes no difference.

The logical ring = wouldn't be broken if it were partitioned. You would have N overlays = that aren't communicating with one another. So the logic from 9.6.4.4. = would be used in that case which states sending a Ping not an = Attach.

>
> Actually, I made a couple of mistakes in = my text. In the paragraph after step 8, "Node-ID" should be = "Resource-ID". The original text of draft-06 is correct per section = 5.1.1 last paragraph.

The problem I see is:

1. JP MUST = connect to its chosen bootstrap node.
2. JP SHOULD send a series of = Attach requests to discover and connect....

In order to perform = 2 you need to know "some" Node-ID's in your neighbor table. So you MUST = send a Join on connection to the bootstrap node and then you can start = forming your Attach requests.

It should read something = like:

1. JP MUST connect to its chosen bootstrap node (AP).
= 2. JP Sends a Join request to JP announcing its intention to join.
= 3. AP sends a Join response.
4. AP does a sequence of Stores to JP = to give it the data it will need.
5. AP does Updates to JP to tell = it about its own routing table.
6. JP SHOULD send a series of Attach = requests to form connections to peers that make up its neighbor table as = well as the desired 16 finger table entries.

Julian

= >
> --Michael
>
> -------- Original Message = --------
> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs = work
> From: jc <julian@orchidseed.org> > Date: Sat, November 21, 2009 11:16 am
> To: Michael Chen = <michaelc@idssoftware.com&= gt;
>
> Attach messages are routed through the overlay = where pings are not.
>
> A ping actually tests the path = while Attach does not.
>
> Also the wording changes break = further 9.* sections. For instance 9.6.1 states "this peer should behave = as if it is joining the network and use pings to find a peer and send it = a Join".
>
> It's clearly not defined correctly as is = however. A ping is error prone unless you've already Attached due to = possible NAT. While an Attach will reach any node that is inside the = ring a ping will not.
>
> Julian
>
> Sent = from my iPhone
>
> On Nov 21, 2009, at 12:42 PM, "Michael = Chen" <michaelc@idssoftware.com&= gt; wrote:
>
>> Hi,
>>
>> = Draft-06 Section 9.4 is dated and needs work.
>>
>> = 2. JP SHOULD use a series of Pings to populate its routing table.
= >> 3. JP SHOULD send Attach requests...
>> 4. JP MUST = enter all the peers it has contacted into its routing
>> = table.
>>
>> Section 11 provided a better method in = which Attach requests are used
>> (instead of Ping) to = discover and populate the routing table. There is
>> no need = to use Ping. Suggest using the following text:
>>
= >> 1. JP MUST connect to its chosen bootstrap node.
>> = 2. JP SHOULD send a series of Attach requests to discover and = connect
>> to peers that make up its neighbor table as well as = the desired 16
>> finger table entries. Note that this does = not populate their
>> routing tables, but only their = connection tables, so JP will not
>> get messages that it is = expected to route to other nodes.
>> 3. JP MUST enter all the = peers it has contacted into its routing
>> table and = connection table.
>> 4. JP SHOULD send a Join to its immediate = successor, the admitting
>> peer (AP) for Node-ID n. The AP = sends the response to the Join.
>> 5. AP MUST do a series of = Store requests to JP to store the data
>> that JP will be = responsible for.
>> 6. AP MUST send JP an Update explicitly = labeling JP as its
>> predecessor. At this point, JP is part = of the ring and
>> responsible for a section of the overlay. = AP can now forget any
>> data which is assigned to JP and not = AP.
>> 7. AP MUST send an Update to all of its neighbors with = the new
>> values of its neighbor set (including JP).
= >> 8. JP SHOULD send Updates to all the peers in its routing = table.
>>
>> In order to populate its neighbor = table, JP n sends an Attach via the
>> bootstrap node directed = at Node-ID n+1 (directly after its own Node-ID).
>> This = allows it to discover its own successor. Call that node s0. It
= >> then sends an Attach (via the bootstap peer or s0) to s0+1 to = discover
>> its second successor (s1). This process can be = repeated to discover as
>> many successors as desired. The = predecessors of JP will be found at a
>> later stage when JP = receives an Update.
>>
>> In order to set up its = finger table entry i, JP simply sends an Attach
>> to peer = (n+2^(numBitsInNodeId-i). This will be routed to a peer in
>> = approximately the right location around the ring.
>>
= >> The joining peer MUST NOT send any Update message placing = itself in
>> the overlay until it has successfully completed = an Attach with each
>> peer that should be in its neighbor = table.
>>
>>
>> Thanks
>>
= >> --Michael
>>
>>
>> = _______________________________________________
>> P2PSIP = mailing list
>> P2PSIP@ietf.org
>> https://www.ietf.org= /mailman/listinfo/p2psip

=

= --Apple-Mail-1--671712683-- From zahra_d84@yahoo.com Sun Nov 22 22:10:20 2009 Return-Path: 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 1CFB63A67FC for ; Sun, 22 Nov 2009 22:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 uo66qAQ4vmhv for ; Sun, 22 Nov 2009 22:10:19 -0800 (PST) Received: from web113605.mail.gq1.yahoo.com (web113605.mail.gq1.yahoo.com [98.136.167.65]) by core3.amsl.com (Postfix) with SMTP id 9BDD93A6A21 for ; Sun, 22 Nov 2009 22:10:18 -0800 (PST) Received: (qmail 16756 invoked by uid 60001); 23 Nov 2009 06:10:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1258956612; bh=U4MlmnTUl4cAmCcUZkrPSjo6gs2k4G4MOgIKWUCpf9I=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=brjyBuEk3XSGdThmDv9Qk5/ZZU47hkUOVqnb3mG/I1OD0HLIO8tWxUygHb4w20u2dvFN39o9MGmGj4buVqXJ8KKTmbE6Gtm5LU1roqY+MeuWgfEV/IrAG13TRTa65+dXKvWgYQs6ia/ByNVX6DFgcGXJTLPPC527nNHQBxqCows= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=bkIipBNICKpdSQLS265tJFCCvFiI9mE+ONVKmmjCNu5Fq2J/567IP5uuxo30Rnp2N9Ad1u1ns7i0ZGsU4OfrdZCwId7A7paZ9SkoNPzN0yu+3UZI8wJhr5HdXU54lsM9J2uMcSImY3Knna/Tcft8nOhEBy7qCxCzp6LB1wnK/R8=; Message-ID: <36512.16273.qm@web113605.mail.gq1.yahoo.com> X-YMail-OSG: Ctq6.GQVM1kb0uKHrpJhyknYTrzj0caE6j_70IFFhb2ea5T3vqz1pnriztHyQCkS7kSlnb4kiwVMCfARFvPCp7QSRab5l69Frottu91UqmypVJnsuuO3bq1AJSO3epMBh457lRQgXiJEHcAE9WSqAUIsNs0VJXsRmpedgN00Kqg61RRIz8tFXmrMZfUVzmlbQuUbIGMurgwDhtOg7u8VN6uLFCohQ4oxm9ALj4eC4cYwk6.JyfHlDuonDPb8EFvND2dPprv1Aw9aGDGiVU2olLB8O2XaGxF6X53BkYFWQrDUp2z6AAqfleTZiRcaERV9H81CqpM9VeilSH5Iobkg1jn346HE76V5ZlrIgWpfd1v6ev4- Received: from [217.219.250.198] by web113605.mail.gq1.yahoo.com via HTTP; Sun, 22 Nov 2009 22:10:11 PST X-Mailer: YahooMailClassic/8.1.6 YahooMailWebService/0.8.100.260964 Date: Sun, 22 Nov 2009 22:10:11 -0800 (PST) From: ZAHRA dehghanianfard To: p2psip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1122840183-1258956611=:16273" Subject: [P2PSIP] windows X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 06:10:20 -0000 --0-1122840183-1258956611=:16273 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable hi. whether created this version of Windows for SIPP2P? thanks. by. =0A=0A=0A Get your new Email address!=0AGrab the Email name you've= always wanted before someone else does!=0Ahttp://mail.promotions.yahoo.com= /newdomains/aa/ --0-1122840183-1258956611=:16273 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
hi.
whether = created this version of Windows for SIPP2P?
thanks.
by.


=0A=0A=0A=0A
Get your preferred Email name!
= =0ANow you can @ymail.com and @rocketmail.com. --0-1122840183-1258956611=:16273-- From julian@orchidseed.org Sun Nov 22 22:53:21 2009 Return-Path: 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 8616C3A6850 for ; Sun, 22 Nov 2009 22:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 SoYmRObnfOVn for ; Sun, 22 Nov 2009 22:53:20 -0800 (PST) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id C2A133A6841 for ; Sun, 22 Nov 2009 22:53:20 -0800 (PST) Received: from adsl-232-19-226.asm.bellsouth.net ([74.232.19.226]:44667 helo=[172.16.1.230]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NCSnT-0004Oz-Mp; Sun, 22 Nov 2009 22:53:17 -0800 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-1--668366382 From: jc In-Reply-To: <36512.16273.qm@web113605.mail.gq1.yahoo.com> Date: Mon, 23 Nov 2009 01:53:11 -0500 Message-Id: <4E72B666-FA4E-4D3A-AFF1-50C9F9B76F7E@orchidseed.org> References: <36512.16273.qm@web113605.mail.gq1.yahoo.com> To: ZAHRA dehghanianfard X-Mailer: Apple Mail (2.1077) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip@ietf.org Subject: Re: [P2PSIP] windows X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 06:53:21 -0000 --Apple-Mail-1--668366382 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Zahra, Several people here have Windows or Cross Platform implementations of = P2PSIP.=20 Julian On Nov 23, 2009, at 1:10 AM, ZAHRA dehghanianfard wrote: > hi. > whether created this version of Windows for SIPP2P? > thanks. > by. >=20 >=20 > Get your preferred Email name!=20 > Now you can @ymail.com and = @rocketmail.com._______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1--668366382 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
hi.
whether created this = version of Windows for = SIPP2P?
thanks.
by.

<= br>
Get your preferred Email = name!
Now you can @ymail.com and = @rocketmail.com._______________________________________________
P2PSIP = mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail-1--668366382-- From melodysong@huawei.com Mon Nov 23 00:02:18 2009 Return-Path: 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 313F93A68F1 for ; Mon, 23 Nov 2009 00:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.718 X-Spam-Level: X-Spam-Status: No, score=0.718 tagged_above=-999 required=5 tests=[AWL=0.903, BAYES_40=-0.185] 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 rfr3X6p-QLDd for ; Mon, 23 Nov 2009 00:02:17 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0D9693A684C for ; Mon, 23 Nov 2009 00:02:17 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTJ00FXJYBN3Q@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 23 Nov 2009 16:02:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KTJ000ETYBNKD@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 23 Nov 2009 16:02:11 +0800 (CST) Received: from s64081 ([10.164.12.12]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KTJ00H73YBMBT@szxml06-in.huawei.com> for p2psip@ietf.org; Mon, 23 Nov 2009 16:02:11 +0800 (CST) Date: Mon, 23 Nov 2009 16:02:10 +0800 From: Song Haibin In-reply-to: <8b2769930911180123i5c9d3a16r7c885aeb6e0317c6@mail.gmail.com> To: "'David A. Bryan'" , "'Rosen, Brian'" Message-id: <012301ca6c13$429b8fb0$0c0ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpoMNtGbdtlQCKLQFSLdVV6MbL49gD3u6rg Cc: p2psip@ietf.org Subject: Re: [P2PSIP] WGLC on draft-ietf-p2psip-base-06 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 08:02:18 -0000 I agree with taking the document to WGLC if the authors take the TURN discovery usage out of this document and leave it to another task of a generic service discovery mechanism. It's weird to have two different service discovery mechanisms. If the authors think their TURN discovery mechanism is good, then how about writing it in a separate proposal for service discovery (not limited to TURN usage), and we will have several candidate drafts. Xie Xie, Haibin >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >On Behalf Of David A. Bryan >Sent: Wednesday, November 18, 2009 5:23 PM >To: Rosen, Brian >Cc: p2psip@ietf.org >Subject: Re: [P2PSIP] WGLC on draft-ietf-p2psip-base-06 > >I know Brian's call here is in response to Cullen formally >objecting to Robert about my taking time to confirm the sense >of the room on list, but I think we need to apply process >rules uniformly here, regardless of who it is that wants the >WG to move on their schedule. > >I think the WG is being pushed to skip a step. I would like to >formally ask that the WGLC be started after adequate time has >been given to respond to my poll for the sense of the mailing >list on wether the document is ready to go to WGLC. > >This WG just had a very active discussion (started by one of >the editors of this draft, actually) about allowing adequate >time for the list to review hums. A week was deemed the >minimal acceptable time. >Hiroshima was a very exceptional meeting. Very few of our >regular attendees were there. As far as I know, only one of >the authors of this draft was present. Both chairs and many of >the other major contributors were not present. > >In light of these facts, while one could argue the hum was a >"sense of the room" question, rather than a consensus call >(and therefore needs no list confirmation), I felt it did. I >was the chair tasked with the work of listening to the audio, >assembling minutes, and confirming hums on list. I didn't feel >enough participants were present for the chairs or AD to say >the room really reflected the WG. I made a decision to send >email asking for list confirmation if we should go to WGLC out >of an abundance of caution. One can argue I didn't have to or >shouldn't have asked the list for confirmation, but I felt it >was the right thing to do, and issued the call for comments as >chair. For consistency we should allow time for folks to comment. > >I understand this is a minor and procedural point. If folks >care they can object once we go to WGLC, of course. However, >considering how long this document has been on the table, and >the long periods of time the editors have sometimes allowed to >pass between revisions, waiting five more days to officially >start WGLC does not adversely impact the work of the group and >is the right thing to do to ensure consistent process is followed. > >(That said, please folks, start reviewing now!!! The editors need your >comments!!!) > >To make it clear to the WG, I personally support taking this >document to WGLC (and have indicated as such before) largely >as an impetus to get reviewers and WG participants to comment >on the document, which in my opinion still needs some work, >but needs reviews to get that work done. However I do not feel >all participants have been given adequate time to voice >disagreement with taking this to WGLC, and feel we need to >allow time for that. > >David > >On Tue, Nov 17, 2009 at 6:28 PM, Rosen, Brian > wrote: >> This message announces a Working Group Last Call on >> draft-ietf-p2psip-base-06. Due to the size of the draft and >the lack >> of extensive reviews, the WGLC will run until Dec 11th. Please get >> your comments in ASAP. Those of you who have committed to >review the >> document in depth, this is your deadline, and we would >appreciate your >> review before the last minute. >> >> Brian >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www.ietf.org/mailman/listinfo/p2psip > From michaelc@IDSSOFTWARE.COM Mon Nov 23 09:35:06 2009 Return-Path: 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 1176C3A67DF for ; Mon, 23 Nov 2009 09:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 ZYjX1MBcPl5H for ; Mon, 23 Nov 2009 09:35:04 -0800 (PST) Received: from smtpoutwbe10.prod.mesa1.secureserver.net (smtpoutwbe10.prod.mesa1.secureserver.net [208.109.78.26]) by core3.amsl.com (Postfix) with SMTP id AE9323A6A5F for ; Mon, 23 Nov 2009 09:35:04 -0800 (PST) Received: (qmail 24901 invoked from network); 23 Nov 2009 17:34:56 -0000 Received: from unknown (HELO gem-wbe28.prod.mesa1.secureserver.net) (64.202.189.162) by smtpoutwbe10.prod.mesa1.secureserver.net with SMTP; 23 Nov 2009 17:34:56 -0000 Received: (qmail 25594 invoked by uid 99); 23 Nov 2009 17:34:56 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 12.175.188.225 User-Agent: Web-Based Email 5.1.29 Message-Id: <20091123103456.61e8c06078a3b23a733c71e914c0b9df.44e9bf0029.wbe@email.secureserver.net> From: "Michael Chen" To: "jc" Date: Mon, 23 Nov 2009 10:34:56 -0700 Mime-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:35:06 -0000
Julian,

I know that dilemma. It's a = ring of 2 scenario. The bootstrap node (BN) is also the admitting node (AP)= of the join node (JP). The sequence of event is like this:

<= /div>
  1) JP looks up for BN (via broadcast, multi-cast, DNS, etc= .)
  2) JP Attach to BN
  3) JP and BN do ICE= check followed by D/TLS handshake.
  3) JP Attach to JP= +1 (looking for its successor)
  4) BN reply the Attach with= the Node-ID of AP =3D=3D BN.

For any Attach reque= st, the sender should check its connection table to see it has already conn= ected to the target peer. At this point, both JP and BN discover that it is= already connected to each other. In our implementation, both JP and BN wil= l skip the ICE check and D/TLS.  Instead, they both reuse the connecti= on obtained from step 2 and 3 and move on.

&nb= sp; 5) JP send JOIN to AP (BN).

This ring of 2= scenario also applies to a populated ring in which the BP also happens to = be the AP of a new peer seeking to join.

Thank= s

--Michael

-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org>
Date: Sun, November 22, 2009 9:57 pm
To: Michael Chen <michaelc@idssoftware.com>
Cc: "p2psip@ietf.org" <p2psip@ietf.org>


Michael,

I have a single bootstrap node w= ith zero successors and predecessors. How does this work under that common = scenario? It doesn't in my lab. The Attach won't be routed anywhere and JP = will never Join nor will any other Node. JP MUST send a Join first and then= Attach to the Resource-ID.

Julian

S= ent from my iPhone

On Nov 22, 2009, at 8:37 PM, "Michael Chen= " <michaelc@idssoftware.com> wrot= e:

Julian,

The last 3 paragraphs of 9.4 exp= lains how this works. Say JP n knows and have connected one and only one no= de in the overlay (the bootstrap node) B. To discover and attach to JP's **= unknonwn** successor s0, JP do the following calculation:

    n1 =3D n + 1; // simple 128-bit modulo addition<= br>

Then construct an Attach request that contains= a lone Resource-ID destination entry:

  = ;  struct Destination {
        Destinatio= nType         type;
  =       uint8      &nb= sp;            lengt= h;
        DestinationData  = ;       destination_data;
  &nbs= p; } dest;

    dest.type =3D DestinationType.resource= ; // Not node!!!
    dest.lenght =3D 17;
    dest.destination_data.resource_id.length =3D 16;
<= div>    memcpy(dest.destination_data.resource_id.value, n1, = 16);

The ResourceID in dest contains the value of = n1. When bootstrap node B receives this Attach request, according to Sectio= n 5.1.1 it will route the message to JP's immediate successor (n1 or higher= ) s1. In the reply, s1 will include its ICE info, which get forwarded back = to JP. Then JP and s1 will do ICE and connect.

Tha= nks

--Michael

=
-------- Original Message --------
Subject: Re: [P2PSIP] Draft-0= 6 section 9.4 needs work
From: jc <julian@= orchidseed.org>
Date: Sun, November 22, 2009 12:06 pm
To: "M= ichael Chen" <michaelc@idssoftware.com>
Cc: p2psip@ietf.org

= Michael,
I understand the discovery of Node-ID's by Resource-ID's. You= are stating that you connect to a bootstrap node and start sending Attach = requests however there is a problem. Where do you obtain the Node-ID's or R= esource-ID's to send the Attach requests to?

This = is a technical impossibility. You MUST have at least another Node-ID or Res= ource-ID other than that of the bootstrap node. You MUST learn at least a s= ingle Node-ID or Resource-ID from the bootstrap node.

<= div>Julian

On Nov 22, 2009, at 2:34 PM, Michael Che= n wrote:

Julian,

Please revisit sec= tion 5.1.1, particularly the last paragraph. The nuance is that for any req= uest (including Attach), the last Destination entry in the destination-list= can be either a Resource-ID or a Node-ID. Normally, an Attach to a known p= eer uses a Node-ID Destination.

However, the exam= ple in Section 11 demonstrates sending an Attach that uses a Resource-ID to= discover an **unknown** peer (JP's successor s0, s1 and finger nodes). Thi= s is a clever use of Attach. Since it is sent to the bootstrap node (or oth= er known peer, e.g. use s0 to find s1), there is no need to use Ping. Like = I said, Section 11 is sound as it is.

Thanks

--Michael
-------- Orig= inal Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs = work
From: jc <jul= ian@orchidseed.org>
Date: Sat, November 21, 2009 10:47 pm
To= : "Michael Chen" <michaelc@idssoftware.com>
Cc: p2psip= @ietf.org


On Nov 21, 2009, at 11:16 PM, Michael Chen wrot= e:

> Julian,
>
> Section 9.4 1. already establis= hed that JP has a connection to the bootstrap node. Function-wise, I think = the example in Section 11 is sufficient to join the overlay.

Right= .

>
> As for 9.6.1, when a peer lost all its successors= , the overlay may have been partitioned (the ring is broken). Whether it us= es Ping or Attach to re-join makes no difference.

The logical ring= wouldn't be broken if it were partitioned. You would have N overlays that = aren't communicating with one another. So the logic from 9.6.4.4. would be = used in that case which states sending a Ping not an Attach.

> =
> Actually, I made a couple of mistakes in my text. In the paragrap= h after step 8, "Node-ID" should be "Resource-ID". The original text of dra= ft-06 is correct per section 5.1.1 last paragraph.

The problem I s= ee is:

1. JP MUST connect to its chosen bootstrap node.
2. JP = SHOULD send a series of Attach requests to discover and connect....
In order to perform 2 you need to know "some" Node-ID's in your neighbor = table. So you MUST send a Join on connection to the bootstrap node and then= you can start forming your Attach requests.

It should read somet= hing like:

1. JP MUST connect to its chosen bootstrap node (AP). 2. JP Sends a Join request to JP announcing its intention to join.
3= . AP sends a Join response.
4. AP does a sequence of Stores to JP to gi= ve it the data it will need.
5. AP does Updates to JP to tell it about = its own routing table.
6. JP SHOULD send a series of Attach requests to= form connections to peers that make up its neighbor table as well as the d= esired 16 finger table entries.

Julian

>
> --M= ichael
>
> -------- Original Message --------
> Subje= ct: Re: [P2PSIP] Draft-06 section 9.4 needs work
> From: jc <julian@orchidseed.org>=
> Date: Sat, November 21, 2009 11:16 am
> To: Michael Chen &= lt;mi= chaelc@idssoftware.com>
>
> Attach messages are route= d through the overlay where pings are not.
>
> A ping actual= ly tests the path while Attach does not.
>
> Also the wordin= g changes break further 9.* sections. For instance 9.6.1 states "this peer = should behave as if it is joining the network and use pings to find a peer = and send it a Join".
>
> It's clearly not defined correctly = as is however. A ping is error prone unless you've already Attached due to = possible NAT. While an Attach will reach any node that is inside the ring a= ping will not.
>
> Julian
>
> Sent from my i= Phone
>
> On Nov 21, 2009, at 12:42 PM, "Michael Chen" <<= a target=3D"_blank" mce_onclick=3D"if(window.location=3D=3Dtop.location){Po= pup.composeWindow('pcompose.php?sendto=3Dmichaelc%40idssoftware.com');}else= {top.Popup.composeWindow('pcompose.php?sendto=3Dmichaelc%40idssoftware.com'= );}; return false;" href=3D"mailto:michaelc@idssoftware.com" mce_href=3D"ma= ilto:michaelc@idssoftware.com">michaelc= @idssoftware.com> wrote:
>
>> Hi,
>> >> Draft-06 Section 9.4 is dated and needs work.
>>
= >> 2. JP SHOULD use a series of Pings to populate its routing table.<= br> >> 3. JP SHOULD send Attach requests...
>> 4. JP MUST e= nter all the peers it has contacted into its routing
>> table. >>
>> Section 11 provided a better method in which Attac= h requests are used
>> (instead of Ping) to discover and populate= the routing table. There is
>> no need to use Ping. Suggest usin= g the following text:
>>
>> 1. JP MUST connect to its = chosen bootstrap node.
>> 2. JP SHOULD send a series of Attach re= quests to discover and connect
>> to peers that make up its neigh= bor table as well as the desired 16
>> finger table entries. Note= that this does not populate their
>> routing tables, but only th= eir connection tables, so JP will not
>> get messages that it is = expected to route to other nodes.
>> 3. JP MUST enter all the pee= rs it has contacted into its routing
>> table and connection tabl= e.
>> 4. JP SHOULD send a Join to its immediate successor, the ad= mitting
>> peer (AP) for Node-ID n. The AP sends the response to = the Join.
>> 5. AP MUST do a series of Store requests to JP to st= ore the data
>> that JP will be responsible for.
>> 6. = AP MUST send JP an Update explicitly labeling JP as its
>> predec= essor. At this point, JP is part of the ring and
>> responsible f= or a section of the overlay. AP can now forget any
>> data which = is assigned to JP and not AP.
>> 7. AP MUST send an Update to all= of its neighbors with the new
>> values of its neighbor set (inc= luding JP).
>> 8. JP SHOULD send Updates to all the peers in its = routing table.
>>
>> In order to populate its neighbor= table, JP n sends an Attach via the
>> bootstrap node directed a= t Node-ID n+1 (directly after its own Node-ID).
>> This allows it= to discover its own successor. Call that node s0. It
>> then sen= ds an Attach (via the bootstap peer or s0) to s0+1 to discover
>>= its second successor (s1). This process can be repeated to discover as
= >> many successors as desired. The predecessors of JP will be found = at a
>> later stage when JP receives an Update.
>>
= >> In order to set up its finger table entry i, JP simply sends an A= ttach
>> to peer (n+2^(numBitsInNodeId-i). This will be routed to= a peer in
>> approximately the right location around the ring. >>
>> The joining peer MUST NOT send any Update message= placing itself in
>> the overlay until it has successfully compl= eted an Attach with each
>> peer that should be in its neighbor t= able.
>>
>>
>> Thanks
>>
>= ;> --Michael
>>
>>
>> __________________= _____________________________
>> P2PSIP mailing list
>>= P2PSIP@ietf.org
>> https://www.ietf.org/mailman/listinfo/p2psip

<= /blockquote> From julian@orchidseed.org Mon Nov 23 09:44:33 2009 Return-Path: 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 DE0F03A6978 for ; Mon, 23 Nov 2009 09:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6] 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 hSZf5cqmfius for ; Mon, 23 Nov 2009 09:44:31 -0800 (PST) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id D830A3A6969 for ; Mon, 23 Nov 2009 09:44:31 -0800 (PST) Received: from adsl-232-19-226.asm.bellsouth.net ([74.232.19.226]:41003 helo=[172.16.1.233]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NCcxc-000497-Ns; Mon, 23 Nov 2009 09:44:28 -0800 References: <20091123103456.61e8c06078a3b23a733c71e914c0b9df.44e9bf0029.wbe@email.secureserver.net> Message-Id: <1D1A5529-4AF7-4E7B-AA96-78059D11F100@orchidseed.org> From: jc To: Michael Chen In-Reply-To: <20091123103456.61e8c06078a3b23a733c71e914c0b9df.44e9bf0029.wbe@email.secureserver.net> Content-Type: multipart/alternative; boundary=Apple-Mail-2--629300766 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Mon, 23 Nov 2009 12:44:13 -0500 X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:44:34 -0000 --Apple-Mail-2--629300766 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Michael, This is what I was attempting to state the entire time and needs to be worded in correctly in the draft. Also why would you perform an ICE connectivity check with a public bootstrap node? This doesn't bring anything worthy of doing. The connectivity check is performed by DTLS/TLS in this case.. Julian Sent from my iPhone On Nov 23, 2009, at 12:34 PM, "Michael Chen" wrote: > Julian, > > I know that dilemma. It's a ring of 2 scenario. The bootstrap node > (BN) is also the admitting node (AP) of the join node (JP). The > sequence of event is like this: > > 1) JP looks up for BN (via broadcast, multi-cast, DNS, etc.) > 2) JP Attach to BN > 3) JP and BN do ICE check followed by D/TLS handshake. > 3) JP Attach to JP+1 (looking for its successor) > 4) BN reply the Attach with the Node-ID of AP == BN. > > For any Attach request, the sender should check its connection table > to see it has already connected to the target peer. At this point, > both JP and BN discover that it is already connected to each other. > In our implementation, both JP and BN will skip the ICE check and D/ > TLS. Instead, they both reuse the connection obtained from step 2 > and 3 and move on. > > 5) JP send JOIN to AP (BN). > > This ring of 2 scenario also applies to a populated ring in which > the BP also happens to be the AP of a new peer seeking to join. > > Thanks > > --Michael > > -------- Original Message -------- > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work > From: jc > Date: Sun, November 22, 2009 9:57 pm > To: Michael Chen > Cc: "p2psip@ietf.org" > > > Michael, > > I have a single bootstrap node with zero successors and > predecessors. How does this work under that common scenario? It > doesn't in my lab. The Attach won't be routed anywhere and JP will > never Join nor will any other Node. JP MUST send a Join first and > then Attach to the Resource-ID. > > Julian > > Sent from my iPhone > > On Nov 22, 2009, at 8:37 PM, "Michael Chen" > wrote: > >> Julian, >> >> The last 3 paragraphs of 9.4 explains how this works. Say JP n >> knows and have connected one and only one node in the overlay (the >> bootstrap node) B. To discover and attach to JP's **unknonwn** >> successor s0, JP do the following calculation: >> >> n1 = n + 1; // simple 128-bit modulo addition >> >> Then construct an Attach request that contains a lone Resource-ID >> destination entry: >> >> struct Destination { >> DestinationType type; >> uint8 length; >> DestinationData destination_data; >> } dest; >> >> dest.type = DestinationType.resource; // Not node!!! >> dest.lenght = 17; >> dest.destination_data.resource_id.length = 16; >> memcpy(dest.destination_data.resource_id.value, n1, 16); >> >> The ResourceID in dest contains the value of n1. When bootstrap >> node B receives this Attach request, according to Section 5.1.1 it >> will route the message to JP's immediate successor (n1 or higher) >> s1. In the reply, s1 will include its ICE info, which get forwarded >> back to JP. Then JP and s1 will do ICE and connect. >> >> Thanks >> >> --Michael >> >> -------- Original Message -------- >> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work >> From: jc >> Date: Sun, November 22, 2009 12:06 pm >> To: "Michael Chen" >> Cc: p2psip@ietf.org >> >> Michael, >> I understand the discovery of Node-ID's by Resource-ID's. You are >> stating that you connect to a bootstrap node and start sending >> Attach requests however there is a problem. Where do you obtain the >> Node-ID's or Resource-ID's to send the Attach requests to? >> >> This is a technical impossibility. You MUST have at least another >> Node-ID or Resource-ID other than that of the bootstrap node. You >> MUST learn at least a single Node-ID or Resource-ID from the >> bootstrap node. >> >> Julian >> >> On Nov 22, 2009, at 2:34 PM, Michael Chen wrote: >> >>> Julian, >>> >>> Please revisit section 5.1.1, particularly the last paragraph. The >>> nuance is that for any request (including Attach), the last >>> Destination entry in the destination-list can be either a Resource- >>> ID or a Node-ID. Normally, an Attach to a known peer uses a Node- >>> ID Destination. >>> >>> However, the example in Section 11 demonstrates sending an Attach >>> that uses a Resource-ID to discover an **unknown** peer (JP's >>> successor s0, s1 and finger nodes). This is a clever use of >>> Attach. Since it is sent to the bootstrap node (or other known >>> peer, e.g. use s0 to find s1), there is no need to use Ping. Like >>> I said, Section 11 is sound as it is. >>> >>> Thanks >>> >>> --Michael >>> -------- Original Message -------- >>> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work >>> From: jc >>> Date: Sat, November 21, 2009 10:47 pm >>> To: "Michael Chen" >>> Cc: p2psip@ietf.org >>> >>> >>> On Nov 21, 2009, at 11:16 PM, Michael Chen wrote: >>> >>> > Julian, >>> > >>> > Section 9.4 1. already established that JP has a connection to >>> the bootstrap node. Function-wise, I think the example in Section >>> 11 is sufficient to join the overlay. >>> >>> Right. >>> >>> > >>> > As for 9.6.1, when a peer lost all its successors, the overlay >>> may have been partitioned (the ring is broken). Whether it uses >>> Ping or Attach to re-join makes no difference. >>> >>> The logical ring wouldn't be broken if it were partitioned. You >>> would have N overlays that aren't communicating with one another. >>> So the logic from 9.6.4.4. would be used in that case which states >>> sending a Ping not an Attach. >>> >>> > >>> > Actually, I made a couple of mistakes in my text. In the >>> paragraph after step 8, "Node-ID" should be "Resource-ID". The >>> original text of draft-06 is correct per section 5.1.1 last >>> paragraph. >>> >>> The problem I see is: >>> >>> 1. JP MUST connect to its chosen bootstrap node. >>> 2. JP SHOULD send a series of Attach requests to discover and >>> connect.... >>> >>> In order to perform 2 you need to know "some" Node-ID's in your >>> neighbor table. So you MUST send a Join on connection to the >>> bootstrap node and then you can start forming your Attach requests. >>> >>> It should read something like: >>> >>> 1. JP MUST connect to its chosen bootstrap node (AP). >>> 2. JP Sends a Join request to JP announcing its intention to join. >>> 3. AP sends a Join response. >>> 4. AP does a sequence of Stores to JP to give it the data it will >>> need. >>> 5. AP does Updates to JP to tell it about its own routing table. >>> 6. JP SHOULD send a series of Attach requests to form connections >>> to peers that make up its neighbor table as well as the desired 16 >>> finger table entries. >>> >>> Julian >>> >>> > >>> > --Michael >>> > >>> > -------- Original Message -------- >>> > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work >>> > From: jc >>> > Date: Sat, November 21, 2009 11:16 am >>> > To: Michael Chen >>> > >>> > Attach messages are routed through the overlay where pings are >>> not. >>> > >>> > A ping actually tests the path while Attach does not. >>> > >>> > Also the wording changes break further 9.* sections. For >>> instance 9.6.1 states "this peer should behave as if it is joining >>> the network and use pings to find a peer and send it a Join". >>> > >>> > It's clearly not defined correctly as is however. A ping is >>> error prone unless you've already Attached due to possible NAT. >>> While an Attach will reach any node that is inside the ring a ping >>> will not. >>> > >>> > Julian >>> > >>> > Sent from my iPhone >>> > >>> > On Nov 21, 2009, at 12:42 PM, "Michael Chen" >> > wrote: >>> > >>> >> Hi, >>> >> >>> >> Draft-06 Section 9.4 is dated and needs work. >>> >> >>> >> 2. JP SHOULD use a series of Pings to populate its routing table. >>> >> 3. JP SHOULD send Attach requests... >>> >> 4. JP MUST enter all the peers it has contacted into its routing >>> >> table. >>> >> >>> >> Section 11 provided a better method in which Attach requests >>> are used >>> >> (instead of Ping) to discover and populate the routing table. >>> There is >>> >> no need to use Ping. Suggest using the following text: >>> >> >>> >> 1. JP MUST connect to its chosen bootstrap node. >>> >> 2. JP SHOULD send a series of Attach requests to discover and >>> connect >>> >> to peers that make up its neighbor table as well as the desired >>> 16 >>> >> finger table entries. Note that this does not populate their >>> >> routing tables, but only their connection tables, so JP will not >>> >> get messages that it is expected to route to other nodes. >>> >> 3. JP MUST enter all the peers it has contacted into its routing >>> >> table and connection table. >>> >> 4. JP SHOULD send a Join to its immediate successor, the >>> admitting >>> >> peer (AP) for Node-ID n. The AP sends the response to the Join. >>> >> 5. AP MUST do a series of Store requests to JP to store the data >>> >> that JP will be responsible for. >>> >> 6. AP MUST send JP an Update explicitly labeling JP as its >>> >> predecessor. At this point, JP is part of the ring and >>> >> responsible for a section of the overlay. AP can now forget any >>> >> data which is assigned to JP and not AP. >>> >> 7. AP MUST send an Update to all of its neighbors with the new >>> >> values of its neighbor set (including JP). >>> >> 8. JP SHOULD send Updates to all the peers in its routing table. >>> >> >>> >> In order to populate its neighbor table, JP n sends an Attach >>> via the >>> >> bootstrap node directed at Node-ID n+1 (directly after its own >>> Node-ID). >>> >> This allows it to discover its own successor. Call that node >>> s0. It >>> >> then sends an Attach (via the bootstap peer or s0) to s0+1 to >>> discover >>> >> its second successor (s1). This process can be repeated to >>> discover as >>> >> many successors as desired. The predecessors of JP will be >>> found at a >>> >> later stage when JP receives an Update. >>> >> >>> >> In order to set up its finger table entry i, JP simply sends an >>> Attach >>> >> to peer (n+2^(numBitsInNodeId-i). This will be routed to a peer >>> in >>> >> approximately the right location around the ring. >>> >> >>> >> The joining peer MUST NOT send any Update message placing >>> itself in >>> >> the overlay until it has successfully completed an Attach with >>> each >>> >> peer that should be in its neighbor table. >>> >> >>> >> >>> >> Thanks >>> >> >>> >> --Michael >>> >> >>> >> >>> >> _______________________________________________ >>> >> P2PSIP mailing list >>> >> P2PSIP@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/p2psip >>> >> > --Apple-Mail-2--629300766 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Michael,
This is what I = was attempting to state the entire time and needs to be worded in = correctly in the draft.

Also why would you = perform an ICE connectivity check with a public bootstrap node? This = doesn't bring anything worthy of doing. The connectivity check is = performed by DTLS/TLS in this = case..

Julian

Sent from my = iPhone

On Nov 23, 2009, at 12:34 PM, "Michael Chen" <michaelc@idssoftware.com> = wrote:

Julian,

I = know that dilemma. It's a ring of 2 scenario. The bootstrap node (BN) is = also the admitting node (AP) of the join node (JP). The sequence of = event is like this:

  1) JP looks up for = BN (via broadcast, multi-cast, DNS, etc.)
  2) JP Attach = to BN
  3) JP and BN do ICE check followed by D/TLS = handshake.
  3) JP Attach to JP+1 (looking for its = successor)
  4) BN reply the Attach with the Node-ID of = AP =3D=3D BN.

For any Attach request, the = sender should check its connection table to see it has already connected = to the target peer. At this point, both JP and BN discover that it is = already connected to each other. In our implementation, both JP and BN = will skip the ICE check and D/TLS.  Instead, they both reuse the = connection obtained from step 2 and 3 and move = on.

  5) JP send JOIN to AP = (BN).

This ring of 2 scenario also applies = to a populated ring in which the BP also happens to be the AP of a new = peer seeking to = join.

Thanks

--Micha= el

-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org>
Date: Sun, November 22, 2009 9:57 pm
To: Michael Chen <michaelc@idssoftware.com><= br> Cc: "p2psip@ietf.org" <p2psip@ietf.org>


Michael,

I have a single bootstrap = node with zero successors and predecessors. How does this work under = that common scenario? It doesn't in my lab. The Attach won't be routed = anywhere and JP will never Join nor will any other Node. JP MUST send a = Join first and then Attach to the = Resource-ID.

Julian

Sent from my = iPhone

On Nov 22, 2009, at 8:37 PM, "Michael Chen" <michaelc@idssoftware.com&= gt; wrote:

Julian,

The last 3 paragraphs of = 9.4 explains how this works. Say JP n knows and have connected one and = only one node in the overlay (the bootstrap node) B. To discover and = attach to JP's **unknonwn** successor s0, JP do the following = calculation:

    n1 =3D n + 1; = // simple 128-bit modulo addition

Then = construct an Attach request that contains a lone Resource-ID destination = entry:

    struct Destination = {
        = DestinationType         = type;
        = uint8           &nb= sp;       = length;
        = DestinationData         = destination_data;
    } = dest;

    dest.type =3D DestinationType.resource; = // Not node!!!
    dest.lenght =3D = 17;
    = dest.destination_data.resource_id.length =3D = 16;
    = memcpy(dest.destination_data.resource_id.value, n1, = 16);

The ResourceID in dest contains the value = of n1. When bootstrap node B receives this Attach request, according to = Section 5.1.1 it will route the message to JP's immediate successor (n1 = or higher) s1. In the reply, s1 will include its ICE info, which get = forwarded back to JP. Then JP and s1 will do ICE and = connect.

Thanks

--Michae= l

-------- Original Message --------
Subject: Re: = [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org> Date: Sun, November 22, 2009 12:06 pm
To: "Michael Chen" <michaelc@idssoftware.com&= gt;
Cc: p2psip@ietf.org

= Michael,
I understand the discovery of Node-ID's by Resource-ID's. = You are stating that you connect to a bootstrap node and start sending = Attach requests however there is a problem. Where do you obtain the = Node-ID's or Resource-ID's to send the Attach requests = to?

This is a technical impossibility. You MUST = have at least another Node-ID or Resource-ID other than that of the = bootstrap node. You MUST learn at least a single Node-ID or Resource-ID = from the bootstrap = node.

Julian

On Nov 22, = 2009, at 2:34 PM, Michael Chen wrote:

Julian,

Please revisit section = 5.1.1, particularly the last paragraph. The nuance is that for any = request (including Attach), the last Destination entry in the = destination-list can be either a Resource-ID or a Node-ID. Normally, an = Attach to a known peer uses a Node-ID Destination. =

However, the example in Section 11 = demonstrates sending an Attach that uses a Resource-ID to discover an = **unknown** peer (JP's successor s0, s1 and finger nodes). This is a = clever use of Attach. Since it is sent to the bootstrap node (or other = known peer, e.g. use s0 to find s1), there is no need to use Ping. Like = I said, Section 11 is sound as it = is.

Thanks

--Michael=
-------- Original Message --------
Subject: Re: = [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org> Date: Sat, November 21, 2009 10:47 pm
To: "Michael Chen" <michaelc@idssoftware.com&= gt;
Cc: p2psip@ietf.org


On = Nov 21, 2009, at 11:16 PM, Michael Chen wrote:

> Julian,
= >
> Section 9.4 1. already established that JP has a = connection to the bootstrap node. Function-wise, I think the example in = Section 11 is sufficient to join the overlay.

Right.

= >
> As for 9.6.1, when a peer lost all its successors, the = overlay may have been partitioned (the ring is broken). Whether it uses = Ping or Attach to re-join makes no difference.

The logical ring = wouldn't be broken if it were partitioned. You would have N overlays = that aren't communicating with one another. So the logic from 9.6.4.4. = would be used in that case which states sending a Ping not an = Attach.

>
> Actually, I made a couple of mistakes in = my text. In the paragraph after step 8, "Node-ID" should be = "Resource-ID". The original text of draft-06 is correct per section = 5.1.1 last paragraph.

The problem I see is:

1. JP MUST = connect to its chosen bootstrap node.
2. JP SHOULD send a series of = Attach requests to discover and connect....

In order to perform = 2 you need to know "some" Node-ID's in your neighbor table. So you MUST = send a Join on connection to the bootstrap node and then you can start = forming your Attach requests.

It should read something = like:

1. JP MUST connect to its chosen bootstrap node (AP).
= 2. JP Sends a Join request to JP announcing its intention to join.
= 3. AP sends a Join response.
4. AP does a sequence of Stores to JP = to give it the data it will need.
5. AP does Updates to JP to tell = it about its own routing table.
6. JP SHOULD send a series of Attach = requests to form connections to peers that make up its neighbor table as = well as the desired 16 finger table entries.

Julian

= >
> --Michael
>
> -------- Original Message = --------
> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs = work
> From: jc <julian@orchidseed.org> > Date: Sat, November 21, 2009 11:16 am
> To: Michael Chen = <michaelc@idssoftware.com&= gt;
>
> Attach messages are routed through the overlay = where pings are not.
>
> A ping actually tests the path = while Attach does not.
>
> Also the wording changes break = further 9.* sections. For instance 9.6.1 states "this peer should behave = as if it is joining the network and use pings to find a peer and send it = a Join".
>
> It's clearly not defined correctly as is = however. A ping is error prone unless you've already Attached due to = possible NAT. While an Attach will reach any node that is inside the = ring a ping will not.
>
> Julian
>
> Sent = from my iPhone
>
> On Nov 21, 2009, at 12:42 PM, "Michael = Chen" <michaelc@idssoftware.com&= gt; wrote:
>
>> Hi,
>>
>> = Draft-06 Section 9.4 is dated and needs work.
>>
>> = 2. JP SHOULD use a series of Pings to populate its routing table.
= >> 3. JP SHOULD send Attach requests...
>> 4. JP MUST = enter all the peers it has contacted into its routing
>> = table.
>>
>> Section 11 provided a better method in = which Attach requests are used
>> (instead of Ping) to = discover and populate the routing table. There is
>> no need = to use Ping. Suggest using the following text:
>>
= >> 1. JP MUST connect to its chosen bootstrap node.
>> = 2. JP SHOULD send a series of Attach requests to discover and = connect
>> to peers that make up its neighbor table as well as = the desired 16
>> finger table entries. Note that this does = not populate their
>> routing tables, but only their = connection tables, so JP will not
>> get messages that it is = expected to route to other nodes.
>> 3. JP MUST enter all the = peers it has contacted into its routing
>> table and = connection table.
>> 4. JP SHOULD send a Join to its immediate = successor, the admitting
>> peer (AP) for Node-ID n. The AP = sends the response to the Join.
>> 5. AP MUST do a series of = Store requests to JP to store the data
>> that JP will be = responsible for.
>> 6. AP MUST send JP an Update explicitly = labeling JP as its
>> predecessor. At this point, JP is part = of the ring and
>> responsible for a section of the overlay. = AP can now forget any
>> data which is assigned to JP and not = AP.
>> 7. AP MUST send an Update to all of its neighbors with = the new
>> values of its neighbor set (including JP).
= >> 8. JP SHOULD send Updates to all the peers in its routing = table.
>>
>> In order to populate its neighbor = table, JP n sends an Attach via the
>> bootstrap node directed = at Node-ID n+1 (directly after its own Node-ID).
>> This = allows it to discover its own successor. Call that node s0. It
= >> then sends an Attach (via the bootstap peer or s0) to s0+1 to = discover
>> its second successor (s1). This process can be = repeated to discover as
>> many successors as desired. The = predecessors of JP will be found at a
>> later stage when JP = receives an Update.
>>
>> In order to set up its = finger table entry i, JP simply sends an Attach
>> to peer = (n+2^(numBitsInNodeId-i). This will be routed to a peer in
>> = approximately the right location around the ring.
>>
= >> The joining peer MUST NOT send any Update message placing = itself in
>> the overlay until it has successfully completed = an Attach with each
>> peer that should be in its neighbor = table.
>>
>>
>> Thanks
>>
= >> --Michael
>>
>>
>> = _______________________________________________
>> P2PSIP = mailing list
>> P2PSIP@ietf.org
>> https://www.ietf.org= /mailman/listinfo/p2psip

=

=
= --Apple-Mail-2--629300766-- From michaelc@IDSSOFTWARE.COM Mon Nov 23 10:55:58 2009 Return-Path: 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 980283A695D for ; Mon, 23 Nov 2009 10:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.924 X-Spam-Level: X-Spam-Status: No, score=-0.924 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 tVfblFZLVkKj for ; Mon, 23 Nov 2009 10:55:57 -0800 (PST) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by core3.amsl.com (Postfix) with SMTP id 2B23E3A6767 for ; Mon, 23 Nov 2009 10:55:56 -0800 (PST) Received: (qmail 3871 invoked from network); 23 Nov 2009 18:55:52 -0000 Received: from unknown (HELO gem-wbe04.prod.mesa1.secureserver.net) (64.202.189.36) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 23 Nov 2009 18:55:52 -0000 Received: (qmail 805 invoked by uid 99); 23 Nov 2009 18:55:52 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 12.175.188.225 User-Agent: Web-Based Email 5.1.29 Message-Id: <20091123115552.61e8c06078a3b23a733c71e914c0b9df.8b6d486ce8.wbe@email.secureserver.net> From: "Michael Chen" To: "jc" Date: Mon, 23 Nov 2009 11:55:52 -0700 Mime-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:55:58 -0000
Julian, this conversation would have lasted 10 seconds if we = were face to face :)

I agree that there is no need= (should not) to do ICE with the bootstrap node. At the current development= stage, our code simply do indiscriminate ICE check to help testing and cod= e coverage. It will be removed.

Thanks

--Michael

-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org>
Date: Mon, November 23, 2009 9:44 am
To: Michael Chen <michaelc@idssoftware.com>
Cc: "p2psip@ietf.org" <p2psip@ietf.org>

Michael,
This is what I was attempting to state the entire t= ime and needs to be worded in correctly in the draft.

<= div>Also why would you perform an ICE connectivity check with a public boot= strap node? This doesn't bring anything worthy of doing. The connectivity c= heck is performed by DTLS/TLS in this case..

Julia= n

Sent from my iPhone

On Nov 23, 2009, at 12:34 PM, "M= ichael Chen" <michaelc@idssoftware.com> wrote:



<= div>  5) JP send JOIN to AP (BN).

This ri= ng of 2 scenario also applies to a populated ring in which the BP also happ= ens to be the AP of a new peer seeking to join.

Thanks

--Michael

-------- Original Message --------
Subject: Re: [P2PSIP] Dr= aft-06 section 9.4 needs work
From: jc <ju= lian@orchidseed.org>
Date: Sun, November 22, 2009 9:57 pm
To= : Michael Chen <michaelc@idssoftware.com= >
Cc: "p2psip@ietf.org" <p2ps= ip@ietf.org>


Michael,

I h= ave a single bootstrap node with zero successors and predecessors. How does= this work under that common scenario? It doesn't in my lab. The Attach won= 't be routed anywhere and JP will never Join nor will any other Node. JP MU= ST send a Join first and then Attach to the Resource-ID.

Julian

Sent from my iPhone

On Nov 22, 20= 09, at 8:37 PM, "Michael Chen" <michaelc@idssoftware.com> wrote:
Julian,

The last 3 paragraphs of 9.4 explains how= this works. Say JP n knows and have connected one and only one node in the= overlay (the bootstrap node) B. To discover and attach to JP's **unknonwn*= * successor s0, JP do the following calculation:

&= nbsp;   n1 =3D n + 1; // simple 128-bit modulo addition
=

Then construct an Attach request that contains a lone R= esource-ID destination entry:

    s= truct Destination {
        DestinationType&nbs= p;        type;
   &nb= sp;    uint8        =            length;
&nb= sp;       DestinationData   &n= bsp;     destination_data;
    } dest= ;

    dest.type =3D DestinationType.resource; // Not = node!!!
    dest.lenght =3D 17;
 &n= bsp;  dest.destination_data.resource_id.length =3D 16;
 = ;   memcpy(dest.destination_data.resource_id.value, n1, 16);

The ResourceID in dest contains the value of n1. When = bootstrap node B receives this Attach request, according to Section 5.1.1 i= t will route the message to JP's immediate successor (n1 or higher) s1. In = the reply, s1 will include its ICE info, which get forwarded back to JP. Th= en JP and s1 will do ICE and connect.

Thanks
=

--Michael

--= ------ Original Message --------
Subject: Re: [P2PSIP] Draft-06 section= 9.4 needs work
From: jc <julian@orchidseed.org>
Date: Sun, November 22, 2009 12:0= 6 pm
To: "Michael Chen" <michaelc@idssoftware.com>
Cc: p2psip@ietf.org

Michael,
I understand the discovery= of Node-ID's by Resource-ID's. You are stating that you connect to a boots= trap node and start sending Attach requests however there is a problem. Whe= re do you obtain the Node-ID's or Resource-ID's to send the Attach requests= to?

This is a technical impossibility. You MUST h= ave at least another Node-ID or Resource-ID other than that of the bootstra= p node. You MUST learn at least a single Node-ID or Resource-ID from the bo= otstrap node.

Julian

On No= v 22, 2009, at 2:34 PM, Michael Chen wrote:

Julian,

Please revisit section 5.1.1, particularly the last paragr= aph. The nuance is that for any request (including Attach), the last Destin= ation entry in the destination-list can be either a Resource-ID or a Node-I= D. Normally, an Attach to a known peer uses a Node-ID Destination.

However, the example in Section 11 demonstrates sending a= n Attach that uses a Resource-ID to discover an **unknown** peer (JP's succ= essor s0, s1 and finger nodes). This is a clever use of Attach. Since it is= sent to the bootstrap node (or other known peer, e.g. use s0 to find s1), = there is no need to use Ping. Like I said, Section 11 is sound as it is.

Thanks

--Michael
-------- Original Message --------
Subject: Re: [= P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.o= rg>
Date: Sat, November 21, 2009 10:47 pm
To: "Michael Chen"= <= michaelc@idssoftware.com>
C= c: <= /a><= /a>p2psip@ietf.org


On Nov 21, 2009, at 11:1= 6 PM, Michael Chen wrote:

> Julian,
>
> Section = 9.4 1. already established that JP has a connection to the bootstrap node. = Function-wise, I think the example in Section 11 is sufficient to join the = overlay.

Right.

>
> As for 9.6.1, when a peer = lost all its successors, the overlay may have been partitioned (the ring is= broken). Whether it uses Ping or Attach to re-join makes no difference.
The logical ring wouldn't be broken if it were partitioned. You woul= d have N overlays that aren't communicating with one another. So the logic = from 9.6.4.4. would be used in that case which states sending a Ping not an= Attach.

>
> Actually, I made a couple of mistakes in m= y text. In the paragraph after step 8, "Node-ID" should be "Resource-ID". T= he original text of draft-06 is correct per section 5.1.1 last paragraph.
The problem I see is:

1. JP MUST connect to its chosen boo= tstrap node.
2. JP SHOULD send a series of Attach requests to discover = and connect....

In order to perform 2 you need to know "some" Node= -ID's in your neighbor table. So you MUST send a Join on connection to the = bootstrap node and then you can start forming your Attach requests.
It should read something like:

1. JP MUST connect to its chosen= bootstrap node (AP).
2. JP Sends a Join request to JP announcing its i= ntention to join.
3. AP sends a Join response.
4. AP does a sequenc= e of Stores to JP to give it the data it will need.
5. AP does Updates = to JP to tell it about its own routing table.
6. JP SHOULD send a serie= s of Attach requests to form connections to peers that make up its neighbor= table as well as the desired 16 finger table entries.

Julian
=
>
> --Michael
>
> -------- Original Message = --------
> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
= > From: jc <julian@orchidseed.org>
> Date: Sat, Novem= ber 21, 2009 11:16 am
> To: Michael Chen <michaelc@idssoftware.com>
>
> Attach messages = are routed through the overlay where pings are not.
>
> A pi= ng actually tests the path while Attach does not.
>
> Also t= he wording changes break further 9.* sections. For instance 9.6.1 states "t= his peer should behave as if it is joining the network and use pings to fin= d a peer and send it a Join".
>
> It's clearly not defined c= orrectly as is however. A ping is error prone unless you've already Attache= d due to possible NAT. While an Attach will reach any node that is inside t= he ring a ping will not.
>
> Julian
>
> Sent = from my iPhone
>
> On Nov 21, 2009, at 12:42 PM, "Michael Ch= en" <michaelc@idssoftware.com> wrote= :
>
>> Hi,
>>
>> Draft-06 Section 9.= 4 is dated and needs work.
>>
>> 2. JP SHOULD use a se= ries of Pings to populate its routing table.
>> 3. JP SHOULD send= Attach requests...
>> 4. JP MUST enter all the peers it has cont= acted into its routing
>> table.
>>
>> Secti= on 11 provided a better method in which Attach requests are used
>&g= t; (instead of Ping) to discover and populate the routing table. There is >> no need to use Ping. Suggest using the following text:
>= >
>> 1. JP MUST connect to its chosen bootstrap node.
>= ;> 2. JP SHOULD send a series of Attach requests to discover and connect=
>> to peers that make up its neighbor table as well as the desir= ed 16
>> finger table entries. Note that this does not populate t= heir
>> routing tables, but only their connection tables, so JP w= ill not
>> get messages that it is expected to route to other nod= es.
>> 3. JP MUST enter all the peers it has contacted into its r= outing
>> table and connection table.
>> 4. JP SHOULD s= end a Join to its immediate successor, the admitting
>> peer (AP)= for Node-ID n. The AP sends the response to the Join.
>> 5. AP M= UST do a series of Store requests to JP to store the data
>> that= JP will be responsible for.
>> 6. AP MUST send JP an Update expl= icitly labeling JP as its
>> predecessor. At this point, JP is pa= rt of the ring and
>> responsible for a section of the overlay. A= P can now forget any
>> data which is assigned to JP and not AP.<= br> >> 7. AP MUST send an Update to all of its neighbors with the new=
>> values of its neighbor set (including JP).
>> 8. JP= SHOULD send Updates to all the peers in its routing table.
>> >> In order to populate its neighbor table, JP n sends an Attach v= ia the
>> bootstrap node directed at Node-ID n+1 (directly after = its own Node-ID).
>> This allows it to discover its own successor= . Call that node s0. It
>> then sends an Attach (via the bootstap= peer or s0) to s0+1 to discover
>> its second successor (s1). Th= is process can be repeated to discover as
>> many successors as d= esired. The predecessors of JP will be found at a
>> later stage = when JP receives an Update.
>>
>> In order to set up i= ts finger table entry i, JP simply sends an Attach
>> to peer (n+= 2^(numBitsInNodeId-i). This will be routed to a peer in
>> approx= imately the right location around the ring.
>>
>> The = joining peer MUST NOT send any Update message placing itself in
>>= ; the overlay until it has successfully completed an Attach with each
&= gt;> peer that should be in its neighbor table.
>>
>&g= t;
>> Thanks
>>
>> --Michael
>> <= br> >>
>> _______________________________________________<= br> >> P2PSIP mailing list
>> P2PSIP@ietf.org=
>> https://www.ietf.org/mail= man/listinfo/p2psip


 From julian@orchidseed.org Mon Nov 23 13:11:00 2009 Return-Path: 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 CAA193A6A1A for ; Mon, 23 Nov 2009 13:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[AWL=-0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_46=0.6] 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 N54IObHoTh4s for ; Mon, 23 Nov 2009 13:10:58 -0800 (PST) Received: from n26.c05.mtsvc.net (n26.c05.mtsvc.net [70.32.68.26]) by core3.amsl.com (Postfix) with ESMTP id 59C2228C0ED for ; Mon, 23 Nov 2009 13:10:58 -0800 (PST) Received: from adsl-232-19-226.asm.bellsouth.net ([74.232.19.226]:37837 helo=[172.16.1.233]) by n26.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1NCgBO-0008O1-OY; Mon, 23 Nov 2009 13:10:54 -0800 References: <20091123115552.61e8c06078a3b23a733c71e914c0b9df.8b6d486ce8.wbe@email.secureserver.net> Message-Id: From: jc To: Michael Chen In-Reply-To: <20091123115552.61e8c06078a3b23a733c71e914c0b9df.8b6d486ce8.wbe@email.secureserver.net> Content-Type: multipart/alternative; boundary=Apple-Mail-4--616913884 Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Mon, 23 Nov 2009 16:10:40 -0500 X-Authenticated-User: 72798 julian@orchidseed.org Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 21:11:01 -0000 --Apple-Mail-4--616913884 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Sent from my iPhone On Nov 23, 2009, at 1:55 PM, "Michael Chen" wrote: > Julian, this conversation would have lasted 10 seconds if we were > face to face :) I agree :) > > I agree that there is no need (should not) to do ICE with the > bootstrap node. At the current development stage, our code simply do > indiscriminate ICE check to help testing and code coverage. It will > be removed. > > Thanks > > --Michael > > -------- Original Message -------- > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work > From: jc > Date: Mon, November 23, 2009 9:44 am > To: Michael Chen > Cc: "p2psip@ietf.org" > > Michael, > This is what I was attempting to state the entire time and needs to > be worded in correctly in the draft. > > Also why would you perform an ICE connectivity check with a public > bootstrap node? This doesn't bring anything worthy of doing. The > connectivity check is performed by DTLS/TLS in this case.. > > Julian > > Sent from my iPhone > > On Nov 23, 2009, at 12:34 PM, "Michael Chen" > wrote: > >> Julian, >> >> I know that dilemma. It's a ring of 2 scenario. The bootstrap node >> (BN) is also the admitting node (AP) of the join node (JP). The >> sequence of event is like this: >> >> 1) JP looks up for BN (via broadcast, multi-cast, DNS, etc.) >> 2) JP Attach to BN >> 3) JP and BN do ICE check followed by D/TLS handshake. >> 3) JP Attach to JP+1 (looking for its successor) >> 4) BN reply the Attach with the Node-ID of AP == BN. >> >> For any Attach request, the sender should check its connection >> table to see it has already connected to the target peer. At this >> point, both JP and BN discover that it is already connected to each >> other. In our implementation, both JP and BN will skip the ICE >> check and D/TLS. Instead, they both reuse the connection obtained >> from step 2 and 3 and move on. >> >> 5) JP send JOIN to AP (BN). >> >> This ring of 2 scenario also applies to a populated ring in which >> the BP also happens to be the AP of a new peer seeking to join. >> >> Thanks >> >> --Michael >> >> -------- Original Message -------- >> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work >> From: jc >> Date: Sun, November 22, 2009 9:57 pm >> To: Michael Chen >> Cc: "p2psip@ietf.org" >> >> >> Michael, >> >> I have a single bootstrap node with zero successors and >> predecessors. How does this work under that common scenario? It >> doesn't in my lab. The Attach won't be routed anywhere and JP will >> never Join nor will any other Node. JP MUST send a Join first and >> then Attach to the Resource-ID. >> >> Julian >> >> Sent from my iPhone >> >> On Nov 22, 2009, at 8:37 PM, "Michael Chen" >> wrote: >> >>> Julian, >>> >>> The last 3 paragraphs of 9.4 explains how this works. Say JP n >>> knows and have connected one and only one node in the overlay (the >>> bootstrap node) B. To discover and attach to JP's **unknonwn** >>> successor s0, JP do the following calculation: >>> >>> n1 = n + 1; // simple 128-bit modulo addition >>> >>> Then construct an Attach request that contains a lone Resource-ID >>> destination entry: >>> >>> struct Destination { >>> DestinationType type; >>> uint8 length; >>> DestinationData destination_data; >>> } dest; >>> >>> dest.type = DestinationType.resource; // Not node!!! >>> dest.lenght = 17; >>> dest.destination_data.resource_id.length = 16; >>> memcpy(dest.destination_data.resource_id.value, n1, 16); >>> >>> The ResourceID in dest contains the value of n1. When bootstrap >>> node B receives this Attach request, according to Section 5.1.1 it >>> will route the message to JP's immediate successor (n1 or higher) >>> s1. In the reply, s1 will include its ICE info, which get >>> forwarded back to JP. Then JP and s1 will do ICE and connect. >>> >>> Thanks >>> >>> --Michael >>> >>> -------- Original Message -------- >>> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work >>> From: jc >>> Date: Sun, November 22, 2009 12:06 pm >>> To: "Michael Chen" >>> Cc: p2psip@ietf.org >>> >>> Michael, >>> I understand the discovery of Node-ID's by Resource-ID's. You are >>> stating that you connect to a bootstrap node and start sending >>> Attach requests however there is a problem. Where do you obtain >>> the Node-ID's or Resource-ID's to send the Attach requests to? >>> >>> This is a technical impossibility. You MUST have at least another >>> Node-ID or Resource-ID other than that of the bootstrap node. You >>> MUST learn at least a single Node-ID or Resource-ID from the >>> bootstrap node. >>> >>> Julian >>> >>> On Nov 22, 2009, at 2:34 PM, Michael Chen wrote: >>> >>>> Julian, >>>> >>>> Please revisit section 5.1.1, particularly the last paragraph. >>>> The nuance is that for any request (including Attach), the last >>>> Destination entry in the destination-list can be either a >>>> Resource-ID or a Node-ID. Normally, an Attach to a known peer >>>> uses a Node-ID Destination. >>>> >>>> However, the example in Section 11 demonstrates sending an Attach >>>> that uses a Resource-ID to discover an **unknown** peer (JP's >>>> successor s0, s1 and finger nodes). This is a clever use of >>>> Attach. Since it is sent to the bootstrap node (or other known >>>> peer, e.g. use s0 to find s1), there is no need to use Ping. Like >>>> I said, Section 11 is sound as it is. >>>> >>>> Thanks >>>> >>>> --Michael >>>> -------- Original Message -------- >>>> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work >>>> From: jc >>>> Date: Sat, November 21, 2009 10:47 pm >>>> To: "Michael Chen" >>>> Cc: p2psip@ietf.org >>>> >>>> >>>> On Nov 21, 2009, at 11:16 PM, Michael Chen wrote: >>>> >>>> > Julian, >>>> > >>>> > Section 9.4 1. already established that JP has a connection to >>>> the bootstrap node. Function-wise, I think the example in Section >>>> 11 is sufficient to join the overlay. >>>> >>>> Right. >>>> >>>> > >>>> > As for 9.6.1, when a peer lost all its successors, the overlay >>>> may have been partitioned (the ring is broken). Whether it uses >>>> Ping or Attach to re-join makes no difference. >>>> >>>> The logical ring wouldn't be broken if it were partitioned. You >>>> would have N overlays that aren't communicating with one another. >>>> So the logic from 9.6.4.4. would be used in that case which >>>> states sending a Ping not an Attach. >>>> >>>> > >>>> > Actually, I made a couple of mistakes in my text. In the >>>> paragraph after step 8, "Node-ID" should be "Resource-ID". The >>>> original text of draft-06 is correct per section 5.1.1 last >>>> paragraph. >>>> >>>> The problem I see is: >>>> >>>> 1. JP MUST connect to its chosen bootstrap node. >>>> 2. JP SHOULD send a series of Attach requests to discover and >>>> connect.... >>>> >>>> In order to perform 2 you need to know "some" Node-ID's in your >>>> neighbor table. So you MUST send a Join on connection to the >>>> bootstrap node and then you can start forming your Attach requests. >>>> >>>> It should read something like: >>>> >>>> 1. JP MUST connect to its chosen bootstrap node (AP). >>>> 2. JP Sends a Join request to JP announcing its intention to join. >>>> 3. AP sends a Join response. >>>> 4. AP does a sequence of Stores to JP to give it the data it will >>>> need. >>>> 5. AP does Updates to JP to tell it about its own routing table. >>>> 6. JP SHOULD send a series of Attach requests to form connections >>>> to peers that make up its neighbor table as well as the desired >>>> 16 finger table entries. >>>> >>>> Julian >>>> >>>> > >>>> > --Michael >>>> > >>>> > -------- Original Message -------- >>>> > Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work >>>> > From: jc >>>> > Date: Sat, November 21, 2009 11:16 am >>>> > To: Michael Chen >>>> > >>>> > Attach messages are routed through the overlay where pings are >>>> not. >>>> > >>>> > A ping actually tests the path while Attach does not. >>>> > >>>> > Also the wording changes break further 9.* sections. For >>>> instance 9.6.1 states "this peer should behave as if it is >>>> joining the network and use pings to find a peer and send it a >>>> Join". >>>> > >>>> > It's clearly not defined correctly as is however. A ping is >>>> error prone unless you've already Attached due to possible NAT. >>>> While an Attach will reach any node that is inside the ring a >>>> ping will not. >>>> > >>>> > Julian >>>> > >>>> > Sent from my iPhone >>>> > >>>> > On Nov 21, 2009, at 12:42 PM, "Michael Chen" >>> > wrote: >>>> > >>>> >> Hi, >>>> >> >>>> >> Draft-06 Section 9.4 is dated and needs work. >>>> >> >>>> >> 2. JP SHOULD use a series of Pings to populate its routing >>>> table. >>>> >> 3. JP SHOULD send Attach requests... >>>> >> 4. JP MUST enter all the peers it has contacted into its routing >>>> >> table. >>>> >> >>>> >> Section 11 provided a better method in which Attach requests >>>> are used >>>> >> (instead of Ping) to discover and populate the routing table. >>>> There is >>>> >> no need to use Ping. Suggest using the following text: >>>> >> >>>> >> 1. JP MUST connect to its chosen bootstrap node. >>>> >> 2. JP SHOULD send a series of Attach requests to discover and >>>> connect >>>> >> to peers that make up its neighbor table as well as the >>>> desired 16 >>>> >> finger table entries. Note that this does not populate their >>>> >> routing tables, but only their connection tables, so JP will not >>>> >> get messages that it is expected to route to other nodes. >>>> >> 3. JP MUST enter all the peers it has contacted into its routing >>>> >> table and connection table. >>>> >> 4. JP SHOULD send a Join to its immediate successor, the >>>> admitting >>>> >> peer (AP) for Node-ID n. The AP sends the response to the Join. >>>> >> 5. AP MUST do a series of Store requests to JP to store the data >>>> >> that JP will be responsible for. >>>> >> 6. AP MUST send JP an Update explicitly labeling JP as its >>>> >> predecessor. At this point, JP is part of the ring and >>>> >> responsible for a section of the overlay. AP can now forget any >>>> >> data which is assigned to JP and not AP. >>>> >> 7. AP MUST send an Update to all of its neighbors with the new >>>> >> values of its neighbor set (including JP). >>>> >> 8. JP SHOULD send Updates to all the peers in its routing table. >>>> >> >>>> >> In order to populate its neighbor table, JP n sends an Attach >>>> via the >>>> >> bootstrap node directed at Node-ID n+1 (directly after its own >>>> Node-ID). >>>> >> This allows it to discover its own successor. Call that node >>>> s0. It >>>> >> then sends an Attach (via the bootstap peer or s0) to s0+1 to >>>> discover >>>> >> its second successor (s1). This process can be repeated to >>>> discover as >>>> >> many successors as desired. The predecessors of JP will be >>>> found at a >>>> >> later stage when JP receives an Update. >>>> >> >>>> >> In order to set up its finger table entry i, JP simply sends >>>> an Attach >>>> >> to peer (n+2^(numBitsInNodeId-i). This will be routed to a >>>> peer in >>>> >> approximately the right location around the ring. >>>> >> >>>> >> The joining peer MUST NOT send any Update message placing >>>> itself in >>>> >> the overlay until it has successfully completed an Attach with >>>> each >>>> >> peer that should be in its neighbor table. >>>> >> >>>> >> >>>> >> Thanks >>>> >> >>>> >> --Michael >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> P2PSIP mailing list >>>> >> P2PSIP@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/p2psip >>>> >>> >> > --Apple-Mail-4--616913884 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my = iPhone

On Nov 23, 2009, at 1:55 PM, "Michael Chen" <michaelc@idssoftware.com> = wrote:

Julian, this conversation would = have lasted 10 seconds if we were face to face = :)

I agree = :)


I agree that there is no need = (should not) to do ICE with the bootstrap node. At the current = development stage, our code simply do indiscriminate ICE check to help = testing and code coverage. It will be = removed.

Thanks

--Mi= chael

-------- Original Message --------
Subject: Re: [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org>
Date: Mon, November 23, 2009 9:44 am
To: Michael Chen <michaelc@idssoftware.com><= br> Cc: "p2psip@ietf.org" <p2psip@ietf.org>

Michael,
This is what I was attempting to state the = entire time and needs to be worded in correctly in the = draft.

Also why would you perform an ICE = connectivity check with a public bootstrap node? This doesn't bring = anything worthy of doing. The connectivity check is performed by = DTLS/TLS in this case..

Julian

Sent from = my iPhone

On Nov 23, 2009, at 12:34 PM, "Michael Chen" = <michaelc@idssoftware.com&= gt; wrote:

Julian,

I know that dilemma. It's a = ring of 2 scenario. The bootstrap node (BN) is also the admitting node = (AP) of the join node (JP). The sequence of event is like = this:

  1) JP looks up for BN (via = broadcast, multi-cast, DNS, etc.)
  2) JP Attach to = BN
  3) JP and BN do ICE check followed by D/TLS = handshake.
  3) JP Attach to JP+1 (looking for its = successor)
  4) BN reply the Attach with the Node-ID of = AP =3D=3D BN.

For any Attach request, the = sender should check its connection table to see it has already connected = to the target peer. At this point, both JP and BN discover that it is = already connected to each other. In our implementation, both JP and BN = will skip the ICE check and D/TLS.  Instead, they both reuse the = connection obtained from step 2 and 3 and move = on.

  5) JP send JOIN to AP = (BN).

This ring of 2 scenario also applies = to a populated ring in which the BP also happens to be the AP of a new = peer seeking to = join.

Thanks

--Micha= el

-------- Original Message --------
Subject: Re: = [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org> Date: Sun, November 22, 2009 9:57 pm
To: Michael Chen <michaelc@idssoftware.com&= gt;
Cc: "p2psip@ietf.org" <p2psip@ietf.org>

=

Michael,

I have a single bootstrap = node with zero successors and predecessors. How does this work under = that common scenario? It doesn't in my lab. The Attach won't be routed = anywhere and JP will never Join nor will any other Node. JP MUST send a = Join first and then Attach to the = Resource-ID.

Julian

Sent from my = iPhone

On Nov 22, 2009, at 8:37 PM, "Michael Chen" <michaelc@idssoftware.com&= gt; wrote:

Julian,

The last 3 paragraphs of = 9.4 explains how this works. Say JP n knows and have connected one and = only one node in the overlay (the bootstrap node) B. To discover and = attach to JP's **unknonwn** successor s0, JP do the following = calculation:

    n1 =3D n + 1; = // simple 128-bit modulo addition

Then = construct an Attach request that contains a lone Resource-ID destination = entry:

    struct Destination = {
        = DestinationType         = type;
        = uint8           &nb= sp;       = length;
        = DestinationData         = destination_data;
    } = dest;

    dest.type =3D DestinationType.resource; = // Not node!!!
    dest.lenght =3D = 17;
    = dest.destination_data.resource_id.length =3D = 16;
    = memcpy(dest.destination_data.resource_id.value, n1, = 16);

The ResourceID in dest contains the value = of n1. When bootstrap node B receives this Attach request, according to = Section 5.1.1 it will route the message to JP's immediate successor (n1 = or higher) s1. In the reply, s1 will include its ICE info, which get = forwarded back to JP. Then JP and s1 will do ICE and = connect.

Thanks

--Michae= l

-------- Original Message --------
Subject: Re: = [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org> Date: Sun, November 22, 2009 12:06 pm
To: "Michael Chen" <michaelc@idssoftware.com&= gt;
Cc: p2psip@ietf.org

= Michael,
I understand the discovery of Node-ID's by Resource-ID's. = You are stating that you connect to a bootstrap node and start sending = Attach requests however there is a problem. Where do you obtain the = Node-ID's or Resource-ID's to send the Attach requests = to?

This is a technical impossibility. You MUST = have at least another Node-ID or Resource-ID other than that of the = bootstrap node. You MUST learn at least a single Node-ID or Resource-ID = from the bootstrap = node.

Julian

On Nov 22, = 2009, at 2:34 PM, Michael Chen wrote:

Julian,

Please revisit section = 5.1.1, particularly the last paragraph. The nuance is that for any = request (including Attach), the last Destination entry in the = destination-list can be either a Resource-ID or a Node-ID. Normally, an = Attach to a known peer uses a Node-ID Destination. =

However, the example in Section 11 = demonstrates sending an Attach that uses a Resource-ID to discover an = **unknown** peer (JP's successor s0, s1 and finger nodes). This is a = clever use of Attach. Since it is sent to the bootstrap node (or other = known peer, e.g. use s0 to find s1), there is no need to use Ping. Like = I said, Section 11 is sound as it = is.

Thanks

--Michael=
-------- Original Message --------
Subject: Re: = [P2PSIP] Draft-06 section 9.4 needs work
From: jc <julian@orchidseed.org> Date: Sat, November 21, 2009 10:47 pm
To: "Michael Chen" <michaelc@idssoftware.com&= gt;
Cc: p2psip@ietf.org


On = Nov 21, 2009, at 11:16 PM, Michael Chen wrote:

> Julian,
= >
> Section 9.4 1. already established that JP has a = connection to the bootstrap node. Function-wise, I think the example in = Section 11 is sufficient to join the overlay.

Right.

= >
> As for 9.6.1, when a peer lost all its successors, the = overlay may have been partitioned (the ring is broken). Whether it uses = Ping or Attach to re-join makes no difference.

The logical ring = wouldn't be broken if it were partitioned. You would have N overlays = that aren't communicating with one another. So the logic from 9.6.4.4. = would be used in that case which states sending a Ping not an = Attach.

>
> Actually, I made a couple of mistakes in = my text. In the paragraph after step 8, "Node-ID" should be = "Resource-ID". The original text of draft-06 is correct per section = 5.1.1 last paragraph.

The problem I see is:

1. JP MUST = connect to its chosen bootstrap node.
2. JP SHOULD send a series of = Attach requests to discover and connect....

In order to perform = 2 you need to know "some" Node-ID's in your neighbor table. So you MUST = send a Join on connection to the bootstrap node and then you can start = forming your Attach requests.

It should read something = like:

1. JP MUST connect to its chosen bootstrap node (AP).
= 2. JP Sends a Join request to JP announcing its intention to join.
= 3. AP sends a Join response.
4. AP does a sequence of Stores to JP = to give it the data it will need.
5. AP does Updates to JP to tell = it about its own routing table.
6. JP SHOULD send a series of Attach = requests to form connections to peers that make up its neighbor table as = well as the desired 16 finger table entries.

Julian

= >
> --Michael
>
> -------- Original Message = --------
> Subject: Re: [P2PSIP] Draft-06 section 9.4 needs = work
> From: jc <julian@orchidseed.org> > Date: Sat, November 21, 2009 11:16 am
> To: Michael Chen = <michaelc@idssoftware.com&= gt;
>
> Attach messages are routed through the overlay = where pings are not.
>
> A ping actually tests the path = while Attach does not.
>
> Also the wording changes break = further 9.* sections. For instance 9.6.1 states "this peer should behave = as if it is joining the network and use pings to find a peer and send it = a Join".
>
> It's clearly not defined correctly as is = however. A ping is error prone unless you've already Attached due to = possible NAT. While an Attach will reach any node that is inside the = ring a ping will not.
>
> Julian
>
> Sent = from my iPhone
>
> On Nov 21, 2009, at 12:42 PM, "Michael = Chen" <michaelc@idssoftware.com&= gt; wrote:
>
>> Hi,
>>
>> = Draft-06 Section 9.4 is dated and needs work.
>>
>> = 2. JP SHOULD use a series of Pings to populate its routing table.
= >> 3. JP SHOULD send Attach requests...
>> 4. JP MUST = enter all the peers it has contacted into its routing
>> = table.
>>
>> Section 11 provided a better method in = which Attach requests are used
>> (instead of Ping) to = discover and populate the routing table. There is
>> no need = to use Ping. Suggest using the following text:
>>
= >> 1. JP MUST connect to its chosen bootstrap node.
>> = 2. JP SHOULD send a series of Attach requests to discover and = connect
>> to peers that make up its neighbor table as well as = the desired 16
>> finger table entries. Note that this does = not populate their
>> routing tables, but only their = connection tables, so JP will not
>> get messages that it is = expected to route to other nodes.
>> 3. JP MUST enter all the = peers it has contacted into its routing
>> table and = connection table.
>> 4. JP SHOULD send a Join to its immediate = successor, the admitting
>> peer (AP) for Node-ID n. The AP = sends the response to the Join.
>> 5. AP MUST do a series of = Store requests to JP to store the data
>> that JP will be = responsible for.
>> 6. AP MUST send JP an Update explicitly = labeling JP as its
>> predecessor. At this point, JP is part = of the ring and
>> responsible for a section of the overlay. = AP can now forget any
>> data which is assigned to JP and not = AP.
>> 7. AP MUST send an Update to all of its neighbors with = the new
>> values of its neighbor set (including JP).
= >> 8. JP SHOULD send Updates to all the peers in its routing = table.
>>
>> In order to populate its neighbor = table, JP n sends an Attach via the
>> bootstrap node directed = at Node-ID n+1 (directly after its own Node-ID).
>> This = allows it to discover its own successor. Call that node s0. It
= >> then sends an Attach (via the bootstap peer or s0) to s0+1 to = discover
>> its second successor (s1). This process can be = repeated to discover as
>> many successors as desired. The = predecessors of JP will be found at a
>> later stage when JP = receives an Update.
>>
>> In order to set up its = finger table entry i, JP simply sends an Attach
>> to peer = (n+2^(numBitsInNodeId-i). This will be routed to a peer in
>> = approximately the right location around the ring.
>>
= >> The joining peer MUST NOT send any Update message placing = itself in
>> the overlay until it has successfully completed = an Attach with each
>> peer that should be in its neighbor = table.
>>
>>
>> Thanks
>>
= >> --Michael
>>
>>
>> = _______________________________________________
>> P2PSIP = mailing list
>> P2PSIP@ietf.org
>> https://www.ietf.org= /mailman/listinfo/p2psip

=

=
=
= --Apple-Mail-4--616913884-- From davidbryan@gmail.com Wed Nov 25 10:48:55 2009 Return-Path: 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 71AA63A67A2 for ; Wed, 25 Nov 2009 10:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.937 X-Spam-Level: X-Spam-Status: No, score=-0.937 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ype7+wJc47hc for ; Wed, 25 Nov 2009 10:48:54 -0800 (PST) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id B0AF23A6AF0 for ; Wed, 25 Nov 2009 10:48:54 -0800 (PST) Received: by ywh15 with SMTP id 15so7523065ywh.5 for ; Wed, 25 Nov 2009 10:48:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=i9Q8kq31MjRowDW67Hx2qBIwwZ4tQHJ1fBaTpdPfYmw=; b=qWm339kzPYkKSxZ4VqQBKpukRRRdIOJsNjmMMy8/u2yudKgiTzSM4CL16EWdsRQc1H YxSTEYXdHy7tZZyFPZMgORNvXBvs9/TS3Ip2Ba4pOLd/Xlgq/FuHDUDXPkMMzLffy3Wu FGSPVQMBPneWv49mW49ol0hNOiA07JtCd502M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=kVXU8HGFGPW2smLBkFGf2Qe4S1fAfr8kaqj4hgHr+VpeEa6FCljzcWotO+ifRAfpZe n38ydLa96Zjhnv6cpZDaS1PGHE6K1nAe8pu5PlqWAgONYYSVJqGIHxFwXyeU2Sx2OFKI +t7em3Y7oQbzOj0wouItVJVxIcxzLhFH9AOPQ= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.112.39 with SMTP id k39mr14206686ybc.157.1259174926075; Wed, 25 Nov 2009 10:48:46 -0800 (PST) In-Reply-To: <8b2769930911151220r372f019es3ea5384eaa999c25@mail.gmail.com> References: <8b2769930911151220r372f019es3ea5384eaa999c25@mail.gmail.com> Date: Wed, 25 Nov 2009 13:48:46 -0500 X-Google-Sender-Auth: d82a6ecae72de630 Message-ID: <8b2769930911251048l3cc3cd53h610df4d1f066fee1@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG , Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [P2PSIP] List followup of meeting consensus: Hums on 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:48:55 -0000 Just wanted to follow up that the list comments support the consensus of the room that the group feels there should be a charter item for self-tuning. Thanks. David (as chair) On Sun, Nov 15, 2009 at 3:20 PM, David A. Bryan wrote: > In the meeting at IETF-76 in Hiroshima, the group was asked to hum on: > > Does the group feel there should be a charter deliverable to address > the self-tuning problem. > > There was hum called in support of doing so. > > A second hum was asked, noting that there were few who had read it and > it was preliminary, but to see if there was a feeling that draft > draft-maenpaa-p2psip-self-tuning-01 was a good input toward a charter > deliverable to work in this area, please hum. > > There was a quiet but hum in support. > > We would like to confirm these hums on the mailing list. Please > comment on these hums. > > David (as chair) > From davidbryan@gmail.com Wed Nov 25 10:51:09 2009 Return-Path: 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 2C7C23A6B15 for ; Wed, 25 Nov 2009 10:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 gLyPwNFUVYr3 for ; Wed, 25 Nov 2009 10:51:08 -0800 (PST) Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 13D193A6B12 for ; Wed, 25 Nov 2009 10:51:07 -0800 (PST) Received: by gxk28 with SMTP id 28so7148215gxk.9 for ; Wed, 25 Nov 2009 10:51:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=7M05ubBJ3nxVKl6RUfex9DqebTi9eVHWCxUNzGhcmFo=; b=ul8eZabcrTumfwfLmwfNtcQ1wk1Lpw8Wq3ab7YYid2ZiZ6tqEMRI/kO03UAePlEWCt GIIM96okPxwoKDncn2Mn84FuTJCc1WYUTUr1bg6m8iqx9GYs2fsZIOU8nkk96jU6n/Cd 01Yui9PgEmrHUr2WNzuvoimDyHkxzXrr9Fdxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=wUkcZZ+cqdq1rWB13Lr6dhxQTz6gP1srRS3XQpc+4hqlRnpyd526KV55O+vjYjX62P hVgs9ccsrKuV03rg0Y3Gk4Y5TCitnFn20UMUAEafWFUEMzrIs+uGcfa6dONFzoPlQq6g wJNnrlf9zHwmvSkFrKGRlClwjvt4KR52h2uJE= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.6.32 with SMTP id 32mr14224076ybf.114.1259175059373; Wed, 25 Nov 2009 10:50:59 -0800 (PST) In-Reply-To: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> References: <8b2769930911151225w33febd63r1978795922d3aeea@mail.gmail.com> Date: Wed, 25 Nov 2009 13:50:59 -0500 X-Google-Sender-Auth: 08173ac5491de808 Message-ID: <8b2769930911251050r1f088139lfa3840e90a160b96@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG , Brian Rosen Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [P2PSIP] List followup of meeting consensus: Interest in generic service discovery X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:51:09 -0000 ...and here it also seems that the list comments are supportive of the him and moving forward on generic service discovery as well. Thanks. David (as chair) On Sun, Nov 15, 2009 at 3:25 PM, David A. Bryan wrote: > In the meeting at IETF-76 in Hiroshima, the group was asked to hum on: > > Should there be a milestone to have a generic service discovery > mechanism for the work in P2PSIP? > > There was some interest, but it was labeled as lukewarm, and not > consensus by the guest chairs. However, there was agreement to take > this discussion to the list. > > We would like to discuss this hum on the mailing list. Please comment > on this hum. > > David (as chair) > From jouni.maenpaa@ericsson.com Fri Nov 27 02:49:56 2009 Return-Path: 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 8D2433A6A16 for ; Fri, 27 Nov 2009 02:49:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] 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 Gcd2yWrENeok for ; Fri, 27 Nov 2009 02:49:54 -0800 (PST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 870063A6A15 for ; Fri, 27 Nov 2009 02:49:53 -0800 (PST) X-AuditID: c1b4fb3e-b7b33ae0000045f9-44-4b0faeca10d9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 49.75.17913.ACEAF0B4; Fri, 27 Nov 2009 11:49:46 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 11:49:17 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Nov 2009 11:49:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A1AA624FF; Fri, 27 Nov 2009 12:49:16 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 67C8221A21; Fri, 27 Nov 2009 12:49:16 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B6B5B21A20; Fri, 27 Nov 2009 12:49:15 +0200 (EET) Message-ID: <4B0FAEAC.40104@ericsson.com> Date: Fri, 27 Nov 2009 12:49:16 +0200 From: =?windows-1252?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "David A. Bryan" , Brian Rosen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 27 Nov 2009 10:49:17.0026 (UTC) FILETIME=[442B2C20:01CA6F4F] X-Brightmail-Tracker: AAAAAA== Cc: "p2psip@ietf.org" Subject: [P2PSIP] Review of RELOAD base draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 10:49:56 -0000 Hi, I volunteered to review the RELOAD base draft in the P2PSIP session in IETF 76. My collegue Ari Keranen also volunteered after the IETF meeting. Since it's a long draft, we decided to do the review together. Our comments are listed below. Cheers, Jouni Maenpaa Ari Keranen Page 13, Section “1.2.1. Usage Layer” The text talks about the abstract Message Transport API. Could the functionality that the API provides be described somewhere in more detail? Page 17, Section “2. Terminology” (1) There are some terms marked with a (*) that are new and “perhaps should be added to the concepts document”. I suppose a decision needs to be made whether to have the terms permanently in the base draft or whether to move them to the concepts draft. (2) Should the terms Kind and Kind-ID be defined here? Page 22, Section “3.2.1. Client Routing” (1) “Note that clients that choose this option MUST process Update messages from the peer. Those updates can indicate that the peer no longer owns the Client's Node-ID.” Should the content of these Update requests be defined somewhere in the draft or are the regular Updates enough for doing this? (2) If I have understood correctly, a peer does not know whether a particular node in its connection table is a peer or a client. Therefore, it has to send stabilization messages (i.e., Updates) to all nodes in its connection table. The cost of this can be very high in overlays experiencing churn. I have more comments on this topic later (in the comments I have for section 9). If a peer could know which nodes in the connection table are clients and which are peers, Updates could be sent only to those nodes (i.e., clients) that need to be informed immediately (peers are informed through the periodic stabilization process so there is no need to send a reactive Update). (3) The description of the second routing option by which a client may be located in an overlay contains the following text: “The Destination List required to reach it [the client] must be learnable via other mechanisms, such as being stored in the overlay by a usage...” Since this alternative is given in the base draft, should the base draft also describe the usage for storing Destination Lists? Without such a usage, the second routing option is not really usable. (4) Should the overlay configuration document contain information about which client routing mode is used in the overlay? Page 22, Section “3.2.2. Minimum Functionality Requirements for Clients” “Implement RELOAD's connection-management connections” What are connection-management connections? Page 23, Section “3.3. Routing” “Client promotion: RELOAD must support clients that become peers at a later point as determined by the overlay algorithm and deployment.” Should client promotion be described somewhere in the base draft? Page 27, step (4) of the second operation required to join the overlay “AP does Updates to JP and to other peers...” Doing this is probably ok in a small and low-churn network (i.e., in cases when it is ok to use reactive stablization). However, in a larger, higher-churn overlay (in which periodic stabilization would be used instead of reactive stabilization), sending Updates to all peers in the AP's connection (or routing/neighbor) table might be too expensive. Such Updates may not be needed since the other peers will learn about the JP through the periodic stablization process. Page 32, Section “4.3. Application Connectivity” “Each usage specifies which types of connections can be initiated using AppAttach.” Should this requirement be listed also in Section “4.1.2. Usages”? Page 36, third paragraph (1) “When an originating node transmits a requests it MUST set a 3 second timer” Should the value of the timer be configurable? (2) Should there be a back-off mechanism for the retransmissions? (3) “If a response has not been received when the timer fires, the request is retransmitted...” How is this related to the procedures in Section “5.6.2. Reliability for Unreliable Links”? Is it intentional that both the originator of the request and the intermediate peers retransmit the messages? (4) “The request MAY be retransmitted up to 4 times...” Should the maximum number of retransmissions be configurable? When should one use less than four retransmissions? (5) The P2PP protocol had a pretty nice way of describing the transaction state machines, including the various timers and retransmissions (see http://tools.ietf.org/id/draft-baset-p2psip-p2pp-01.txt, figures 8-11). I would like to see similar diagrams in the RELOAD base draft as well. This would be very helpful when implementing RELOAD. P2PP also specified different state machines for reliable and unreliable transports. This could be done in the RELOAD base draft as well. Page 36, fourth paragraph “the maximum request lifetime (15s)” Should the maximum request lifetime be configurable? Page 38, first paragraph There is an open question: “We consider it an open question what the final protocol definition method and encodings use.” I suppose this open question can be removed. Page 38 (1) “Note: the use of "typedef" here is an extension to the TLS language, but its meaning should be relatively obvious” Perhaps it would be a good idea to explain the meaning anyway. (2) Is an opaque string of bytes always preceded by one or more length bytes like in case of ResourceID? Could you clarify this in the draft (it is currently not very clear)? Page 41, “version” field in the forwarding header Just wanted to verify that it is intentional to still use version 0.1. Page 42, Section “5.3.2.1. Processing Configuration Sequence Numbers” (1) Is the Config_Update request sent on a direct connection or across the overlay? If it is sent across the overlay via multiple hops, then it can cause additional load at intermediate peers. The Config_Update request may also be considerably larger than other requests sent in the overlay, because the configuration document can be rather large.. I would like to see some additional discussion on the traffic load the proposed mechanism can cause. If the configuration documents propagate very quickly throughout the system, then there might be a considerable short-term traffic peak. Perhaps there is a need for a mechanism that can limit the additional traffic caused by Config_Update requests. (2) As an optimization, intermediate peers could potentially inspect the configuration documents in the Config_Update messages they forward and update their own configuration settings if they see a newer document. However, I am not sure whether this would reduce the load enough. Page 46 Where is the format of the MessageCode defined? Page 48, definition of error_info What is the format of the text string? UTF-8? Page 52, Section “5.4.1. Topology Plugin Requirements” (1) “All overlay algorithms MUST specify maintenance procedures that send Updates to all members of the Connection Table whenever the range of Ids for which the peer is responsible changes” Doesn't this mean that all overlay algorithms are mandated to use reactive stablization? I would rephrase this to something like “All overlay algorithms MUST specify maintenance procedures.”, that is, not mandate reactive Updates. (2) Further, sending to all members of the Connection Table might be an overkill. Wouldn't it be enough to send only to the peers in the Neighbor set (provided that the overlay algorithm that is used maintains such a set)? Page 54, Section “5.4.2.3. Update” (1) “In general, peers MUST send Update messages to all their adjacencies whenever they detect a topology shift” Again, the draft is mandating the use of reactive stablization. So I guess this sentence should be removed. Alternatively, the MUST could be changed to MAY. (2) “The UpdateAns response is expected to be either success or an error” I think that in some cases, it might be beneficial to have some content in the UpdateAns response (e.g., routing table entries). Therefore, I think the draft should make it possible for UpdateAns responses to contain overlay-specific data (in the same way it allows this for UpdateReq requests). Page 59, AttachReqAns struct Is the “role” encoded as a string? Wouldn't an enum be sufficient? Page 60, definition of “rel_addr_port” “corresponds to the rel-addr and rel-port productions. Only present for type "relay".” Should this be present also for srflx and prflx types as in the struct on the previous page? Page 61, Section “5.5.1.3. Using ICE With RELOAD” “Because RELOAD always tries to use TCP and then UDP as a fallback [...]” Is this normative? Can't a peer prefer UDP? Page 70, Section “5.5.6.2. Response Definition” “If the Config_UpdateReq is of type “kind” it MUST only be processed if it is correctly digitally signed by an acceptable kind signer.” Could you define what an “acceptable kind signer” is here? Perhaps I missed something, but this was unclear to me. Page 73, Section “5.6.2.2. Retransmission and Flow Control” This section mentions multiple alternatives for the retransmission and congestion control scheme. Should all the peers in the overlay use the same retransmission and congestion control scheme? In that case, the scheme to use should probably be specified in the overlay configuration document. Page 82, text about replica numbers “If the replica number is zero, then the peer MUST check that it is responsible for the resource and, if not, reject the request. If the replica number is nonzero, then the peer MUST check that it expects to be a replica for the resource and that the request sender is consistent with being the responsible node (i.e., that the receiving peer does not know of a better node) and, if not, reject the request.” This text may assume too much about the replication strategy that is being used. As far as I know, in some replication strategies (e.g., multi publication key replication), a peer storing a replica may not be able to check whether it is supposed to store a replica (in the successor replication strategy that RELOAD uses, this can be done by checking the predecessor list). Therefore, I think this text should be made more generic so that it allows the use of other replication strategies. Page 96, Section “8. TURN Server Usage” Perhaps there could be some additional text in this section stating that the overlay MAY use an alternative, more advanced service discovery mechanism for locating TURN servers if such a mechanism is available. Pages 97-98, Section “9. Chord Algorithm” (1) One additional major difference to the original Chord algorithm that should be mentioned here is that chord-reload can optionally use reactive stabilization. The original Chord algorithm does not use reactive stablization but only periodic stabilization. One could also explain why reactive stabilization is allowed in chord-reload (i.e., that it has been shown to work well in small, low-churn overlays). One should also add some information about previous results, which have shown that reactive recovery can result in degraded performance or even congestion collapse in large-scale (1000 peers or more) overlays experiencing moderate or high levels of churn. Results proving that reactive recovery is not optimal in such networks are available in [1]. (2) It should also be mentioned in here that reactive stabilization MAY be disabled in chord-reload (the “if using reactive recovery” statements in the text actually allow this). In this case, only periodic stabilization is used. Use of periodic stabilization is more appropriate in large-scale (1000 peers or more) overlays experiencing churn. Page 98, Section “9.1. Overview” (1) “The neighbor table typically contains the three peers before this peer and the three peers after it in the DHT ring” The draft should state here that the successor list and the predecessor list can contain more entries if necessary. The Chord paper [2] states that O(log2(N)) successors should be maintained to increase robustness. Maintaining three successors is sufficient in very small overlays. However, in a Chord ring with for instance 1000 peers, on the order of 10 successors should be maintained to make the system more robust. Perhaps the number of predecessors and successors to maintain should be made configurable? (2) “There may not be three entreis...” => “There may not be three *entries*...” Page 99, Section “9.3. Redundancy” (1) “When a peer receives a Store request for Resource-ID k, and it is responsible for Resource-ID k, it stores the data and returns a success response. It then sends a Store request to its successor in the neighbor table and to that peer's successor.” I would expect that in large-scale overlays experiencing churn, it may be necessary to store more than 2 replica copies. Perhaps the number of replicas to store should be configurable (of course the size of the neighbor table limits the number of replicas that can be stored). (2) This section is missing details on when replicas can be removed and when the replicating peer needs to store further replicas. Those details are specified in the end of Section “9.6.3. Receiving Updates”. Could those details be moved to Section 9.3? Page 99, Section “9.4. Joining” (1) “3. JP SHOULD send Attach requests to initiate connections to each of the peers in the neighbor table as well as to the desired 16 finger table entries.” Should it be mentioned here that also finger tables having more than 16 entries are allowed? Perhaps the number of fingers to maintain should be made configurable. (2) “8. AP MUST send an Update to all its neighbors with the new values of its neighbor set (including JP).” Informing all the neighbors of the AP may be unnecessary if periodic recovery is being used. Could this sentence be modified as follows: “8. If using reactive recovery, the AP MUST send an Update...” If periodic recovery is used, then peridic stabilization will take care of informing the neighbors of the AP that a new peer has joined. (3) “In order to set up its neighbor table entry for peer i...” I guess this should be “In order to set up its finger table entry for peer i...” Page 102, Section “9.6.1. Handling Neighbor Failures” (1) This section and many other subsections contain statements like this: “If using reactive recovery...” I think it should be stated explicitly somewhere (in the beginning of Section 9, as I am suggesting above) that reactive recovery can be disabled, in which case only periodic recovery is used. (2) Should the overlay configuration document indicate whether reactive recovery is used or not in the overlay? Page 104, second paragraph “If peer N which is responsible for a Resource-ID R discovers that the replica set for R (the next two nodes in its successor set)...” Same comment as before: perhaps replica sets consisting of more than two nodes shoud be allowed. Page 104, Section “9.6.4.1. Updating Neighbor Table” (1) “A peer MUST periodically send an Update request to every peer in its Connection Table” Should “Connection Table” be rather “Neighbor Table”? Sending to every peer in the Connection Table means that an Update is sent also to the fingers (i.e., at the very minimum to 3+3+16=22 peers, to all the clients attached to the peer, and also to all of the peers that are in the connection table but not in the routing table; such as peers that are using this peer as a finger). This may cause too much traffic. Note that the original Chord algorithm sends only an Update to the first predecessor and to the first successor. I would rephrase this to something like: “A peer MUST periodically send an Update request to all or a subset of the peers in its neighbor table” (2) “The default time is about every ten minutes.” This is not sufficient in large-scale networks experiencing churn. However, it may be sufficient in small-scale, low-churn overlays in which reactive recovery is used. Therefore, I would modify this as follows: “If reactive recovery is used, the default time is about every ten minutes.” Page 104-105, Section “9.6.4.2. Refreshing finger table” (1) “A peer SHOULD NOT send Ping requests looking for new finger table entries more often than the configuration element “chord-reload-ping-interval”, which defaults to 3600 seconds (one per hour)”. This is not sufficient in large-scale networks experiencing churn. However, it may be sufficient in small-scale, low-churn overlays in which reactive recovery is used. Therefore, I would modify this as follows: “A peer SHOULD NOT send Ping requests looking for new finger table entries more often than the configuration element “chord-reload-ping-interval”. If reactive recovery is used, this defaults to 3600 seconds (one per hour).” (2) Paragraph 4 on page 105 describing Alternative 2: I would add a warning here stating that Alternative 2 should only be used in small-scale, low-churn overlays because it can cause much more traffic than Alternative 1. Alternative 1 is more appropriate for large-scale overlays experiencing churn. Page 112, last paragraph of Section 10.1. “When a node receives a new configuration file, it MUST change its configuration to meet the new requirements. This may require the node to exit the DHT and re-join.” Exiting and re-joining as a result of receiving a new configuration file is potentially a huge problem. If the configuration file spreads rapidly in the overlay, there is a short period of time during which all the peers will exit and re-join. The resulting churn will most probably be so high that the network will collapse. Page 138, Section “15.2. Informative References” [I-D.maenpaa-p2psip-self-tuning]: there is a newer version of the draft available: [I-D.maenpaa-p2psip-self-tuning] Maenpaa, J., Camarillo, G., and J. Hautakorpi, "A Self- tuning Distributed Hash Table (DHT) for REsource Location And Discovery (RELOAD)", draft-maenpaa-p2psip-self-tuning-01 (work in progress), October 2009. ==== Nits ==== Node-ID is sometimes spelled as “Node-Id” and sometimes as “Node-ID”. Further, sometimes "Peer-ID" or "peer ID" is used. Page 10, Section “1.2. Architecture” “RELOAD is fundamentally an overlay network” I guess it would be better to say “The RELOAD network is fundamentally an overlay network” to be consistent with the text in the previous subsection. Page 12, last paragraph “the roles of various layer” => “the roles of various *layers*” Page 13, the figure There seem to be some indentation issues in the figure. Page 25 “RELOAD does not support an intermediate peer returning a response that it will not recursively route a normal request” Is something missing from this sentence? Page 35, Section “5.2.1 Request Origination” “The simplest such destination list is a single entry containing the peer or Resource-ID.” => “The simplest such destination list is a single entry containing the *Node*-ID or Resource-ID.” Page 43, Section 5.3.2.2 enum DestinationType uses term “node”, whereas the definition of “type” on the following page uses “peer”. Page 44, definition of “type” Could you open the acronym PDU? Page 58, Section “5.5.1. Attach”, first paragraph “A node sends an Attach request when it wishes to establish a direct TCP or UDP connection...” Should this be “a direct TLS or DTLS connection...”? Page 66, row 6 “Check the certificate receive in...” => “Check the certificate *received* in...” Page 74, first paragraph “...if it is known that all nodes are are...” => “...if it is known that all nodes *are*...” Page 102, the description of the “fingers” field: “The finger table if the Updating peer...” => “The finger table *of* the updating peer...” Page 111, definition of “multicast-bootstrap” “This element represents the address of a multicast, boradcast...” => “This element represents the address of a multicast, *broadcast*...” Page 116, second last paragraph of Section 10.3. “...and have appropriate HTTP stats codes.” => “...and have appropriate HTTP *status* codes.” Page 124, Section “12.4. Certificate-based Security” (1) “The user is also assigned one or more Node-IDs by the central enrollment authority. Both the name and the peer ID are placed in the certificate,...” => “The user is also assigned one or more Node-IDs by the central enrollment authority. Both the name and the *Node-ID* are placed in the certificate,...” (2) “o As a overlay peer with the peer ID(s)...” => “o As a overlay peer with the *Node-ID(s)*...” Page 137, Section “14. Acknowledgments” “Hautakorp” => “Hautakorpi” Page 143, “Appendix B. AIMD Retransmission Scheme” “...and is based on the theAIMD...” => “...and is based on *the AIMD*...” [1] Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, "Handling churn in a DHT", In Proc. of the USENIX Annual Techincal Conference June 2004. [2] Stoica, I., Morris, R., Liben-Nowell, D., Karger, D., Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications", IEEE/ACM Transactions on Networking Volume 11, Issue 1, 17-32, Feb 2003.