From melodysong@huawei.com Sun May 3 20:39: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 E4BC83A6FAE for ; Sun, 3 May 2009 20:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, 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 d8y4lPmV1lns for ; Sun, 3 May 2009 20:39:02 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 593643A6856 for ; Sun, 3 May 2009 20:39:00 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ3004O3OUZQL@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 04 May 2009 11:40:12 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KJ300KTIOUZKB@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 04 May 2009 11:40:11 +0800 (CST) Received: from s64081 ([10.164.12.17]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KJ3009QBOUYE8@szxml06-in.huawei.com> for p2psip@ietf.org; Mon, 04 May 2009 11:40:11 +0800 (CST) Date: Mon, 04 May 2009 11:40:10 +0800 From: Song Haibin In-reply-to: To: "'Narayanan, Vidya'" , 'Cullen Jennings' Message-id: <010201c9cc6a$069c3530$110ca40a@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: Acm6G+lVdXOAREs4Tf2SLT4FH5N6fAEncxOwA2uXz+A= Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Access control rule in RELOAD to support generic keyword-like storage 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, 04 May 2009 03:39:10 -0000 I think access control is useful and I prefer approach b. If this could be done somewhere, I think some kind of change track could be useful so that you can know who updated the record for each time. Thanks! Haibin >-----Original Message----- >From: p2psip-bounces@ietf.org [mailto:p2psip-bounces@ietf.org] >On Behalf Of Narayanan, Vidya >Sent: Friday, April 17, 2009 1:46 AM >To: Cullen Jennings >Cc: p2psip@ietf.org >Subject: Re: [P2PSIP] Access control rule in RELOAD to support >generic keyword-like storage > >Cullen, >I'm okay going with option b you mention below. I think >disambiguating node and user ids might be useful. >And, I >don't think it is unreasonable to limit future updates to >using the same id that was used at the time of creation. > Could you give an example for this, esp. for sip usage? I have some vague use cases in mind, but they are not related to the sip usage. -Haibin >Cheers, >Vidya > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Friday, April 10, 2009 1:34 PM >> To: Narayanan, Vidya >> Cc: p2psip@ietf.org >> Subject: Re: [P2PSIP] Access control rule in RELOAD to >support generic >> keyword-like storage >> >> >> Vidya, I like this and think we should add it to the draft but one >> question. I worry about it being a bit vague of it if is a >> certificate with same user id or node id that is allowed to do an >> update. I think we need to do one of two things >> >> a) define this so the nodeid and userid are stored and a certificate >> that matches either the nodeid or userid is allowed ot update >> >> b) define two new rules here, one that requires the node-id to match >> and ones that requires the userid to match. So we would have >something >> like NO-MATCH-CREATE-WITH-RESTRICTED-NODE-UDPATE >> and >> NO-MATCH-CREATE-WITH-RESTRICTED-USER-UDPATE >> >> I'd probably prefer approach b to aproach a but don't feel strongly >> either way. >> >> Thougths? >> >> Cullen, in my individual contrubotro role >> >> >> On Mar 22, 2009, at 8:31 PM, Narayanan, Vidya wrote: >> >> > In addition to the access control rules defined in section 6.3 of >> > the draft, I think there is a need for a rule, where any node is >> > allowed to write to a Resource ID, but, only the creator >is allowed >> > to modify or overwrite the entry by default. This allows for >> > generic keyword-like storage on the overlay which will >eventually be >> > needed to support various types of kinds and usages on the overlay >> > effectively. The notion here is that no authorization is >needed on >> > the Resource ID, but access control is applied to the data >> > operations, once it exists. Here is suggestive text for supporting >> > this: >> > >> > "6.3.6. NO-MATCH-CREATE-WITH-RESTRICTED-UDPATE >> > >> > This policy allows storage of data with no constraints on >choosing a >> > Resource ID. However, by default, only the creator of the >entry is >> > allowed to modify or overwrite the stored data once created. The >> > user name and/or node id present in the certificate of the >> > requesting node MUST be used as the creator of the data. Upon >> > receiving a request to store, a node MUST verify if it already has >> > an entry present for the particular kind and Resource ID >> > corresponding to the same user name or node id that is >contained in >> > the Store Request. If so, the received Store Request MUST be >> > treated as an update to the existing data and the >appropriate checks >> > as described in section 6.4 must be applied. If no corresponding >> > match is found, the StoredData contained in the Store Request >> > message MUST be stored as a new entry in accordance with section >> > 6.4. This rule is useful for generic keyword-like storage on the >> > overlay, which is likely to be useful for several classes of >> > applications that may b e defined for use with RELOAD. The access >> > control allows ensuring that the data created by a given >node is not >> > randomly overwritten by any other node." >> > >> > It may be good to include the Resource Name in the StoredData >> > structure as well. This will allow the storing node to >more easily >> > create an index of the resources it is storing, which can then be >> > used for retrieval of data. However, I think it will work even >> > without it - I'm looking for other thoughts on this. >> > >> > Thanks, >> > Vidya >> > _______________________________________________ >> > 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 hocs@itri.org.tw Mon May 4 01:14: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 29A5B3A6976 for ; Mon, 4 May 2009 01:14:13 -0700 (PDT) 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 xhWNlchNak3B for ; Mon, 4 May 2009 01:14:11 -0700 (PDT) Received: from maillog2.itri.org.tw (maillog.itri.org.tw [61.61.254.20]) by core3.amsl.com (Postfix) with ESMTP id 882013A67D1 for ; Mon, 4 May 2009 01:14:10 -0700 (PDT) Received: from mail.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by maillog2.itri.org.tw with ESMTP id n448FXED036981 for ; Mon, 4 May 2009 16:15:33 +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 n448FWp7005072 for ; Mon, 4 May 2009 16:15:33 +0800 (CST) Received: from ms33.itri.org.tw (ms33.itri.org.tw [140.96.151.30]) by mail.itri.org.tw (8.13.4/8.13.4) with ESMTP id n448FWR7005069 for ; Mon, 4 May 2009 16:15:32 +0800 (CST) Received: from 52092035394 ([140.96.151.160]) by ms33.itri.org.tw (Lotus Domino Release 7.0.3FP1) with ESMTP id 2009050416153144-4453 ; Mon, 4 May 2009 16:15:31 +0800 From: "JeffreyHo" To: Date: Mon, 4 May 2009 16:15:28 +0800 Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnMkHvagYrfCbNqS0WSJD9dvMGHRQ== X-MIMETrack: Itemize by SMTP Server on MS33/ITRI(Release 7.0.3FP1|February 24, 2008) at 2009-05-04 16:15:31, Serialize by Router on MS33/ITRI(Release 7.0.3FP1|February 24, 2008) at 2009-05-04 16:15:32, Serialize complete at 2009-05-04 16:15:32 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0083_01C9CCD3.8CCD7290" X-MAIL: maillog2.itri.org.tw n448FXED036981 Subject: [P2PSIP] question about discovery through enrollment server 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, 04 May 2009 08:14:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0083_01C9CCD3.8CCD7290 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Dear all, I have some questions about the content of 10.2 discovery through enrollment server in RELOAD Base. Could someone please give me answer? (1) According to the following paragraphs in 10.2. Discovery Through Enrollment Server, The peer first determines the overlay name. This value is provided by the user or some other out of band provisioning mechanism. If the name is an IP address, that is directly used otherwise the peer MUST do a DNS SRV query using a Service name of "p2p_enroll" and a protocol of tcp to find an enrollment server. Is the overlay name here equivalent to the attribute 'instance-name' in the overlay configuration? If yes, but why this paragraph say " If the name is an IP address, that is directly used "? It seems the name means the location of the enrollment server not overlay instance-name. It makes me confused. (2) According to 10.1. Overlay Configuration, it said that The file can contain multiple "configuration" elements where each one contains the configuration information for a different overlay. In addition, in 10.2. Discovery Through Enrollment Server, it said that the peer performs a GET to the URL formed by appending a path of "/p2psip/enroll" to the overlay name. For example, if the overlay name was example.com, the URL would be "https://example.com/p2psip/enroll". My question is below. If an single enrollment server maintains two different overlays, named exam1.com and exam2.com, which have two separated "configuration" elements in the same overlay configuration file, this single enrollment server must be able to accept the GET request both https://exam1.com/p2psip/enroll and https://exam2.com/p2psip/enroll" from some peers for different overlay. Is such concept right? If right, how does this enrollment sever be implemented? Any comment and answer will be appreciated. Thanks a lot in advance. BR, Jeffrey %;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C 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_0083_01C9CCD3.8CCD7290 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="big5" [P2PSIP] question about discovery through enrollment server

Dear all,

I have some questions about= the content of 10.2 discovery through enrollment server in RELOAD Base.= Could someone please give me answer?

(1) According to the following= paragraphs in 10.2.  Discovery Through Enrollment Server,

   The peer first= determines the overlay name. This value is provided
   by the user or= some other out of band provisioning mechanism. 
   If the name is= an IP address, that is directly used otherwise the peer
   MUST do a DNS= SRV query using a Service name of "p2p_enroll" and
   a protocol of= tcp to find an enrollment server.

Is the overlay name here= equivalent to the attribute 'instance-name' in the overlay configuration?= If yes, but why this paragraph say " If the name= is an IP address, that is directly used "? It seems the name means= the location of the enrollment server not overlay instance-name. It makes= me confused.

(2)= According to 10.1. Overlay Configuration, it said that The file can= contain multiple "configuration" elements where each one= contains the configuration information for a different overlay.  In= addition, in 10.2.  Discovery Through Enrollment Server, it= said that the peer performs a GET to the URL formed by appending a path of= "/p2psip/enroll" to the overlay name.  For example, if the= overlay name was example.com, the URL would be "https://example.com/p2psip/enroll".

My= question is below.
If an= single enrollment server maintains two different overlays, named exam1.com= and exam2.com, which have two separated "configuration" elements= in the same overlay configuration file, this single enrollment server must= be able to accept the GET request both https://exam1.com/p2psip/enroll and https://exam2.com/p2psip/enroll" from some peers for different overlay. Is such concept= right? If right, how does this enrollment sever be= implemented?

Any= comment and answer will be appreciated.
Thanks a= lot in advance.

BR,
Jeffrey

=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_0083_01C9CCD3.8CCD7290-- From glitch@me.com Mon May 4 02:16:42 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 1D9343A6F71 for ; Mon, 4 May 2009 02:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.391 X-Spam-Level: X-Spam-Status: No, score=0.391 tagged_above=-999 required=5 tests=[AWL=-2.061, BAYES_50=0.001, 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 WZJnemDY1TNw for ; Mon, 4 May 2009 02:16:34 -0700 (PDT) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by core3.amsl.com (Postfix) with ESMTP id 09C9F3A6F5A for ; Mon, 4 May 2009 02:15:45 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_3bXZ6BruRT+W7IZZkNemjQ)" Received: from [10.0.1.6] (ip68-5-31-14.oc.oc.cox.net [68.5.31.14]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KJ400LWJ4GMPB30@asmtp017.mac.com> for p2psip@ietf.org; Mon, 04 May 2009 02:17:10 -0700 (PDT) Message-id: <34538940-41B0-414C-BA17-11642CDC54E5@me.com> From: glitch To: JeffreyHo In-reply-to: Date: Mon, 04 May 2009 02:17:09 -0700 References: X-Mailer: Apple Mail (2.930.4) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] question about discovery through enrollment server 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, 04 May 2009 09:16:42 -0000 --Boundary_(ID_3bXZ6BruRT+W7IZZkNemjQ) Content-type: text/plain; charset=BIG5; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable 1. The "overlay name" is described in = http://tools.ietf.org/html/draft-hardie-p2poverlay-pointers-00=20 . 2. One Web server with two domains setup and with web-service's for =20 enrollment or any combination thereof. glitch On May 4, 2009, at 1:15 AM, JeffreyHo wrote: > Dear all, > > I have some questions about the content of 10.2 discovery through =20 > enrollment server in RELOAD Base. Could someone please give me answer? > > (1) According to the following paragraphs in 10.2. Discovery =20 > Through Enrollment Server, > > The peer first determines the overlay name. This value is provided > by the user or some other out of band provisioning mechanism. > If the name is an IP address, that is directly used otherwise the =20= > peer > MUST do a DNS SRV query using a Service name of "p2p_enroll" and > a protocol of tcp to find an enrollment server. > > Is the overlay name here equivalent to the attribute 'instance-name' =20= > in the overlay configuration? If yes, but why this paragraph say " =20 > If the name is an IP address, that is directly used "? It seems the =20= > name means the location of the enrollment server not overlay =20 > instance-name. It makes me confused. > > (2) According to 10.1. Overlay Configuration, it said that The file =20= > can contain multiple "configuration" elements where each one =20 > contains the configuration information for a different overlay. In =20= > addition, in 10.2. Discovery Through Enrollment Server, it said =20 > that the peer performs a GET to the URL formed by appending a path =20 > of "/p2psip/enroll" to the overlay name. For example, if the =20 > overlay name was example.com, the URL would be = "https://example.com/p2psip/enroll=20 > ". > > My question is below. > If an single enrollment server maintains two different overlays, =20 > named exam1.com and exam2.com, which have two separated =20 > "configuration" elements in the same overlay configuration file, =20 > this single enrollment server must be able to accept the GET request =20= > both https://exam1.com/p2psip/enroll and = https://exam2.com/p2psip/enroll=20 > " from some peers for different overlay. Is such concept right? If =20 > right, how does this enrollment sever be implemented? > > Any comment and answer will be appreciated. > Thanks a lot in advance. > > BR, > Jeffrey > > =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=20 > =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 =20 > or disclose it in any way and delete it if you are not the intended =20= > recipient. > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_3bXZ6BruRT+W7IZZkNemjQ) Content-type: text/html; charset=BIG5 Content-transfer-encoding: quoted-printable 1. The "overlay name" is = described in ht= tp://tools.ietf.org/html/draft-hardie-p2poverlay-pointers-00.

=
2. One Web server with two domains setup and = with web-service's for enrollment or any combination = thereof.

glitch

On May = 4, 2009, at 1:15 AM, JeffreyHo wrote:

=

Dear all,

I have some questions about the content of = 10.2 discovery through enrollment server in RELOAD Base. Could someone = please give me answer?

(1) According to the following paragraphs in 10.2.  = Discovery Through Enrollment Server,

   The peer first determines the = overlay name. This value is provided
   by the user or some other out of = band provisioning mechanism. 
   If the name is an IP address, = that is directly used otherwise the peer
   MUST do a DNS SRV query using a = Service name of "p2p_enroll" and
   a protocol of tcp to find an = enrollment server.

Is the overlay name here equivalent to the attribute = 'instance-name' in the overlay configuration? If yes, but why this = paragraph say " If the name is an IP address, that = is directly used "? It seems the name means the location of the = enrollment server not overlay instance-name. It makes me = confused.

(2) According to 10.1. Overlay Configuration, = it said that The file can contain multiple "configuration" elements = where each one contains the configuration information for a different = overlay.  In addition, in 10.2.  Discovery Through = Enrollment Server, it said that the peer performs a GET to the URL = formed by appending a path of "/p2psip/enroll" to the overlay = name.  For example, if the overlay name was example.com, the URL = would be "https://example.com/p2psip/enroll".

My question = is below.
If an single enrollment server maintains two = different overlays, named exam1.com and exam2.com, which have two = separated "configuration" elements in the same overlay configuration = file, this single enrollment server must be able to accept the GET = request both https://exam1.com/p2psip/enroll and https://exam2.com/p2psip/enroll" from some peers for different overlay. Is = such concept right? If right, how does this enrollment sever be = implemented?

Any comment and answer will be = appreciated.
Thanks a lot in advance. =

BR,
Jeffrey

=
=A5=BB=ABH=A5=F3=A5i=AF=E0=A5]=A7t=A4u=AC=E3=B0|=BE=F7=B1= K=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.
=
_________________________________________= ______
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Boundary_(ID_3bXZ6BruRT+W7IZZkNemjQ)-- From michaelc@idssoftware.com Thu May 7 09:59:37 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 EA1793A7035 for ; Thu, 7 May 2009 09:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[AWL=-0.048, 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 iYKxe8hi4fzP for ; Thu, 7 May 2009 09:59:37 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id BBBB328C2C6 for ; Thu, 7 May 2009 09:59:35 -0700 (PDT) Received: from [64.203.45.253] (helo=[10.9.0.1]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M26xz-0007MG-Ml for p2psip@ietf.org; Thu, 07 May 2009 13:01:03 -0400 Message-ID: <4A0322A7.70609@idssoftware.com> Date: Thu, 07 May 2009 10:04:23 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940fb1d573220bab2d42b81d410c101f293350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.203.45.253 Subject: [P2PSIP] 32-bit length in ForwardingHeader of draft-ietf-p2psip-base-02 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, 07 May 2009 22:31:57 -0000 Hi, In draft-ietf-p2psip-base-02, section 5.3.2, the Forwarding Header's length field was increased from 24-bit to 32-bit from version-01. This change is unwarranted and should be reverted. 1) The maximum message size remain 24-bit (5.2.3. Message Contents Format, payload). There is no need to have a 32-bit length in the forwarding header. 2) This change throw off the alignment of all fields after 'length' in the header. They are now all start with an odd address offset, and the fixed portion of the header (up to options_length) is now an odd number. This design incurs performance penalty on many hardware, and it requires clumsy software implementation. It is just ugly. Some common sense is in order. Thanks --Michael From glitch@me.com Thu May 7 16: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 852053A6A0E for ; Thu, 7 May 2009 16:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.447 X-Spam-Level: X-Spam-Status: No, score=-1.447 tagged_above=-999 required=5 tests=[AWL=1.152, 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 W1oCVnroSlkW for ; Thu, 7 May 2009 16:44:51 -0700 (PDT) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by core3.amsl.com (Postfix) with ESMTP id B0C1C3A6DA1 for ; Thu, 7 May 2009 16:44:51 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [10.0.1.5] (ip68-5-31-14.oc.oc.cox.net [68.5.31.14]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KJA00MQUSP7LP40@asmtp019.mac.com> for p2psip@ietf.org; Thu, 07 May 2009 16:46:20 -0700 (PDT) Message-id: From: glitch To: Michael Chen In-reply-to: <4A0322A7.70609@idssoftware.com> Date: Thu, 07 May 2009 16:46:19 -0700 References: <4A0322A7.70609@idssoftware.com> X-Mailer: Apple Mail (2.930.4) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] 32-bit length in ForwardingHeader of draft-ietf-p2psip-base-02 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, 07 May 2009 23:44:52 -0000 I second this as it is also a hack in my implementation, at least IMHO. @Michael Do you have a public implementation for interoperability testing? I cannot locate one. -g On May 7, 2009, at 11:04 AM, Michael Chen wrote: > Hi, > > In draft-ietf-p2psip-base-02, section 5.3.2, the Forwarding Header's > length field was increased from 24-bit to 32-bit from version-01. > This change is unwarranted and should be reverted. > > 1) The maximum message size remain 24-bit (5.2.3. Message Contents > Format, payload). There is no need to have a 32-bit length in the > forwarding header. > > 2) This change throw off the alignment of all fields after 'length' > in the header. They are now all start with an odd address offset, > and the fixed portion of the header (up to options_length) is now an > odd number. > > This design incurs performance penalty on many hardware, and it > requires clumsy software implementation. It is just ugly. Some > common sense is in order. > > Thanks > > --Michael > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From michaelc@idssoftware.com Fri May 8 07:33:39 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 B80353A68DA for ; Fri, 8 May 2009 07:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.756, 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 IHIEMcJNw2o8 for ; Fri, 8 May 2009 07:33:39 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id EC04C3A67E1 for ; Fri, 8 May 2009 07:33:38 -0700 (PDT) Received: from [64.203.45.253] (helo=[10.9.0.1]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1M2R9y-0004mm-2F; Fri, 08 May 2009 10:34:46 -0400 Message-ID: <4A0451DD.2000704@idssoftware.com> Date: Fri, 08 May 2009 07:38:05 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: glitch References: <4A0322A7.70609@idssoftware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940896fe3d10e5c88a4f3d27baba0dafbe1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.203.45.253 Cc: p2psip@ietf.org Subject: Re: [P2PSIP] 32-bit length in ForwardingHeader of draft-ietf-p2psip-base-02 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, 08 May 2009 14:33:39 -0000 g, This thing is very much a moving target now. However, we do plan on releasing a close source free Windows binary when it levels off feature-wise. Stay tuned. --Michael glitch wrote: > I second this as it is also a hack in my implementation, at least IMHO. > > @Michael Do you have a public implementation for interoperability > testing? I cannot locate one. > > -g > > On May 7, 2009, at 11:04 AM, Michael Chen wrote: > >> Hi, >> >> In draft-ietf-p2psip-base-02, section 5.3.2, the Forwarding Header's >> length field was increased from 24-bit to 32-bit from version-01. >> This change is unwarranted and should be reverted. >> >> 1) The maximum message size remain 24-bit (5.2.3. Message Contents >> Format, payload). There is no need to have a 32-bit length in the >> forwarding header. >> >> 2) This change throw off the alignment of all fields after 'length' >> in the header. They are now all start with an odd address offset, and >> the fixed portion of the header (up to options_length) is now an odd >> number. >> >> This design incurs performance penalty on many hardware, and it >> requires clumsy software implementation. It is just ugly. Some common >> sense is in order. >> >> Thanks >> >> --Michael >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip > > > From glitch@me.com Mon May 11 00:33: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 26F033A6A84 for ; Mon, 11 May 2009 00:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 JsvLlQrg21xR for ; Mon, 11 May 2009 00:33:26 -0700 (PDT) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by core3.amsl.com (Postfix) with ESMTP id 5CB3D3A67B0 for ; Mon, 11 May 2009 00:33:26 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [10.0.1.5] (ip68-5-31-14.oc.oc.cox.net [68.5.31.14]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KJG00M10YE86400@asmtp022.mac.com> for p2psip@ietf.org; Mon, 11 May 2009 00:34:57 -0700 (PDT) Message-id: From: jolix To: Michael Chen In-reply-to: <4A0451DD.2000704@idssoftware.com> Date: Mon, 11 May 2009 00:34:56 -0700 References: <4A0322A7.70609@idssoftware.com> <4A0451DD.2000704@idssoftware.com> X-Mailer: Apple Mail (2.930.4) Cc: p2psip@ietf.org Subject: Re: [P2PSIP] 32-bit length in ForwardingHeader of draft-ietf-p2psip-base-02 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, 11 May 2009 07:33:27 -0000 M, I am implementing a cross platform C++ library which will be open source and free. Will yours be "paid" and if not then why closed source? The reason I ask is if it misbehaves with my implementation the only reaction I can take is ban it and not investigate it. Then again this all depends on if your using central or shared security model and/or support both and if I retain Chord "periodic stabilization" vs "cou" which the first creates churn even in the absense of said churn. :-) thx -g On May 8, 2009, at 8:38 AM, Michael Chen wrote: > g, > > This thing is very much a moving target now. However, we do plan on > releasing a close source free Windows binary when it levels off > feature-wise. Stay tuned. > > --Michael > > glitch wrote: >> I second this as it is also a hack in my implementation, at least >> IMHO. >> >> @Michael Do you have a public implementation for interoperability >> testing? I cannot locate one. >> >> -g >> >> On May 7, 2009, at 11:04 AM, Michael Chen wrote: >> >>> Hi, >>> >>> In draft-ietf-p2psip-base-02, section 5.3.2, the Forwarding >>> Header's length field was increased from 24-bit to 32-bit from >>> version-01. This change is unwarranted and should be reverted. >>> >>> 1) The maximum message size remain 24-bit (5.2.3. Message Contents >>> Format, payload). There is no need to have a 32-bit length in the >>> forwarding header. >>> >>> 2) This change throw off the alignment of all fields after >>> 'length' in the header. They are now all start with an odd address >>> offset, and the fixed portion of the header (up to options_length) >>> is now an odd number. >>> >>> This design incurs performance penalty on many hardware, and it >>> requires clumsy software implementation. It is just ugly. Some >>> common sense is in order. >>> >>> Thanks >>> >>> --Michael >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www.ietf.org/mailman/listinfo/p2psip >> >> >> From jouni.maenpaa@ericsson.com Mon May 11 03:12:42 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 DAE323A6904 for ; Mon, 11 May 2009 03:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=0.220, 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 6XdOCXoa3uvM for ; Mon, 11 May 2009 03:12:41 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E9A373A688C for ; Mon, 11 May 2009 03:12:40 -0700 (PDT) X-AuditID: c1b4fb3c-b7b7fae0000015ab-1a-4a07fa7166d9 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 5B.CE.05547.17AF70A4; Mon, 11 May 2009 12:14:09 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 May 2009 12:14:09 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 May 2009 12:14:09 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0AAEF25A5; Mon, 11 May 2009 13:14:09 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C6990219F7; Mon, 11 May 2009 13:14:08 +0300 (EEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 62681219CF; Mon, 11 May 2009 13:14:08 +0300 (EEST) Message-ID: <4A07FA75.5040300@ericsson.com> Date: Mon, 11 May 2009 13:14:13 +0300 From: =?ISO-8859-1?Q?Jouni_M=E4enp=E4=E4?= User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: "p2psip@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 11 May 2009 10:14:09.0189 (UTC) FILETIME=[392EC550:01C9D221] X-Brightmail-Tracker: AAAAAA== Subject: [P2PSIP] Answers to feedback on the Self-tuning DHT 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, 11 May 2009 10:12:42 -0000 Hi, We presented the draft "Self-tuning DHT for RELOAD" (http://tools.ietf.org/id/draft-maenpaa-p2psip-self-tuning-00.txt) in the P2PSIP session of the previous IETF meeting in San Francisco. We would now like to address the feedback we received during the presentation. First, it was asked whether the self-tuning algorithm could be made more compatible with the algorithm in RELOAD base. The self-tuning draft follows closely the original Chord DHT specified in [Stoica 2003] whereas the Chord algorithm specified in the RELOAD base draft is a modified version of the original Chord algorithm. The major difference is that the algorithm in RELOAD base uses reactive stabilization for the neighborhood set (neighborhood set consists of the successors and predecessors of a peer on the Chord ring) whereas the self-tuning draft uses periodic stabilization. To make the self-tuning algorithm and the algorithm in RELOAD base more compatible, we would either need to make the self tuning algorithm use reactive stabilization or make the algorithm in RELOAD base use periodic stabilization. If the self-tuning algorithm was modified to use reactive stabilization, then it would no longer be able to handle large-scale and high-churn overlays, as was discussed above. Consequently, keeping both approaches as two different topology plugins seems to make sense. There was also some discussion on reactive versus periodic stabilization. It has been shown in [Rhea 2004] that reactive stabilization works well for small overlays and moderate churn. However, in large-scale (e.g., 1000 peers or more) or high-churn overlays, reactive stabilization runs the risk of creating a positive feedback cycle, which can eventually result in congestion collapse. In [Rhea 2004], it is shown that a 1000-peer overlay under churn uses significantly less bandwidth and has lower latencies when periodic stabilization is used than when reactive stabilization is used. Although in the experiments carried out in [Rhea 2004], reactive stabilization performed well when there was no churn, its bandwidth use was observed to jump dramatically under churn. At higher churn rates and larger scale overlays, periodic stabilization uses less bandwidth and the resulting lower contention for the network leads to lower latencies. For this reason, most DHTs use periodic stabilization. Third, there was a question whether introducing self-tuning behavior will make the overlay unstable, since there may be a delay between getting information from the overlay and adapting the DHT parameters. In a self-tuning DHT, each peer collects statistical data from the overlay and then uses this data to adjust the DHT parameters. Each peer maintains of history of the collected data (e.g., a failure history). Thus, the best trade-off between accuracy and responsiveness to changed network conditions can be achieved by selecting an appropriate size for the history. Guidelines for choosing an appropriate size for the history are given for instance in [Ghinita 2006, Mahajan 2003]. A DHT becomes unstable if peers use DHT parameters that are inappropriate for the prevailing operating conditions. Self-tuning behavior does not make a DHT unstable since peers try to adapt the DHT parameters when the operating conditions change. It has been shown that a self-tuning DHT outperforms a DHT using a fixed stabilization interval [Ghinita 2006]. Fourth, there was a question on how well the self-tuning algorithm performs in a small-scale overlay. As described in [Rhea 2004], if a fixed stabilization interval is used, periodic stabilization is wasteful in a low-churn small-scale network because if configured inappropriately, it executes the stabilization routines more often than is actually necessary. However, a self-tuning DHT avoids this problem since it adjust the stabilization interval by making it longer if it observes that the churn rate becomes lower. Because of this, a self-tuning DHT can perform well also in low-churn small-scale overlays. Fifth, there was a question on how well the algorithm tolerates churn. As explained above, a DHT using reactive stabilization can overload the network with messages under high churn rates. On the other hand, a DHT with periodic stabilization uses a fixed stabilization interval. The problem with this is that if the churn rate becomes higher than expected, the stabilization interval may be too infrequent and as a result, the network becomes partitioned. The idea in a self-tuning DHT is that if the churn rate is observed to increase, peers will adjust the stabilization interval by making it shorter. This allows a self-tuning DHT to tolerate high churn rates. Finally, someone asked what happens if different peers have different views of the network conditions. Each peer in the DHT uses only local information to adjust the stabilization interval. A peer adjusts the stabilization interval based on the failures it detects in its routing table and also based on the session times of peers in the routing table. Thus, each peer attempts to adjust the stabilization interval so that it is appropriate for the observed network conditions. Because only local information is used, each peer may not necessarily end up using exactly the same stabilization interval. This does not matter, however, because every peer uses a stabilization interval that is sufficient for the local conditions. Due to the length of this email, people answering something about one topic should probably change the subject and start a new thread. Best Regards, Jouni Maenpaa [Ghinita 2006] Ghinita, G. and Y. Teo, "An adaptive stabilization framework for distributed hash tables", 20th International Parallel and Distributed Processing Symposium April 2006. [Mahajan 2003] Mahajan, R., Castro, M., and A. Rowstron, "Controlling the cost of reliability in peer-to-peer overlays", In Proceedings of the 2nd International Workshop on Peer-to-Peer Systems Feb. 2003. [Rhea 2004] Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz, "Handling churn in a DHT", In Proc. of the USENIX Annual Techincal Conference June 2004. [Stoica 2003] 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. From vidyan@qualcomm.com Mon May 11 12:47: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 7376728C16A for ; Mon, 11 May 2009 12:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.256 X-Spam-Level: X-Spam-Status: No, score=-102.256 tagged_above=-999 required=5 tests=[AWL=-1.469, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812, 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 dcfSBql8IGGg for ; Mon, 11 May 2009 12:47:43 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id BD93728C170 for ; Mon, 11 May 2009 12:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1242071252; x=1273607252; h=from:to:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version: x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20"p2psip@ietf.org"=20|Date:=20Mon,=201 1=20May=202009=2012:47:18=20-0700|Subject:=20Section=209 =20of=20RELOAD=20-=20Comments|Thread-Topic:=20Section=209 =20of=20RELOAD=20-=20Comments|Thread-Index:=20AcnScUqgXWh WHWaqRMymGS0R/44qjA=3D=3D|Message-ID:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5612"=3B=20a=3D"18035056"; bh=f+x3HmawxMkS9MqR1qyS+xzPdC3HYyJBMKWMva66dsw=; b=ZOa5pCYzvUxtDkR1zfxigX60fciM6UTEoZVjcmiaarctn6ek3XYY/UJM w5sooP78+g/xCDB3G2r4ViCSpXMVPllTJRDYGV9jn7UYhxPyv91shjMOf X1GDM51UdDUwEfGjock0sKC3oDsyr5n6jjPdZG8BR1TyNkxMH5UUuNHCK U=; X-IronPort-AV: E=McAfee;i="5300,2777,5612"; a="18035056" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2009 12:47:22 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4BJlL7j013315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 May 2009 12:47:22 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4BJlLcR032505 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 11 May 2009 12:47:21 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.1.358.0; Mon, 11 May 2009 12:47:21 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Mon, 11 May 2009 12:47:21 -0700 From: "Narayanan, Vidya" To: "p2psip@ietf.org" Date: Mon, 11 May 2009 12:47:18 -0700 Thread-Topic: Section 9 of RELOAD - Comments Thread-Index: AcnScUqgXWhWHWaqRMymGS0R/44qjA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [P2PSIP] Section 9 of RELOAD - Comments 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, 11 May 2009 19:47:44 -0000 I've described a number of comments on section 9 below. But, if the respon= ses can be separated out under each topic, it will help the discussion quit= e a bit, given the length of this email.=20 Routing (Section 9.3):=20 ---------------------- The routing rule as specified does not work in all cases. If a node with I= D N and immediate successor S receives a message for resource id k such tha= t N < k < S, since k is neither a node directly attached to N and nor is t= here a node whose ID is between N and k, the message cannot be routed. The= routing rule should instead read as follows:=20 "If a peer is not responsible for a Resource-ID k, but is directly connecte= d to a node with Node-ID k, then it routes the message to that node. Other= wise, it routes the request to the peer in the routing table that has the l= argest Node-ID that is in the interval between the peer and k. **If no suc= h node is found, it finds the smallest node id that is greater than k and r= outes the message to that node.** The routing table is the union of the ne= ighbor table and the finger table." The new text is as enclosed in "** **" above. =20 Redundancy (Section 9.4):=20 ------------------------- On the open issue, there should be no need to wait for successful redundant= copy storage to return a STORE response. It doesn't make sense to send a = failure if one of the redundant storage attempts fails anyway - so, the wai= t becomes a pointless exercise. =20 "Note that a malicious node can return a success response but not store the data locally or in the replica set. Requesting peers that wish to ensure that the replication actually occurred SHOULD [[Open Issue: SHOULD or MAY?]] contact each peer listed in the replicas field of the Store response and retrieve a copy of the data." The above text is not just relevant for redundant copies of data stored - i= t is true for even the actual resource-id owner. Also, in light of not wai= ting for the replica responses, the STORE response will not contain a list = of replicas - so, this needs to be corrected. =20 Joining (Section 9.5):=20 ---------------------- It is not clear why the join procedure requires all neighbor and finger con= nections to be established prior to sending the JOIN message itself. To be= functional in the overlay, only the immediate successor relationships must= be correctly in place. The other successors, predecessors and fingers can= be established subsequently. This also doesn't cause nodes to establish u= nnecessary connections unless the node has successfully joined. There is a= lso the question of whether a JP is supposed to establish a TLS connection = to the BP to send messages through it, which is presently not addressed in = the draft. It seems to me that a more streamlined join process can be defi= ned as follows:=20 1. JP connects to its chosen bootstrap node. JP MUST form a TLS session wi= th the bootstrap node, using the certificate or PSK required for overlay me= mbership. =20 2. JP sends a Join request message to its own Node-ID n, through the BP. = This is routed to the admitting peer (AP). The AP sends a response to the = Join. =20 3. JP also sends an Attach request message to n through the BP. This may = be sent in parallel with the Join message. The AP sends an attach response= , resulting in connection establishment between the JP and AP. =20 4. AP does a series of Store requests to JP to store the data that JP will= be responsible for. =20 5. AP sends JP an Update explicitly labeling JP as its predecessor. AP al= so sends an Update to all its other neighbors with the new value of its nei= ghbor set (including JP). At this point, JP is part of the ring and respon= sible for a section of the overlay. AP SHOULD now store any data that JP i= s responsible for as part of replicas it will store (since AP is still JP's= successor, it will need to store the data as well anyway). =20 6. JP sends Attach requests to the neighbors and establishes connections w= ith the required successors and predecessors.=20 7. JP establishes finger connections by sending Attach requests to peers (= n+2^i). (Comments on finger selection below). =20 Updates (Section 9.7):=20 ---------------------- Section 9.7.1. states that every time a connection is lost, the peer should= remove it from its neighbor table and find a different peer. Section 9.7.= 3. talks about attempting to re-establish connections when a neighbor is de= tected to be invalid. These are at odds. It seems to make sense that the = peer would always try to re-establish connections and only remove that neig= hbor if the connection cannot be re-established. =20 Further, having the enrollment server involved in specifying the frequency = of updates and probes seems strange. How is the enrollment server supposed= to know the magic values here? It seems like it should be enough to specif= y a recommended value and leave it at that. Since the finger stabilization= is for optimization and the neighbor stabilization is reactive anyway in t= he present draft, having these parameters in the config document seem to be= of little use. =20 Finger entries (Section 9.7.3 and elsewhere):=20 --------------------------------------------- The draft requires 16 finger table entries - at first, I took those to mean= 16 different resource ids that will be probed per formula. After reading = 9.7.3, it appears that it is talking about 16 different fingers that a node= should maintain. In a small overlay, that's ridiculously large. The text= is also unclear on what happens when the overlay shrinks. Further, the te= xt states that a peer SHOULD consider the finger table entry valid if it is= in the range [n + 2^(numBitsInNodeId-i), n + 1.5 x 2^(numBitsInNodeId-i)].= For small overlays, there may be no entries in this range for every i in [= 0, 127]. =20 A node should only need log N fingers to route in OlogN hops. What we need= to specify is an algorithm that uses the same pattern in resource ids to p= robe - the fingers corresponding to multiple of those will collapse to the = same node in a small overlay. In our implementation, the algorithm works a= s follows:=20 A node looks at the list of resource-ids corresponding to f=3D(n+2^i), for = all values of i=3D[0,127]. Let's say that it first probes n+2^0 and obtain= s a finger of f0. It checks f0 against the next set of resource-ids to pro= be and determines the next larger resource-id to probe from the list. It p= opulates the finger table entries for all other fingers f for which n < f <= f0, with f0 as the corresponding finger. Depending on the number of nodes= in the overlay, this should result in approximately logN fingers in the fi= nger table at any time. Periodic stabilization should adjust the number of= fingers automatically. In fact, the number of fingers a node has should p= rovide a rough estimate (with accuracy in the order of log N) of the size o= f the overlay. The current text suggests that the number of fingers should= be decided based on the overlay size, which does not seem intuitive or nec= essary. =20 Leaving (Section 9.9):=20 ---------------------- In the event of a graceful leave, a peer should be able to send updates to = all members of the neighbor set. It seems redundant to have the peer send = a Leave message, followed by every peer receiving the Leave to send updates= . Is there a reason for this?=20 Thanks, Vidya From glitch@me.com Mon May 11 15:41:10 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 201FA3A67DA for ; Mon, 11 May 2009 15:41:10 -0700 (PDT) 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.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 pjwITRNjq8mH for ; Mon, 11 May 2009 15:41:08 -0700 (PDT) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by core3.amsl.com (Postfix) with ESMTP id C05933A68B4 for ; Mon, 11 May 2009 15:40:48 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_QDpJ8UfzJVzNPWtPoRoPmA)" Received: from [10.0.1.5] (ip68-5-31-14.oc.oc.cox.net [68.5.31.14]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KJI00E5T4EDKP70@asmtp014.mac.com> for p2psip@ietf.org; Mon, 11 May 2009 15:42:14 -0700 (PDT) Message-id: From: glitch To: "Narayanan, Vidya" In-reply-to: Date: Mon, 11 May 2009 15:42:14 -0700 References: X-Mailer: Apple Mail (2.930.4) Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Section 9 of RELOAD - Comments 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, 11 May 2009 22:41:10 -0000 --Boundary_(ID_QDpJ8UfzJVzNPWtPoRoPmA) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT The RELOAD routing is fundamentally flawed and for that reason I am tossing the Chord implementation that it defines and replacing "periodic stabilization" with "correction on use and correct on change" also I am ditching finger tables all together as they aren't needed whatsoever with these changes. Also this brings global broadcast and multicast that can be registered via the hash table which are very useful for ICE and any other signaling with little overhead. I guess I will have to write my own RFC since RELOAD is IMHO using outdated overlay technology and since having said that shouldn't it be a flawless design and not broken right now? I think so. @Narayan You could not be more wrong about "the number of fingers a node has should provide a rough estimate (with accuracy in the order of log N) of the size of the overlay". People use this formula in Kadmelia, Chord, Chimera, etc and it does not work whatsoever and your accuracy is even wrong too. I use the algorithm described here: http://dks.sics.se/pub/netsize.pdf -g On May 11, 2009, at 12:47 PM, Narayanan, Vidya wrote: > I've described a number of comments on section 9 below. But, if the > responses can be separated out under each topic, it will help the > discussion quite a bit, given the length of this email. > > Routing (Section 9.3): > ---------------------- > The routing rule as specified does not work in all cases. If a node > with ID N and immediate successor S receives a message for resource > id k such that N < k < S, since k is neither a node directly > attached to N and nor is there a node whose ID is between N and k, > the message cannot be routed. The routing rule should instead read > as follows: > > "If a peer is not responsible for a Resource-ID k, but is directly > connected to a node with Node-ID k, then it routes the message to > that node. Otherwise, it routes the request to the peer in the > routing table that has the largest Node-ID that is in the interval > between the peer and k. **If no such node is found, it finds the > smallest node id that is greater than k and routes the message to > that node.** The routing table is the union of the neighbor table > and the finger table." > > The new text is as enclosed in "** **" above. > > Redundancy (Section 9.4): > ------------------------- > On the open issue, there should be no need to wait for successful > redundant copy storage to return a STORE response. It doesn't make > sense to send a failure if one of the redundant storage attempts > fails anyway - so, the wait becomes a pointless exercise. > > "Note that a malicious node can return a success response but not > store the data locally or in the replica set. Requesting peers that > wish to ensure that the replication actually occurred SHOULD [[Open > Issue: SHOULD or MAY?]] contact each peer listed in the replicas > field of the Store response and retrieve a copy of the data." > > The above text is not just relevant for redundant copies of data > stored - it is true for even the actual resource-id owner. Also, in > light of not waiting for the replica responses, the STORE response > will not contain a list of replicas - so, this needs to be corrected. > > Joining (Section 9.5): > ---------------------- > It is not clear why the join procedure requires all neighbor and > finger connections to be established prior to sending the JOIN > message itself. To be functional in the overlay, only the immediate > successor relationships must be correctly in place. The other > successors, predecessors and fingers can be established > subsequently. This also doesn't cause nodes to establish > unnecessary connections unless the node has successfully joined. > There is also the question of whether a JP is supposed to establish > a TLS connection to the BP to send messages through it, which is > presently not addressed in the draft. It seems to me that a more > streamlined join process can be defined as follows: > > 1. JP connects to its chosen bootstrap node. JP MUST form a TLS > session with the bootstrap node, using the certificate or PSK > required for overlay membership. > 2. JP sends a Join request message to its own Node-ID n, through > the BP. This is routed to the admitting peer (AP). The AP sends a > response to the Join. > 3. JP also sends an Attach request message to n through the BP. > This may be sent in parallel with the Join message. The AP sends an > attach response, resulting in connection establishment between the > JP and AP. > 4. AP does a series of Store requests to JP to store the data that > JP will be responsible for. > 5. AP sends JP an Update explicitly labeling JP as its > predecessor. AP also sends an Update to all its other neighbors > with the new value of its neighbor set (including JP). At this > point, JP is part of the ring and responsible for a section of the > overlay. AP SHOULD now store any data that JP is responsible for as > part of replicas it will store (since AP is still JP's successor, it > will need to store the data as well anyway). > 6. JP sends Attach requests to the neighbors and establishes > connections with the required successors and predecessors. > 7. JP establishes finger connections by sending Attach requests to > peers (n+2^i). (Comments on finger selection below). > > Updates (Section 9.7): > ---------------------- > Section 9.7.1. states that every time a connection is lost, the peer > should remove it from its neighbor table and find a different peer. > Section 9.7.3. talks about attempting to re-establish connections > when a neighbor is detected to be invalid. These are at odds. It > seems to make sense that the peer would always try to re-establish > connections and only remove that neighbor if the connection cannot > be re-established. > > Further, having the enrollment server involved in specifying the > frequency of updates and probes seems strange. How is the > enrollment server supposed to know the magic values here? It seems > like it should be enough to specify a recommended value and leave it > at that. Since the finger stabilization is for optimization and the > neighbor stabilization is reactive anyway in the present draft, > having these parameters in the config document seem to be of little > use. > > Finger entries (Section 9.7.3 and elsewhere): > --------------------------------------------- > The draft requires 16 finger table entries - at first, I took those > to mean 16 different resource ids that will be probed per formula. > After reading 9.7.3, it appears that it is talking about 16 > different fingers that a node should maintain. In a small overlay, > that's ridiculously large. The text is also unclear on what happens > when the overlay shrinks. Further, the text states that a peer > SHOULD consider the finger table entry valid if it is in the range > [n + 2^(numBitsInNodeId-i), n + 1.5 x 2^(numBitsInNodeId-i)]. For > small overlays, there may be no entries in this range for every i in > [0, 127]. > > A node should only need log N fingers to route in OlogN hops. What > we need to specify is an algorithm that uses the same pattern in > resource ids to probe - the fingers corresponding to multiple of > those will collapse to the same node in a small overlay. In our > implementation, the algorithm works as follows: > > A node looks at the list of resource-ids corresponding to f=(n+2^i), > for all values of i=[0,127]. Let's say that it first probes n+2^0 > and obtains a finger of f0. It checks f0 against the next set of > resource-ids to probe and determines the next larger resource-id to > probe from the list. It populates the finger table entries for all > other fingers f for which n < f < f0, with f0 as the corresponding > finger. Depending on the number of nodes in the overlay, this > should result in approximately logN fingers in the finger table at > any time. Periodic stabilization should adjust the number of > fingers automatically. In fact, the number of fingers a node has > should provide a rough estimate (with accuracy in the order of log > N) of the size of the overlay. The current text suggests that the > number of fingers should be decided based on the overlay size, which > does not seem intuitive or necessary. > > Leaving (Section 9.9): > ---------------------- > In the event of a graceful leave, a peer should be able to send > updates to all members of the neighbor set. It seems redundant to > have the peer send a Leave message, followed by every peer receiving > the Leave to send updates. Is there a reason for this? > > Thanks, > Vidya > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_QDpJ8UfzJVzNPWtPoRoPmA) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: quoted-printable The RELOAD routing = is fundamentally flawed and for that reason I am tossing the = Chord implementation that it defines and replacing = "periodic stabilization" with "correction on use and correct on = change" also I am ditching finger tables all together as they = aren't needed whatsoever with these changes. Also this brings = global broadcast and multicast that can be registered via the = hash table which are very useful for ICE and any other = signaling with little overhead.

I guess I will have = to write my own RFC since RELOAD is IMHO using outdated overlay = technology and since having said that shouldn't it be a flawless design = and not broken right now? I think so.

@Narayan = You could not be more wrong about "the number of fingers a node has = should provide a rough estimate (with accuracy in the order of log N) of = the size of the overlay". People use this formula in Kadmelia, = Chord, Chimera, etc and it does not work whatsoever and your = accuracy is even wrong too. I use the algorithm described here: http://dks.sics.se/pub/netsize= .pdf

-g

On = May 11, 2009, at 12:47 PM, Narayanan, Vidya wrote:

I've = described a number of comments on section 9 below.  But, if the = responses can be separated out under each topic, it will help the = discussion quite a bit, given the length of this email.

Routing = (Section 9.3):
----------------------
The routing rule as = specified does not work in all cases.  If a node with ID N and = immediate successor S receives a message for resource id k such that =  N < k < S, since k is neither a node directly attached to N = and nor is there a node whose ID is between N and k, the message cannot = be routed.  The routing rule should instead read as follows: =

"If a peer is not responsible for a Resource-ID k, but is = directly connected to a node with Node-ID k, then it routes the message = to that node.  Otherwise, it routes the request to the peer in the = routing table that has the largest Node-ID that is in the interval = between the peer and k.  **If no such node is found, it finds the = smallest node id that is greater than k and routes the message to that = node.**  The routing table is the union of the neighbor table and = the finger table."

The new text is as enclosed in "**  **" = above.  

Redundancy (Section 9.4): =
-------------------------
On the open issue, there should be no = need to wait for successful redundant copy storage to return a STORE = response.  It doesn't make sense to send a failure if one of the = redundant storage attempts fails anyway - so, the wait becomes a = pointless exercise.  

  "Note that a malicious = node can return a success response but not
  store the = data locally or in the replica set.  Requesting peers that
=   wish to ensure that the replication actually occurred SHOULD = [[Open
  Issue:  SHOULD or MAY?]] contact each peer = listed in the replicas
  field of the Store response and = retrieve a copy of the data."

The above text is not just relevant = for redundant copies of data stored - it is true for even the actual = resource-id owner.  Also, in light of not waiting for the replica = responses, the STORE response will not contain a list of replicas - so, = this needs to be corrected.  

Joining (Section 9.5): =
----------------------
It is not clear why the join procedure = requires all neighbor and finger connections to be established prior to = sending the JOIN message itself.  To be functional in the overlay, = only the immediate successor relationships must be correctly in place. =  The other successors, predecessors and fingers can be established = subsequently.  This also doesn't cause nodes to establish = unnecessary connections unless the node has successfully joined. =  There is also the question of whether a JP is supposed to = establish a TLS connection to the BP to send messages through it, which = is presently not addressed in the draft.  It seems to me that a = more streamlined join process can be defined as follows:

1. =  JP connects to its chosen bootstrap node. JP MUST form a TLS = session with the bootstrap node, using the certificate or PSK required = for overlay membership.  
2.  JP sends a Join request = message to its own Node-ID n, through the BP.  This is routed to = the admitting peer (AP).  The AP sends a response to the Join. =  
3.  JP also sends an Attach request message to n through = the BP.  This may be sent in parallel with the Join message. =  The AP sends an attach response, resulting in connection = establishment between the JP and AP.  
4.  AP does a series = of Store requests to JP to store the data that JP will be responsible = for.  
5.  AP sends JP an Update explicitly labeling JP as = its predecessor.  AP also sends an Update to all its other = neighbors with the new value of its neighbor set (including JP). =  At this point, JP is part of the ring and responsible for a = section of the overlay.  AP SHOULD now store any data that JP is = responsible for as part of replicas it will store (since AP is still = JP's successor, it will need to store the data as well anyway). =  
6.  JP sends Attach requests to the neighbors and = establishes connections with the required successors and predecessors. =
7.  JP establishes finger connections by sending Attach = requests to peers (n+2^i). (Comments on finger selection below). =  

Updates (Section 9.7): =
----------------------
Section 9.7.1. states that every time a = connection is lost, the peer should remove it from its neighbor table = and find a different peer.  Section 9.7.3. talks about attempting = to re-establish connections when a neighbor is detected to be invalid. =  These are at odds.  It seems to make sense that the peer = would always try to re-establish connections and only remove that = neighbor if the connection cannot be re-established. =  

Further, having the enrollment server involved in = specifying the frequency of updates and probes seems strange.  How = is the enrollment server supposed to know the magic values here? It = seems like it should be enough to specify a recommended value and leave = it at that.  Since the finger stabilization is for optimization and = the neighbor stabilization is reactive anyway in the present draft, = having these parameters in the config document seem to be of little use. =   

Finger entries (Section 9.7.3 and elsewhere): =
---------------------------------------------
The draft requires = 16 finger table entries - at first, I took those to mean 16 different = resource ids that will be probed per formula.  After reading 9.7.3, = it appears that it is talking about 16 different fingers that a node = should maintain.  In a small overlay, that's ridiculously large. =  The text is also unclear on what happens when the overlay shrinks. =  Further, the text states that a peer SHOULD consider the finger = table entry valid if it is in the range [n + 2^(numBitsInNodeId-i), n + = 1.5 x 2^(numBitsInNodeId-i)]. For small overlays, there may be no = entries in this range for every i in [0, 127].  

A node = should only need log N fingers to route in OlogN hops.  What we = need to specify is an algorithm that uses the same pattern in resource = ids to probe - the fingers corresponding to multiple of those will = collapse to the same node in a small overlay.  In our = implementation, the algorithm works as follows:

A node looks at = the list of resource-ids corresponding to f=3D(n+2^i), for all values of = i=3D[0,127].  Let's say that it first probes n+2^0 and obtains a = finger of f0.  It checks f0 against the next set of resource-ids to = probe and determines the next larger resource-id to probe from the list. =  It populates the finger table entries for all other fingers f for = which n < f < f0, with f0 as the corresponding finger. =  Depending on the number of nodes in the overlay, this should = result in approximately logN fingers in the finger table at any time. =  Periodic stabilization should adjust the number of fingers = automatically.  In fact, the number of fingers a node has should = provide a rough estimate (with accuracy in the order of log N) of the = size of the overlay.  The current text suggests that the number of = fingers should be decided based on the overlay size, which does not seem = intuitive or necessary.  

Leaving (Section 9.9): =
----------------------
In the event of a graceful leave, a peer = should be able to send updates to all members of the neighbor set. =  It seems redundant to have the peer send a Leave message, followed = by every peer receiving the Leave to send updates.  Is there a = reason for this? =

Thanks,
Vidya
______________________________________________= _
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Boundary_(ID_QDpJ8UfzJVzNPWtPoRoPmA)-- From bbl@lowekamp.net Mon May 11 19:47: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 5EF623A699F for ; Mon, 11 May 2009 19:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.083 X-Spam-Level: X-Spam-Status: No, score=-0.083 tagged_above=-999 required=5 tests=[AWL=-1.777, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, 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 TneqcF+V8Wr6 for ; Mon, 11 May 2009 19:47:39 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 906233A67D7 for ; Mon, 11 May 2009 19:47:38 -0700 (PDT) Received: by fxm2 with SMTP id 2so3064254fxm.37 for ; Mon, 11 May 2009 19:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.109.19 with SMTP id h19mr4206482fap.20.1242096546615; Mon, 11 May 2009 19:49:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 May 2009 22:49:06 -0400 Message-ID: From: Bruce Lowekamp To: "Narayanan, Vidya" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Section 9 of RELOAD - Comments 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, 12 May 2009 02:47:40 -0000 Vidya, Thanks for the comments. Responses inline. On Mon, May 11, 2009 at 3:47 PM, Narayanan, Vidya wro= te: > I've described a number of comments on section 9 below. =C2=A0But, if the= responses can be separated out under each topic, it will help the discussi= on quite a bit, given the length of this email. > > Routing (Section 9.3): > ---------------------- > The routing rule as specified does not work in all cases. =C2=A0If a node= with ID N and immediate successor S receives a message for resource id k s= uch that =C2=A0N < k < S, since k is neither a node directly attached to N = and nor is there a node whose ID is between N and k, the message cannot be = routed. =C2=A0The routing rule should instead read as follows: > > "If a peer is not responsible for a Resource-ID k, but is directly connec= ted to a node with Node-ID k, then it routes the message to that node. =C2= =A0Otherwise, it routes the request to the peer in the routing table that h= as the largest Node-ID that is in the interval between the peer and k. =C2= =A0**If no such node is found, it finds the smallest node id that is greate= r than k and routes the message to that node.** =C2=A0The routing table is = the union of the neighbor table and the finger table." > > The new text is as enclosed in "** =C2=A0**" above. > You're right, that text misses the last step of chord routing. Will updat= e. > Redundancy (Section 9.4): > ------------------------- > On the open issue, there should be no need to wait for successful redunda= nt copy storage to return a STORE response. =C2=A0It doesn't make sense to = send a failure if one of the redundant storage attempts fails anyway - so, = the wait becomes a pointless exercise. > > =C2=A0 "Note that a malicious node can return a success response but not > =C2=A0 store the data locally or in the replica set. =C2=A0Requesting pee= rs that > =C2=A0 wish to ensure that the replication actually occurred SHOULD [[Ope= n > =C2=A0 Issue: =C2=A0SHOULD or MAY?]] contact each peer listed in the repl= icas > =C2=A0 field of the Store response and retrieve a copy of the data." > > The above text is not just relevant for redundant copies of data stored -= it is true for even the actual resource-id owner. =C2=A0Also, in light of = not waiting for the replica responses, the STORE response will not contain = a list of replicas - so, this needs to be corrected. > Yes, that last text doesn't apply just to replicas. Will reword. The responsible peer can, however, include the peerids of the peers on which it will place replicas, even if it doesn't wait to confirm their responses. > Joining (Section 9.5): > ---------------------- > It is not clear why the join procedure requires all neighbor and finger c= onnections to be established prior to sending the JOIN message itself. =C2= =A0To be functional in the overlay, only the immediate successor relationsh= ips must be correctly in place. =C2=A0The other successors, predecessors an= d fingers can be established subsequently. =C2=A0This also doesn't cause no= des to establish unnecessary connections unless the node has successfully j= oined. =C2=A0There is also the question of whether a JP is supposed to esta= blish a TLS connection to the BP to send messages through it, which is pres= ently not addressed in the draft. =C2=A0It seems to me that a more streamli= ned join process can be defined as follows: > You're right that it's just an optimization to have finger table entries, but it's not completely clear to me that adding a new peer without finger table entries provides a benefit to the overlay. I can see that being a SHOULD, though. Yes, messages sent to the bootstrap peer are sent with (D)TLS. > 1. =C2=A0JP connects to its chosen bootstrap node. JP MUST form a TLS ses= sion with the bootstrap node, using the certificate or PSK required for ove= rlay membership. > 2. =C2=A0JP sends a Join request message to its own Node-ID n, through th= e BP. =C2=A0This is routed to the admitting peer (AP). =C2=A0The AP sends a= response to the Join. > 3. =C2=A0JP also sends an Attach request message to n through the BP. =C2= =A0This may be sent in parallel with the Join message. =C2=A0The AP sends a= n attach response, resulting in connection establishment between the JP and= AP. > 4. =C2=A0AP does a series of Store requests to JP to store the data that = JP will be responsible for. > 5. =C2=A0AP sends JP an Update explicitly labeling JP as its predecessor.= =C2=A0AP also sends an Update to all its other neighbors with the new valu= e of its neighbor set (including JP). =C2=A0At this point, JP is part of th= e ring and responsible for a section of the overlay. =C2=A0AP SHOULD now st= ore any data that JP is responsible for as part of replicas it will store (= since AP is still JP's successor, it will need to store the data as well an= yway). > 6. =C2=A0JP sends Attach requests to the neighbors and establishes connec= tions with the required successors and predecessors. > 7. =C2=A0JP establishes finger connections by sending Attach requests to = peers (n+2^i). (Comments on finger selection below). > > Updates (Section 9.7): > ---------------------- > Section 9.7.1. states that every time a connection is lost, the peer shou= ld remove it from its neighbor table and find a different peer. =C2=A0Secti= on 9.7.3. talks about attempting to re-establish connections when a neighbo= r is detected to be invalid. =C2=A0These are at odds. =C2=A0It seems to mak= e sense that the peer would always try to re-establish connections and only= remove that neighbor if the connection cannot be re-established. > Working on some new text along these lines for the next revision. > Further, having the enrollment server involved in specifying the frequenc= y of updates and probes seems strange. =C2=A0How is the enrollment server s= upposed to know the magic values here? It seems like it should be enough to= specify a recommended value and leave it at that. =C2=A0Since the finger s= tabilization is for optimization and the neighbor stabilization is reactive= anyway in the present draft, having these parameters in the config documen= t seem to be of little use. > Are you revisiting the issue of wanting to split the authority for enrollment and config files, or are you questioning whether it should be possible to specify update frequency in a config file at all? > Finger entries (Section 9.7.3 and elsewhere): > --------------------------------------------- > The draft requires 16 finger table entries - at first, I took those to me= an 16 different resource ids that will be probed per formula. =C2=A0After r= eading 9.7.3, it appears that it is talking about 16 different fingers that= a node should maintain. =C2=A0In a small overlay, that's ridiculously larg= e. =C2=A0The text is also unclear on what happens when the overlay shrinks.= =C2=A0Further, the text states that a peer SHOULD consider the finger tabl= e entry valid if it is in the range [n + 2^(numBitsInNodeId-i), n + 1.5 x 2= ^(numBitsInNodeId-i)]. For small overlays, there may be no entries in this = range for every i in [0, 127]. > The text was left the way it is in an effort to make it simpler, but I think there may be an issue in there where too many MUSTs are prohibiting common optimizations. Definitely need to take a look at that. I think the right answer here is to check the existing text for being too pedantic and compare its length & complexity with the optimization you describe (which I agree is how this should really be implemented). > A node should only need log N fingers to route in OlogN hops. =C2=A0What = we need to specify is an algorithm that uses the same pattern in resource i= ds to probe - the fingers corresponding to multiple of those will collapse = to the same node in a small overlay. =C2=A0In our implementation, the algor= ithm works as follows: > > A node looks at the list of resource-ids corresponding to f=3D(n+2^i), fo= r all values of i=3D[0,127]. =C2=A0Let's say that it first probes n+2^0 and= obtains a finger of f0. =C2=A0It checks f0 against the next set of resourc= e-ids to probe and determines the next larger resource-id to probe from the= list. =C2=A0It populates the finger table entries for all other fingers f = for which n < f < f0, with f0 as the corresponding finger. =C2=A0Depending = on the number of nodes in the overlay, this should result in approximately = logN fingers in the finger table at any time. =C2=A0Periodic stabilization = should adjust the number of fingers automatically. =C2=A0In fact, the numbe= r of fingers a node has should provide a rough estimate (with accuracy in t= he order of log N) of the size of the overlay. =C2=A0The current text sugge= sts that the number of fingers should be decided based on the overlay size,= which does not seem intuitive or necessary. > > Leaving (Section 9.9): > ---------------------- > In the event of a graceful leave, a peer should be able to send updates t= o all members of the neighbor set. =C2=A0It seems redundant to have the pee= r send a Leave message, followed by every peer receiving the Leave to send = updates. =C2=A0Is there a reason for this? > Yeah, it's pretty excessive. I haven't personally looked at it too hard because I tend to think about ungraceful leaves more, and periodic updates remove the issue entirely. Bruce > Thanks, > Vidya > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From vidyan@qualcomm.com Tue May 12 11:42: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 B4EBD3A6E5E for ; Tue, 12 May 2009 11:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.127 X-Spam-Level: X-Spam-Status: No, score=-105.127 tagged_above=-999 required=5 tests=[AWL=1.472, 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 erFWYJfsg2oB for ; Tue, 12 May 2009 11:42:37 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7879B3A6E49 for ; Tue, 12 May 2009 11:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=vidyan@qualcomm.com; q=dns/txt; s=qcdkim; t=1242153849; x=1273689849; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Narayanan,=20Vidya"=20|To: =20Bruce=20Lowekamp=20|CC:=20"p2psip@ie tf.org"=20|Date:=20Tue,=2012=20May=20200 9=2011:44:01=20-0700|Subject:=20RE:=20[P2PSIP]=20Section =209=20of=20RELOAD=20-=20Comments|Thread-Topic:=20[P2PSIP ]=20Section=209=20of=20RELOAD=20-=20Comments |Thread-Index:=20AcnSrDnMc2K5oQoJSEaxx3TMi+5kgQAhI5cQ |Message-ID:=20|References:=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20e n-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"utf-8" |Content-Transfer-Encoding:=20base64|MIME-Version:=201.0 |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5613"=3B=20 a=3D"18082805"; bh=odA/Niqy+fkEWnxHJNn8pkB+uniHtjX7ouDtV3J7tNU=; b=ZyOY/MaNr1W55W5A4Xi6ChRw9CuvxIH+vSuifAS5LjJQs2B+3PF3cGLB Eo54mfqwk7b8CAGS6/9Ct0RGgj7inPFdHF4Gx4Nr/SbjaCmOnenQvJ3r1 s0m2RUyhXJOaaQ5q93fsu6v7tK+QTByuey4oETTyc24lqHJVjuOv87jRk c=; X-IronPort-AV: E=McAfee;i="5300,2777,5613"; a="18082805" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 May 2009 11:44:09 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4CIi8bY021402 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 May 2009 11:44:09 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n4CIi4Tv018729 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 12 May 2009 11:44:04 -0700 Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 12 May 2009 11:44:04 -0700 Received: from NALASEXMB08.na.qualcomm.com ([10.47.16.13]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Tue, 12 May 2009 11:44:03 -0700 From: "Narayanan, Vidya" To: Bruce Lowekamp Date: Tue, 12 May 2009 11:44:01 -0700 Thread-Topic: [P2PSIP] Section 9 of RELOAD - Comments Thread-Index: AcnSrDnMc2K5oQoJSEaxx3TMi+5kgQAhI5cQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Section 9 of RELOAD - Comments 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, 12 May 2009 18:42:38 -0000 PHNuaXA+DQoNCj4gPiBKb2luaW5nIChTZWN0aW9uIDkuNSk6DQo+ID4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+IEl0IGlzIG5vdCBjbGVhciB3aHkgdGhlIGpvaW4gcHJvY2VkdXJlIHJlcXVp cmVzIGFsbCBuZWlnaGJvciBhbmQNCj4gZmluZ2VyIGNvbm5lY3Rpb25zIHRvIGJlIGVzdGFibGlz aGVkIHByaW9yIHRvIHNlbmRpbmcgdGhlIEpPSU4gbWVzc2FnZQ0KPiBpdHNlbGYuIMKgVG8gYmUg ZnVuY3Rpb25hbCBpbiB0aGUgb3ZlcmxheSwgb25seSB0aGUgaW1tZWRpYXRlIHN1Y2Nlc3Nvcg0K PiByZWxhdGlvbnNoaXBzIG11c3QgYmUgY29ycmVjdGx5IGluIHBsYWNlLiDCoFRoZSBvdGhlciBz dWNjZXNzb3JzLA0KPiBwcmVkZWNlc3NvcnMgYW5kIGZpbmdlcnMgY2FuIGJlIGVzdGFibGlzaGVk IHN1YnNlcXVlbnRseS4gwqBUaGlzIGFsc28NCj4gZG9lc24ndCBjYXVzZSBub2RlcyB0byBlc3Rh Ymxpc2ggdW5uZWNlc3NhcnkgY29ubmVjdGlvbnMgdW5sZXNzIHRoZQ0KPiBub2RlIGhhcyBzdWNj ZXNzZnVsbHkgam9pbmVkLiDCoFRoZXJlIGlzIGFsc28gdGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXIg YQ0KPiBKUCBpcyBzdXBwb3NlZCB0byBlc3RhYmxpc2ggYSBUTFMgY29ubmVjdGlvbiB0byB0aGUg QlAgdG8gc2VuZCBtZXNzYWdlcw0KPiB0aHJvdWdoIGl0LCB3aGljaCBpcyBwcmVzZW50bHkgbm90 IGFkZHJlc3NlZCBpbiB0aGUgZHJhZnQuIMKgSXQgc2VlbXMgdG8NCj4gbWUgdGhhdCBhIG1vcmUg c3RyZWFtbGluZWQgam9pbiBwcm9jZXNzIGNhbiBiZSBkZWZpbmVkIGFzIGZvbGxvd3M6DQo+ID4N Cj4gDQo+IFlvdSdyZSByaWdodCB0aGF0IGl0J3MganVzdCBhbiBvcHRpbWl6YXRpb24gdG8gaGF2 ZSBmaW5nZXIgdGFibGUNCj4gZW50cmllcywgYnV0IGl0J3Mgbm90IGNvbXBsZXRlbHkgY2xlYXIg dG8gbWUgdGhhdCBhZGRpbmcgYSBuZXcgcGVlcg0KPiB3aXRob3V0IGZpbmdlciB0YWJsZSBlbnRy aWVzIHByb3ZpZGVzIGEgYmVuZWZpdCB0byB0aGUgb3ZlcmxheS4gIEkgY2FuDQo+IHNlZSB0aGF0 IGJlaW5nIGEgU0hPVUxELCB0aG91Z2guDQo+IA0KDQpUaGUgZmluZ2VyIGVudHJpZXMgbXVzdCBi ZSBhZGRlZCB1cG9uIEpvaW4uICBJJ20gbm90IHNheWluZyB0aGF0IHRoZSBwZWVyIGNhbiB3YWl0 IGxvbmdlciB0byBkbyB0aGF0LiAgSG93ZXZlciwgdGhlcmUgaXMgbm8gZ2FpbiBpbiBkb2luZyB0 aGUgZmluZ2VyIGNvbm5lY3Rpb25zIHVwZnJvbnQgLSBpdCBpcyBub3QgbGlrZSB0aGUgQVAgb3Ig YW55IG5vZGUgdHJpZXMgdG8gdmVyaWZ5IHRoYXQgaGFzIGhhcHBlbmVkLiAgU28sIGluIHRlcm1z IG9mIHByb2Nlc3NpbmcgdGhlIGpvaW4sIGl0IGlzIHRoZSBzYW1lLiAgQW5kLCBpdCBtYWtlcyBt b3JlIHNlbnNlIHRvIGdvIHRocm91Z2ggdGhvc2UgYWZ0ZXIgYSBzdWNjZXNzZnVsIGpvaW4sIHJh dGhlciB0aGFuIGhhdmluZyB0byB0ZWFyIGRvd24gaWYgdGhlIG5vZGUgaXMgdW5hYmxlIHRvIGpv aW4gZm9yIGFueSByZWFzb24uICANCg0KPHNuaXA+DQogDQo+ID4gRnVydGhlciwgaGF2aW5nIHRo ZSBlbnJvbGxtZW50IHNlcnZlciBpbnZvbHZlZCBpbiBzcGVjaWZ5aW5nIHRoZQ0KPiBmcmVxdWVu Y3kgb2YgdXBkYXRlcyBhbmQgcHJvYmVzIHNlZW1zIHN0cmFuZ2UuIMKgSG93IGlzIHRoZSBlbnJv bGxtZW50DQo+IHNlcnZlciBzdXBwb3NlZCB0byBrbm93IHRoZSBtYWdpYyB2YWx1ZXMgaGVyZT8g SXQgc2VlbXMgbGlrZSBpdCBzaG91bGQNCj4gYmUgZW5vdWdoIHRvIHNwZWNpZnkgYSByZWNvbW1l bmRlZCB2YWx1ZSBhbmQgbGVhdmUgaXQgYXQgdGhhdC4gwqBTaW5jZQ0KPiB0aGUgZmluZ2VyIHN0 YWJpbGl6YXRpb24gaXMgZm9yIG9wdGltaXphdGlvbiBhbmQgdGhlIG5laWdoYm9yDQo+IHN0YWJp bGl6YXRpb24gaXMgcmVhY3RpdmUgYW55d2F5IGluIHRoZSBwcmVzZW50IGRyYWZ0LCBoYXZpbmcg dGhlc2UNCj4gcGFyYW1ldGVycyBpbiB0aGUgY29uZmlnIGRvY3VtZW50IHNlZW0gdG8gYmUgb2Yg bGl0dGxlIHVzZS4NCj4gPg0KPiANCj4gQXJlIHlvdSByZXZpc2l0aW5nIHRoZSBpc3N1ZSBvZiB3 YW50aW5nIHRvIHNwbGl0IHRoZSBhdXRob3JpdHkgZm9yDQo+IGVucm9sbG1lbnQgYW5kIGNvbmZp ZyBmaWxlcywgb3IgYXJlIHlvdSBxdWVzdGlvbmluZyB3aGV0aGVyIGl0IHNob3VsZA0KPiBiZSBw b3NzaWJsZSB0byBzcGVjaWZ5IHVwZGF0ZSBmcmVxdWVuY3kgaW4gYSBjb25maWcgZmlsZSBhdCBh bGw/DQo+IA0KDQpUaGUgbGF0dGVyIC0gSSdtIG5vdCBzZWVpbmcgYSBuZWVkIGZvciB0aGVzZSBi ZWluZyBjb25maWd1cmFibGUuIA0KDQo+IA0KPiA+IEZpbmdlciBlbnRyaWVzIChTZWN0aW9uIDku Ny4zIGFuZCBlbHNld2hlcmUpOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiA+IFRoZSBkcmFmdCByZXF1aXJlcyAxNiBmaW5nZXIgdGFibGUgZW50 cmllcyAtIGF0IGZpcnN0LCBJIHRvb2sgdGhvc2UNCj4gdG8gbWVhbiAxNiBkaWZmZXJlbnQgcmVz b3VyY2UgaWRzIHRoYXQgd2lsbCBiZSBwcm9iZWQgcGVyIGZvcm11bGEuDQo+IMKgQWZ0ZXIgcmVh ZGluZyA5LjcuMywgaXQgYXBwZWFycyB0aGF0IGl0IGlzIHRhbGtpbmcgYWJvdXQgMTYgZGlmZmVy ZW50DQo+IGZpbmdlcnMgdGhhdCBhIG5vZGUgc2hvdWxkIG1haW50YWluLiDCoEluIGEgc21hbGwg b3ZlcmxheSwgdGhhdCdzDQo+IHJpZGljdWxvdXNseSBsYXJnZS4gwqBUaGUgdGV4dCBpcyBhbHNv IHVuY2xlYXIgb24gd2hhdCBoYXBwZW5zIHdoZW4gdGhlDQo+IG92ZXJsYXkgc2hyaW5rcy4gwqBG dXJ0aGVyLCB0aGUgdGV4dCBzdGF0ZXMgdGhhdCBhIHBlZXIgU0hPVUxEIGNvbnNpZGVyDQo+IHRo ZSBmaW5nZXIgdGFibGUgZW50cnkgdmFsaWQgaWYgaXQgaXMgaW4gdGhlIHJhbmdlIFtuICsNCj4g Ml4obnVtQml0c0luTm9kZUlkLWkpLCBuICsgMS41IHggMl4obnVtQml0c0luTm9kZUlkLWkpXS4g Rm9yIHNtYWxsDQo+IG92ZXJsYXlzLCB0aGVyZSBtYXkgYmUgbm8gZW50cmllcyBpbiB0aGlzIHJh bmdlIGZvciBldmVyeSBpIGluIFswLA0KPiAxMjddLg0KPiA+DQo+IA0KPiBUaGUgdGV4dCB3YXMg bGVmdCB0aGUgd2F5IGl0IGlzIGluIGFuIGVmZm9ydCB0byBtYWtlIGl0IHNpbXBsZXIsIGJ1dCBJ DQo+IHRoaW5rIHRoZXJlIG1heSBiZSBhbiBpc3N1ZSBpbiB0aGVyZSB3aGVyZSB0b28gbWFueSBN VVNUcyBhcmUNCj4gcHJvaGliaXRpbmcgY29tbW9uIG9wdGltaXphdGlvbnMuICBEZWZpbml0ZWx5 IG5lZWQgdG8gdGFrZSBhIGxvb2sgYXQNCj4gdGhhdC4gIEkgdGhpbmsgdGhlIHJpZ2h0IGFuc3dl ciBoZXJlIGlzIHRvIGNoZWNrIHRoZSBleGlzdGluZyB0ZXh0IGZvcg0KPiBiZWluZyB0b28gcGVk YW50aWMgYW5kIGNvbXBhcmUgaXRzIGxlbmd0aCAmIGNvbXBsZXhpdHkgd2l0aCB0aGUNCj4gb3B0 aW1pemF0aW9uIHlvdSBkZXNjcmliZSAod2hpY2ggSSBhZ3JlZSBpcyBob3cgdGhpcyBzaG91bGQg cmVhbGx5IGJlDQo+IGltcGxlbWVudGVkKS4NCj4gDQoNCkkgZG9uJ3QgYmVsaWV2ZSB0aGUgY3Vy cmVudCB0ZXh0IGlzIGltcGxlbWVudGFibGUgLSBpdCBpcyBjb25mdXNpbmcgYXQgYmVzdC4gIEl0 IG5lZWRzIHRvIGJlIHJld29yZGVkIGZvciBjbGFyaXR5LiAgQSByZXdvcmRpbmcgYWxvbmcgdGhl IGxpbmVzIG9mIHdoYXQgSSB3cm90ZSBpcyBvbmUgcG9zc2liaWxpdHkuIA0KDQpCZXN0LA0KVmlk eWENCg== From bbl@lowekamp.net Tue May 12 19:26:22 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 9295A3A6D6B for ; Tue, 12 May 2009 19:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.109, 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 rcDb7ZdQHW0F for ; Tue, 12 May 2009 19:26:21 -0700 (PDT) Received: from mail-fx0-f158.google.com (mail-fx0-f158.google.com [209.85.220.158]) by core3.amsl.com (Postfix) with ESMTP id 4A3353A6841 for ; Tue, 12 May 2009 19:26:21 -0700 (PDT) Received: by fxm2 with SMTP id 2so361031fxm.37 for ; Tue, 12 May 2009 19:27:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.114.68 with SMTP id d4mr199773faq.86.1242181670645; Tue, 12 May 2009 19:27:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 May 2009 22:27:50 -0400 Message-ID: From: Bruce Lowekamp To: "Narayanan, Vidya" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] Section 9 of RELOAD - Comments 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, 13 May 2009 02:26:22 -0000 On Tue, May 12, 2009 at 2:44 PM, Narayanan, Vidya wro= te: > > >> > Joining (Section 9.5): >> > ---------------------- >> > It is not clear why the join procedure requires all neighbor and >> finger connections to be established prior to sending the JOIN message >> itself. =C2=A0To be functional in the overlay, only the immediate succes= sor >> relationships must be correctly in place. =C2=A0The other successors, >> predecessors and fingers can be established subsequently. =C2=A0This als= o >> doesn't cause nodes to establish unnecessary connections unless the >> node has successfully joined. =C2=A0There is also the question of whethe= r a >> JP is supposed to establish a TLS connection to the BP to send messages >> through it, which is presently not addressed in the draft. =C2=A0It seem= s to >> me that a more streamlined join process can be defined as follows: >> > >> >> You're right that it's just an optimization to have finger table >> entries, but it's not completely clear to me that adding a new peer >> without finger table entries provides a benefit to the overlay. =C2=A0I = can >> see that being a SHOULD, though. >> > > The finger entries must be added upon Join. =C2=A0I'm not saying that the= peer can wait longer to do that. =C2=A0However, there is no gain in doing = the finger connections upfront - it is not like the AP or any node tries to= verify that has happened. =C2=A0So, in terms of processing the join, it is= the same. =C2=A0And, it makes more sense to go through those after a succe= ssful join, rather than having to tear down if the node is unable to join f= or any reason. > In terms of processing the join, completely agree, but in terms of overall overlay routing efficiency, it's better to delay the join until the finger table connections are complete, otherwise you add more linear routing to the overlay. Difficult to compare routing efficiency vs the odds that a node is unable to join, but my instinct leans toward routing efficiency. > > >> > Further, having the enrollment server involved in specifying the >> frequency of updates and probes seems strange. =C2=A0How is the enrollme= nt >> server supposed to know the magic values here? It seems like it should >> be enough to specify a recommended value and leave it at that. =C2=A0Sin= ce >> the finger stabilization is for optimization and the neighbor >> stabilization is reactive anyway in the present draft, having these >> parameters in the config document seem to be of little use. >> > >> >> Are you revisiting the issue of wanting to split the authority for >> enrollment and config files, or are you questioning whether it should >> be possible to specify update frequency in a config file at all? >> > > The latter - I'm not seeing a need for these being configurable. > I'm inclined to leave them configurable unless there is a significant reason not to. I'm actually inclined to make quite a few of the other constants specified in the current draft configurable. >> >> > Finger entries (Section 9.7.3 and elsewhere): >> > --------------------------------------------- >> > The draft requires 16 finger table entries - at first, I took those >> to mean 16 different resource ids that will be probed per formula. >> =C2=A0After reading 9.7.3, it appears that it is talking about 16 differ= ent >> fingers that a node should maintain. =C2=A0In a small overlay, that's >> ridiculously large. =C2=A0The text is also unclear on what happens when = the >> overlay shrinks. =C2=A0Further, the text states that a peer SHOULD consi= der >> the finger table entry valid if it is in the range [n + >> 2^(numBitsInNodeId-i), n + 1.5 x 2^(numBitsInNodeId-i)]. For small >> overlays, there may be no entries in this range for every i in [0, >> 127]. >> > >> >> The text was left the way it is in an effort to make it simpler, but I >> think there may be an issue in there where too many MUSTs are >> prohibiting common optimizations. =C2=A0Definitely need to take a look a= t >> that. =C2=A0I think the right answer here is to check the existing text = for >> being too pedantic and compare its length & complexity with the >> optimization you describe (which I agree is how this should really be >> implemented). >> > > I don't believe the current text is implementable - it is confusing at be= st. =C2=A0It needs to be reworded for clarity. =C2=A0A rewording along the = lines of what I wrote is one possibility. > Will definitely make a pass at that. Thanks for the text. Bruce > Best, > Vidya > From Even.roni@huawei.com Mon May 25 04:59:10 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 B235828C1A6 for ; Mon, 25 May 2009 04:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.227 X-Spam-Level: * X-Spam-Status: No, score=1.227 tagged_above=-999 required=5 tests=[AWL=1.966, BAYES_20=-0.74, 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 yArQAZZ9HD58 for ; Mon, 25 May 2009 04:59:05 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1D2C33A6F7B for ; Mon, 25 May 2009 04:59:05 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK7005JS817T4@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 25 May 2009 20:00:43 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KK7001MQ817KZ@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 25 May 2009 20:00:43 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-101-49.red.bezeqint.net [79.182.101.49]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KK700A5680XWF@szxml01-in.huawei.com> for p2psip@ietf.org; Mon, 25 May 2009 20:00:43 +0800 (CST) Date: Mon, 25 May 2009 14:59:43 +0300 From: Roni Even To: p2psip@ietf.org Message-id: <007801c9dd30$52b93d10$f82bb730$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Mmllzb/3+sxPcgC2CHjJSw)" Content-language: en-us Thread-index: AcndMEnzLiDiH0R2R/mVV8D7BIh7NA== Subject: [P2PSIP] Transport parameter used in section 5.5.2.1 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, 25 May 2009 11:59:10 -0000 This is a multipart message in MIME format. --Boundary_(ID_Mmllzb/3+sxPcgC2CHjJSw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, IceLiteCandidate defined is section 5.5.2.1 is using a parameter called Transport. I could not find the specification for this parameter in the document. I think the name was changed in the 01 draft to OverlayLink Thanks Roni Even --Boundary_(ID_Mmllzb/3+sxPcgC2CHjJSw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

IceLiteCandidate defined is section 5.5.2.1 is using a parameter called Transport. I could not find the specification for this parameter in the document.

I think the name was changed in the 01 draft to OverlayLink

Thanks

Roni Even

--Boundary_(ID_Mmllzb/3+sxPcgC2CHjJSw)-- From hishigh@gmail.com Wed May 27 04:17: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 B0F623A6C58 for ; Wed, 27 May 2009 04:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.513 X-Spam-Level: X-Spam-Status: No, score=-1.513 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=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 rcEed-RVx-vc for ; Wed, 27 May 2009 04:17:48 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id E69C23A6B93 for ; Wed, 27 May 2009 04:17:47 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so4640378yxb.49 for ; Wed, 27 May 2009 04:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=1FaIf+ldoUjTPC1SpJvj+tMkt6col+5qyu7e3KJ9a3M=; b=Tf5Wk93MVXn6qenA1DpFX5AuwJNd/0PAcR3IBzLHs/3Q5QW6BYDll8F1hlt509R7li 46osoWfRpHtWQ3aWqpHNISOZoHavUkNa/UhvFwA3b05JNiA8D/fkBOxEmjk5V9eiQIjC gmDFhOA8BtykwuZeOJP72hDU9vd/34oy4l2I0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VwRGzV9uSfoT7jIOk3EfLbFrxI9ExSaEaljVjyDs12kRloAKHWXnwRkpOFkZlUFp9L KNCXPbui1626E00rqabY2OT9BQP6iMOwz1WufHESo11WjQKVgwnCdyOXTfPoxqR4tgO9 hLh9zXme02XbEZwlQ0ODXpdDgUU3vmpWUHiOI= MIME-Version: 1.0 Received: by 10.151.111.13 with SMTP id o13mr18962980ybm.259.1243422674070; Wed, 27 May 2009 04:11:14 -0700 (PDT) Date: Wed, 27 May 2009 19:11:14 +0800 Message-ID: <8bd755250905270411y772ceb93ua1945de3adb86664@mail.gmail.com> From: yunfei zhang To: P2PSIP Mailing List Content-Type: multipart/alternative; boundary=00151750e5aecb2bb8046ae2e64a Subject: [P2PSIP] problem statement of peer to peer streaming protocol 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, 27 May 2009 11:17:48 -0000 --00151750e5aecb2bb8046ae2e64a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,all, I have submitted problem statement draft of peer to peer streaming protocol(PPSP)to IETF website in the following link.(http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-03.txt) which may related to P2PSIP WG.Any comments and suggestions are highly welcome. The abstract is as follows: We propose to develop an open peer-to-peer (P2P) streaming protocol named PPSP. This document describes the problems related to PPSP and outlines considerations that have to be taken in account when arriving at equitable solutions. BR Yunfei --00151750e5aecb2bb8046ae2e64a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,all,
=A0=A0=A0 I have submitted problem s= tatement draft of peer to peer streaming protocol(PPSP)to IETF website in t= he following link.(= http://www.ietf.org/internet-drafts/draft-zhang-ppsp-problem-statement-03.t= xt) =A0which may related to=A0= P2PSIP WG.Any comments and suggestions are highly welcome.=20
=A0=A0=A0=A0=A0=A0 The abstract is a= s follows:

We propose to develop an open peer-to-peer (P2P) streaming protoco= l named PPSP. This document describes the problems related to PPSP and outl= ines considerations that have to be taken in account when arriving at equit= able solutions.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0 BR

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yunfei<= /span>

--00151750e5aecb2bb8046ae2e64a-- From jiang.x.f@huawei.com Sat May 30 18:44:17 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 A85EB3A68CC for ; Sat, 30 May 2009 18:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.042 X-Spam-Level: X-Spam-Status: No, score=-0.042 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, 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 oa4nXLjtiT9I for ; Sat, 30 May 2009 18:44:16 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B769B3A6452 for ; Sat, 30 May 2009 18:44:16 -0700 (PDT) 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 <0KKH00J6VJKFEF@szxga03-in.huawei.com> for p2psip@ietf.org; Sun, 31 May 2009 09:45:51 +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 <0KKH00LBCJKFED@szxga03-in.huawei.com> for p2psip@ietf.org; Sun, 31 May 2009 09:45:51 +0800 (CST) Received: from j36340a ([10.164.12.19]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KKH00MF8JKE2G@szxml06-in.huawei.com> for p2psip@ietf.org; Sun, 31 May 2009 09:45:51 +0800 (CST) Date: Sun, 31 May 2009 09:45:50 +0800 From: jiangxingfeng To: p2psip@ietf.org Message-id: <018901c9e191$870aa8a0$130ca40a@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=UTF-8 Content-transfer-encoding: 7BIT Thread-index: AcngbJPy1d6CzGV5RH+Rk60sntNOhgBIzTRw Cc: ron.even.tlv@gmail.com Subject: [P2PSIP] FW: I-D Action:draft-jiang-p2psip-relay-02.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: Sun, 31 May 2009 01:44:17 -0000 Hi, all: A new revision for proposing DRR and RPR routing mode in P2PSIP has been submitted. Please access the link http://www.ietf.org/internet-drafts/draft-jiang-p2psip-relay-02.txt to take a look. Any comments and questions are welcome. Compared with version 01, the new draft makes significant changes. Authors re-organize the draft to make split DRR and RPR related contents easily and gives specific scenarios where DRR and RPR works. According to the minutes of IETF74, DRR has been accepted by the WG as a work item. So authors hope the contents in the revision for the DRR can be as a base for DRR work item. We also hope to get more comments and questions on RPR and hope WG can decide whether or not accept RPR as an another work item. Look forward to your comments. Regards Jiang XingFeng -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Friday, May 29, 2009 10:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-jiang-p2psip-relay-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An extension to RELOAD to support Direct Response and Relay Peer routing Author(s) : X. Jiang, et al. Filename : draft-jiang-p2psip-relay-02.txt Pages : 20 Date : 2009-05-29 This document proposes an extension to RELOAD to support direct response and relay peer routing modes. RELOAD recommends symmetric recursive routing for routing messages. The new extensions provide a shorter route for responses and describes the potential cases where these extensions can be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jiang-p2psip-relay-02.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.