From p2psip-bounces@ietf.org Mon Jul 02 02:50:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5FjY-00081B-1L; Mon, 02 Jul 2007 02:50:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5FjW-0007lk-9l for p2psip@ietf.org; Mon, 02 Jul 2007 02:50:02 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5FjR-0000iS-SU for p2psip@ietf.org; Mon, 02 Jul 2007 02:50:02 -0400 Received: from [65.65.155.30] (helo=[192.168.1.2]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I5FjQ-0004pr-3G; Mon, 02 Jul 2007 01:49:56 -0500 In-Reply-To: <4686F473.5020709@sip-communicator.org> References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> <467DB508.6040108@sip-communicator.org> <4684DBF1.4000203@sip-communicator.org> <0EC20206-306D-4E5F-BA1C-BC26919F5FEB@softarmor.com> <46859661.3040300@sip-communicator.org> <4F9C8C9A-0F3F-4123-B332-2617CBFBBB12@softarmor.com> <4686F473.5020709@sip-communicator.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Peer protocol, DHT and running code Date: Mon, 2 Jul 2007 01:49:41 -0500 To: Emil Ivov X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jun 30, 2007, at 7:25 PM, Emil Ivov wrote: > >> but protocols need to be amenable to this sort of tunneling even >> if we don't standardize it. >> But the FIREWALL doesn't keep track of TCP connections. It just looks >> at syn/ack to determine whether an incoming packet appears to be >> part of an established TCP flow. If it is an initial connection >> "opening" from outside, it gets discarded. This is completely >> stateless inspection on the firewall. It does leave one a bit open to >> SYN-flood DOS attacks, but there are other workarounds for that. > > Well, isn't it quite obvious that this kind of firewalls won't work > for > P2P even when TCP based because it won't allow for end-to-end > simultaneous connection establishment? > They work if one can find something like a STUN-relay for TCP out in public address space. This seems to work for at least one VoIP application widely advertised to be P2P. If that STUN-relay like thing is also a peer, which the nodes-behind- firewalls found using the overlay, then it seems like we'd have a working P2P scenario. >> Now if you can figure all this out, let me know and I'm sure I can >> find some startup money to make us both rich! > > Heey, no problem. I am sure that if we start entangling photons right > now in a month or two we'll be able to build a quantum firewall and > it'll be doing all kinds of magic, so you better get that money > ready! :-)) Cool! I'm on it! I hear venture money is falling out of trees these days . . . unfortunately, I'm in the desert this week and there aren't any trees, but next week is looking good. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 02 03:13:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5G69-0004CM-Qu; Mon, 02 Jul 2007 03:13:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5G68-0004CH-Ml for p2psip@ietf.org; Mon, 02 Jul 2007 03:13:24 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5G62-0004kg-MO for p2psip@ietf.org; Mon, 02 Jul 2007 03:13:24 -0400 Received: (qmail 25647 invoked for bounce); 2 Jul 2007 09:15:28 -0000 Received: from unknown (HELO ?192.168.0.1?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 2 Jul 2007 09:15:28 -0000 Message-ID: <4688A58D.7070904@sip-communicator.org> Date: Mon, 02 Jul 2007 09:13:17 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070622) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] Peer protocol, DHT and running code References: <4674F5ED.9070000@telecomitalia.it> <7E1BE70B-2F19-494C-931A-E0758FF75C5E@magma.ca> <4678E6B4.8090000@telecomitalia.it> <23314627-21D2-4F8D-88A3-87AA97C913D2@magma.ca> <46797C8A.6070600@telecomitalia.it> <075a01c7b451$43bd0440$640fa8c0@cis.neustar.com> <077b01c7b465$948c2ea0$640fa8c0@cis.neustar.com> <467D9FA2.4030404@softarmor.com> <467DB508.6040108@sip-communicator.org> <4684DBF1.4000203@sip-communicator.org> <0EC20206-306D-4E5F-BA1C-BC26919F5FEB@softarmor.com> <46859661.3040300@sip-communicator.org> <4F9C8C9A-0F3F-4123-B332-2617CBFBBB12@softarmor.com> <4686F473.5020709@sip-communicator.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean Willis wrote: > On Jun 30, 2007, at 7:25 PM, Emil Ivov wrote: > >>> but protocols need to be amenable to this sort of tunneling even >>> if we don't standardize it. But the FIREWALL doesn't keep track >>> of TCP connections. It just looks at syn/ack to determine whether >>> an incoming packet appears to be part of an established TCP >>> flow. If it is an initial connection "opening" from outside, it >>> gets discarded. This is completely stateless inspection on the >>> firewall. It does leave one a bit open to SYN-flood DOS attacks, >>> but there are other workarounds for that. >> Well, isn't it quite obvious that this kind of firewalls won't work >> for P2P even when TCP based because it won't allow for end-to-end >> simultaneous connection establishment? >> > > They work if one can find something like a STUN-relay for TCP out in > public address space. This seems to work for at least one VoIP > application widely advertised to be P2P. > > If that STUN-relay like thing is also a peer, which the nodes-behind- > firewalls found using the overlay, then it seems like we'd have a > working P2P scenario. Relaying certainly makes sense for media, but I was actually referring to the peer protocol and connections among peers. The VoIP application widely advertised as P2P, that I think you are referring to, would indeed work behind these firewalls but only as a client. I don't think that nodes located behind them would be promoted to peers (or super nodes or whatever). >>> Now if you can figure all this out, let me know and I'm sure I >>> can find some startup money to make us both rich! >> Heey, no problem. I am sure that if we start entangling photons >> right now in a month or two we'll be able to build a quantum >> firewall and it'll be doing all kinds of magic, so you better get >> that money ready! :-)) > > Cool! I'm on it! I hear venture money is falling out of trees these > days . . . unfortunately, I'm in the desert this week and there > aren't any trees, but next week is looking good. OK, then alternately, I could take care of the money, and you could take care of the photons! Cheers Emil > > -- Dean > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 02 05:15:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5I0I-0006Hw-0s; Mon, 02 Jul 2007 05:15:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5I0G-0006Ho-I6 for p2psip@ietf.org; Mon, 02 Jul 2007 05:15:28 -0400 Received: from web52507.mail.re2.yahoo.com ([206.190.48.190]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5Hzg-0007cT-UI for p2psip@ietf.org; Mon, 02 Jul 2007 05:15:28 -0400 Received: (qmail 46683 invoked by uid 60001); 2 Jul 2007 09:14:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=uf68BQnTkfCe6PrlGriR2f0dWzpG6HlQoBAILvjy/t37PgTVy19Ro5Ow/2mx1Rvr/ILyS5vfzrcBTNCAXYjkyF52PfflNizqzPbKvgQmYQlzMsB0P6/PVabjZvlvWXT3Tzw3wSc9FGoU8Ov4vSkh3+8Yvg+HUu6V3BEMtoYrxow=; X-YMail-OSG: P75IvG8VM1mQBVp502CExfGx1drGhSED9PvnhoaX4Bu4VjuHW40Kl2GB68ENK0DRnUycTKbpv8aLzrljQy2n.IsTLWmxTUJCoAnzeLlf65nZW0htf_YKBCvbxd2fHsgXxLjgfOsLJQug8M5er2YP2.TdBA-- Received: from [212.2.96.100] by web52507.mail.re2.yahoo.com via HTTP; Mon, 02 Jul 2007 02:14:52 PDT Date: Mon, 2 Jul 2007 02:14:52 -0700 (PDT) From: Krzysztof Hennig Subject: Re: [P2PSIP] Question on additional services To: Victor Pascual "Ávila" In-Reply-To: <618e24240706300927j215d3272s773501b3999af520@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <807457.46675.qm@web52507.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Victor, In general DHT may keep any type of mapping you want to store. Current discussion covers only storing AoR <-> Contact URI mapping. It may also store presence status, xcap profiles, waiting instant messages and others. Our research team is focusing on providing Value Addes Services for P2P SIP. One of such scenarios is Voice Mail based on presence. In the this case we have been thinking of an agent (say Service Agent) that is responsible for Service State for one specific user, in this scenario: voice calls. The Service Agent is selected randomly as usual in P2P eg. during bootstraping process. Then this agent could make Call Forwarding decisions. To add new services we were thinking of other Agent (say Profile Agent) that would keep user's profile (xcap, presence, other parameter). That agent would provide Service Agents with some parameters that Service Agents could use to determine Call Forwarding decisions. Each service could have some parameters as URN to define it's specific behavior. As an example proposed LOCSER SIP method could be reused to lookup users Profile Agent and fetch users profile by Service Agents. It would work like OPTIONS but would query for user's capabilities rather that users device capabilities. End user could publish, update or remove it's profile by this method. Again LOCSER could be reused. I know that above solution causes big overhead on communication and peer node performance but enables more services to be deployed more quickly. Beside this above scenario has lots of security issues eg. how to allow 3rd party to store data on your peer node? In addition a open framework for Service to URN mapping has to be developed. In GSM Architecture such agents are: Home Location Register (as PA), Visited MSC (as SA). In IMS architecture such agents are: Home Subscriber Server (as PA), S-CSCF (as AS). Do we need to follow this architecture? Our team has not yet defined where in the P2P reference model (concepts-04) all above agents would be placed. However, architecture it would be distributed for sure! Does anyone have thoughts about this vision? kind regards! Krzysztof +48 601 134 075 --- Victor Pascual Ávila wrote: > Hello, > As far as I know, DHT is as a distributed database > used to store the > information required to provide the mapping between > AoRs and Contact URIs. > It is exepected that DHT may also store information > required to provide > other services required to form and operate or just > enhance basic > functionalities. > Should these additional services be distributed? So > that the loss of a peer > does not result in the loss of a service. > > > Thanks in advance, > Victor Pascual > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ____________________________________________________________________________________ Get the free Yahoo! toolbar and rest assured with the added security of spyware protection. http://new.toolbar.yahoo.com/toolbar/features/norton/index.php _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 02 07:25:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5K1X-00047E-3F; Mon, 02 Jul 2007 07:24:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5K1U-0003tg-CX; Mon, 02 Jul 2007 07:24:52 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5K1P-0006Mr-Ul; Mon, 02 Jul 2007 07:24:52 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Mon, 2 Jul 2007 13:24:46 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Jul 2007 13:24:44 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: AW: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P torealize presence and IM services? Date: Mon, 2 Jul 2007 13:24:43 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> In-Reply-To: <20070629092928.9153FDED81@mail.orgltd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P torealize presence and IM services? Thread-Index: Ace6GZIu3gmGf2+MQsukwUUTYgUwQAAA5nswAAMa6lAAAzzO4ACX3EKw From: "Beck01, Wolfgang" To: , , X-OriginalArrivalTime: 02 Jul 2007 11:24:44.0326 (UTC) FILETIME=[97092460:01C7BC9B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > Vikas Tandon [mailto:vikas.tandon@orgltd.com] wrote: >=20 > I'm not sure how well this goes with the SIMPLE concepts. However doing P2P will increase the traffic between=20 > the peers since every presence update needs to be sent to every buddy in the buddylist which is heavy on the=20 > mobile devices and networks. Also P2P will not help in having other services utilize presence information.=20 Presence scalability is an issue even with C/S SIP. The real difficulty with NOTIFY is that different watchers may see different presence documents, due to the presentity's policies. Off-line presence brings further complications. Some random thoughts: If a group of watchers receives the same presence document, an application layer multicast may distribute the load between devices. Could draft-ietf-sip-uri-list-message be abused for this purpose? A peer receiving a NOTIFY with a recipient-list forwards it to some contacts mentioned there (removing those contacts from the recipient-list before sending). Possible, but I don't want to write the Security Considerations section.. Offline presence can be done by storing a user's presence document like a file in P2P file sharing networks. To meet the presentity's policy, we would need some elaborate encryption scheme, so that watchers can only those parts they are allowed to see. Multiple versions of the presence document might be necessary, one for every watcher/presentity pair. Wolfgang _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 02 08:43:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5LFK-0001EY-76; Mon, 02 Jul 2007 08:43:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5LFJ-0001ES-54 for p2psip@ietf.org; Mon, 02 Jul 2007 08:43:13 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5LF9-00080I-Jm for p2psip@ietf.org; Mon, 02 Jul 2007 08:43:13 -0400 Received: by wa-out-1112.google.com with SMTP id k17so2618943waf for ; Mon, 02 Jul 2007 05:43:02 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=BzJNGfiZu/O1GoPOfgpppMOZA4gSA6T/aTAzUWqw4n+74V+hYAYGc87yZ7/AMKoxsVMgTbQRd3+huNYPtI+KB/8QOFGSydCVdr1vI/fWRMBP4QXanvJIHksAFw+I569PaJdu93B9agehHnwQlnuH9UtzzcBF2UeueJbmAN4wtyk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Z4zixADu5hcDTLQMvtjALS0zzoSt+CFIHkxgTBmapLT7a/qeuQK4zyL2TdV6iNoZOTvtNT/pizkXMFvQjD91SIbgEOoDOFDvFQMnMsBZNrVyG/gvFVRGAsWy69KDkiqlr9vV7gP72nxjfbwAn/OVowN+b1JityJMqGZQHXpeQaI= Received: by 10.114.155.1 with SMTP id c1mr5078091wae.1183380182628; Mon, 02 Jul 2007 05:43:02 -0700 (PDT) Received: by 10.114.113.13 with HTTP; Mon, 2 Jul 2007 05:43:02 -0700 (PDT) Message-ID: <618e24240707020543y704e4675y5bf385bf7a9541c5@mail.gmail.com> Date: Mon, 2 Jul 2007 14:43:02 +0200 From: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" To: "Krzysztof Hennig" Subject: Re: [P2PSIP] Question on additional services In-Reply-To: <807457.46675.qm@web52507.mail.re2.yahoo.com> MIME-Version: 1.0 References: <618e24240706300927j215d3272s773501b3999af520@mail.gmail.com> <807457.46675.qm@web52507.mail.re2.yahoo.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1241286033==" Errors-To: p2psip-bounces@ietf.org --===============1241286033== Content-Type: multipart/alternative; boundary="----=_Part_105955_29329698.1183380182599" ------=_Part_105955_29329698.1183380182599 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Krzysztof, thank you for your explanation. On 02/07/07, Krzysztof Hennig wrote: > > Does anyone have thoughts about this vision? > IMHO, using SOA (service oriented architecture) makes sense. DHT could act as 'Service broker', 'n' Agents could act as a 'service provider' and 'n*m' Agents could act as a 'service implementor'. Then 'Service providers' could be able to publish (using the DHT) services implemented by 'service implementors'. Does it make sense??? Thanks in advance, Victor Pascual ------=_Part_105955_29329698.1183380182599 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Krzysztof,
thank you for your explanation.

On 02/07/07, Krzysztof Hennig <krzysztof_hennig@yahoo.com > wrote:
Does anyone have thoughts about this vision?

IMHO, using SOA (service oriented architecture) makes sense. DHT could act as 'Service broker', 'n' Agents could act as a 'service provider' and 'n*m' Agents could act as a 'service implementor'. Then 'Service providers' could be able to publish (using the DHT) services implemented by 'service implementors'.
Does it make sense???

Thanks in advance,
Victor Pascual
------=_Part_105955_29329698.1183380182599-- --===============1241286033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1241286033==-- From p2psip-bounces@ietf.org Mon Jul 02 10:39:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5N3T-0004gB-9I; Mon, 02 Jul 2007 10:39:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5N3R-0004g4-1R for p2psip@ietf.org; Mon, 02 Jul 2007 10:39:05 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5N3K-0000Tl-Bb for p2psip@ietf.org; Mon, 02 Jul 2007 10:39:05 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Jul 2007 10:38:58 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAC6qiEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,487,1175486400"; d="scan'208"; a="125043765:sNHT29464012" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l62EcwKP011012 for ; Mon, 2 Jul 2007 10:38:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l62EcWsM022911 for ; Mon, 2 Jul 2007 14:38:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 10:38:48 -0400 Received: from [10.86.241.79] ([10.86.241.79]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 10:38:47 -0400 Message-ID: <46890DFA.7000408@cisco.com> Date: Mon, 02 Jul 2007 10:38:50 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2007 14:38:47.0892 (UTC) FILETIME=[B3245140:01C7BCB6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1198; t=1183387138; x=1184251138; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20New=20Draft=3A=20ASP=20-=20a=20binary=20p2p=20protocol |Sender:=20 |To:=20P2PSIP=20WG=20; bh=cIJcnivd7R9hqewkEi7VB1cr59cMj2cP+3kXYxy0DRw=; b=C2iL4e7EQ+mt2iiIoeGHoX+Sn+kYL9SDEgN/ebBpEJYOA1T6sVWAfcniX3iUR8P66rXmR5FM 7pP77yfaGHvuQaA7wHRFW1bMQSVWzZsWKdntDcNsmru46HBZ0OprEMFy; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [P2PSIP] New Draft: ASP - a binary p2p protocol X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Ekr, Cullen and I have just submitted a new I-D, which you can find here: http://www.ietf.org/internet-drafts/draft-jennings-p2psip-asp-00.txt This draft proposes a binary peer protocol called ASP - Address Settlement by Peer-to-Peer. Its rough in places but we tried to focus on a few areas that we felt were important in the design of a p2p protocol: * security model * layering * notion of 'usages' and data types that can be added to the protocol * NAT traversal - how to allow peers to act as STUN/TURN servers, and how to store and find them in the DHT, and how to use ICE to establish sip and p2p connectivity * what it means to have pluggable DHT and what the API looks like * how to do message forwarding with a focus on performance * how to handle protocol extensibility Questions and comments are welcome of course. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 02 15:06:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RES-0003fn-UT; Mon, 02 Jul 2007 15:06:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5REP-0003fT-MK for p2psip@ietf.org; Mon, 02 Jul 2007 15:06:41 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5REL-0001n6-75 for p2psip@ietf.org; Mon, 02 Jul 2007 15:06:41 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Mon, 2 Jul 2007 12:06:25 -0700 From: "David Barrett" To: "'Beck01, Wolfgang'" , , , Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? Date: Mon, 2 Jul 2007 12:06:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace6GZIu3gmGf2+MQsukwUUTYgUwQAAA5nswAAMa6lAAAzzO4ACX3EKwABFpl+A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] > > Presence scalability is an issue even with C/S SIP. Am I misunderstanding you, or are you saying client-server architectures have difficulty scaling presence-based applications? Hasn't AIM, MSN, ICQ, YahooIM, and basically every IM on the planet successfully demonstrated that C/S architectures can scale presence-based applications to, well, the entire planet? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 02 15:12:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RKG-0008Qt-BO; Mon, 02 Jul 2007 15:12:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RKD-0008Pc-Qg; Mon, 02 Jul 2007 15:12:41 -0400 Received: from shaman.nostrum.com ([72.232.15.10] helo=nostrum.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5RK5-0002hF-Kg; Mon, 02 Jul 2007 15:12:41 -0400 Received: from [172.17.1.65] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.1/8.14.1) with ESMTP id l62JCQqc022995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Jul 2007 14:12:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? Date: Mon, 2 Jul 2007 14:12:25 -0500 To: "David Barrett" X-Mailer: Apple Mail (2.752.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: p2psip@ietf.org, vikas.tandon@orgltd.com, simple@ietf.org, "'Beck01, Wolfgang'" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David - He's referring to the discussion and analysis taking place in SIMPLE. See http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- scaling-analysis-00.txt for that background. RjS On Jul 2, 2007, at 2:06 PM, David Barrett wrote: >> -----Original Message----- >> From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] >> >> Presence scalability is an issue even with C/S SIP. > > Am I misunderstanding you, or are you saying client-server > architectures > have difficulty scaling presence-based applications? Hasn't AIM, > MSN, ICQ, > YahooIM, and basically every IM on the planet successfully > demonstrated that > C/S architectures can scale presence-based applications to, well, > the entire > planet? > > -david > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 02 17:00:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5T0w-0003C3-9n; Mon, 02 Jul 2007 17:00:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5T0v-0003Bp-2J for p2psip@ietf.org; Mon, 02 Jul 2007 17:00:53 -0400 Received: from web52508.mail.re2.yahoo.com ([206.190.48.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5T02-0005HO-GV for p2psip@ietf.org; Mon, 02 Jul 2007 17:00:53 -0400 Received: (qmail 8447 invoked by uid 60001); 2 Jul 2007 20:53:17 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ST9A8IUS0siqZ4KczzrcHk+Ztzu/8wAa98tSAlsQQ2//t9z6HqgNU3TyWW+nwtX2auM+kYbntSYgL0UXX5bfsJ91xtSy86+NEAdnRa2Me32Mce4BVYIRogqbETr9B3c+vYubbVOd5+K6Yf+jdkn9CRXCow6PhxUTqFlKLVQ3W4s=; X-YMail-OSG: qRee4PkVM1nlT4Om9JKUN.Evitj7cgRa1HqIAiuQJh._otWb14B72qRZCMh_X718LKe3keSz678KzDOBWTUl6bFBRJK4IyOsksv78UMFTc.y97tKdwcff4nDq9jmqg-- Received: from [212.76.43.10] by web52508.mail.re2.yahoo.com via HTTP; Mon, 02 Jul 2007 13:53:17 PDT Date: Mon, 2 Jul 2007 13:53:17 -0700 (PDT) From: Krzysztof Hennig Subject: Re: [P2PSIP] Question on additional services To: Victor Pascual "Ávila" In-Reply-To: <618e24240707020543y704e4675y5bf385bf7a9541c5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <713656.8020.qm@web52508.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Victor Pascual, I can agree with you. SOA approach makes sense. However SOA as it is shown in enterprise environment in my opinion is not a goot choice. We need something simpler but also service oriented. I see that above DHT (routing & storage layer in P2P SIP) there must exist some entities which may work as a service provider, service implementor or service data storage. I may misunderstand the way you described SOA, but in all systems I learned there has been always a processing node and storage node. Can you please describe 'service provider', 'service implementor' a bit more from functional point of view? Where in your model are A-party UA and B-party UA? How do they set up a service profile? IMHO we also have to think wether we need only simple profile/parameter fetch or full orchestration between controlling peer and service data peer. The latter scenario seems more flexible however requires more CPU on service handling peer, more bandwidth to pass all messages and causes longer delays in processing. In my opinion the latter case is not suitable for case when peer is located in radio network (see discussion about battery life). I am also not convinced wether exchanging big XML documents describing service profile is a good solution. Issues are the same: CPU, bandwidth and delays. If we provide a lightweight mechnism for this (eg. XPath), we could put service controlling entity in a mobile handset with limited battery capabilities. Taking into consideration all above I have a feeling that we are getting closer to C/S model instead of distributing it among peers. Even worse, it looks like the control point is somewhere in the network but not in the end UA's as it is today within the Internet with HTTP. Do you have the same feeling? We can conclude that at least we have to work out a naming convention for service entities or agents to understand each other. What do you think ? Is there already any draft, framework or concept within P2PSIP covering this? kind regards! /Krzysztof --- Victor Pascual Ávila wrote: > Hi Krzysztof, > thank you for your explanation. > > On 02/07/07, Krzysztof Hennig > wrote: > > > > Does anyone have thoughts about this vision? > > > > IMHO, using SOA (service oriented architecture) > makes sense. DHT could act > as 'Service broker', 'n' Agents could act as a > 'service provider' and 'n*m' > Agents could act as a 'service implementor'. Then > 'Service providers' could > be able to publish (using the DHT) services > implemented by 'service > implementors'. > Does it make sense??? > > Thanks in advance, > Victor Pascual > ____________________________________________________________________________________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 03 00:10:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ZiN-0007xU-Av; Tue, 03 Jul 2007 00:10:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5ZiL-0007x6-WA for p2psip@ietf.org; Tue, 03 Jul 2007 00:10:10 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5ZhF-0005Yp-UE for p2psip@ietf.org; Tue, 03 Jul 2007 00:10:09 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Mon, 2 Jul 2007 21:08:54 -0700 From: "David Barrett" To: "'Robert Sparks'" Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? Date: Mon, 2 Jul 2007 21:08:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: Ace83RnMqO3krqCLR1KPaMaEnYXZzAAQToEA X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: p2psip@ietf.org, vikas.tandon@orgltd.com, simple@ietf.org, "'Beck01, Wolfgang'" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: Thanks, very cool. Am I correct in understanding that the document estimates that: - 2 presence domains - With 20k online users in each domain - Would result in 489 messages per second between domains - Producing 830KBps (6.48Mbps) of sustained traffic between domains Have you been able to calibrate the assumptions of that document against the real-world traffic experienced by any of the many IM vendors out there? Is there anybody using SIMPLE in the real world that can confirm the assumptions about average message sizes and such? -david > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com] > Sent: Monday, July 02, 2007 12:12 PM > To: David Barrett > Cc: 'Beck01, Wolfgang'; vikas.tandon@orgltd.com; melodysong@huawei.com; > simple@ietf.org; p2psip@ietf.org > Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into > P2Ptorealize presence and IM services? > > David - > > He's referring to the discussion and analysis taking place in SIMPLE. > See http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- > scaling-analysis-00.txt > for that background. > > RjS > > On Jul 2, 2007, at 2:06 PM, David Barrett wrote: > > >> -----Original Message----- > >> From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] > >> > >> Presence scalability is an issue even with C/S SIP. > > > > Am I misunderstanding you, or are you saying client-server > > architectures > > have difficulty scaling presence-based applications? Hasn't AIM, > > MSN, ICQ, > > YahooIM, and basically every IM on the planet successfully > > demonstrated that > > C/S architectures can scale presence-based applications to, well, > > the entire > > planet? > > > > -david > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 03 01:16:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5akp-00038s-Cl; Tue, 03 Jul 2007 01:16:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5akn-00038m-PA for p2psip@ietf.org; Tue, 03 Jul 2007 01:16:45 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5ajy-0002nC-9W for p2psip@ietf.org; Tue, 03 Jul 2007 01:16:45 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 02 Jul 2007 22:15:53 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIB3iUarR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,490,1175497200"; d="scan'208"; a="499613903:sNHT42995672" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l635FriC012836; Mon, 2 Jul 2007 22:15:53 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l635Fqmp027634; Tue, 3 Jul 2007 05:15:52 GMT In-Reply-To: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <910115EC-3A01-4790-B291-94965C5BEF1F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Date: Mon, 2 Jul 2007 22:14:52 -0700 To: Dean Willis X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4624; t=1183439753; x=1184303753; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Concepts=20issue=3A=20Domains=20and=20Over lays |Sender:=20; bh=8ASFL2uTm9cA8uRCzViGwNSkCepLo31N+wZhs73uHGk=; b=CxBqt3lB+qp9a7Gv9N5wbmp3ChyzqhJMG9KPeCN7ltnyI1xc4NoMSjsTQzj4WGIlv0XiaxGZ nIAS16PA4vy+n7RRgVMQqP1+kfekeGWmWJc58CLtalcTOMql//SRJnLfezNentGPtJwXVn5vla 63j5Lck3A6tR+IjYsUAkARrxY=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Short answer: Yes, Dean, I basically like what you are proposing. Long answer: I got pretty lost on the thread that came out of this but it occurred to me that looking at this as domains and overlays might be trying to wag the dog from the wrong end. Consider the other end of the dog, namespaces and enrollment servers. I think we can all agree that if Cullen is known on some overlay as fluffy@example.org, then we really don't want Dean to also be known on some other overlay as fluffy@example.org. We need the names to be useful and refer to a unique human user. So who decided who gets the name fluffy@example.org, Dean or Cullen? The enrollment server that is responsible for example.org gets to decide. I think this more or less means that an enrollment server may be able to have more than one domain mapped to it but a domain maps to at most one enrollment server. Now all the peers on the overlay need to be able to have a common trust root of some form on who the peers believe is allowed to allocate the names in this particular overlay. Once again, that is the enrollment server. So an given overlay can only have one logical enrollment server. (Someone will say there could be multiple trust roots here but given the peers in the overlay have to know about *everyone* of the trust roots, I would just argue this had virtually formed all the trust roots into a single logical enrollment server). Similarly, if someone is trying to reach fluffy@example.org, unless fluffy is in all the overlays that the example.org enrollment server is responsible for, then we need to know which overlay to look in and it seems the only way to know this is to have at most one overlay for each domain. So if you follow this somewhat confused logic, I come out thinking that the easiest solution looks like the following: A set of one more domain name (typically one) maps to a exactly one logical enrollment server. The single logical enrollment server maps to exactly one overlay. The enrollment server creates unique names inside the namespace that is delegated to it by the domain names that map to it. So to answer Deans question below - model one works for me. Model two only works for me if every peer in the overlay knows about the credentials of every enrollment server for every domain that can allocate names in the overlay *before* any peer ever enrolls in the overlay. This seems pretty impractical for anything but a very small set of enrollment servers. Cullen On Jun 13, 2007, at 4:00 PM, Dean Willis wrote: > > Someone brought this up on the list, and I wanted to clarify the > consensus here before nailing it down further in the concepts doc. > > We think of usernames as domain-scoped, like "joebob@example.com". > > One model of an overlay allows users to enroll names from many > domains. In this model, there might be only one overlay serving > every domain in the world, including (for example) "example.com" > and "example.net". Clearly routing messages within this overlay is > straightforward, and there's no need to talk to any other overlay. > > In another model, each overlay corresponds to one or more but not > all domains, and we use RFC 3263 procedures to route between > overlays. So "example.com" might be in one overlay, and > "example.net" in another. Each overlay can look up the other in DNS > to find it. > > This second model mostly precludes having one domain scattered > across multiple overlays. > > Here's the deal: Assume we have overlays A and B. Alice@example.com > enrolls with overlay A, and Bob@example.com enrolls with overlay B. > > Alice now wants to call Bob. She looks him up in her overlay, and > he's not there. What to do? She can't just look up example.com in > DNS, because it has been split across A and B and DNS just doesn't > work that way. Now, if both A and B registered with some "upstream" > lookup function (a meta-overlay), then Alice could perhaps look > there. But this starts to get messy really quickly. > > So unless we want to solve the namespace-split-across-overlays > problem (and that's not easy), we're much better off at this time > having a model where each domain can be mapped onto only one > overlay at a time. > > Y'all ok with that? > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 03 11:10:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5k1L-0005jX-NP; Tue, 03 Jul 2007 11:10:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5k1K-0005gd-6X for p2psip@ietf.org; Tue, 03 Jul 2007 11:10:26 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5k0f-0000FT-A5 for p2psip@ietf.org; Tue, 03 Jul 2007 11:10:26 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Tue, 03 Jul 2007 08:09:36 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l63F9QWs000763; Tue, 3 Jul 2007 08:09:30 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l63F9P0c020085; Tue, 3 Jul 2007 08:09:26 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jul 2007 08:09:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Tue, 3 Jul 2007 08:07:24 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22A26DCA@namail5.corp.adobe.com> In-Reply-To: <910115EC-3A01-4790-B291-94965C5BEF1F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Concepts issue: Domains and Overlays Thread-Index: Ace9MWHD+vUfDtjbTF+DzT9QkMfRDgAUGYGA References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <910115EC-3A01-4790-B291-94965C5BEF1F@cisco.com> From: "Henry Sinnreich" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 03 Jul 2007 15:09:25.0218 (UTC) FILETIME=[24AFC420:01C7BD84] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a fascinating discussion and very helpful as well. I would like to suggest adding some ingredients close to earth: Can there be tracking models for usage of the S2PSIP applications across several overlays, security implications, CALEA support (perish the thought!), _outside the counting of credentials provided by the various enrollment servers_? If such tracking is nonsense, please state so and why. On what features would you spend your own time and money, if you had the power to decide? Thanks, Henry -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Tuesday, July 03, 2007 12:15 AM To: Dean Willis Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Short answer: Yes, Dean, I basically like what you are proposing. Long answer: I got pretty lost on the thread that came out of this but it occurred =20 to me that looking at this as domains and overlays might be trying to =20 wag the dog from the wrong end. Consider the other end of the dog, =20 namespaces and enrollment servers. I think we can all agree that if Cullen is known on some overlay as =20 fluffy@example.org, then we really don't want Dean to also be known =20 on some other overlay as fluffy@example.org. We need the names to be =20 useful and refer to a unique human user. So who decided who gets the =20 name fluffy@example.org, Dean or Cullen? The enrollment server that =20 is responsible for example.org gets to decide. I think this more or =20 less means that an enrollment server may be able to have more than =20 one domain mapped to it but a domain maps to at most one enrollment =20 server. Now all the peers on the overlay need to be able to have a =20 common trust root of some form on who the peers believe is allowed to =20 allocate the names in this particular overlay. Once again, that is =20 the enrollment server. So an given overlay can only have one logical =20 enrollment server. (Someone will say there could be multiple trust =20 roots here but given the peers in the overlay have to know about =20 *everyone* of the trust roots, I would just argue this had virtually =20 formed all the trust roots into a single logical enrollment server). =20 Similarly, if someone is trying to reach fluffy@example.org, unless =20 fluffy is in all the overlays that the example.org enrollment server =20 is responsible for, then we need to know which overlay to look in and =20 it seems the only way to know this is to have at most one overlay for =20 each domain. So if you follow this somewhat confused logic, I come =20 out thinking that the easiest solution looks like the following: A set of one more domain name (typically one) maps to a exactly one =20 logical enrollment server. The single logical enrollment server maps =20 to exactly one overlay. The enrollment server creates unique names =20 inside the namespace that is delegated to it by the domain names that =20 map to it. So to answer Deans question below - model one works for me. Model two =20 only works for me if every peer in the overlay knows about the =20 credentials of every enrollment server for every domain that can =20 allocate names in the overlay *before* any peer ever enrolls in the =20 overlay. This seems pretty impractical for anything but a very small =20 set of enrollment servers. Cullen On Jun 13, 2007, at 4:00 PM, Dean Willis wrote: > > Someone brought this up on the list, and I wanted to clarify the =20 > consensus here before nailing it down further in the concepts doc. > > We think of usernames as domain-scoped, like "joebob@example.com". > > One model of an overlay allows users to enroll names from many =20 > domains. In this model, there might be only one overlay serving =20 > every domain in the world, including (for example) "example.com" =20 > and "example.net". Clearly routing messages within this overlay is =20 > straightforward, and there's no need to talk to any other overlay. > > In another model, each overlay corresponds to one or more but not =20 > all domains, and we use RFC 3263 procedures to route between =20 > overlays. So "example.com" might be in one overlay, and =20 > "example.net" in another. Each overlay can look up the other in DNS =20 > to find it. > > This second model mostly precludes having one domain scattered =20 > across multiple overlays. > > Here's the deal: Assume we have overlays A and B. Alice@example.com =20 > enrolls with overlay A, and Bob@example.com enrolls with overlay B. > > Alice now wants to call Bob. She looks him up in her overlay, and =20 > he's not there. What to do? She can't just look up example.com in =20 > DNS, because it has been split across A and B and DNS just doesn't =20 > work that way. Now, if both A and B registered with some "upstream" =20 > lookup function (a meta-overlay), then Alice could perhaps look =20 > there. But this starts to get messy really quickly. > > So unless we want to solve the namespace-split-across-overlays =20 > problem (and that's not easy), we're much better off at this time =20 > having a model where each domain can be mapped onto only one =20 > overlay at a time. > > Y'all ok with that? > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 03 11:34:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kOi-0002u5-UE; Tue, 03 Jul 2007 11:34:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kOh-0002sa-Qd for p2psip@ietf.org; Tue, 03 Jul 2007 11:34:35 -0400 Received: from aplesnation.dom1.jhuapl.edu ([128.244.198.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5kOB-0006Pq-Ox for p2psip@ietf.org; Tue, 03 Jul 2007 11:34:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Question on additional services Date: Tue, 3 Jul 2007 11:34:03 -0400 Message-ID: <7B95239DDD54E54B9BFA23847142B1EE02175662@aplesnation.dom1.jhuapl.edu> In-Reply-To: <713656.8020.qm@web52508.mail.re2.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Question on additional services Thread-Index: Ace87CXkDCWMpID3R+S3rQqqeN18lQAmosiA References: <618e24240707020543y704e4675y5bf385bf7a9541c5@mail.gmail.com> <713656.8020.qm@web52508.mail.re2.yahoo.com> From: "Wang, XiaoXiao (Sherry)" To: "Krzysztof Hennig" , =?iso-8859-1?Q?Victor_Pascual_=22=C1vila?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Krzysztof,=20 How about using something like IP Multimedia Subsystem (IMS) from 3GPP, = but exactly the same. IMS is SIP based, service orientated, and access = independent. It can implement what you asked for, e.g. set up a service = profile, orchestration between controlling peer and service data peer, = etc.=20 It is just a thought, I may misunderstand your intention. Thanks, Sherry=20 -----Original Message----- From: Krzysztof Hennig [mailto:krzysztof_hennig@yahoo.com]=20 Sent: Monday, July 02, 2007 4:53 PM To: Victor Pascual "=C1vila Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Question on additional services Hi Victor Pascual, I can agree with you. SOA approach makes sense. However SOA as it is shown in enterprise environment in my opinion is = not a goot choice. We need something simpler but also service oriented. I see that above DHT (routing & storage layer in P2P SIP) there must exist some entities which may work as a service = provider, service implementor or service data storage. I may = misunderstand the way you described SOA, but in all systems I learned = there has been always a processing node and storage node. Can you please = describe 'service provider', 'service implementor' a bit more from = functional point of view? Where in your model are A-party UA and B-party UA? How do they set up a = service profile? IMHO we also have to think wether we need only simple profile/parameter = fetch or full orchestration between controlling peer and service data = peer. The latter scenario seems more flexible however requires more CPU = on service handling peer, more bandwidth to pass all messages and causes = longer delays in processing. In my opinion the latter case is not = suitable for case when peer is located in radio network (see discussion = about battery life).=20 I am also not convinced wether exchanging big XML documents describing = service profile is a good solution. Issues are the same: CPU, bandwidth = and delays. If we provide a lightweight mechnism for this (eg. XPath), = we could put service controlling entity in a mobile handset with limited = battery capabilities. Taking into consideration all above I have a feeling that we are getting = closer to C/S model instead of distributing it among peers. Even worse, = it looks like the control point is somewhere in the network but not in = the end UA's as it is today within the Internet with HTTP. Do you have = the same feeling?=20 We can conclude that at least we have to work out a naming convention = for service entities or agents to understand each other. What do you = think ? Is there already any draft, framework or concept within P2PSIP = covering this? kind regards! /Krzysztof --- Victor Pascual =C1vila wrote: > Hi Krzysztof, > thank you for your explanation. >=20 > On 02/07/07, Krzysztof Hennig > wrote: > > > > Does anyone have thoughts about this vision? > > >=20 > IMHO, using SOA (service oriented architecture) makes sense. DHT could = > act as 'Service broker', 'n' Agents could act as a 'service provider'=20 > and 'n*m' > Agents could act as a 'service implementor'. Then 'Service providers'=20 > could be able to publish (using the DHT) services implemented by=20 > 'service implementors'. > Does it make sense??? >=20 > Thanks in advance, > Victor Pascual >=20 =20 _________________________________________________________________________= ___________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's = updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=3Dmonopolyherenow =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 03 11:41:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kVh-000659-3r; Tue, 03 Jul 2007 11:41:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5kVe-0005eh-Mj for p2psip@ietf.org; Tue, 03 Jul 2007 11:41:46 -0400 Received: from aplesnation.dom1.jhuapl.edu ([128.244.198.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5kUp-0007Y2-2D for p2psip@ietf.org; Tue, 03 Jul 2007 11:41:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Question on additional services Date: Tue, 3 Jul 2007 11:40:54 -0400 Message-ID: <7B95239DDD54E54B9BFA23847142B1EE0217566C@aplesnation.dom1.jhuapl.edu> In-Reply-To: <7B95239DDD54E54B9BFA23847142B1EE02175662@aplesnation.dom1.jhuapl.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Question on additional services Thread-Index: Ace87CXkDCWMpID3R+S3rQqqeN18lQAmosiAAABqeuA= References: <618e24240707020543y704e4675y5bf385bf7a9541c5@mail.gmail.com><713656.8020.qm@web52508.mail.re2.yahoo.com> <7B95239DDD54E54B9BFA23847142B1EE02175662@aplesnation.dom1.jhuapl.edu> From: "Wang, XiaoXiao (Sherry)" To: "Krzysztof Hennig" , =?iso-8859-1?Q?Victor_Pascual_=22=C1vila?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Ooops, it should be "but NOT the exactly same".=20 Thanks, Sherry=20 -----Original Message----- From: Wang, XiaoXiao (Sherry) [mailto:Sherry.Wang@jhuapl.edu]=20 Sent: Tuesday, July 03, 2007 11:34 AM To: Krzysztof Hennig; Victor Pascual "=C1vila Cc: P2PSIP Mailing List Subject: RE: [P2PSIP] Question on additional services Krzysztof,=20 How about using something like IP Multimedia Subsystem (IMS) from 3GPP, = but exactly the same. IMS is SIP based, service orientated, and access = independent. It can implement what you asked for, e.g. set up a service = profile, orchestration between controlling peer and service data peer, = etc.=20 It is just a thought, I may misunderstand your intention. Thanks, Sherry=20 -----Original Message----- From: Krzysztof Hennig [mailto:krzysztof_hennig@yahoo.com] Sent: Monday, July 02, 2007 4:53 PM To: Victor Pascual "=C1vila Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Question on additional services Hi Victor Pascual, I can agree with you. SOA approach makes sense. However SOA as it is shown in enterprise environment in my opinion is = not a goot choice. We need something simpler but also service oriented. I see that above DHT (routing & storage layer in P2P SIP) there must exist some entities which may work as a service = provider, service implementor or service data storage. I may = misunderstand the way you described SOA, but in all systems I learned = there has been always a processing node and storage node. Can you please = describe 'service provider', 'service implementor' a bit more from = functional point of view? Where in your model are A-party UA and B-party UA? How do they set up a = service profile? IMHO we also have to think wether we need only simple profile/parameter = fetch or full orchestration between controlling peer and service data = peer. The latter scenario seems more flexible however requires more CPU = on service handling peer, more bandwidth to pass all messages and causes = longer delays in processing. In my opinion the latter case is not = suitable for case when peer is located in radio network (see discussion = about battery life).=20 I am also not convinced wether exchanging big XML documents describing = service profile is a good solution. Issues are the same: CPU, bandwidth = and delays. If we provide a lightweight mechnism for this (eg. XPath), = we could put service controlling entity in a mobile handset with limited = battery capabilities. Taking into consideration all above I have a feeling that we are getting = closer to C/S model instead of distributing it among peers. Even worse, = it looks like the control point is somewhere in the network but not in = the end UA's as it is today within the Internet with HTTP. Do you have = the same feeling?=20 We can conclude that at least we have to work out a naming convention = for service entities or agents to understand each other. What do you = think ? Is there already any draft, framework or concept within P2PSIP = covering this? kind regards! /Krzysztof --- Victor Pascual =C1vila wrote: > Hi Krzysztof, > thank you for your explanation. >=20 > On 02/07/07, Krzysztof Hennig > wrote: > > > > Does anyone have thoughts about this vision? > > >=20 > IMHO, using SOA (service oriented architecture) makes sense. DHT could = > act as 'Service broker', 'n' Agents could act as a 'service provider' > and 'n*m' > Agents could act as a 'service implementor'. Then 'Service providers'=20 > could be able to publish (using the DHT) services implemented by=20 > 'service implementors'. > Does it make sense??? >=20 > Thanks in advance, > Victor Pascual >=20 =20 _________________________________________________________________________= ___________ Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's = updated for today's economy) at Yahoo! Games. http://get.games.yahoo.com/proddesc?gamekey=3Dmonopolyherenow =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 03 17:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5plD-0005cX-SY; Tue, 03 Jul 2007 17:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5plC-0005ZU-Uh for p2psip@ietf.org; Tue, 03 Jul 2007 17:18:10 -0400 Received: from web52502.mail.re2.yahoo.com ([206.190.48.185]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5pl8-0004lo-Dr for p2psip@ietf.org; Tue, 03 Jul 2007 17:18:10 -0400 Received: (qmail 87357 invoked by uid 60001); 3 Jul 2007 21:18:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=N1y+mfg1KXZJagt21dvpbHbRpDHxXJd9u2sRV5CCTcxRe4qCEE37/rn74zwyIWCGXiJ1YIZ9iP3aFxtffZ9Z1GsZUtALfJwk+NokFt3kw0AS7BZIvi/7H2LNvHe9N37qBqXLeFoLPPW8DN6eAxmai34zkwEzHYelYGgMog0lr44= ; Message-ID: <20070703211806.87351.qmail@web52502.mail.re2.yahoo.com> X-YMail-OSG: P9ndcSQVM1luyZURGAWuCpscYqXpa1E0t9T96zwIeg5iMBf6litJZPbGiYdjbHguLfA5GLmYZG1ZrURWZjKqbxSoHa_fp72yMiV3n_KJR10k6R.R6B1plk8hsImNbJBg6twYeda4D4Twqvlj3rREJERaiA-- Received: from [212.76.43.10] by web52502.mail.re2.yahoo.com via HTTP; Tue, 03 Jul 2007 14:18:06 PDT Date: Tue, 3 Jul 2007 14:18:06 -0700 (PDT) From: Krzysztof Hennig Subject: RE: [P2PSIP] Question on additional services To: "Wang, XiaoXiao \(Sherry\)" In-Reply-To: <7B95239DDD54E54B9BFA23847142B1EE02175662@aplesnation.dom1.jhuapl.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Sherry, I borrowed my proposal from 3GPP IMS architecture where you have CSCF and HSS as handling and profile node respectively. I have even written it as an example in my first email. Such architecture can be found in many systems since gives lots of flexibility and scalability, at least in C/S approach. I haven't considered it deeply in P2P, but might be interresting. To be more general I think we should focus on orchestration. I haven't considered yet how to organise it in totally distributed systems. The 3GPP is working on it within IMS. They have introduced a SCIM function - service Capability Interaction Manager. http://en.wikipedia.org/wiki/Service_Capability_Interaction_Manager I will focus on it in my further research and give some feedback on the mailing list. Have a nice day! Krzysztof --- "Wang, XiaoXiao (Sherry)" wrote: > Krzysztof, > > How about using something like IP Multimedia > Subsystem (IMS) from 3GPP, but exactly the same. IMS > is SIP based, service orientated, and access > independent. It can implement what you asked for, > e.g. set up a service profile, orchestration between > controlling peer and service data peer, etc. > > It is just a thought, I may misunderstand your > intention. > > Thanks, > Sherry > > -----Original Message----- > From: Krzysztof Hennig > [mailto:krzysztof_hennig@yahoo.com] > Sent: Monday, July 02, 2007 4:53 PM > To: Victor Pascual "Ávila > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Question on additional > services > > Hi Victor Pascual, > I can agree with you. SOA approach makes sense. > However SOA as it is shown in enterprise > environment in my opinion is not a goot choice. We > need something simpler but also service oriented. > > I see that above DHT (routing & storage layer in P2P > SIP) there must exist some entities which may work > as a service provider, service implementor or > service data storage. I may misunderstand the way > you described SOA, but in all systems I learned > there has been always a processing node and storage > node. Can you please describe 'service provider', > 'service implementor' a bit more from functional > point of view? > Where in your model are A-party UA and B-party UA? > How do they set up a service profile? > > IMHO we also have to think wether we need only > simple profile/parameter fetch or full orchestration > between controlling peer and service data peer. The > latter scenario seems more flexible however requires > more CPU on service handling peer, more bandwidth to > pass all messages and causes longer delays in > processing. In my opinion the latter case is not > suitable for case when peer is located in radio > network (see discussion about battery life). > > I am also not convinced wether exchanging big XML > documents describing service profile is a good > solution. Issues are the same: CPU, bandwidth and > delays. If we provide a lightweight mechnism for > this (eg. XPath), we could put service controlling > entity in a mobile handset with limited battery > capabilities. > > Taking into consideration all above I have a feeling > that we are getting closer to C/S model instead of > distributing it among peers. Even worse, it looks > like the control point is somewhere in the network > but not in the end UA's as it is today within the > Internet with HTTP. Do you have the same feeling? > > We can conclude that at least we have to work out a > naming convention for service entities or agents to > understand each other. What do you think ? Is there > already any draft, framework or concept within > P2PSIP covering this? > > kind regards! > /Krzysztof > > --- Victor Pascual Ávila > wrote: > > > Hi Krzysztof, > > thank you for your explanation. > > > > On 02/07/07, Krzysztof Hennig > > wrote: > > > > > > Does anyone have thoughts about this vision? > > > > > > > IMHO, using SOA (service oriented architecture) > makes sense. DHT could > > act as 'Service broker', 'n' Agents could act as a > 'service provider' > > and 'n*m' > > Agents could act as a 'service implementor'. Then > 'Service providers' > > could be able to publish (using the DHT) services > implemented by > > 'service implementors'. > > Does it make sense??? > > > > Thanks in advance, > > Victor Pascual > > > > > > > ____________________________________________________________________________________ > Boardwalk for $500? In 2007? Ha! Play Monopoly Here > and Now (it's updated for today's economy) at Yahoo! > Games. > http://get.games.yahoo.com/proddesc?gamekey=monopolyherenow > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ____________________________________________________________________________________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! Games. http://videogames.yahoo.com/platform?platform=120121 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 03 23:46:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5voY-00051X-9X; Tue, 03 Jul 2007 23:46:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5voY-00051S-0g for p2psip@ietf.org; Tue, 03 Jul 2007 23:46:02 -0400 Received: from aplesnation.dom1.jhuapl.edu ([128.244.198.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5voR-0001Xy-Gp for p2psip@ietf.org; Tue, 03 Jul 2007 23:46:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Question on additional services Date: Tue, 3 Jul 2007 23:45:54 -0400 Message-ID: <7B95239DDD54E54B9BFA23847142B1EE0217575D@aplesnation.dom1.jhuapl.edu> In-Reply-To: <20070703211806.87351.qmail@web52502.mail.re2.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Question on additional services Thread-Index: Ace9t6680avAI7hVRHercw4zRW+hUgANQkKA References: <7B95239DDD54E54B9BFA23847142B1EE02175662@aplesnation.dom1.jhuapl.edu> <20070703211806.87351.qmail@web52502.mail.re2.yahoo.com> From: "Wang, XiaoXiao (Sherry)" To: "Krzysztof Hennig" X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Krzysztof, I totally agree with you. That's why I said "IMS-like", because IMS has = some elements that we can borrow. However, its client/server model = (centralized) is a major issue. I was fighting it for a while. That is = the reason for me to join this P2P mailing list and to get some = insights. Thanks for the link and comments. Sherry=20 -----Original Message----- From: Krzysztof Hennig [mailto:krzysztof_hennig@yahoo.com]=20 Sent: Tuesday, July 03, 2007 5:18 PM To: Wang, XiaoXiao (Sherry) Cc: P2PSIP Mailing List Subject: RE: [P2PSIP] Question on additional services Hi Sherry, I borrowed my proposal from 3GPP IMS architecture where you have CSCF = and HSS as handling and profile node respectively. I have even written = it as an example in my first email. Such architecture can be found in = many systems since gives lots of flexibility and scalability, at least = in C/S approach. I haven't considered it deeply in P2P, but might be = interresting. To be more general I think we should focus on orchestration. I haven't = considered yet how to organise it in totally distributed systems. The = 3GPP is working on it within IMS. They have introduced a SCIM function - = service Capability Interaction Manager.=20 http://en.wikipedia.org/wiki/Service_Capability_Interaction_Manager I will focus on it in my further research and give some feedback on the = mailing list. Have a nice day! Krzysztof --- "Wang, XiaoXiao (Sherry)" wrote: > Krzysztof, >=20 > How about using something like IP Multimedia Subsystem (IMS) from=20 > 3GPP, but exactly the same. IMS is SIP based, service orientated, and=20 > access independent. It can implement what you asked for, e.g. set up a = > service profile, orchestration between controlling peer and service=20 > data peer, etc. >=20 > It is just a thought, I may misunderstand your intention. >=20 > Thanks, > Sherry >=20 > -----Original Message----- > From: Krzysztof Hennig > [mailto:krzysztof_hennig@yahoo.com] > Sent: Monday, July 02, 2007 4:53 PM > To: Victor Pascual "=C1vila > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Question on additional services >=20 > Hi Victor Pascual, > I can agree with you. SOA approach makes sense. > However SOA as it is shown in enterprise environment in my opinion is = > not a goot choice. We need something simpler but also service=20 > oriented. >=20 > I see that above DHT (routing & storage layer in P2P > SIP) there must exist some entities which may work as a service=20 > provider, service implementor or service data storage. I may=20 > misunderstand the way you described SOA, but in all systems I learned=20 > there has been always a processing node and storage node. Can you=20 > please describe 'service provider', 'service implementor' a bit more=20 > from functional point of view? > Where in your model are A-party UA and B-party UA? > How do they set up a service profile? >=20 > IMHO we also have to think wether we need only simple=20 > profile/parameter fetch or full orchestration between controlling peer = > and service data peer. The latter scenario seems more flexible however = > requires more CPU on service handling peer, more bandwidth to pass all = > messages and causes longer delays in processing. In my opinion the=20 > latter case is not suitable for case when peer is located in radio=20 > network (see discussion about battery life). >=20 > I am also not convinced wether exchanging big XML documents describing = > service profile is a good solution. Issues are the same: CPU,=20 > bandwidth and delays. If we provide a lightweight mechnism for this=20 > (eg. XPath), we could put service controlling entity in a mobile=20 > handset with limited battery capabilities. >=20 > Taking into consideration all above I have a feeling that we are=20 > getting closer to C/S model instead of distributing it among peers.=20 > Even worse, it looks like the control point is somewhere in the=20 > network but not in the end UA's as it is today within the Internet=20 > with HTTP. Do you have the same feeling? >=20 > We can conclude that at least we have to work out a naming convention=20 > for service entities or agents to understand each other. What do you=20 > think ? Is there already any draft, framework or concept within P2PSIP = > covering this? >=20 > kind regards! > /Krzysztof >=20 > --- Victor Pascual =C1vila > wrote: >=20 > > Hi Krzysztof, > > thank you for your explanation. > >=20 > > On 02/07/07, Krzysztof Hennig > > wrote: > > > > > > Does anyone have thoughts about this vision? > > > > >=20 > > IMHO, using SOA (service oriented architecture) > makes sense. DHT could > > act as 'Service broker', 'n' Agents could act as a > 'service provider'=20 > > and 'n*m' > > Agents could act as a 'service implementor'. Then > 'Service providers'=20 > > could be able to publish (using the DHT) services > implemented by > > 'service implementors'. > > Does it make sense??? > >=20 > > Thanks in advance, > > Victor Pascual > >=20 >=20 >=20 >=20 > =20 > _________________________________________________________________________= ___________ > Boardwalk for $500? In 2007? Ha! Play Monopoly Here and Now (it's=20 > updated for today's economy) at Yahoo! > Games. > http://get.games.yahoo.com/proddesc?gamekey=3Dmonopolyherenow > =20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 =20 _________________________________________________________________________= ___________ Be a PS3 game guru. Get your game face on with the latest PS3 news and previews at Yahoo! = Games. http://videogames.yahoo.com/platform?platform=3D120121 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 04 20:52:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FZt-00067f-VS; Wed, 04 Jul 2007 20:52:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FZp-00065d-JP; Wed, 04 Jul 2007 20:52:09 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6FZk-00009P-QK; Wed, 04 Jul 2007 20:52:09 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKO00BVYL197U@szxga01-in.huawei.com>; Thu, 05 Jul 2007 08:51:10 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JKO0062OL19YQ@szxga01-in.huawei.com>; Thu, 05 Jul 2007 08:51:09 +0800 (CST) Received: from s64081 ([10.164.5.72]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JKO005GTL15NE@szxml03-in.huawei.com>; Thu, 05 Jul 2007 08:51:09 +0800 (CST) Date: Thu, 05 Jul 2007 08:51:04 +0800 From: Song Yongchao Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P torealize presence and IM services? In-reply-to: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> To: "'Beck01, Wolfgang'" Message-id: <000301c7be9e$91280de0$4805a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Ace6GZIu3gmGf2+MQsukwUUTYgUwQAAA5nswAAMa6lAAAzzO4ACX3EKwAICsVOA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: vikas.tandon@orgltd.com, p2psip@ietf.org, simple@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with that. The draft = http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- scaling-analysis-00.txt has shown the complexity and the load that the presence server has to handle in order to provide its service. Self-organization infrastructure may help with the scalability of C/S presence by utilizing the processing resource of the end users. Using an application layer multicast and uri list message should be a = good choice.=20 Sure, there are many questions to be considered, including offline = messages, churn of the p2p network, the presentity's policies, the durability and availability of the presence information in P2P network and security considerations. Best Regards! Song Yongchao -----Original Message----- From: Beck01, Wolfgang [mailto:BeckW@t-systems.com]=20 Sent: 2007=C4=EA7=D4=C22=C8=D5 19:25 To: vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into = P2P torealize presence and IM services? Presence scalability is an issue even with C/S SIP. The real difficulty with NOTIFY is that different watchers may see different presence documents, due to the presentity's policies. Off-line presence brings further complications. Some random thoughts: If a group of watchers receives the same presence document, an application layer multicast may distribute the load between devices. Could draft-ietf-sip-uri-list-message be abused for this purpose? A peer receiving a NOTIFY with a recipient-list forwards it to some contacts mentioned there (removing those contacts from the recipient-list before sending). Possible, but I don't want to write the Security Considerations section.. Offline presence can be done by storing a user's presence document like a file in P2P file sharing networks. To meet the presentity's policy, we would need some elaborate encryption scheme, so that watchers can only those parts they are allowed to see. Multiple versions of the presence document might be necessary, one for every watcher/presentity pair. Wolfgang _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 05 18:42:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6a13-0006di-0s; Thu, 05 Jul 2007 18:41:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6a10-0006aN-Rm; Thu, 05 Jul 2007 18:41:34 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I6a10-0001s4-EP; Thu, 05 Jul 2007 18:41:34 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Thu, 05 Jul 2007 15:40:01 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l65MdwWs010055; Thu, 5 Jul 2007 15:39:58 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l65McFI9027887; Thu, 5 Jul 2007 15:38:15 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 15:39:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? Date: Thu, 5 Jul 2007 15:39:51 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> In-Reply-To: <000301c7be9e$91280de0$4805a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? Thread-Index: Ace6GZIu3gmGf2+MQsukwUUTYgUwQAAA5nswAAMa6lAAAzzO4ACX3EKwAICsVOAALtpjsA== References: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> <000301c7be9e$91280de0$4805a40a@china.huawei.com> From: "Henry Sinnreich" To: "Song Yongchao" , "Beck01, Wolfgang" X-OriginalArrivalTime: 05 Jul 2007 22:39:57.0770 (UTC) FILETIME=[6A2B5AA0:01C7BF55] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: vikas.tandon@orgltd.com, p2psip@ietf.org, simple@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Can anyone share a comparison for presence using P2P vs. using SIMPLE client-server? At first glance it looks obvious that P2P SIMPLE is the answer, but an analysis would be of great help. Thanks, Henry -----Original Message----- From: Song Yongchao [mailto:melodysong@huawei.com] Sent: Wednesday, July 04, 2007 7:51 PM To: 'Beck01, Wolfgang' Cc: vikas.tandon@orgltd.com; p2psip@ietf.org; simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? I agree with that. The draft http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- scaling-analysis-00.txt has shown the complexity and the load that the presence server has to handle in order to provide its service. Self-organization infrastructure may help with the scalability of C/S presence by utilizing the processing resource of the end users. Using an application layer multicast and uri list message should be a good choice. Sure, there are many questions to be considered, including offline messages, churn of the p2p network, the presentity's policies, the durability and availability of the presence information in P2P network and security considerations. Best Regards! Song Yongchao -----Original Message----- From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] Sent: 2007$BG/(J7$B7n(J2$BF|(J 19:25 To: vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2P torealize presence and IM services? Presence scalability is an issue even with C/S SIP. The real difficulty with NOTIFY is that different watchers may see different presence documents, due to the presentity's policies. Off-line presence brings further complications. Some random thoughts: If a group of watchers receives the same presence document, an application layer multicast may distribute the load between devices. Could draft-ietf-sip-uri-list-message be abused for this purpose? A peer receiving a NOTIFY with a recipient-list forwards it to some contacts mentioned there (removing those contacts from the recipient-list before sending). Possible, but I don't want to write the Security Considerations section.. Offline presence can be done by storing a user's presence document like a file in P2P file sharing networks. To meet the presentity's policy, we would need some elaborate encryption scheme, so that watchers can only those parts they are allowed to see. Multiple versions of the presence document might be necessary, one for every watcher/presentity pair. Wolfgang _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 05 19:07:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aPm-0000zF-2n; Thu, 05 Jul 2007 19:07:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aPi-0000WV-A0; Thu, 05 Jul 2007 19:07:06 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6aPe-0003p1-LI; Thu, 05 Jul 2007 19:07:06 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 05 Jul 2007 16:07:02 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHUWjUarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175497200"; d="scan'208"; a="500464268:sNHT38115008" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l65N71aZ017255; Thu, 5 Jul 2007 16:07:01 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l65N71mo013059; Thu, 5 Jul 2007 23:07:01 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 19:07:00 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 19:07:00 -0400 Message-ID: <468D7997.6080200@cisco.com> Date: Thu, 05 Jul 2007 19:07:03 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? References: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> <000301c7be9e$91280de0$4805a40a@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 23:07:00.0398 (UTC) FILETIME=[3154BCE0:01C7BF59] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4981; t=1183676821; x=1184540821; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20RE=3A=20[Simple]=20Do=20we=20need=20to=20i ntroduce=20SIMPLE=20into=09P2Ptorealize=0A=20presence=20and=20IM=20service s? |Sender:=20; bh=fKulI5JE5fRnKJ7qWBgP1eyb2OGrEPNdRM0h9mg9+po=; b=Llxcpmfp9IINkGKR7++em6vPVBOgt3c/r1es31FuVkrbgYL4EEfkOWmO0CIfgma9QJatF59o RMw7S+Nb6v8v5SSaJwlKN1U6fzA22p5j4s+kEPKRZgC8g8xlSevr3NIZ; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: simple@ietf.org, vikas.tandon@orgltd.com, p2psip@ietf.org, "Beck01, Wolfgang" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org There are definitely a lot of questions to be addressed in making SIMPLE work in a p2p system. One the question of RLS services, I would tend to think that they are not needed in a p2p system. The whole premise of RLS services is that the server has access to a much richer set of bandwidth and processing resources. So, let it do the 'fan-out' work of processing the buddy list and managing the dialogs. In a p2p model, the 'server' would be just another client on the ring. SO there is no reason to expect that it is any better suited to perform the task. MOst of the issues, I think, are really around security and authorization. Part of a presence server's role is to perform privacy processing - to limit who can subscribe and to limit what data they can see. In a client/server system, the presence server can perform this role since the client trusts its server to do so. In a p2p system, would you trust some other node in the network to execute your privacy preferences? I think not. So, rather, I think that, while online, a user's own user agent would have to supply the presence for the user. While offline, they would store a presence document that all would have access to, which indicates some limited form of offline access. Thus, a user is their own presence server. That eliminates the need for tools like XCAP and presence authorization policy documents, since know the user and their presence server are colocated. As always, multiple devices are a challenge.... -Jonathan R. Henry Sinnreich wrote: > Can anyone share a comparison for presence using P2P vs. using SIMPLE > client-server? > > At first glance it looks obvious that P2P SIMPLE is the answer, but > an analysis would be of great help. > > Thanks, Henry > > -----Original Message----- From: Song Yongchao > [mailto:melodysong@huawei.com] Sent: Wednesday, July 04, 2007 7:51 PM > To: 'Beck01, Wolfgang' Cc: vikas.tandon@orgltd.com; p2psip@ietf.org; > simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2Ptorealize presence and IM services? > > I agree with that. The draft > http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- > scaling-analysis-00.txt has shown the complexity and the load that > the presence server has to handle in order to provide its service. > Self-organization infrastructure may help with the scalability of C/S > presence by utilizing the processing resource of the end users. > Using an application layer multicast and uri list message should be a > good choice. > > Sure, there are many questions to be considered, including offline > messages, churn of the p2p network, the presentity's policies, the > durability and availability of the presence information in P2P > network and security considerations. > > > > Best Regards! Song Yongchao > > -----Original Message----- From: Beck01, Wolfgang > [mailto:BeckW@t-systems.com] Sent: 2007$BG/(B7$B7n(B2$BF|(B 19:25 To: > vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: > p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2P torealize presence and IM services? > > Presence scalability is an issue even with C/S SIP. The real > difficulty with NOTIFY is that different watchers may see different > presence documents, due to the presentity's policies. Off-line > presence brings further complications. > > Some random thoughts: > > If a group of watchers receives the same presence document, an > application layer multicast may distribute the load between devices. > Could draft-ietf-sip-uri-list-message be abused for this purpose? A > peer receiving a NOTIFY with a recipient-list forwards it to some > contacts mentioned there (removing those contacts from the > recipient-list before sending). Possible, but I don't want to write > the Security Considerations section.. > > Offline presence can be done by storing a user's presence document > like a file in P2P file sharing networks. To meet the presentity's > policy, we would need some elaborate encryption scheme, so that > watchers can only those parts they are allowed to see. Multiple > versions of the presence document might be necessary, one for every > watcher/presentity pair. > > > Wolfgang > > > > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 05 19:45:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6b0P-0004rW-IZ; Thu, 05 Jul 2007 19:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6b0N-0004qi-0C; Thu, 05 Jul 2007 19:44:59 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6b0G-0005sW-0u; Thu, 05 Jul 2007 19:44:58 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Thu, 05 Jul 2007 16:44:03 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l65Ngsot001739; Thu, 5 Jul 2007 16:42:54 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l65NgLI9006190; Thu, 5 Jul 2007 16:42:21 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 16:44:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? Date: Thu, 5 Jul 2007 16:42:58 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22A6D29D@namail5.corp.adobe.com> In-Reply-To: <468D7997.6080200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? Thread-Index: Ace/WTsKcWu58XmvSS6TgK7la1dZrgABFPGw References: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> <000301c7be9e$91280de0$4805a40a@china.huawei.com><24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> <468D7997.6080200@cisco.com> From: "Henry Sinnreich" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 05 Jul 2007 23:44:02.0926 (UTC) FILETIME=[5E0F98E0:01C7BF5E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: "Beck01, Wolfgang" , vikas.tandon@orgltd.com, simple@ietf.org, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org So to summarize in a SIMPLE-istic way: Most of the "SIMPLE problem statement" issues would go away using P2P? If yes, do you see any other overload problems popping up? (I fail to see them and Skype meets all of my presence needs). Henry -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Thursday, July 05, 2007 6:07 PM To: Henry Sinnreich Cc: simple@ietf.org; vikas.tandon@orgltd.com; p2psip@ietf.org; Beck01,Wolfgang Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? There are definitely a lot of questions to be addressed in making SIMPLE work in a p2p system. One the question of RLS services, I would tend to think that they are not needed in a p2p system. The whole premise of RLS services is that the server has access to a much richer set of bandwidth and processing resources. So, let it do the 'fan-out' work of processing the buddy list and managing the dialogs. In a p2p model, the 'server' would be just another client on the ring. SO there is no reason to expect that it is any better suited to perform the task. MOst of the issues, I think, are really around security and authorization. Part of a presence server's role is to perform privacy processing - to limit who can subscribe and to limit what data they can see. In a client/server system, the presence server can perform this role since the client trusts its server to do so. In a p2p system, would you trust some other node in the network to execute your privacy preferences? I think not. So, rather, I think that, while online, a user's own user agent would have to supply the presence for the user. While offline, they would store a presence document that all would have access to, which indicates some limited form of offline access. Thus, a user is their own presence server. That eliminates the need for tools like XCAP and presence authorization policy documents, since know the user and their presence server are colocated. As always, multiple devices are a challenge.... -Jonathan R. Henry Sinnreich wrote: > Can anyone share a comparison for presence using P2P vs. using SIMPLE > client-server? > > At first glance it looks obvious that P2P SIMPLE is the answer, but > an analysis would be of great help. > > Thanks, Henry > > -----Original Message----- From: Song Yongchao > [mailto:melodysong@huawei.com] Sent: Wednesday, July 04, 2007 7:51 PM > To: 'Beck01, Wolfgang' Cc: vikas.tandon@orgltd.com; p2psip@ietf.org; > simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2Ptorealize presence and IM services? > > I agree with that. The draft > http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- > scaling-analysis-00.txt has shown the complexity and the load that > the presence server has to handle in order to provide its service. > Self-organization infrastructure may help with the scalability of C/S > presence by utilizing the processing resource of the end users. > Using an application layer multicast and uri list message should be a > good choice. > > Sure, there are many questions to be considered, including offline > messages, churn of the p2p network, the presentity's policies, the > durability and availability of the presence information in P2P > network and security considerations. > > > > Best Regards! Song Yongchao > > -----Original Message----- From: Beck01, Wolfgang > [mailto:BeckW@t-systems.com] Sent: 2007$BG/(J7$B7n(J2$BF|(J 19:25 To: > vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: > p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2P torealize presence and IM services? > > Presence scalability is an issue even with C/S SIP. The real > difficulty with NOTIFY is that different watchers may see different > presence documents, due to the presentity's policies. Off-line > presence brings further complications. > > Some random thoughts: > > If a group of watchers receives the same presence document, an > application layer multicast may distribute the load between devices. > Could draft-ietf-sip-uri-list-message be abused for this purpose? A > peer receiving a NOTIFY with a recipient-list forwards it to some > contacts mentioned there (removing those contacts from the > recipient-list before sending). Possible, but I don't want to write > the Security Considerations section.. > > Offline presence can be done by storing a user's presence document > like a file in P2P file sharing networks. To meet the presentity's > policy, we would need some elaborate encryption scheme, so that > watchers can only those parts they are allowed to see. Multiple > versions of the presence document might be necessary, one for every > watcher/presentity pair. > > > Wolfgang > > > > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 05 21:28:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cc0-0001jZ-1U; Thu, 05 Jul 2007 21:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cbx-0001dR-Dd; Thu, 05 Jul 2007 21:27:53 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6cbs-0002cy-LP; Thu, 05 Jul 2007 21:27:53 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Jul 2007 18:27:48 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEI3jUarR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175497200"; d="scan'208"; a="177355296:sNHT34674201" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l661Rla2013086; Thu, 5 Jul 2007 18:27:47 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l661RlXH002686; Fri, 6 Jul 2007 01:27:47 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 21:27:46 -0400 Received: from [10.86.242.189] ([10.86.242.189]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 21:27:46 -0400 Message-ID: <468D9A93.8050209@cisco.com> Date: Thu, 05 Jul 2007 21:27:47 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? References: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> <000301c7be9e$91280de0$4805a40a@china.huawei.com><24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> <468D7997.6080200@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22A6D29D@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22A6D29D@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 01:27:46.0288 (UTC) FILETIME=[DB794700:01C7BF6C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8262; t=1183685267; x=1184549267; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20RE=3A=20[Simple]=20Do=20we=20need=20to=20i ntroduce=20SIMPLEinto=09P2Ptorealize=0A=20presence=20and=20IM=20services? |Sender:=20; bh=gNGHJq82TkUBCo2O0TMrCrnodZpAG3jnlgzV17MWDGQ=; b=U0ASpwmZtriWCwWBM5vHZSyNNgds5NekdUmET5wIhz2LjZSW7xblCazkItH64dYiNN9u4XIn 1XauKaxLnBgMFDd2il/jGNCCRxD2RdRiSUeSC0XScm/3nPqdZWjY2Q2H; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: "Beck01, Wolfgang" , vikas.tandon@orgltd.com, simple@ietf.org, p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The problems become entirely different ones. However, from a purely scale perspective, I'd say a *pure* p2p completely solves it. The simple-problem statement is based on a model whereby a large amount of traffic is focused between a pair of large networks, typically through a small number of servers that serve as the perimeter servers for each network. In a p2p model, there is no such perimeter server. If each user agent is its own presence client and server, the workload is completely distributed through the network. Each node in the p2p network would have to support a volume of subscriptions and notifications exactly equal to the volume associated with its own buddy list. The work per node is not proportional to the size of the network in any way (at least not at this layer; the workload of managing the ring scales as logN over N). In essence, such a network could scale to nearly unbounded sizes without any kind of central point that becomes a bottleneck. The penalty for this is going to be primarily loss of functionality. Offline presence will stink or be non-existent. Presence composition is limited to the information knowable and obtainable by the endpoint itself. Multiple endpoints is going to be really awful to handle and will probably not work very well. Buddy lists and privacy policies, if stored locally, will suffer from problems when you change computers or lose your PC. You want to store them in the network, which is doable but introduces some issues. The access bandwidth required for this is substantially more than any configuration we've considered so far; a constant factor larger than the bandwidth required for a client that doesn't have an RLS, much larger than for one that does. The security of the system becomes as good as the p2p security overall, though privacy is arguably better since there are no intermediaries to trust and you no longer need to signal policy from a UA to a separate presence server, so you can have more flexibility there. However, this is assuming a single global p2p network. If its segmented into several ones that need to connect via gateways, you're right back to simple-problem-statement. Though there may be ways to distribute the gateways if the two federating networks are both p2p. If one is not (i.e., federate a p2p network with a regular client-server one), that is definitely having the simple-problem-statement issue. -Jonathan R. Henry Sinnreich wrote: > So to summarize in a SIMPLE-istic way: Most of the "SIMPLE problem > statement" issues would go away using P2P? > > If yes, do you see any other overload problems popping up? > > (I fail to see them and Skype meets all of my presence needs). > > Henry > > -----Original Message----- From: Jonathan Rosenberg > [mailto:jdrosen@cisco.com] Sent: Thursday, July 05, 2007 6:07 PM To: > Henry Sinnreich Cc: simple@ietf.org; vikas.tandon@orgltd.com; > p2psip@ietf.org; Beck01,Wolfgang Subject: Re: [P2PSIP] RE: [Simple] > Do we need to introduce SIMPLEinto P2Ptorealize presence and IM > services? > > There are definitely a lot of questions to be addressed in making > SIMPLE work in a p2p system. > > One the question of RLS services, I would tend to think that they are > not needed in a p2p system. The whole premise of RLS services is > that the server has access to a much richer set of bandwidth and > processing resources. So, let it do the 'fan-out' work of processing > the buddy list and managing the dialogs. In a p2p model, the 'server' > would be just another client on the ring. SO there is no reason to > expect that it is any better suited to perform the task. > > MOst of the issues, I think, are really around security and > authorization. Part of a presence server's role is to perform privacy > processing - to limit who can subscribe and to limit what data they > can see. In a client/server system, the presence server can perform > this role since the client trusts its server to do so. In a p2p > system, would you trust some other node in the network to execute > your privacy preferences? I think not. > > So, rather, I think that, while online, a user's own user agent would > have to supply the presence for the user. While offline, they would > store a presence document that all would have access to, which > indicates some limited form of offline access. Thus, a user is their > own presence server. That eliminates the need for tools like XCAP and > presence authorization policy documents, since know the user and > their presence server are colocated. > > As always, multiple devices are a challenge.... > > -Jonathan R. > > > Henry Sinnreich wrote: >> Can anyone share a comparison for presence using P2P vs. using >> SIMPLE client-server? >> >> At first glance it looks obvious that P2P SIMPLE is the answer, but >> an analysis would be of great help. >> >> Thanks, Henry >> >> -----Original Message----- From: Song Yongchao >> [mailto:melodysong@huawei.com] Sent: Wednesday, July 04, 2007 7:51 >> PM To: 'Beck01, Wolfgang' Cc: vikas.tandon@orgltd.com; >> p2psip@ietf.org; simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] >> Do we need to introduce SIMPLE into P2Ptorealize presence and IM >> services? >> >> I agree with that. The draft >> http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- >> scaling-analysis-00.txt has shown the complexity and the load that >> the presence server has to handle in order to provide its service. >> Self-organization infrastructure may help with the scalability of >> C/S presence by utilizing the processing resource of the end users. >> Using an application layer multicast and uri list message should >> be a good choice. >> >> Sure, there are many questions to be considered, including offline >> messages, churn of the p2p network, the presentity's policies, the >> durability and availability of the presence information in P2P >> network and security considerations. >> >> >> >> Best Regards! Song Yongchao >> >> -----Original Message----- From: Beck01, Wolfgang >> [mailto:BeckW@t-systems.com] Sent: 2007$BG/(B7$B7n(B2$BF|(B 19:25 To: >> vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: >> p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to >> introduce SIMPLE into P2P torealize presence and IM services? >> >> Presence scalability is an issue even with C/S SIP. The real >> difficulty with NOTIFY is that different watchers may see different >> presence documents, due to the presentity's policies. Off-line >> presence brings further complications. >> >> Some random thoughts: >> >> If a group of watchers receives the same presence document, an >> application layer multicast may distribute the load between >> devices. Could draft-ietf-sip-uri-list-message be abused for this >> purpose? A peer receiving a NOTIFY with a recipient-list forwards >> it to some contacts mentioned there (removing those contacts from >> the recipient-list before sending). Possible, but I don't want to >> write the Security Considerations section.. >> >> Offline presence can be done by storing a user's presence document >> like a file in P2P file sharing networks. To meet the presentity's >> policy, we would need some elaborate encryption scheme, so that >> watchers can only those parts they are allowed to see. Multiple >> versions of the presence document might be necessary, one for every >> watcher/presentity pair. >> >> >> Wolfgang >> >> >> >> >> _______________________________________________ P2PSIP mailing list >> P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip >> >> _______________________________________________ P2PSIP mailing list >> P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip >> > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 06 03:43:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6iTj-0006D1-DB; Fri, 06 Jul 2007 03:43:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6iTi-0006Cw-7a for p2psip@ietf.org; Fri, 06 Jul 2007 03:43:46 -0400 Received: from smtp-vbr11.xs4all.nl ([194.109.24.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6iTd-0003qP-Pf for p2psip@ietf.org; Fri, 06 Jul 2007 03:43:46 -0400 Received: from [192.168.0.6] (mit.xs4all.nl [213.84.95.205]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id l667hXPj093815 for ; Fri, 6 Jul 2007 09:43:38 +0200 (CEST) (envelope-from ag@ag-projects.com) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22A6D24B@namail5.corp.adobe.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22A6D24B@namail5.corp.adobe.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Adrian Georgescu Date: Fri, 6 Jul 2007 09:43:29 +0200 To: p2psip@ietf.org X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by XS4ALL Virus Scanner X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [P2PSIP] P2P for Redundant SIP Proxies scenario (draft-bryan-p2psip-usecases-00) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > http://www.ietf.org/internet-drafts/draft-bryan-p2psip-usecases-00.txt My company has implemented a self-organizing and fully distributed SIP server farm by using P2P/DHT concepts. With reference to this draft I would like to confirm that the scenario from 3.4.2 (P2P for Redundant SIP Proxies) is valid and useful. May I refine the scenario statement as we found in practice that this technology is useful not only for distributing the SIP Proxy functionality but all the network resources that required scalability and resilience without introducing a single point of failure. 3.4.2. P2P for self-organizing SIP Proxies and other SIP application servers Service providers may wish to connect a farm of SIP servers together in a transparent way, passing resources (user registrations or other call information) between themselves with as little configuration or traffic as possible. Ideally, the redundancy and exchange of information should require a minimum of configuration between the devices (e.g. a bootstrap DNS domain and a TLS digital certificate). A P2P architecture between the SIP proxies or other hosted SIP applications like Presence allows server farms to self-organize and operated in this way. With this approach, it is easy to add more servers with minimal or no service disruptions, allow for geographical distribution of resources and increases the general robustness of the system. Kind regards, Adrian Georgescu AG Projects _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 06 13:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6raj-0002Y3-Oi; Fri, 06 Jul 2007 13:27:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6rai-0002R0-3i for p2psip@ietf.org; Fri, 06 Jul 2007 13:27:36 -0400 Received: from an-out-0708.google.com ([209.85.132.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6rae-0006Ly-QL for p2psip@ietf.org; Fri, 06 Jul 2007 13:27:36 -0400 Received: by an-out-0708.google.com with SMTP id c17so59559anc for ; Fri, 06 Jul 2007 10:27:32 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=FGVO5T2Ax4/70zzvT5WqxekdR5++QzDd6xEdOPE5+nY7gT1K1ifcLFfkZsPkL1lUuELik5gKjpqU9CisUho7KMhVxXVgYcSsPykMat/lSlGT3KWLpSAfnO6/g13odF5jhy9Glp/cEXANlDFBnefCKfBp9pS2VK0C74http2twQw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=VHQQ4QSMJ1hEYx5MBlleGNJR1ZLkrz+aSBiweBn2bZ0YTkqT9Ro8Rdgk4HsazJdq7N4gofqJQty/Ys2r7rrRAU1aENxhD2vDsf8gbO4x44pje384svAuldpJ7Tl267L66zwf/G53ofqcrKfP91EL6up1Zp55nqZIhn6DXvce/A8= Received: by 10.100.128.8 with SMTP id a8mr427348and.1183742852010; Fri, 06 Jul 2007 10:27:32 -0700 (PDT) Received: by 10.100.107.1 with HTTP; Fri, 6 Jul 2007 10:27:31 -0700 (PDT) Message-ID: <20d2bdfb0707061027k34a6b69v92e4c7ed3b20a0ab@mail.gmail.com> Date: Fri, 6 Jul 2007 13:27:31 -0400 From: "Bruce Lowekamp" To: "Jonathan Rosenberg" Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? In-Reply-To: <468D9A93.8050209@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1E4CCB2441C5C0409AD8A929482A09F31BB7C0@S4DE9JSAAIG.ost.t-com.de> <000301c7be9e$91280de0$4805a40a@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D22A6D254@namail5.corp.adobe.com> <468D7997.6080200@cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22A6D29D@namail5.corp.adobe.com> <468D9A93.8050209@cisco.com> X-Google-Sender-Auth: 38555724298dc906 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: p2psip@ietf.org, Henry Sinnreich , vikas.tandon@orgltd.com, simple@ietf.org, "Beck01, Wolfgang" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 7/5/07, Jonathan Rosenberg wrote: > In a p2p model, there is no such perimeter server. If each user agent is > its own presence client and server, the workload is completely > distributed through the network. Each node in the p2p network would have > to support a volume of subscriptions and notifications exactly equal to > the volume associated with its own buddy list. The work per node is not > proportional to the size of the network in any way (at least not at this > layer; the workload of managing the ring scales as logN over N). In > essence, such a network could scale to nearly unbounded sizes without > any kind of central point that becomes a bottleneck. > > The penalty for this is going to be primarily loss of functionality. > Offline presence will stink or be non-existent. Presence composition is > limited to the information knowable and obtainable by the endpoint > itself. Multiple endpoints is going to be really awful to handle and > will probably not work very well. Buddy lists and privacy policies, if > stored locally, will suffer from problems when you change computers or > lose your PC. You want to store them in the network, which is doable but > introduces some issues. A slightly different model is to have the presence information stored on the responsible peer for the user's registration. That has the same global load balancing and traffic charactersitics as having the user's own UA handle presence traffic, except that it transfers the load from the user's own UA to whatever peer randomly winds up being responsible for the registration. I think it's reasonable to argue that this is unfair and that the user's own UA should handle presence when online (pay your own price for having 200 friends, etc). I don't think we should give up on good offline presence, though, so I think we still need to have the responsible peer capable of acting as the PA when the user has no online UA. A lot of use-cases for P2PSIP require offline storage (for voicemail, buddy lists, etc), so having the responsible peer handle presence when the user has no active UA seems like a natural extension. Migration of subscriptions is well-defined, so no new mechanisms are needed. Since the user is offline and presumably has static presence status, using a longer expiration to reduce load seems reasonable, and the responsible peer would know when the user is again online so that the responsible peer can send a final NOTIFY that forces the subscriptions to migrate to the user's UA again. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 06 15:59:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6txe-00005e-Ev; Fri, 06 Jul 2007 15:59:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6txb-0008Bp-50; Fri, 06 Jul 2007 15:59:23 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6txa-00086A-9H; Fri, 06 Jul 2007 15:59:23 -0400 Received: from bruc002x.sbs.be (bruc002x.sbs.be [193.210.175.98]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l66JwNqp010085; Fri, 6 Jul 2007 21:58:24 +0200 Received: from bru0032a.ww018.siemens.net (bru0032a.ww018.siemens.net [193.210.175.90]) by bruc002x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l66JwRx7006919; Fri, 6 Jul 2007 21:58:27 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0032a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jul 2007 21:58:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? Date: Fri, 6 Jul 2007 21:57:40 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B01822DE1@BRU0038A.ww018.siemens.net> In-Reply-To: <20070706023042.8A1CDDEC34@mail.orgltd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? Thread-Index: Ace/UZ7AQfYYjpdXQUm1M48mOqxEOwAKVXaQACEbomA= From: "Willekens, Marc" To: "ext Vikas Tandon" X-OriginalArrivalTime: 06 Jul 2007 19:58:23.0792 (UTC) FILETIME=[02857300:01C7C008] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Cc: p2psip@ietf.org, simple@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org It's good to see the evolution of the consensus around p2p and that it's not the Holy Grail which will solve everything. "A one size fits all" approach will not work in the "real world". The SIP/SIMPLE certainly has to be considered in a p2p environment, but not as the only and only one solution but as part of different deployment models such as: 1. Large ISP model with a world coverage (ca. 10.000.000 users) 2. Medium Operator Model which is mostly still country related (ca. 1000.000 users) 3. Small Community model (ca. 100.000 users) 4. Tiny Personality model (ca. 100 users) These different deployment models have their own advantages and disadvantages. For the large, medium and small model, a "central presence server" is mostly provided which can make use of mass of scale advantages and certain traffic optimization techniques such as an RLS. This is the point of view from the clients making use of the presence system. The central server can make use of clustering, load balancing and p2p distributed concepts. The '"trust" is completely provided (or not provided) in the "closed domain". In case something is wrong, you know where to go to with your complaints. In the "Tiny Personality Model", each end-device or an own more reliable computing resource provides its own presence server for the own presentity and subscriptions from watchers are handled by the functionality provided by the end-ueser resource. Each client owns and controls its own server. In this model, there is a "peer-to-peer" relationship but a p2p protocol is not used to distribute the presence data over different peers to avoid the problems with trust and reliability as indicated already by Jonathan. However, this system combined with the p2pSIP gives an end-user the ability to build up its own network without the need of being dependent on an ISP, Network operator or an Enterprise. This certainly has advantages in different use cases, e.g. for ad-hoc kind of networking, a small virtual team with worldwide members, etc... A requirement for the end-device is the ability to be part of the different deployments in parallel with a uniform user experience and interface. That's why open standards are needed! Much of the inter-domain scaling problems can then be avoided because the different domain acceses are handled by the end-devices. Br, Marc. -----Original Message----- From: ext Vikas Tandon [mailto:vikas.tandon@orgltd.com] Sent: vrijdag 6 juli 2007 5:25 To: 'Jonathan Rosenberg'; 'Henry Sinnreich' Cc: simple@ietf.org; p2psip@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLEinto P2Ptorealize presence and IM services? A significant aspect of P2P vs Client/Server(CSP) is the ability to use Presence as a service in the network and other services like presence based call routing. Under this aspect e, a Client Server Model plays a significant role. Some other considerations are: 1. Looking at the memory and processing requirements in P2P mode, the client needs to process more information (e.g. keep track of every buddy's client capabilities, service capability etc.). 2. Another aspect of P2P is the offline messages for which you'd need some kind of server which monitors presence/online status of message inbox. 3. Also in context of wireless devices, it makes more sense to have a CSP model since coverage and connectivity are a practical issue today (e.g. in a 2.5G network, I'm supposed to receive an IM from a buddy but I'm on a voice call and the message is not delivered to me because my GPRS is suspended due to voice call - who will store and retransmit the message to me the moment I'm available again?) I'd think of a combination of P2P and CSP model providing more value as opposed to a single protocol. regards, Vikas -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] Sent: Friday, July 06, 2007 4:37 AM To: Henry Sinnreich Cc: Song Yongchao; Beck01, Wolfgang; vikas.tandon@orgltd.com; p2psip@ietf.org; simple@ietf.org Subject: Re: [P2PSIP] RE: [Simple] Do we need to introduce SIMPLE into P2Ptorealize presence and IM services? There are definitely a lot of questions to be addressed in making SIMPLE work in a p2p system. One the question of RLS services, I would tend to think that they are not needed in a p2p system. The whole premise of RLS services is that the server has access to a much richer set of bandwidth and processing resources. So, let it do the 'fan-out' work of processing the buddy list and managing the dialogs. In a p2p model, the 'server' would be just another client on the ring. SO there is no reason to expect that it is any better suited to perform the task. MOst of the issues, I think, are really around security and authorization. Part of a presence server's role is to perform privacy processing - to limit who can subscribe and to limit what data they can see. In a client/server system, the presence server can perform this role since the client trusts its server to do so. In a p2p system, would you trust some other node in the network to execute your privacy preferences? I think not. So, rather, I think that, while online, a user's own user agent would have to supply the presence for the user. While offline, they would store a presence document that all would have access to, which indicates some limited form of offline access. Thus, a user is their own presence server. That eliminates the need for tools like XCAP and presence authorization policy documents, since know the user and their presence server are colocated. As always, multiple devices are a challenge.... -Jonathan R. Henry Sinnreich wrote: > Can anyone share a comparison for presence using P2P vs. using SIMPLE > client-server? > > At first glance it looks obvious that P2P SIMPLE is the answer, but an > analysis would be of great help. > > Thanks, Henry > > -----Original Message----- From: Song Yongchao > [mailto:melodysong@huawei.com] Sent: Wednesday, July 04, 2007 7:51 PM > To: 'Beck01, Wolfgang' Cc: vikas.tandon@orgltd.com; p2psip@ietf.org; > simple@ietf.org Subject: RE: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2Ptorealize presence and IM services? > > I agree with that. The draft > http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain- > scaling-analysis-00.txt has shown the complexity and the load that the > presence server has to handle in order to provide its service. > Self-organization infrastructure may help with the scalability of C/S > presence by utilizing the processing resource of the end users. > Using an application layer multicast and uri list message should be a > good choice. > > Sure, there are many questions to be considered, including offline > messages, churn of the p2p network, the presentity's policies, the > durability and availability of the presence information in P2P network > and security considerations. > > > > Best Regards! Song Yongchao > > -----Original Message----- From: Beck01, Wolfgang > [mailto:BeckW@t-systems.com] Sent: 2007$BG/(J7$B7n(J2$BF|(J 19:25 To: > vikas.tandon@orgltd.com; melodysong@huawei.com; simple@ietf.org Cc: > p2psip@ietf.org Subject: AW: [P2PSIP] RE: [Simple] Do we need to > introduce SIMPLE into P2P torealize presence and IM services? > > Presence scalability is an issue even with C/S SIP. The real > difficulty with NOTIFY is that different watchers may see different > presence documents, due to the presentity's policies. Off-line > presence brings further complications. > > Some random thoughts: > > If a group of watchers receives the same presence document, an > application layer multicast may distribute the load between devices. > Could draft-ietf-sip-uri-list-message be abused for this purpose? A > peer receiving a NOTIFY with a recipient-list forwards it to some > contacts mentioned there (removing those contacts from the > recipient-list before sending). Possible, but I don't want to write > the Security Considerations section.. > > Offline presence can be done by storing a user's presence document > like a file in P2P file sharing networks. To meet the presentity's > policy, we would need some elaborate encryption scheme, so that > watchers can only those parts they are allowed to see. Multiple > versions of the presence document might be necessary, one for every > watcher/presentity pair. > > > Wolfgang > > > > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list > P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 06 16:20:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uIP-0000tb-Ut; Fri, 06 Jul 2007 16:20:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uIN-0000oZ-W8 for p2psip@ietf.org; Fri, 06 Jul 2007 16:20:52 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6uIN-0001hv-MH for p2psip@ietf.org; Fri, 06 Jul 2007 16:20:51 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 06 Jul 2007 13:20:43 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAM9AjkarR7PEh2dsb2JhbACPNgEBCQ4s X-IronPort-AV: i="4.16,509,1175497200"; d="scan'208"; a="165901507:sNHT26380278" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l66KKhq9007502 for ; Fri, 6 Jul 2007 13:20:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l66KKgka009302 for ; Fri, 6 Jul 2007 20:20:42 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 13:20:42 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 13:20:42 -0700 Message-ID: <468EA41E.3030906@cisco.com> Date: Fri, 06 Jul 2007 16:20:46 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2007 20:20:42.0723 (UTC) FILETIME=[20961B30:01C7C00B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1629; t=1183753243; x=1184617243; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20ICE=20tutorial=20in=20Chicago=20[DO=20NOT=20REPLY] |Sender:=20; bh=/a2gGbj9z3uAeaOyVraQo7NcVcWVa35n/rdAvyWYEgQ=; b=gMJ5ugkBQ/FLIe9SPj0AR02TjDxdtokdYcNDuwLXRZsOzkQ/ExBndOSpcQnDm2hezb6pjjnJ TC0uUSE+V7u9P8erqD/dp+JIK92WrPjnWcSNuuCPYqI+k2lEfGJ0iBP8; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [P2PSIP] ICE tutorial in Chicago [DO NOT REPLY] X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) [-17 should be available shortly] WHEN: Tuesday, July 24, 2007, 1145-1245 (lunch logistics are in progress and will be announced ASAP) WHERE: Red Lacquar WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 06 16:47:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uiZ-0000VU-Mu; Fri, 06 Jul 2007 16:47:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6uiZ-0000UG-BF for p2psip@ietf.org; Fri, 06 Jul 2007 16:47:55 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6uiU-0000UJ-Ue for p2psip@ietf.org; Fri, 06 Jul 2007 16:47:55 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I6uiI-0002NV-1b; Fri, 06 Jul 2007 15:47:38 -0500 From: "Brian Rosen" To: "'Jonathan Rosenberg'" , "'P2PSIP WG'" References: <468EA41E.3030906@cisco.com> Subject: RE: [P2PSIP] ICE tutorial in Chicago [DO NOT REPLY] Date: Fri, 6 Jul 2007 16:47:47 -0400 Message-ID: <079201c7c00e$eabd0600$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <468EA41E.3030906@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfACyMiYRsZhslpS5KZBek5fcj9bAAA2tUw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Would people advocating NAT traversal which is not ICE based please plan to attend this tutorial. This version of the tutorial will be specifically directed at groups like p2psip who are looking at non-sip applications of NAT traversal. Other such groups include HIP, MIP, behave, avt, ... Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Friday, July 06, 2007 4:21 PM > To: P2PSIP WG > Subject: [P2PSIP] ICE tutorial in Chicago [DO NOT REPLY] > > (Apologies to multiple recipients) > (DO NOT REPLY) > > WHAT: Tutorial on Interactive Connectivity Establishment (ICE) > (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) > [-17 should be available shortly] > > WHEN: Tuesday, July 24, 2007, 1145-1245 > (lunch logistics are in progress and will be announced ASAP) > > WHERE: Red Lacquar > > WHO: Anyone that would like to learn more about ICE. > > WHY: ICE, developed by the mmusic working group, has been > defined as the IETF tool for NAT traversal for SIP-based > media. It is also seeing increased usage for traversal > for other kinds of application traffic - anything worrying > about any-to-any communications. In this tutorial, we will > overview the background of the problem, consider the > requirements driving ICE, and provide an overview of > how ICE works. An understanding of SIP is not required. > The tutorial will be based on the pending -17 version. > > RSVP: Please send a note to me with the Subject line "ice-is-nice" > (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a > count of the number of participants for lunch purposes. > > > !DO NOT REPLY TO THIS NOTE! > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 08 04:53:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SVi-0000jw-1Y; Sun, 08 Jul 2007 04:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SVf-0000jf-Vz for p2psip@ietf.org; Sun, 08 Jul 2007 04:52:52 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7SVb-0001rU-4f for p2psip@ietf.org; Sun, 08 Jul 2007 04:52:51 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l688qj78023776 for ; Sun, 8 Jul 2007 10:52:45 +0200 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l688qm7R019566 for ; Sun, 8 Jul 2007 10:52:49 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Jul 2007 10:52:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [P2PSIP] do we need a client protocol? Date: Sun, 8 Jul 2007 10:51:22 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B01822DF9@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace/3U9ILapZOxl0Tf2hwCm6BAAcwQBX3icA From: "Willekens, Marc" To: X-OriginalArrivalTime: 08 Jul 2007 08:52:45.0444 (UTC) FILETIME=[5A3CAC40:01C7C13D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 -----Original Message----- From: Willekens, Marc=20 Sent: vrijdag 6 juli 2007 16:53 To: 'Alan Johnston' Subject: RE: [P2PSIP] do we need a client protocol? Don't we have to consider the "p2p" as a kind of intermediary service routing layer? The peer contributes to the distributed routing based on its own provided resources, which is, as indicated in many mailings, a important point to consider for mobile devices, for power, memory and bandwidth consumption. As such, there is a strong requirement to have a dedicated and optimized protocol for the service routing layer which can optimally be implemented and supported by special hardware, in the same way as is done for the fast IP routers, and which avoids influences to the traffic destined to/originated from the device acting both as an routing intermediary and as an end-node. Br, Marc. -----Original Message----- From: Alan Johnston [mailto:alan@sipstation.com]=20 Sent: woensdag 27 juni 2007 1:05 To: Henry Sinnreich Cc: Philip Matthews; Avshalom Houri; P2PSIP Mailing List Subject: Re: [P2PSIP] do we need a client protocol? I've been giving this a lot of thought lately, thinking about the actual requirements. We want to allow energy-limited devices to participate to some level in=20 P2PSIP. As such, perhaps instead of saying we need a client protocol,=20 perhaps we just need levels of participation in the overlay peer protocol. For example, a normal peer in the overlay will maintain peer protocol=20 connections with many (perhaps dozens) of peers. Why? So that it can=20 quickly and efficiently route requests witFrom p2psip-bounces@ietf.org Sun Jul 08 04:53:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SVi-0000jw-1Y; Sun, 08 Jul 2007 04:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SVf-0000jf-Vz for p2psip@ietf.org; Sun, 08 Jul 2007 04:52:52 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7SVb-0001rU-4f for p2psip@ietf.org; Sun, 08 Jul 2007 04:52:51 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l688qj78023776 for ; Sun, 8 Jul 2007 10:52:45 +0200 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l688qm7R019566 for ; Sun, 8 Jul 2007 10:52:49 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Jul 2007 10:52:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: [P2PSIP] do we need a client protocol? Date: Sun, 8 Jul 2007 10:51:22 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B01822DF9@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace/3U9ILapZOxl0Tf2hwCm6BAAcwQBX3icA From: "Willekens, Marc" To: X-OriginalArrivalTime: 08 Jul 2007 08:52:45.0444 (UTC) FILETIME=[5A3CAC40:01C7C13D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 -----Original Message----- From: Willekens, Marc=20 Sent: vrijdag 6 juli 2007 16:53 To: 'Alan Johnston' Subject: RE: [P2PSIP] do we need a client protocol? Don't we have to consider the "p2p" as a kind of intermediary service routing layer? The peer contributes to the distributed routing based on its own provided resources, which is, as indicated in many mailings, a important point to consider for mobile devices, for power, memory and bandwidth consumption. As such, there is a strong requirement to have a dedicated and optimized protocol for the service routing layer which can optimally be implemented and supported by special hardware, in the same way as is done for the fast IP routers, and which avoids influences to the traffic destined to/originated from the device acting both as an routing intermediary and as an end-node. Br, Marc. -----Original Message----- From: Alan Johnston [mailto:alan@sipstation.com]=20 Sent: woensdag 27 juni 2007 1:05 To: Henry Sinnreich Cc: Philip Matthews; Avshalom Houri; P2PSIP Mailing List Subject: Re: [P2PSIP] do we need a client protocol? I've been giving this a lot of thought lately, thinking about the actual requirements. We want to allow energy-limited devices to participate to some level in=20 P2PSIP. As such, perhaps instead of saying we need a client protocol,=20 perhaps we just need levels of participation in the overlay peer protocol. For example, a normal peer in the overlay will maintain peer protocol=20 connections with many (perhaps dozens) of peers. Why? So that it can=20 quickly and efficiently route requests within the overlay. Perhaps an energy-limited device could just minimize the number of peer=20 protocol connections it maintains, perhaps even down to a minimum of=20 two. This would result in slower routing of its requests through the=20 overlay, but that seems like a reasonable tradeoff. Also, perhaps there are some other peer protocol functions, such as data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their requests=20 and responses could be routed over the overlay with a lower priority=20 than full peers. We need to manage the tradeoffs so that those peers=20 who contribute the least to the overlay also get the lowest performance=20 from it. Thoughts? Thanks, Alan Henry Sinnreich wrote: > Folks, > > Given the length of the discussion on "do we need a client protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about the > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive > peerterminology > > David A. Bryan wrote: > =20 >> If I understand this right, not sure I like it. Do these >> =20 > "non-contributing > =20 >> peer" (I *do* like contributing better than active/passive) entities >> =20 > have a > =20 >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> =20 > for > =20 >> most >> DHTs, how do we allow you to be in the overlay and not store resources >> =20 > (not > =20 >> typical for most current DHT algorithms) >> =20 > > Well, that certainly depends on the DHT algorithm involved. It certainly > seems that a peer that moves between contributing and non-contributing > might HAVE a peer ID, but whether it chooses to insert itself into the > DHT "right now" might determine whether it is contributing "right now" > or not. > > =20 >> My concern all along has been that I don't understand why something >> is a peer if it isn't doing anything other than talking to someone=20 >> and making requests, hence why I supported client in the first place. >> I fail to see how something that isn't contributing anything, and=20 >> instead talks to a peer to get resources, is in any way a peer. It=20 >> seems completely not in keeping with the idea of P2P. I also worry it >> is likely to be very confusing since we've been using the other >> terminology for over a year now. Just looks like a souce of confusion. >> =20 > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth connection > and therefore not wish to offer resources. Does this modality make it > two different nodes? > > =20 >> If we do go this way, there is one subtle point. If I join the overlay >> =20 > but > =20 >> don't happen to offer any services (other than maybe >> =20 > storage...depending on > =20 >> how we definie it, that might or might not be mandatory), would I be >> contributing? If joining the overlay (in the sense that we have a >> =20 > PeerID > =20 >> and >> we route traffic) doesn't require me to store, I could offer no >> =20 > services > > That's "offer no other services", since routing is itself a service. > > =20 >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., no >> Peer-ID) >> =20 > > I think there's a range of "contributing" in play. For most DHT models, > a minimally contributing node will route a request it receives. It might > ask nicely (perhaps a q-value mechanism) to not have to route requests, > but would probably mathematically still have to route something it gets. > > I think we distinguish based hin the overlay. Perhaps an energy-limited device could just minimize the number of peer=20 protocol connections it maintains, perhaps even down to a minimum of=20 two. This would result in slower routing of its requests through the=20 overlay, but that seems like a reasonable tradeoff. Also, perhaps there are some other peer protocol functions, such as data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their requests=20 and responses could be routed over the overlay with a lower priority=20 than full peers. We need to manage the tradeoffs so that those peers=20 who contribute the least to the overlay also get the lowest performance=20 from it. Thoughts? Thanks, Alan Henry Sinnreich wrote: > Folks, > > Given the length of the discussion on "do we need a client protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about the > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive > peerterminology > > David A. Bryan wrote: > =20 >> If I understand this right, not sure I like it. Do these >> =20 > "non-contributing > =20 >> peer" (I *do* like contributing better than active/passive) entities >> =20 > have a > =20 >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> =20 > for > =20 >> most >> DHTs, how do we allow you to be in the overlay and not store resources >> =20 > (not > =20 >> typical for most current DHT algorithms) >> =20 > > Well, that certainly depends on the DHT algorithm involved. It certainly > seems that a peer that moves between contributing and non-contributing > might HAVE a peer ID, but whether it chooses to insert itself into the > DHT "right now" might determine whether it is contributing "right now" > or not. > > =20 >> My concern all along has been that I don't understand why something >> is a peer if it isn't doing anything other than talking to someone=20 >> and making requests, hence why I supported client in the first place. >> I fail to see how something that isn't contributing anything, and=20 >> instead talks to a peer to get resources, is in any way a peer. It=20 >> seems completely not in keeping with the idea of P2P. I also worry it >> is likely to be very confusing since we've been using the other >> terminology for over a year now. Just looks like a souce of confusion. >> =20 > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth connection > and therefore not wish to offer resources. Does this modality make it > two different nodes? > > =20 >> If we do go this way, there is one subtle point. If I join the overlay >> =20 > but > =20 >> don't happen to offer any services (other than maybe >> =20 > storage...depending on > =20 >> how we definie it, that might or might not be mandatory), would I be >> contributing? If joining the overlay (in the sense that we have a >> =20 > PeerID > =20 >> and >> we route traffic) doesn't require me to store, I could offer no >> =20 > services > > That's "offer no other services", since routing is itself a service. > > =20 >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., no >> Peer-ID) >> =20 > > I think there's a range of "contributing" in play. For most DHT models, > a minimally contributing node will route a request it receives. It might > ask nicely (perhaps a q-value mechanism) to not have to route requests, > but would probably mathematically still have to route something it gets. > > I think we distinguish based on the service advertisements from the > peer. > > =20 >> If we are so opposed to client for confusion with SIP UAs, lets pick a >> =20 > new > =20 >> name, but why some flavor of peer when it does nothing remotely peer >> =20 > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore change > it service offering. > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 08 04:53:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SVi-0000k1-8b; Sun, 08 Jul 2007 04:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SVg-0000jh-KF for p2psip@ietf.org; Sun, 08 Jul 2007 04:52:52 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7SVb-0001rT-4h for p2psip@ietf.org; Sun, 08 Jul 2007 04:52:52 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l688qjmR023777 for ; Sun, 8 Jul 2007 10:52:45 +0200 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l688qm7T019566 for ; Sun, 8 Jul 2007 10:52:49 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Jul 2007 10:52:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: [P2PSIP] do we need a client protocol? Date: Sun, 8 Jul 2007 10:52:00 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B01822DFA@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace/39lxOupTSTjATyqSKnBfRTVuQQBXWIRA From: "Willekens, Marc" To: X-OriginalArrivalTime: 08 Jul 2007 08:52:45.0584 (UTC) FILETIME=[5A520900:01C7C13D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6852087d2a39b5d20c975154ae1cd415 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1629332144==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1629332144== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C13D.59EEF9B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C13D.59EEF9B7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Willekens, Marc=20 Sent: vrijdag 6 juli 2007 17:11 To: 'marcin.matuszewski@nokia.com' Subject: RE: [P2PSIP] do we need a client protocol? Hi Marcin, You're right. In a p2p, the "standby time" of the battery can negatively be influenced. As such, we really have to differentiate between "transit traffic" and node related traffic (from/towards an application). For the transit traffic, an optimized protocon the service advertisements from the > peer. > > =20 >> If we are so opposed to client for confusion with SIP UAs, lets pick a >> =20 > new > =20 >> name, but why some flavor of peer when it does nothing remotely peer >> =20 > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore change > it service offering. > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 08 04:53:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SVi-0000k1-8b; Sun, 08 Jul 2007 04:52:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SVg-0000jh-KF for p2psip@ietf.org; Sun, 08 Jul 2007 04:52:52 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7SVb-0001rT-4h for p2psip@ietf.org; Sun, 08 Jul 2007 04:52:52 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l688qjmR023777 for ; Sun, 8 Jul 2007 10:52:45 +0200 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l688qm7T019566 for ; Sun, 8 Jul 2007 10:52:49 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Jul 2007 10:52:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: [P2PSIP] do we need a client protocol? Date: Sun, 8 Jul 2007 10:52:00 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B01822DFA@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace/39lxOupTSTjATyqSKnBfRTVuQQBXWIRA From: "Willekens, Marc" To: X-OriginalArrivalTime: 08 Jul 2007 08:52:45.0584 (UTC) FILETIME=[5A520900:01C7C13D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6852087d2a39b5d20c975154ae1cd415 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1629332144==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1629332144== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C13D.59EEF9B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C13D.59EEF9B7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Willekens, Marc=20 Sent: vrijdag 6 juli 2007 17:11 To: 'marcin.matuszewski@nokia.com' Subject: RE: [P2PSIP] do we need a client protocol? Hi Marcin, You're right. In a p2p, the "standby time" of the battery can negatively be influenced. As such, we really have to differentiate between "transit traffic" and node related traffic (from/towards an application). For the transit traffic, an optimized protocol is required which can be supported by hardware. For the node outgoing traffic, the service routing layer needs the knowledge where to route the message towards: this could be a fixed proxy function or a p2p distributed location. =20 br, Marc. ________________________________ From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] Sent: woensdag 27 juni 2007 9:33 To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices are very powerful. From this reason some of mobile terminals may become peers (depending on the case scenario: churn, size of the network). However there are also many entry-level/low-end devices that have slow CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We also have problems with handling searches. =20 I assume that we will have some mobile terminals taking part in DHT and some accessing resources stored in DHT using a client protocol. Marcin ________________________________ From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing List Subject: Re: [P2PSIP] do we need a client protocol? =09 =09 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the actual requirements. =09 We want to allow energy-limited devices to participate to some level in P2PSIP. As such, perhaps instead of saying we need a client protocol,=20 perhaps we just need levels of participation in the overlay peer protocol. =09 For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can=20 quickly and efficiently route requests within the overlay. Perhaps an energy-limited device could just minimize the number of peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff.=20 The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for adjustment. I don't think it is under complete control of individual peer in the case of known DHT algorithms.=20 =09 Also, perhaps there are some other peer protocol functions, such as data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest performance from it. I am not quite sure I understand the benefit of introducing such various levels of participation. Having a client protocol seems to be much simpler and easier than introducing these various levels of participation.=20 =09 Thanks. =09 Eunsoo =09 =09 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about the=20 > WG charter, but about the return on the investment. > > ol is required which can be supported by hardware. For the node outgoing traffic, the service routing layer needs the knowledge where to route the message towards: this could be a fixed proxy function or a p2p distributed location. =20 br, Marc. ________________________________ From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] Sent: woensdag 27 juni 2007 9:33 To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 We have wide variety of mobile terminals. The capabilities of mobile terminals are constantly improving e.g. even now Nokia's N-series/E-series devices are very powerful. From this reason some of mobile terminals may become peers (depending on the case scenario: churn, size of the network). However there are also many entry-level/low-end devices that have slow CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want long battery life. DHT maintenance and handling searches have impact on idle state that is more important from battery life perspective than the active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed however as Eunsoo said it would be quite difficult to control the number of connections in DHT. We also have problems with handling searches. =20 I assume that we will have some mobile terminals taking part in DHT and some accessing resources stored in DHT using a client protocol. Marcin ________________________________ From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing List Subject: Re: [P2PSIP] do we need a client protocol? =09 =09 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the actual requirements. =09 We want to allow energy-limited devices to participate to some level in P2PSIP. As such, perhaps instead of saying we need a client protocol,=20 perhaps we just need levels of participation in the overlay peer protocol. =09 For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can=20 quickly and efficiently route requests within the overlay. Perhaps an energy-limited device could just minimize the number of peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff.=20 The underling algorithm (e.g. a certain DHT algorithm) will dictate the number of connections even though there might be some room for adjustment. I don't think it is under complete control of individual peer in the case of known DHT algorithms.=20 =09 Also, perhaps there are some other peer protocol functions, such as data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest performance from it. I am not quite sure I understand the benefit of introducing such various levels of participation. Having a client protocol seems to be much simpler and easier than introducing these various levels of participation.=20 =09 Thanks. =09 Eunsoo =09 =09 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive=20 > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It certainly > seems that a peer that moves between contributing and non-contributing=20 > might HAVE a peer ID, but whether it chooses to insert itself into the > DHT "right now" might determine whether it is contributing "right now" > or not. > > >> My concern all along has been that I don't understand why something=20 >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first place. >> I fail to see how something that isn't contributing anything, and=20 >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth connection=20 > and therefore not wish to offer resources. Does this modality make it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT models,=20 > a minimally contributing node will route a request it receives. It might > ask nicely (perhaps a q-value mechanism) to not have to route requests, > but would probably mathematically still have to route something it gets.=20 > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets pick a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =09 ------_=_NextPart_001_01C7C13D.59EEF9B7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive=20 > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It certainly > seems that a peer that moves between contributing and non-contributing=20 > might HAVE a peer ID, but whether it chooses to insert itself into the > DHT "right now" might determine whether it is contributing "right now" > or not. > > >> My concern all along has been that I don't understand why something=20 >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first place. >> I fail to see how something that isn't contributing anything, and=20 >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth connection=20 > and therefore not wish to offer resources. Does this modality make it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT models,=20 > a minimally contributing node will route a request it receives. It might > ask nicely (perhaps a q-value mechanism) to not have to route requests, > but would probably mathematically still have to route something it gets.=20 > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets pick a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =09 ------_=_NextPart_001_01C7C13D.59EEF9B7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: Willekens, Marc =
Sent: vrijdag 6=20 juli 2007 17:11
To: = 'marcin.matuszewski@nokia.com'
Subject:=20 RE: [P2PSIP] do we need a client protocol?

Hi Marcin,
You're right. In a p2p, the "standby time" of the battery can = negatively=20 be influenced. As such, we really have to differentiate between "transit = traffic" and node related traffic (from/towards an application). For the = transit=20 traffic, an optimized protocol is required which can be supported by = hardware.=20 For the node outgoing traffic, the service routing layer needs=20 the knowledge where to route the message towards: this could = be a=20 fixed proxy function or a p2p distributed location.
 
br,
Marc.

From: marcin.matuszewski@nokia.com=20 [mailto:marcin.matuszewski@nokia.com]
Sent: woensdag 27 juni = 2007=20 9:33
To: eunsooshim@gmail.com; = alan@sipstation.com
Cc:=20 hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi,
 
We have wide variety of mobile = terminals. The=20 capabilities of mobile terminals are constantly improving e.g. even = now Nokia's N-series/E-series devices are very powerful. From = this=20 reason some of mobile terminals may become peers (depending on = the=20 case scenario: churn, size of the network). However there are=20 also many entry-level/low-end devices that have slow CPUs = and limited memory. 
Battery life is another issue. Most of the = mobile phone users=20 want long battery life. DHT maintenance and handling = searches=20 have impact on idle state that is more important from battery = life=20 perspective than the active state (e.g. when user is = calling/answering a=20 call).
    
I was considering a similar = solution tETA http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii">
 

From: Willekens, Marc =
Sent: vrijdag 6=20 juli 2007 17:11
To: = 'marcin.matuszewski@nokia.com'
Subject:=20 RE: [P2PSIP] do we need a client protocol?

Hi Marcin,
You're right. In a p2p, the "standby time" of the battery can = negatively=20 be influenced. As such, we really have to differentiate between "transit = traffic" and node related traffic (from/towards an application). For the = transit=20 traffic, an optimized protocol is required which can be supported by = hardware.=20 For the node outgoing traffic, the service routing layer needs=20 the knowledge where to route the message towards: this could = be a=20 fixed proxy function or a p2p distributed location.
 
br,
Marc.

From: marcin.matuszewski@nokia.com=20 [mailto:marcin.matuszewski@nokia.com]
Sent: woensdag 27 juni = 2007=20 9:33
To: eunsooshim@gmail.com; = alan@sipstation.com
Cc:=20 hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi,
 
We have wide variety of mobile = terminals. The=20 capabilities of mobile terminals are constantly improving e.g. even = now Nokia's N-series/E-series devices are very powerful. From = this=20 reason some of mobile terminals may become peers (depending on = the=20 case scenario: churn, size of the network). However there are=20 also many entry-level/low-end devices that have slow CPUs = and limited memory. 
Battery life is another issue. Most of the = mobile phone users=20 want long battery life. DHT maintenance and handling = searches=20 have impact on idle state that is more important from battery = life=20 perspective than the active state (e.g. when user is = calling/answering a=20 call).
    
I was considering a similar = solution to the=20 one that Alan proposed however as Eunsoo said it would be quite difficult to = control the=20 number of connections in DHT. We also have problems with handling=20 searches.
 
I assume that we will have some mobile terminals = taking part in=20 DHT and some accessing resources stored in DHT using a client=20 protocol.

Marcin
From: ext Eunsoo Shim=20 [mailto:eunsooshim@gmail.com]
Sent: 27 June, 2007=20 02:26
To: Alan Johnston
Cc: Henry Sinnreich; = Avshalom=20 Houri; Philip Matthews; P2PSIP Mailing List
Subject: Re: = [P2PSIP] do=20 we need a client protocol?



On 6/26/07, Alan=20 Johnston <alan@sipstation.com> = wrote:=20
I've=20 been giving this a lot of thought lately, thinking about the=20 actual
requirements.

We want to allow energy-limited = devices to=20 participate to some level in
P2PSIP.   As such, perhaps = instead=20 of saying we need a client protocol,
perhaps we just need levels = of=20 participation in the overlay peer protocol.

For example, a = normal=20 peer in the overlay will maintain peer protocol
connections with = many=20 (perhaps dozens) of peers.  Why?  So that it can =
quickly and efficiently route requests within the = overlay.


Perhaps=20 an energy-limited device could just minimize the number of = peer
protocol=20 connections it maintains, perhaps even down to a minimum=20 of
two.  This would result in slower routing of its = requests=20 through the
overlay, but that seems like a reasonable tradeoff.=20

The underling algorithm (e.g. a certain DHT algorithm) will = dictate=20 the number of connections even though there might be some room for = adjustment.=20 I don't think it is under complete control of individual peer in the = case of=20 known DHT algorithms.

Also,=20 perhaps there are some other peer protocol functions, such as=20 data
replication (storage would still be done, but not = replication), that=20
could be skipped by these energy-limited = peers.  Perhaps their=20 requests
and responses could be routed over the overlay with a = lower=20 priority
than full peers.  We need to manage the = tradeoffs so=20 that those peers
who contribute the least to the overlay also get = the=20 lowest performance
from it.


I am not quite sure I understand the benefit of = introducing such=20 various levels of participation.
Having a client protocol seems to = be much=20 simpler and easier than introducing these various levels of = participation.=20 would be quite difficult to = control the=20 number of connections in DHT. We also have problems with handling=20 searches.
 
I assume that we will have some mobile terminals = taking part in=20 DHT and some accessing resources stored in DHT using a client=20 protocol.

Marcin
From: ext Eunsoo Shim=20 [mailto:eunsooshim@gmail.com]
Sent: 27 June, 2007=20 02:26
To: Alan Johnston
Cc: Henry Sinnreich; = Avshalom=20 Houri; Philip Matthews; P2PSIP Mailing List
Subject: Re: = [P2PSIP] do=20 we need a client protocol?



On 6/26/07, Alan=20 Johnston <alan@sipstation.com> = wrote:=20
I've=20 been giving this a lot of thought lately, thinking about the=20 actual
requirements.

We want to allow energy-limited = devices to=20 participate to some level in
P2PSIP.   As such, perhaps = instead=20 of saying we need a client protocol,
perhaps we just need levels = of=20 participation in the overlay peer protocol.

For example, a = normal=20 peer in the overlay will maintain peer protocol
connections with = many=20 (perhaps dozens) of peers.  Why?  So that it can =
quickly and efficiently route requests within the = overlay.


Perhaps=20 an energy-limited device could just minimize the number of = peer
protocol=20 connections it maintains, perhaps even down to a minimum=20 of
two.  This would result in slower routing of its = requests=20 through the
overlay, but that seems like a reasonable tradeoff.=20

The underling algorithm (e.g. a certain DHT algorithm) will = dictate=20 the number of connections even though there might be some room for = adjustment.=20 I don't think it is under complete control of individual peer in the = case of=20 known DHT algorithms.

Also,=20 perhaps there are some other peer protocol functions, such as=20 data
replication (storage would still be done, but not = replication), that=20
could be skipped by these energy-limited = peers.  Perhaps their=20 requests
and responses could be routed over the overlay with a = lower=20 priority
than full peers.  We need to manage the = tradeoffs so=20 that those peers
who contribute the least to the overlay also get = the=20 lowest performance
from it.


I am not quite sure I understand the benefit of = introducing such=20 various levels of participation.
Having a client protocol seems to = be much=20 simpler and easier than introducing these various levels of = participation.=20

Thanks.

Eunsoo


Henry=20 Sinnreich wrote:
> Folks,
>
> Given the length of = the=20 discussion on "do we need a client protocol?"
> let me repeat = the=20 simple imperatives for the client:
>
> - Limited battery = in=20 mobile devices, and
>
> - Other uses besides SIP. = Business=20 planning folks may not care about the
> WG charter, but about = the=20 return on the investment.
>
> Thanks, = Henry
>
>=20 -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com=20 ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: = David A.=20 Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip=20 Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal = for=20 active/passive
> peerterminology
>
> David A. = Bryan=20 wrote:
>
>> If I understand this right, not sure I = like it.=20 Do these
>>
> "non-contributing
>
>> = peer" (I=20 *do* like contributing better than active/passive) entities=20
>>
> have a
>
>> Peer-ID? In = otherwords, are=20 they part of the overlay at all? If so,
>>
>=20 for
>
>> most
>> DHTs, how do we allow you = to be in=20 the overlay and not store resources
>>
>=20 (not
>
>> typical for most current DHT=20 algorithms)
>>
>
> Well, that certainly depends = on the=20 DHT algorithm involved. It certainly
> seems that a peer that = moves=20 between contributing and non-contributing
> might HAVE a peer = ID, but=20 whether it chooses to insert itself into the
> DHT "right now" = might=20 determine whether it is contributing "right now"
> or=20 not.
>
>
>> My concern all along has been that = I don't=20 understand why something
>> is a peer if it isn't doing = anything=20 other than talking to someone
>> and making requests, hence = why I=20 supported client in the first place.
>>  I fail = to see=20 how something that isn't contributing anything, and
>> = instead=20 talks to a peer to get resources, is in any way a peer. = It
>> seems=20 completely not in keeping with the idea of P2P. I also worry=20 it
>>  is likely to be very confusing since we've = been=20 using the other
>> terminology for over a year now. Just = looks=20 like a souce of confusion.
>>
>
> A node might=20 sometimes have a high-bandwidth connection and wish to
> = contribute=20 resources, and sometimes not have a high-bandwidth connection =
> and=20 therefore not wish to offer resources. Does this modality make = it
>=20 two different nodes?
>
>
>> If we do go this = way, there=20 is one subtle point. If I join the overlay
>>
>=20 but
>
>> don't happen to offer any services (other = than=20 maybe
>>
> storage...depending on
>
>> = how we=20 definie it, that might or might not be mandatory), would I = be
>>=20 contributing? If joining the overlay (in the sense that we have=20 a
>>
> PeerID
>
>> and
>> we = route=20 traffic) doesn't require me to store, I could offer = no
>>
>=20 services
>
> That's "offer no other services", since = routing is=20 itself a service.
>
>
>> and
>> still = be a=20 peer. How do we distinguish between this case and a
>>=20 "non-contri>
Thanks.

Eunsoo


Henry=20 Sinnreich wrote:
> Folks,
>
> Given the length of = the=20 discussion on "do we need a client protocol?"
> let me repeat = the=20 simple imperatives for the client:
>
> - Limited battery = in=20 mobile devices, and
>
> - Other uses besides SIP. = Business=20 planning folks may not care about the
> WG charter, but about = the=20 return on the investment.
>
> Thanks, = Henry
>
>=20 -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com=20 ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: = David A.=20 Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip=20 Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal = for=20 active/passive
> peerterminology
>
> David A. = Bryan=20 wrote:
>
>> If I understand this right, not sure I = like it.=20 Do these
>>
> "non-contributing
>
>> = peer" (I=20 *do* like contributing better than active/passive) entities=20
>>
> have a
>
>> Peer-ID? In = otherwords, are=20 they part of the overlay at all? If so,
>>
>=20 for
>
>> most
>> DHTs, how do we allow you = to be in=20 the overlay and not store resources
>>
>=20 (not
>
>> typical for most current DHT=20 algorithms)
>>
>
> Well, that certainly depends = on the=20 DHT algorithm involved. It certainly
> seems that a peer that = moves=20 between contributing and non-contributing
> might HAVE a peer = ID, but=20 whether it chooses to insert itself into the
> DHT "right now" = might=20 determine whether it is contributing "right now"
> or=20 not.
>
>
>> My concern all along has been that = I don't=20 understand why something
>> is a peer if it isn't doing = anything=20 other than talking to someone
>> and making requests, hence = why I=20 supported client in the first place.
>>  I fail = to see=20 how something that isn't contributing anything, and
>> = instead=20 talks to a peer to get resources, is in any way a peer. = It
>> seems=20 completely not in keeping with the idea of P2P. I also worry=20 it
>>  is likely to be very confusing since we've = been=20 using the other
>> terminology for over a year now. Just = looks=20 like a souce of confusion.
>>
>
> A node might=20 sometimes have a high-bandwidth connection and wish to
> = contribute=20 resources, and sometimes not have a high-bandwidth connection =
> and=20 therefore not wish to offer resources. Does this modality make = it
>=20 two different nodes?
>
>
>> If we do go this = way, there=20 is one subtle point. If I join the overlay
>>
>=20 but
>
>> don't happen to offer any services (other = than=20 maybe
>>
> storage...depending on
>
>> = how we=20 definie it, that might or might not be mandatory), would I = be
>>=20 contributing? If joining the overlay (in the sense that we have=20 a
>>
> PeerID
>
>> and
>> we = route=20 traffic) doesn't require me to store, I could offer = no
>>
>=20 services
>
> That's "offer no other services", since = routing is=20 itself a service.
>
>
>> and
>> still = be a=20 peer. How do we distinguish between this case and a
>>=20 "non-contributing peer" who isn't even part of the overlay (i.e.,=20 no
>> Peer-ID)
>>
>
> I think there's = a range=20 of "contributing" in play. For most DHT models,
> a minimally = contributing node will route a request it receives. It might
> = ask=20 nicely (perhaps a q-value mechanism) to not have to route = requests,
>=20 but would probably mathematically still have to route something it = gets.=20
>
> I think we distinguish based on the service = advertisements=20 from the
> peer.
>
>
>> If we are so = opposed to=20 client for confusion with SIP UAs, lets pick a
>>
> = new=20
>
>> name, but why some flavor of peer when it does = nothing=20 remotely peer
>>
> like?
>
> Because in = 15=20 minutes it might roam onto a WiFi net and therefore change
> = it=20 service offering.
>
> --
> Dean
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>
>


______= _________________________________________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

------_=_NextPart_001_01C7C13D.59EEF9B7-- --===============1629332144== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1629332144==-- buting peer" who isn't even part of the overlay (i.e.,=20 no
>> Peer-ID)
>>
>
> I think there's = a range=20 of "contributing" in play. For most DHT models,
> a minimally = contributing node will route a request it receives. It might
> = ask=20 nicely (perhaps a q-value mechanism) to not have to route = requests,
>=20 but would probably mathematically still have to route something it = gets.=20
>
> I think we distinguish based on the service = advertisements=20 from the
> peer.
>
>
>> If we are so = opposed to=20 client for confusion with SIP UAs, lets pick a
>>
> = new=20
>
>> name, but why some flavor of peer when it does = nothing=20 remotely peer
>>
> like?
>
> Because in = 15=20 minutes it might roam onto a WiFi net and therefore change
> = it=20 service offering.
>
> --
> Dean
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>
>


______= _________________________________________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

------_=_NextPart_001_01C7C13D.59EEF9B7-- --===============1629332144== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1629332144==-- From p2psip-bounces@ietf.org Sun Jul 08 04:53:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SWA-0001sJ-TU; Sun, 08 Jul 2007 04:53:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7SW9-0001sA-7k for p2psip@ietf.org; Sun, 08 Jul 2007 04:53:21 -0400 Received: from mail-out.sbs.be ([193.109.72.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7SW7-00067w-HW for p2psip@ietf.org; Sun, 08 Jul 2007 04:53:21 -0400 Received: from bruc001x.sbs.be (bruc001x.sbs.be [193.210.175.38]) by mail-out.sbs.be (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id l688qj4W023782 for ; Sun, 8 Jul 2007 10:52:45 +0200 Received: from bru0007a.ww018.siemens.net (bru0007a.ww018.siemens.net [193.210.175.161]) by bruc001x.sbs.be (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id l688qn7R019571 for ; Sun, 8 Jul 2007 10:52:49 +0200 Received: from BRU0038A.ww018.siemens.net ([193.210.175.28]) by bru0007a.ww018.siemens.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 8 Jul 2007 10:52:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: FW: [P2PSIP] do we need a client protocol? Date: Sun, 8 Jul 2007 10:52:24 +0200 Message-ID: <67043E463DDBFD4A8087ED940BFF756B01822DFB@BRU0038A.ww018.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace/4xAcHYq4SdzlRpiCaLTKb9HGzwBWjopQ From: "Willekens, Marc" To: X-OriginalArrivalTime: 08 Jul 2007 08:52:46.0272 (UTC) FILETIME=[5ABB0400:01C7C13D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8506cd99a2b34fd8177504aff14605e X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1781708336==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1781708336== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C13D.5A4E5727" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C13D.5A4E5727 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 ________________________________ From: Willekens, Marc=20 Sent: vrijdag 6 juli 2007 17:34 To: 'David Barrett' Subject: RE: [P2PSIP] do we need a client protocol? Hi David, Yes, we can try to consider the ratio between A and B, but more = important is the unknown and uncontrolable value of "n". When your phone is used as a "transfer node" in the p2p routing network, = then you are influenced by all the other peers making use of your = transfer function. Every time they setup a media session, your device is = negatively influenced. If we want the p2p to become successful for = limited devices and to avoid that people will turn of their phones to = avoid the additional uncontrollable battery consumption, a kind of = dynamic resource indication function is required by the p2p protocol. = E.g. when a certain battery level threshold is reached, a decision can = be made that the device will no longer be an resource contributing = element in the p2p network. This is important to consider to reserve the = resources for emergency calls. br, Marc.=20 ________________________________ From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: woensdag 27 juni 2007 19:06 To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com; = alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I don't know anything about mobile application design vis-=E0-vis = battery life, but I'm guessing power usage could be vastly = oversimplified to something like: =20 Power =3D A + nB =20 Where A is the overall cost of just having the device powered on and = listening to the radio, and B is the cost of sending a byte of data. = What I'm wondering is, what is the ratio of A to B? Can anyone give = real-world data? =20 For example, I'd accept that sending 200Mbps probably requires about 2x = the power 100Mbps: for a high enough value of 'n', then the constant A = gets marginalized. But what about 200Kbps or 200bps? For some low = value of 'n', then A dominates the power usage. =20 The reason I ask is I wonder if it's even useful to discuss power usage = for something like P2PSIP. It could be that even for a "real" peer, 'n' = is so low that the power consumption is dominated by other factors, = rendering the entire discussion moot. =20 Can anybody give real-world data on this topic? =20 -david=20 =20 ________________________________ From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] = Sent: Wednesday, June 27, 2007 12:33 AM To: eunsooshim@gmail.com; alan@sipstation.com Cc: hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca; = p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Hi, =20 We have wide variety of mobile terminals. The capabilities of mobile = terminals are constantly improving e.g. even now Nokia's = N-series/E-series devices are very powerful. From this reason some of = mobile terminals may become peers (depending on the case scenario: = churn, size of the network). However there are also many = entry-level/low-end devices that have slow CPUs and limited memory.=20 Battery life is another issue. Most of the mobile phone users want long = battery life. DHT maintenance and handling searches have impact on idle = state that is more important from battery life perspective than the = active state (e.g. when user is calling/answering a call). =20 I was considering a similar solution to the one that Alan proposed = however as Eunsoo said it would be quite difficult to control the number = of connections in DHT. We also have problems with handling searches. =20 I assume that we will have some mobile terminals taking part in DHT and = some accessing resources stored in DHT using a client protocol. Marcin =09 ________________________________ From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: 27 June, 2007 02:26 To: Alan Johnston Cc: Henry Sinnreich; Avshalom Houri; Philip Matthews; P2PSIP Mailing = List Subject: Re: [P2PSIP] do we need a client protocol? =20 On 6/26/07, Alan Johnston wrote:=20 I've been giving this a lot of thought lately, thinking about the = actual requirements. =09 We want to allow energy-limited devices to participate to some level in P2PSIP. As such, perhaps instead of saying we need a client protocol, = perhaps we just need levels of participation in the overlay peer = protocol. =09 For example, a normal peer in the overlay will maintain peer protocol connections with many (perhaps dozens) of peers. Why? So that it can=20 quickly and efficiently route requests within the overlay. =20 =20 Perhaps an energy-limited device could just minimize the number of = peer protocol connections it maintains, perhaps even down to a minimum of two. This would result in slower routing of its requests through the overlay, but that seems like a reasonable tradeoff.=20 =09 The underling algorithm (e.g. a certain DHT algorithm) will dictate the = number of connections even though there might be some room for = adjustment. I don't think it is under complete control of individual = peer in the case of known DHT algorithms.=20 =20 Also, perhaps there are some other peer protocol functions, such as = data replication (storage would still be done, but not replication), that=20 could be skipped by these energy-limited peers. Perhaps their = requests and responses could be routed over the overlay with a lower priority than full peers. We need to manage the tradeoffs so that those peers who contribute the least to the overlay also get the lowest = performance from it. =09 =09 I am not quite sure I understand the benefit of introducing such = various levels of participation. Having a client protocol seems to be much simpler and easier than = introducing these various levels of participation.=20 =09 Thanks. =09 Eunsoo =20 Henry Sinnreich wrote: > Folks, >=20 > Given the length of the discussion on "do we need a client = protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about = the=20 > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com ] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = > peerterminology > > David A. Bryan wrote: > >> If I understand this right, not sure I like it. Do these >> > "non-contributing > >> peer" (I *do* like contributing better than active/passive) = entities=20 >> > have a > >> Peer-ID? In otherwords, are they part of the overlay at all? If so, >> > for > >> most >> DHTs, how do we allow you to be in the overlay and not store = resources=20 >> > (not > >> typical for most current DHT algorithms) >> > > Well, that certainly depends on the DHT algorithm involved. It = certainly > seems that a peer that moves between contributing and = non-contributing=20 > might HAVE a peer ID, but whether it chooses to insert itself into = the > DHT "right now" might determine whether it is contributing "right = now" > or not. > > >> My concern all along has been that I don't understand why something = >> is a peer if it isn't doing anything other than talking to someone >> and making requests, hence why I supported client in the first = place. >> I fail to see how something that isn't contributing anything, and=20 >> instead talks to a peer to get resources, is in any way a peer. It >> seems completely not in keeping with the idea of P2P. I also worry = it >> is likely to be very confusing since we've been using the other=20 >> terminology for over a year now. Just looks like a souce of = confusion. >> > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a high-bandwidth = connection=20 > and therefore not wish to offer resources. Does this modality make = it > two different nodes? > > >> If we do go this way, there is one subtle point. If I join the = overlay >> > but > >> don't happen to offer any services (other than maybe >> > storage...depending on > >> how we definie it, that might or might not be mandatory), would I = be >> contributing? If joining the overlay (in the sense that we have a >> > PeerID > >> and >> we route traffic) doesn't require me to store, I could offer no >> > services > > That's "offer no other services", since routing is itself a service. > > >> and >> still be a peer. How do we distinguish between this case and a >> "non-contributing peer" who isn't even part of the overlay (i.e., = no >> Peer-ID) >> > > I think there's a range of "contributing" in play. For most DHT = models,=20 > a minimally contributing node will route a request it receives. It = might > ask nicely (perhaps a q-value mechanism) to not have to route = requests, > but would probably mathematically still have to route something it = gets.=20 > > I think we distinguish based on the service advertisements from the > peer. > > >> If we are so opposed to client for confusion with SIP UAs, lets = pick a >> > new=20 > >> name, but why some flavor of peer when it does nothing remotely = peer >> > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore = change > it service offering.=20 > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 ------_=_NextPart_001_01C7C13D.5A4E5727 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

From: Willekens, Marc =
Sent: vrijdag 6=20 juli 2007 17:34
To: 'David Barrett'
Subject: RE: = [P2PSIP] do=20 we need a client protocol?

Hi David,
Yes, we can try to consider the ratio between A and B, but more = important=20 is the unknown and uncontrolable value of "n".
When your phone is used as a "transfer node" in the p2p routing = network,=20 then you are influenced by all the other peers making use of your = transfer=20 function. Every time they setup a media session, your device is = negatively=20 influenced.  If we want the p2p to become successful for = limited=20 devices and to avoid that people will turn of their phones to avoid = the=20 additional uncontrollable battery consumption, a kind = of dynamic=20 resource indication function is required by the p2p protocol. E.g. = when a=20 certain battery level threshold is reached, a decision can be made = that the=20 device will no longer be an resource contributing element in the = p2p=20 network. This is important to consider to reserve the resources for = emergency calls.
br,
Marc. 

From: David Barrett=20 [mailto:dbarrett@quinthar.com]
Sent: woensdag 27 juni 2007=20 19:06
To: marcin.matuszewski@nokia.com; eunsooshim@gmail.com;=20 alan@sipstation.com
Cc: hsinnrei@adobe.com; = AVSHALOM@il.ibm.com;=20 philip_matthews@magma.ca; p2psip@ietf.org
Subject: RE: = [P2PSIP] do we=20 need a client protocol?

I don=92t = know anything=20 about mobile application design vis-=E0-vis battery life, but I=92m = guessing power=20 usage could be vastly oversimplified to something=20 like:

 

Power =3D A=20 + nB

 

Where A is = the overall=20 cost of just having the device powered on and listening to the radio, = and B is=20 the cost of sending a byte of data.  What I=92m wondering is, what = is the=20 ratio of A to B?  Can anyone give real-world=20 data?

 

For example, = I=92d accept=20 that sending 200Mbps probably requires about 2x the power 100Mbps: for a = high=20 enough value of =91n=92, then the constant A gets marginalized.  = But what about=20 200Kbps or 200bps?  For some low value of =91n=92, then A dominates = the power=20 usage.

 

The reason I = ask is I=20 wonder if it=92s even useful to discuss power usage for something like=20 P2PSIP.  It could be that even for a =93real=94 peer, =91n=92 is so = low that the=20 power consumption is dominated by other factors, rendering the entire = discussion=20 moot.

 

Can anybody = give=20 real-world data on this topic?

 

-david=20

 

From:=20 marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] =
Sent: Wednesday, June 27, 2007 = 12:33=20 AM
To: = eunsooshim@gmail.com;=20 alan@sipstation.com
Cc:=20 hsinnrei@adobe.com; AVSHALOM@il.ibm.com; philip_matthews@magma.ca;=20 p2psip@ietf.org
Subject: RE:=20 [P2PSIP] do we need a client = protocol?

 

Hi,

 

We have wide=20 variety of mobile terminals. The capabilities of mobile = terminals=20 are constantly improving e.g. even now Nokia's = N-series/E-series=20 devices are very powerful. From this reason some of mobile=20 terminals may become peers (depending on the case scenario: churn, = size of=20 the network). However there are = also many entry-level/low-end=20 devices that have slow CPUs and limited=20 memory. 

Battery life is = another issue.=20 Most of the mobile phone users want long battery life. DHT = maintenance and=20 handling searches have impact on idle state that is more important=20 from battery life perspective than the active state (e.g. when = user is=20 calling/answering a call).

    

I was = considering=20 a similar solution to the one that Alan proposed however as Eunsoo said=20 it would be quite difficult to control the number of = connections in=20 DHT. We also have problems with handling=20 searches.

 

I assume = that we will have some mobile terminals taking part in DHT and some = accessing resources stored in DHT using a client=20 protocol.


Marcin

From: ext=20 Eunsoo Shim [mailto:eunsooshim@gmail.com]
Sent: 27 June, 2007 = 02:26
To: Alan Johnston
Cc: Henry Sinnreich; Avshalom = Houri;=20 Philip Matthews; P2PSIP Mailing List
Subject: Re: [P2PSIP] do we = need a client=20 protocol?

 

On 6/26/07, Alan Johnston <alan@sipstation.com>=20 wrote:

I've been giving this a lot of thought = lately,=20 thinking about the actual
requirements.

We want to allow=20 energy-limited devices to participate to some level = in
P2PSIP.  =20 As such, perhaps instead of saying we need a client protocol, =
perhaps we=20 just need levels of participation in the overlay peer = protocol.

For=20 example, a normal peer in the overlay will maintain peer=20 protocol
connections with many (perhaps dozens) of=20 peers.  Why?  So that it can
quickly and = efficiently=20 route requests within the overlay.

 

 

Perhaps an energy-limited device could = just minimize=20 the number of peer
protocol connections it maintains, perhaps = even down=20 to a minimum of
two.  This would result in slower = routing of=20 its requests through the
overlay, but that seems like a = reasonable=20 tradeoff.


The underling algorithm (e.g. a certain = DHT=20 algorithm) will dictate the number of connections even though there = might be=20 some room for adjustment. I don't think it is under complete control = of=20 individual peer in the case of known DHT algorithms.=20

 

Also, perhaps there are some other peer = protocol=20 functions, such as data
replication (storage would still be done, = but not=20 replication), that
could be skipped by these energy-limited=20 peers.  Perhaps their requests
and responses could be = routed=20 over the overlay with a lower priority
than full = peers.  We=20 need to manage the tradeoffs so that those peers
who contribute = the least=20 to the overlay also get the lowest performance
from=20 it.



I am not quite sure I = understand=20 the benefit of introducing such various levels of = participation.
Having a=20 client protocol seems to be much simpler and easier than introducing = these=20 various levels of participation.=20

Thanks.

Eunsoo

 

Henry Sinnreich wrote:
> = Folks,
>=20
> Given the length of the discussion on "do we need a client=20 protocol?"
> let me repeat the simple imperatives for the=20 client:
>
> - Limited battery in mobile devices,=20 and
>
> - Other uses besides SIP. Business planning = folks may=20 not care about the
> WG charter, but about the return on the=20 investment.
>
> Thanks, Henry
>
> = -----Original=20 Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com=20 ]
> Sent: Thursday, June 14, 2007 11:23 PM
> To: = David A.=20 Bryan
> Cc: Avshalom Houri; P2PSIP Mailing List; Philip=20 Matthews
> Subject: Re: [P2PSIP] Concepts document: proposal = for=20 active/passive
> peerterminology
>
> David A. = Bryan=20 wrote:
>
>> If I understand this right, not sure I = like it.=20 Do these
>>
> "non-contributing
>
>> = peer" (I=20 *do* like contributing better than active/passive) entities=20
>>
> have a
>
>> Peer-ID? In = otherwords, are=20 they part of the overlay at all? If so,
>>
>=20 for
>
>> most
>> DHTs, how do we allow you = to be in=20 the overlay and not store resources
>>
>=20 (not
>
>> typical for most current DHT=20 algorithms)
>>
>
> Well, that certainly depends = on the=20 DHT algorithm involved. It certainly
> seems that a peer that = moves=20 between contributing and non-contributing
> might HAVE a peer = ID, but=20 whether it chooses to insert itself into the
> DHT "right now" = might=20 determine whether it is contributing "right now"
> or=20 not.
>
>
>> My concern all along has been that = I don't=20 understand why something
>> is a peer if it isn't doing = anything=20 other than talking to someone
>> and making requests, hence = why I=20 supported client in the first place.
>>  I fail = to see=20 how something that isn't contributing anything, and
>> = instead=20 talks to a peer to get resources, is in any way a peer. = It
>> seems=20 completely not in keeping with the idea of P2P. I also worry=20 it
>>  is likely to be very confusing since we've = been=20 using the other
>> terminology for over a year now. Just = looks=20 like a souce of confusion.
>>
>
> A node might=20 sometimes have a high-bandwidth connection and wish to
> = contribute=20 resources, and sometimes not have a high-bandwidth connection =
> and=20 therefore not wish to offer resources. Does this modality make = it
>=20 two different nodes?
>
>
>> If we do go this = way, there=20 is one subtle point. If I join the overlay
>>
>=20 but
>
>> don't happen to offer any services (other = than=20 maybe
>>
> storage...depending on
>
>> = how we=20 definie it, that might or might not be mandatory), would I = be
>>=20 contributing? If joining the overlay (in the sense that we have=20 a
>>
> PeerID
>
>> and
>> we = route=20 traffic) doesn't require me to store, I could offer = no
>>
>=20 services
>
> That's "offer no other services", since = routing is=20 itself a service.
>
>
>> and
>> still = be a=20 peer. How do we distinguish between this case and a
>>=20 "non-contributing peer" who isn't even part of the overlay (i.e.,=20 no
>> Peer-ID)
>>
>
> I think there's = a range=20 of "contributing" in play. For most DHT models,
> a minimally = contributing node will route a request it receives. It might
> = ask=20 nicely (perhaps a q-value mechanism) to not have to route = requests,
>=20 but would probably mathematically still have to route something it = gets.=20
>
> I think we distinguish based on the service = advertisements=20 from the
> peer.
>
>
>> If we are so = opposed to=20 client for confusion with SIP UAs, lets pick a
>>
> = new=20
>
>> name, but why some flavor of peer when it does = nothing=20 remotely peer
>>
> like?
>
> Because in = 15=20 minutes it might roam onto a WiFi net and therefore change
> = it=20 service offering.
>
> --
> Dean
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>=20 _______________________________________________
> P2PSIP = mailing=20 list
> P2PSIP@ietf.org
> https://www1.ietf.= org/mailman/listinfo/p2psip
>
>
>


______= _________________________________________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

=

 

= ------_=_NextPart_001_01C7C13D.5A4E5727-- --===============1781708336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1781708336==-- From p2psip-bounces@ietf.org Sun Jul 08 14:07:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7bAA-0005Kk-7f; Sun, 08 Jul 2007 14:07:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7bA8-0005C4-Up for p2psip@ietf.org; Sun, 08 Jul 2007 14:07:12 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7bA3-0002Qi-TX for p2psip@ietf.org; Sun, 08 Jul 2007 14:07:12 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Sun, 08 Jul 2007 11:07:06 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l68I5sot012965; Sun, 8 Jul 2007 11:05:55 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l68I5JI9001986; Sun, 8 Jul 2007 11:05:19 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Jul 2007 11:07:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays Date: Sun, 8 Jul 2007 11:06:59 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22A6D56A@namail5.corp.adobe.com> In-Reply-To: <910115EC-3A01-4790-B291-94965C5BEF1F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Concepts issue: Domains and Overlays Thread-Index: Ace9MWHD+vUfDtjbTF+DzT9QkMfRDgEU95vw References: <63075F75-44EA-423A-A5E1-BDF74C380FE0@softarmor.com> <910115EC-3A01-4790-B291-94965C5BEF1F@cisco.com> From: "Henry Sinnreich" To: "Cullen Jennings" , "Dean Willis" X-OriginalArrivalTime: 08 Jul 2007 18:07:04.0216 (UTC) FILETIME=[CA028980:01C7C18A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Cullen Jennings wrote: > Consider the other end of the dog, =20 > namespaces and enrollment servers. This is an extremely useful contribution since the critical importance of the enrollment server cannot be over emphasized. The enrollment server can also play a role by linking p2p domains from a business perspective, for example: - p2p.com runs a global commercial p2p overlay and has resellers, such as - myisp.com who resells p2p service to - ourit.com who enrolls its employees into the ourit.com overlay, and to - ourschool.edu for students and alumni of ourschool.edu Note there must be a hierarchy of enrollment servers to make this happen and the hierarchy is controlled by cryptographic means. The advantage of creating the enrollment hierarchy include greater reach for p2p.com and the accompanying better functioning of the partitioned overlay: The more users, the better it works. Contrary to the golden tree of the DNS hierarchy however we would want many such p2p trees for a healthy competitive market place. (This is no endorsement in any way for private ENUM, but that's a rat hole to please avoid here on the list). Does it make sense to have a BCP on namespaces and enrollment servers? Such a BCP could also discuss the use the UUID (RFC 4122) that has been mentioned in several I-Ds submitted to the P2PSIP WG. Henry -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Tuesday, July 03, 2007 12:15 AM To: Dean Willis Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays Short answer: Yes, Dean, I basically like what you are proposing. Long answer: I got pretty lost on the thread that came out of this but it occurred =20 to me that looking at this as domains and overlays might be trying to =20 wag the dog from the wrong end. Consider the other end of the dog, =20 namespaces and enrollment servers. I think we can all agree that if Cullen is known on some overlay as =20 fluffy@example.org, then we really don't want Dean to also be known =20 on some other overlay as fluffy@example.org. We need the names to be =20 useful and refer to a unique human user. So who decided who gets the =20 name fluffy@example.org, Dean or Cullen? The enrollment server that =20 is responsible for example.org gets to decide. I think this more or =20 less means that an enrollment server may be able to have more than =20 one domain mapped to it but a domain maps to at most one enrollment =20 server. Now all the peers on the overlay need to be able to have a =20 common trust root of some form on who the peers believe is allowed to =20 allocate the names in this particular overlay. Once again, that is =20 the enrollment server. So an given overlay can only have one logical =20 enrollment server. (Someone will say there could be multiple trust =20 roots here but given the peers in the overlay have to know about =20 *everyone* of the trust roots, I would just argue this had virtually =20 formed all the trust roots into a single logical enrollment server). =20 Similarly, if someone is trying to reach fluffy@example.org, unless =20 fluffy is in all the overlays that the example.org enrollment server =20 is responsible for, then we need to know which overlay to look in and =20 it seems the only way to know this is to have at most one overlay for =20 each domain. So if you follow this somewhat confused logic, I come =20 out thinking that the easiest solution looks like the following: A set of one more domain name (typically one) maps to a exactly one =20 logical enrollment server. The single logical enrollment server maps =20 to exactly one overlay. The enrollment server creates unique names =20 inside the namespace that is delegated to it by the domain names that =20 map to it. So to answer Deans question below - model one works for me. Model two =20 only works for me if every peer in the overlay knows about the =20 credentials of every enrollment server for every domain that can =20 allocate names in the overlay *before* any peer ever enrolls in the =20 overlay. This seems pretty impractical for anything but a very small =20 set of enrollment servers. Cullen On Jun 13, 2007, at 4:00 PM, Dean Willis wrote: > > Someone brought this up on the list, and I wanted to clarify the =20 > consensus here before nailing it down further in the concepts doc. > > We think of usernames as domain-scoped, like "joebob@example.com". > > One model of an overlay allows users to enroll names from many =20 > domains. In this model, there might be only one overlay serving =20 > every domain in the world, including (for example) "example.com" =20 > and "example.net". Clearly routing messages within this overlay is =20 > straightforward, and there's no need to talk to any other overlay. > > In another model, each overlay corresponds to one or more but not =20 > all domains, and we use RFC 3263 procedures to route between =20 > overlays. So "example.com" might be in one overlay, and =20 > "example.net" in another. Each overlay can look up the other in DNS =20 > to find it. > > This second model mostly precludes having one domain scattered =20 > across multiple overlays. > > Here's the deal: Assume we have overlays A and B. Alice@example.com =20 > enrolls with overlay A, and Bob@example.com enrolls with overlay B. > > Alice now wants to call Bob. She looks him up in her overlay, and =20 > he's not there. What to do? She can't just look up example.com in =20 > DNS, because it has been split across A and B and DNS just doesn't =20 > work that way. Now, if both A and B registered with some "upstream" =20 > lookup function (a meta-overlay), then Alice could perhaps look =20 > there. But this starts to get messy really quickly. > > So unless we want to solve the namespace-split-across-overlays =20 > problem (and that's not easy), we're much better off at this time =20 > having a model where each domain can be mapped onto only one =20 > overlay at a time. > > Y'all ok with that? > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 09 10:20:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7u6W-0005Wj-SJ; Mon, 09 Jul 2007 10:20:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7u6U-0005RM-Pl for p2psip@ietf.org; Mon, 09 Jul 2007 10:20:42 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7u6Q-0000SH-Iv for p2psip@ietf.org; Mon, 09 Jul 2007 10:20:42 -0400 Received: by an-out-0708.google.com with SMTP id c17so186269anc for ; Mon, 09 Jul 2007 07:20:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=qWHXXcp/kEsO/H0n6C4Eo9QvF+VzLOjQXOfE+L1YngL7pvrSs27f/+ZI+/aw8w6sb0zIkRCdjzOvN2PJyUp43ym8BCLTF5K3hgIN3PqoFRzgVcLXZmyLsk39C8F4j7IYh1q9N4261K1Ui/dheqzv7XV0eBqng014xO3zdgn36yA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=CXaVVNHnkNqx6N/ibwIQCFTmibLw/E/FSd5UoXpuKxfU7q+BCw4xfw4TQsLPg1JDUaAM8R51zteU5gPycxjazRajpubz3QJoxSA732jeAsfvXqTKEqQ5TKq4PbZHouEfq2ZspImxV56cQrkBomd2caftNIczvqoE/l5/V7Z+1BQ= Received: by 10.100.135.16 with SMTP id i16mr1586856and.1183990837530; Mon, 09 Jul 2007 07:20:37 -0700 (PDT) Received: by 10.100.112.12 with HTTP; Mon, 9 Jul 2007 07:20:37 -0700 (PDT) Message-ID: <20d2bdfb0707090720o4afb663ewa3f1f3e64c4ac102@mail.gmail.com> Date: Mon, 9 Jul 2007 10:20:37 -0400 From: "Bruce Lowekamp" To: "P2PSIP Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 9c35f82553e13cb5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [P2PSIP] new RELOAD drafts X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We have submitted an update to the base RELOAD draft, draft-bryan-p2psip-reload-01 and on security extensions for RELOAD draft-lowekamp-p2psip-reload-security-01 Until they are available in the repository, they are available from p2psip.org The major change to reload-01 is the addition of sections describing the TRANSPORT-OPEN and TRANSPORT-TUNNEL methods for NAT traversal. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 09 10:27:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7uDC-0002e1-Gt; Mon, 09 Jul 2007 10:27:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7uDC-0002dw-0u for p2psip@ietf.org; Mon, 09 Jul 2007 10:27:38 -0400 Received: from an-out-0708.google.com ([209.85.132.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7uD7-0000fk-QB for p2psip@ietf.org; Mon, 09 Jul 2007 10:27:38 -0400 Received: by an-out-0708.google.com with SMTP id c17so186748anc for ; Mon, 09 Jul 2007 07:27:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=YHt3nYNJkaQrckPpj6BtiWms4SxhpdNpjkDheepBWuOh5Jq68h1PQQNFE7PB1Heo6HTDOS3qqAr48VVQnxQ0p9Q1I/CUwNMwFKKnDm5CXVrrgIDeUwA9hvbsSUFm8jcJfQ6inxeZcEXTHdkIlcqdxQLgBTBq3Tba1YdHqx7E/3I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=flHTXC5lVzE6waBMAldb5Q6m+FxpdrL1JeQ8rrs71uiblYwzmlUv3zfQwrVQHqIqQPb2pVpmPeoOFx7qoc3sRNnYZopcwEZ65lctKDCA6yIjCX/vPsnYAb7APPbiRBFMzHIH68McjLT/eRkL25+6lmv/jM0uCQ3CpgYyeAk7vLs= Received: by 10.100.91.6 with SMTP id o6mr1616316anb.1183991253166; Mon, 09 Jul 2007 07:27:33 -0700 (PDT) Received: by 10.100.112.12 with HTTP; Mon, 9 Jul 2007 07:27:33 -0700 (PDT) Message-ID: <20d2bdfb0707090727y7363d235o45148cad018d3e77@mail.gmail.com> Date: Mon, 9 Jul 2007 10:27:33 -0400 From: "Bruce Lowekamp" To: "P2PSIP Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: c2238aeba84a947d X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [P2PSIP] draft-bryan-p2psip-usecases-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We have submitted draft-bryan-p2psip-usecases-00. This draft is already available in the repository and is also posted on p2psip.org. This draft is a minor revision to the previous draft-bryan-sipping-p2p-usecases-00. The authors have some more significant revsions in mind, but we felt it was important to put this draft in a place where newcomers to the group will find it. Comments or contributions are welcome. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 09 12:48:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wPn-0003VX-Qb; Mon, 09 Jul 2007 12:48:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wPm-0003VR-6Q for p2psip@ietf.org; Mon, 09 Jul 2007 12:48:46 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I7wPW-00043j-Qc for p2psip@ietf.org; Mon, 09 Jul 2007 12:48:46 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 09 Jul 2007 09:46:47 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l69GjWot026396; Mon, 9 Jul 2007 09:45:32 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l69Gkc0e020641; Mon, 9 Jul 2007 09:46:40 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 09:46:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Jul 2007 09:46:34 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22A6D6B9@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The client role in the Concepts and Terminology I-D Thread-Index: AcfCSAap3HCXUaAjRz621snxgDrWaQ== From: "Henry Sinnreich" To: "P2PSIP Mailing List" X-OriginalArrivalTime: 09 Jul 2007 16:46:39.0117 (UTC) FILETIME=[B8709BD0:01C7C248] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: bryan@sipeerior.com, Philip Matthews Subject: [P2PSIP] The client role in the Concepts and Terminology I-D X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Given the importance of "Concepts and Terminology for Peer to Peer SIP", ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-willis-p2psip-co ncepts-04.txt=20 I would suggest improving the text by introducing something like this to section 5.5. Possible Client Behavior: "One of the main motivations for the client protocol is to avoid the 'always talking' mode for mobile devices that would participate as full peers and contribute the IP messages required for the overlay maintenance. The continuous IP packet exchange may contribute to the depletion of the battery and possibly also to increase the charges for certain mobile services. As a consequence, it is desirable for certain mobile devices to benefit from the P2PSIP overlay but not to contribute to its maintenance or to the routing and data storage functions of P2P SIP. The client protocol is a subset of the peer protocol that allows the client to store and retrieve data from the P2PSIP overlay and also to exercise the overlay for message routing. The client protocol should be flexible enough to also be extensible for non-SIP applications, such as search, multicast, streaming media and content distribution." Delete on page 19 the following and similar on other pages: "In essence, the client contributes its storage capacity to its associated peer."... Replace with: "Due to their high churn and low bandwidth, certain mobile devices are not only lesser capable peers, but actually would degrade the performance of the P2P SIP overlay network as a whole." Thanks, Henry Sinnreich _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 09 14:10:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7xgl-00082g-Bs; Mon, 09 Jul 2007 14:10:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7xgj-00082T-62 for p2psip@ietf.org; Mon, 09 Jul 2007 14:10:21 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7xgi-0007mv-TR for p2psip@ietf.org; Mon, 09 Jul 2007 14:10:21 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I7xgE-0002uN-1M; Mon, 09 Jul 2007 14:09:50 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Mon, 9 Jul 2007 14:10:12 -0400 To: P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Subject: [P2PSIP] New version of Concepts draft: draft-ietf-p2psip-concepts-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Folks: The latest version of the Concepts draft is now available as http://tools.ietf.org/html/draft-ietf-p2psip-concepts-00 This draft is now the (first) official document of the working group. The authors didn't make a huge number of changes to the draft this time. Mostly, the changes are minor improvements to the presentation of the material, but some additions to the list of open questions. While there has been a fair amount of discussion on things like the possible existence and role of clients, we didn't see a lot of solid new material that we could add. Hopefully, some of these issues will be resolved in time for the next revision before the Vancouver meeting. Dean did most of the work in producing this revision. - Philip Here is a list of changes from the previous version (draft-willis- p2psip-concepts-04): 1. Revised "Open Questions" to reflect current discussion. 2. Resolved conflict between "services provided by overlay" and "named services provided by peers" by calling all overlay-level operations "functions". Thus, we would now speak of an overlay providing a "distributed transport function". 3. Resolved open issue "Does P2PSIP provide a distributed location function or an alternative mechanism to RFC 3263? The answer seems to be both, but what is the relationship between these?" by documenting that each overlay provides an alternative to [RFC3263] within that overlay, but that [RFC3263] is used in the conventional manner between overlays. 4. Revised abstract to include SIP message routing within the scope. 5. Added brief mention of peer's capacity for services offered in overview section on distributed database. 6. Revised definition of P2PSIP Service. 7. Revised abstract and high level discussion. 8. Added discussion of proposed peer models and relationship to SIP UAs. 9. Revised reference model diagram to clarify client behavior. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 09 14:15:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7xlw-0004Yh-Oc; Mon, 09 Jul 2007 14:15:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7xld-0003yK-NJ for p2psip@ietf.org; Mon, 09 Jul 2007 14:15:25 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7xlX-00085O-IT for p2psip@ietf.org; Mon, 09 Jul 2007 14:15:25 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I7xlW-0001CI-2v; Mon, 09 Jul 2007 14:15:19 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22A6D6B9@namail5.corp.adobe.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22A6D6B9@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7C9C7199-427C-4A4B-BC12-50060EAB2541@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] The client role in the Concepts and Terminology I-D Date: Mon, 9 Jul 2007 14:15:40 -0400 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: bryan@sipeerior.com, P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry: For the latest revision of the Concepts draft (now draft-ietf-p2psip- concepts-00), the authors elected to not make significant changes to the section discussing possible client behavior. While we have seem some discussion recently on the list, we didn't think that things had changed enough to warrant significant change yet. In fact, we are hoping that your promised draft on why we want clients, and the follow-up discussion, will provide material for the next revision. - Philip On 9-Jul-07, at 12:46 , Henry Sinnreich wrote: > Given the importance of "Concepts and Terminology for Peer to Peer > SIP", > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-willis- > p2psip-co > ncepts-04.txt > > I would suggest improving the text by introducing something like > this to > section 5.5. Possible Client Behavior: > > "One of the main motivations for the client protocol is to avoid the > 'always talking' mode for mobile devices that would participate as > full > peers and contribute the IP messages required for the overlay > maintenance. The continuous IP packet exchange may contribute to the > depletion of the battery and possibly also to increase the charges for > certain mobile services. > > As a consequence, it is desirable for certain mobile devices to > benefit > from the P2PSIP overlay but not to contribute to its maintenance or to > the routing and data storage functions of P2P SIP. > > The client protocol is a subset of the peer protocol that allows the > client to store and retrieve data from the P2PSIP overlay and also to > exercise the overlay for message routing. > > The client protocol should be flexible enough to also be extensible > for > non-SIP applications, such as search, multicast, streaming media and > content distribution." > > Delete on page 19 the following and similar on other pages: > > "In essence, the client contributes its storage capacity to its > associated peer."... > > Replace with: > > "Due to their high churn and low bandwidth, certain mobile devices are > not only lesser capable peers, but actually would degrade the > performance of the P2P SIP overlay network as a whole." > > Thanks, > > Henry Sinnreich > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 09 15:51:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zGl-00016h-Aw; Mon, 09 Jul 2007 15:51:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zGk-000146-6D for p2psip@ietf.org; Mon, 09 Jul 2007 15:51:38 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7zGj-0007Ry-BX for p2psip@ietf.org; Mon, 09 Jul 2007 15:51:38 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l69JpU4Y011564; Mon, 9 Jul 2007 22:51:31 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 22:51:30 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 22:51:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] do we need a client protocol? Date: Mon, 9 Jul 2007 22:54:26 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04BAFCAD@esebe102.NOE.Nokia.com> In-Reply-To: <92489DF0-AE49-49C7-872D-D378819E9410@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace6YH/7YdAtIn/pQ6ywZxet08edegH/uCKw References: <997FC080-AD1F-40B9-BB5E-F3989125E42B@softarmor.com> <92489DF0-AE49-49C7-872D-D378819E9410@softarmor.com> From: To: , X-OriginalArrivalTime: 09 Jul 2007 19:51:29.0957 (UTC) FILETIME=[8B187D50:01C7C262] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org If you would like to run a web server on your nokia symbian device go to this webpage: http://mymobilesite.net/. If you need more info about the server and the future of internet communication please read the following article=20 http://forum.nokia.com/main/resources/technologies/mobile_web_server/ind ex.html My personal webpage powered by a web server that runs on my mobile phone: mm.mymobilesite.net Marcin >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: 29 June, 2007 18:07 >To: David Barrett >Cc: p2psip@ietf.org >Subject: Re: [P2PSIP] do we need a client protocol? > > >On Jun 29, 2007, at 2:02 AM, David Barrett wrote: > >> >> Until the whole IP network listen/battery-life thing has been worked=20 >> out in a more general fashion (ie, one that doesn't require layer 2=20 >> tricks between the client and the network), it's probably=20 >premature to=20 >> worry about. >> >> Do you agree, or did I misunderstand your conclusion? > >Well, let's put it another way. > >A lot of folks are putting a whole lot of money into IP=20 >applications running on mobile devices, and into mobile=20 >devices designed to run IP applications. I was playing with a=20 >SIP client on my Nokia 770 last night, and it's already been=20 >obsoleted by the new 800. > >Folks are also putting a lot of money into better 802.11=20 >chipsets, but we can't expect a "magic bullet" on that front=20 >that will turn a PDA into a data-center-class server. > >So the reality is, we're going to have a whole lot of boxes=20 >running in mobile configurations, and these boxes are not=20 >going to have all the capabilities of server-class machines,=20 >and that's just the way it is going to be for quite a long time. > >Now, do you want to pay attention to half the nodes on the=20 >Internet, or not? > >-- >Dean > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 09 16:11:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zZY-0006N5-KA; Mon, 09 Jul 2007 16:11:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zZX-0006Mz-N1 for p2psip@ietf.org; Mon, 09 Jul 2007 16:11:03 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I7zZT-0004pK-6v for p2psip@ietf.org; Mon, 09 Jul 2007 16:11:03 -0400 Received: from source ([192.150.11.134]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Mon, 09 Jul 2007 13:10:54 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l69K9cot001365; Mon, 9 Jul 2007 13:09:39 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l69KAG1E017684; Mon, 9 Jul 2007 13:10:47 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jul 2007 13:10:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] do we need a client protocol? Date: Mon, 9 Jul 2007 13:10:41 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22A6D845@namail5.corp.adobe.com> In-Reply-To: <3F18E76823C95E4795181D74BAC7664F04BAFCAD@esebe102.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: Ace6YH/7YdAtIn/pQ6ywZxet08edegH/uCKwAAEWJvA= References: <997FC080-AD1F-40B9-BB5E-F3989125E42B@softarmor.com><92489DF0-AE49-49C7-872D-D378819E9410@softarmor.com> <3F18E76823C95E4795181D74BAC7664F04BAFCAD@esebe102.NOE.Nokia.com> From: "Henry Sinnreich" To: , , X-OriginalArrivalTime: 09 Jul 2007 20:10:45.0844 (UTC) FILETIME=[3C0ED940:01C7C265] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Jiri Kuthan , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I have no dog in this fight :-) but for the sake of accuracy, the first SIP server version of the future SER from iptel.org was built by Jiri Kuthan on an HP PDA around 2000-2001 or so. The least I can say is that building various Internet servers on mobile devices injects a healthy dose of reality. Henry -----Original Message----- From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] Sent: Monday, July 09, 2007 2:54 PM To: dean.willis@softarmor.com; dbarrett@quinthar.com Cc: p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? If you would like to run a web server on your nokia symbian device go to this webpage: http://mymobilesite.net/. If you need more info about the server and the future of internet communication please read the following article=20 http://forum.nokia.com/main/resources/technologies/mobile_web_server/ind ex.html My personal webpage powered by a web server that runs on my mobile phone: mm.mymobilesite.net Marcin >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: 29 June, 2007 18:07 >To: David Barrett >Cc: p2psip@ietf.org >Subject: Re: [P2PSIP] do we need a client protocol? > > >On Jun 29, 2007, at 2:02 AM, David Barrett wrote: > >> >> Until the whole IP network listen/battery-life thing has been worked=20 >> out in a more general fashion (ie, one that doesn't require layer 2=20 >> tricks between the client and the network), it's probably=20 >premature to=20 >> worry about. >> >> Do you agree, or did I misunderstand your conclusion? > >Well, let's put it another way. > >A lot of folks are putting a whole lot of money into IP=20 >applications running on mobile devices, and into mobile=20 >devices designed to run IP applications. I was playing with a=20 >SIP client on my Nokia 770 last night, and it's already been=20 >obsoleted by the new 800. > >Folks are also putting a lot of money into better 802.11=20 >chipsets, but we can't expect a "magic bullet" on that front=20 >that will turn a PDA into a data-center-class server. > >So the reality is, we're going to have a whole lot of boxes=20 >running in mobile configurations, and these boxes are not=20 >going to have all the capabilities of server-class machines,=20 >and that's just the way it is going to be for quite a long time. > >Now, do you want to pay attention to half the nodes on the=20 >Internet, or not? > >-- >Dean > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 09 17:36:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80uQ-0007o2-Nl; Mon, 09 Jul 2007 17:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I80uO-0007np-Cu for p2psip@ietf.org; Mon, 09 Jul 2007 17:36:40 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I80uK-0007aC-2k for p2psip@ietf.org; Mon, 09 Jul 2007 17:36:40 -0400 Received: by py-out-1112.google.com with SMTP id f31so3631812pyh for ; Mon, 09 Jul 2007 14:36:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type; b=R/xvZ3SaAoAjVMtq9horonnMNpG2g0ne7UqV8sjxTz21xzLKf7KAdXYxoVGl+iNr9x9AKX+8isohmusfgcMWDS/mk8hcCmzbqs0P5/9n6hV5Q67wghCzslYzGJxRNwZr12s9I9sg5Yxy8EoA+/aMGnI5La8fa/hVsksC6YOkMzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=jis6PSZfLS9Cs6vaviy6xzNBtjhPcdEWVwCuVLY3suj9Rujur3UvIJM92wBEp1de+chde5R8A45kJu3+AkVR2GcHL4o6dcQNv9U8FZsrAiJLO5sWlLUG+cYNeZd1YUspjUDY0N+2j//Zgdv87NlDA4LpDA565ro5OQlwqSGKvCs= Received: by 10.65.123.14 with SMTP id a14mr3482437qbn.1184016995314; Mon, 09 Jul 2007 14:36:35 -0700 (PDT) Received: by 10.65.185.14 with HTTP; Mon, 9 Jul 2007 14:36:34 -0700 (PDT) Message-ID: Date: Mon, 9 Jul 2007 23:36:35 +0200 From: "Michal Giermasinski" To: dbarrett@quinthar.com, marc.willekens@nsn.com Subject: RE: [P2PSIP] do we need a client protocol? MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1746065181==" Errors-To: p2psip-bounces@ietf.org --===============1746065181== Content-Type: multipart/alternative; boundary="----=_Part_118207_5122272.1184016995206" ------=_Part_118207_5122272.1184016995206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Marc, David! There is also another _commercial_ issue that is probably worth to remember. When you "attach" the overlay and you become an active peer in message routing, mobile device must take care of messages that are not addressed to it. Currently most of users use GPRS-like access to the internet and telco operators charge them on the amount of packets basis. This is an issue that users may not be happy with. If you have let say unlimited access to the internet you can make use of P2PPeerProtocol and play the role of regular peer in the overlay. You can put some storege, message routing actions to the overlay. But if a user suffer from his bills while he would like to take some advantages from p2pSip network there must be some way to help him. This is in my oppinion one of the reasons that there should be a client protocol defined. Well, there is also a problem that most of users would like just to take advantages from the access to the network than to play some serving roles. That's the reason why users running peer protocol must be favoured from those using client protocol. Do you see any possibilities of such favouring? Best regards Michal ------=_Part_118207_5122272.1184016995206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Marc, David!
 
There is also another _commercial_ issue that is probably worth to remember. When you "attach" the overlay and you become an active peer in message routing, mobile device must take care of messages that are not addressed to it. Currently most of users use GPRS-like access to the internet and telco operators charge them on the amount of packets basis.
 
This is an issue that users may not be happy with. If you have let say unlimited access to the internet you can make use of P2PPeerProtocol and play the role of regular peer in the overlay. You can put some storege, message routing actions to the overlay.
But if a user suffer from his bills while he would like to take some advantages from p2pSip network there must be some way to help him. This is in my oppinion one of the reasons that there should be a client protocol defined.
 
Well, there is also a problem that most of users would like just to take advantages from the access to the network than to play some serving roles. That's the reason why users running peer protocol must be favoured from those using client protocol.
 
Do you see any possibilities of such favouring?
 
Best regards
Michal
------=_Part_118207_5122272.1184016995206-- --===============1746065181== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1746065181==-- From p2psip-bounces@ietf.org Tue Jul 10 05:48:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CKp-0000Jr-SO; Tue, 10 Jul 2007 05:48:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8CKo-0000HF-2E for p2psip@ietf.org; Tue, 10 Jul 2007 05:48:42 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8CKn-00005Y-A5 for p2psip@ietf.org; Tue, 10 Jul 2007 05:48:41 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6A9m3kp026178; Tue, 10 Jul 2007 12:48:21 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 12:48:11 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 12:48:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] do we need a client protocol? Date: Tue, 10 Jul 2007 12:51:08 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04BAFE71@esebe102.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: AcfCcUQaAl4gPBy7QJmGWsKm+OVgkAAX5CDQ References: From: To: , , X-OriginalArrivalTime: 10 Jul 2007 09:48:11.0567 (UTC) FILETIME=[6D9643F0:01C7C2D7] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0128492925==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0128492925== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C2D7.6D6E4096" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C2D7.6D6E4096 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Michal, =20 You are right: charging and battery life are very important issues from the end user perspective. As you said most of mobile phone users do not enjoy flat rate subscriptions. They have to pay for every bit sent over the air interface (received and sent).=20 =20 Besides many mobile phones are behind firewalls (don't mention NATs). In order to be reachable they have send keepalives to some proxy/relay/etc. In addition they would have to maintain DHT, forward search queries, respond to GET/PUT requests for P2PSIP resource (user) records they are responsible for. Thus, we would require mobile phone users to pay for "only God knows what" traffic and recharge their mobile phones much more frequently. =20 Yes there is some percentage of mobile phone users who would do that but if we are targeting the mass market we need to consider those issues (at least now, things may change in the future). =20 According to my quick study of 100 mobile phone users, it seems that we should expect even higher rate of free riders in mobile P2P applications. =20 =20 Marcin ________________________________ From: ext Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 10 July, 2007 00:37 To: dbarrett@quinthar.com; Willekens Marc (NSN - BE/Belgium - MiniMD) Cc: p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =09 =09 Hi Marc, David! =20 There is also another _commercial_ issue that is probably worth to remember. When you "attach" the overlay and you become an active peer in message routing, mobile device must take care of messages that are not addressed to it. Currently most of users use GPRS-like access to the internet and telco operators charge them on the amount of packets basis. =20 This is an issue that users may not be happy with. If you have let say unlimited access to the internet you can make use of P2PPeerProtocol and play the role of regular peer in the overlay. You can put some storege, message routing actions to the overlay.=20 But if a user suffer from his bills while he would like to take some advantages from p2pSip network there must be some way to help him. This is in my oppinion one of the reasons that there should be a client protocol defined.=20 =20 Well, there is also a problem that most of users would like just to take advantages from the access to the network than to play some serving roles. That's the reason why users running peer protocol must be favoured from those using client protocol.=20 =20 Do you see any possibilities of such favouring? =20 Best regards Michal ------_=_NextPart_001_01C7C2D7.6D6E4096 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Michal,
 
You are right: charging and battery life = are very=20 important issues from the end user perspective. As you said most = of mobile=20 phone users do not enjoy flat rate subscriptions. They have to pay = for=20 every bit sent over the air interface (received and sent). =
 
Besides many mobile phones are behind = firewalls (don't=20 mention NATs). In order to be reachable they have send keepalives to = some=20 proxy/relay/etc. In addition they would have to maintain DHT, = forward=20 search queries, respond to GET/PUT requests for P2PSIP resource (user)=20 records they are responsible for. Thus, we would require = mobile=20 phone users to pay for "only God knows what" traffic and = recharge=20 their mobile phones much more frequently.
 
Yes there is some percentage of mobile phone = users who=20 would do that but if we are targeting the mass market we need to = consider those=20 issues (at least now, things may change in the = future).
 
According to my quick study of 100 mobile = phone users,=20 it seems that we should expect even higher rate of free = riders in=20 mobile P2P applications.  
 
Marcin

From: ext Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: 10 July, 2007=20 00:37
To: dbarrett@quinthar.com; Willekens Marc (NSN - = BE/Belgium -=20 MiniMD)
Cc: p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi Marc, David!
 
There is also another _commercial_ issue that is probably worth = to=20 remember. When you "attach" the overlay and you become an active peer = in=20 message routing, mobile device must take care of messages that are not = addressed to it. Currently most of users use GPRS-like access to the = internet=20 and telco operators charge them on the amount of packets basis.
 
This is an issue that users may not be happy with. If you have = let say=20 unlimited access to the internet you can make use of P2PPeerProtocol = and play=20 the role of regular peer in the overlay. You can put some storege, = message=20 routing actions to the overlay.
But if a user suffer from his bills while he would like to take = some=20 advantages from p2pSip network there must be some way to help him. = This is in=20 my oppinion one of the reasons that there should be a client protocol = defined.=20
 
Well, there is also a problem that most of users would like just = to take=20 advantages from the access to the network than to play some serving = roles.=20 That's the reason why users running peer protocol must be favoured = from those=20 using client protocol.
 
Do you see any possibilities of such favouring?
 
Best regards
Michal
------_=_NextPart_001_01C7C2D7.6D6E4096-- --===============0128492925== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0128492925==-- From p2psip-bounces@ietf.org Tue Jul 10 09:55:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8GBp-0005ZZ-IV; Tue, 10 Jul 2007 09:55:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8GBn-0005Wr-4q for p2psip@ietf.org; Tue, 10 Jul 2007 09:55:39 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8GBl-0005MO-Jl for p2psip@ietf.org; Tue, 10 Jul 2007 09:55:39 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 4575114DDC56 for ; Tue, 10 Jul 2007 21:55:11 +0800 (CST) Message-ID: <001801c7c2f9$ed8a2f50$a507740a@DELLWEI> From: "Wei Gengyu" To: References: <3F18E76823C95E4795181D74BAC7664F04BAFE71@esebe102.NOE.Nokia.com> Subject: Re: [P2PSIP] do we need a client protocol? Date: Tue, 10 Jul 2007 21:55:07 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1227912394==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1227912394== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C7C33C.FAA722E0" This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C7C33C.FAA722E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksIA0KDQpJZiB0aGUgcHJvYmxlbXMgd2VyZSByZWFsbHkgY29uc2lkZXJlZCBpbiB0aGlzIHdh eSwgcGVyaGFwcyB0aGVyZSBhcmUgc29tZSBvdGhlciBzaXR1YXRpb25zOg0KMS4gc29tZSBtb2Jp bGUgdXNlcnMgaGF2ZSBmaXhlZCBmZWUgcGVyIG1vbnRoLCBzbyB0aGV5IGRvIG5vdCBjYXJlIHRo ZSBhbW91bnQgb2YgdHJhZmZpYy4NCjIuIHNvbWUgbW9iaWxlIHVzZXJzIG9mZmVuIHVzZSBhZGFw dG9yIGNvbm5lY3RpbmcgdG8gcG93ZXIgc3VwcGx5IGluIG9mZmljZSBvciBob21lLCBzbyB0aGV5 IGRvIG5vdCBjYXJlIGJhdHRlcnkuIA0KMy4gc29tZSB1c2VycyBtYXkgZm9yd2FyZCB0aGVpciBt b2JpbGUgY2FsbCB0byBhIGZpeGVkIElTRE4gdGVybWluYWwsIHdoZXRoZXIgdGhlIHBhcnRpY2lw YW50IHdpbGwgYmUgdHJlYXRlZCBhcyBwZWVyIG9yIGNsaWVudCB3aXRob3V0IGJhdHRlcnkgb3Ig YmFuZHdpZHRoIGxpbWl0YXRpb24/DQogICBJbiB0aGlzIGNhc2UsIHRoZSBzZXJ2aWNlIGNhcGFi aWxpdHkgcHJvYmxlbSBtYXkgb2NjdXJzIGR1ZSB0byBtb2JpbGUgdXNlciBhdHRyaWJ1dGVzIG9y IElTRE4gdXNlciBhdHRyaWJ1dGVzLg0KICAgKFNvbWVvbmUgaW4gdGhlIGxpc3QgZXZlciBtZXRp b25lZCBzZXJ2aWNlIGNhcGFiaWxpeSBwcm9ibGVtKS4NCjQuIGludmVzdGlnYXRpb24gb2YgMTAw IHVzZXJzIGlzIG5vdCBzdWZmaWNpZW50LCBhcyBvbmUgbW9iaWxlIGNhcnJpZXIgaGVyZSBoYXZl IG1vcmUgdGhhbiAyMCwwMDAsMDAwIHVzZXJzLiANCg0KSWYgeW91IHRyeSwgeW91IGNvdWxkIGxp c3QgbWFueSBwcm9ibGVtcyBpbiBvdGhlciBzaXR1YXRpb25zLg0KDQpIb3dldmVyLCBteSBzdWdn ZXN0aW9uIGlzIHRoYXQgd2Ugc2hvdWxkIG5vdCBjb25zaWRlciB0aGVtIGluIHRoaXMgc3RhZ2Uu DQpBdCB0aGlzIGJlZ2luaW5nIHN0YWdlLCBQMlBTSVAgbWF5IGZvbGxvdyB0aGUgS0lTUyBwcmlu Y2lwbGUsIGkuZS4ga2VlcCBpdCBzaW1wbGUgYW5kIHN0dXBpZC4NCg0KUmVnYXJkcywgDQoNCkdl bmd5dQ0KICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KICBGcm9tOiBtYXJjaW4ubWF0 dXN6ZXdza2lAbm9raWEuY29tIA0KICBUbzogbWljaGFsLmdpZXJtYXNpbnNraUBnbWFpbC5jb20g OyBkYmFycmV0dEBxdWludGhhci5jb20gOyBtYXJjLndpbGxla2Vuc0Buc24uY29tIA0KICBDYzog cDJwc2lwQGlldGYub3JnIA0KICBTZW50OiBUdWVzZGF5LCBKdWx5IDEwLCAyMDA3IDU6NTEgUE0N CiAgU3ViamVjdDogUkU6IFtQMlBTSVBdIGRvIHdlIG5lZWQgYSBjbGllbnQgcHJvdG9jb2w/DQoN Cg0KICBIaSBNaWNoYWwsDQoNCiAgWW91IGFyZSByaWdodDogY2hhcmdpbmcgYW5kIGJhdHRlcnkg bGlmZSBhcmUgdmVyeSBpbXBvcnRhbnQgaXNzdWVzIGZyb20gdGhlIGVuZCB1c2VyIHBlcnNwZWN0 aXZlLiBBcyB5b3Ugc2FpZCBtb3N0IG9mIG1vYmlsZSBwaG9uZSB1c2VycyBkbyBub3QgZW5qb3kg ZmxhdCByYXRlIHN1YnNjcmlwdGlvbnMuIFRoZXkgaGF2ZSB0byBwYXkgZm9yIGV2ZXJ5IGJpdCBz ZW50IG92ZXIgdGhlIGFpciBpbnRlcmZhY2UgKHJlY2VpdmVkIGFuZCBzZW50KS4gDQoNCiAgQmVz aWRlcyBtYW55IG1vYmlsZSBwaG9uZXMgYXJlIGJlaGluZCBmaXJld2FsbHMgKGRvbid0IG1lbnRp b24gTkFUcykuIEluIG9yZGVyIHRvIGJlIHJlYWNoYWJsZSB0aGV5IGhhdmUgc2VuZCBrZWVwYWxp dmVzIHRvIHNvbWUgcHJveHkvcmVsYXkvZXRjLiBJbiBhZGRpdGlvbiB0aGV5IHdvdWxkIGhhdmUg dG8gbWFpbnRhaW4gREhULCBmb3J3YXJkIHNlYXJjaCBxdWVyaWVzLCByZXNwb25kIHRvIEdFVC9Q VVQgcmVxdWVzdHMgZm9yIFAyUFNJUCByZXNvdXJjZSAodXNlcikgcmVjb3JkcyB0aGV5IGFyZSBy ZXNwb25zaWJsZSBmb3IuIFRodXMsIHdlIHdvdWxkIHJlcXVpcmUgbW9iaWxlIHBob25lIHVzZXJz IHRvIHBheSBmb3IgIm9ubHkgR29kIGtub3dzIHdoYXQiIHRyYWZmaWMgYW5kIHJlY2hhcmdlIHRo ZWlyIG1vYmlsZSBwaG9uZXMgbXVjaCBtb3JlIGZyZXF1ZW50bHkuDQoNCiAgWWVzIHRoZXJlIGlz IHNvbWUgcGVyY2VudGFnZSBvZiBtb2JpbGUgcGhvbmUgdXNlcnMgd2hvIHdvdWxkIGRvIHRoYXQg YnV0IGlmIHdlIGFyZSB0YXJnZXRpbmcgdGhlIG1hc3MgbWFya2V0IHdlIG5lZWQgdG8gY29uc2lk ZXIgdGhvc2UgaXNzdWVzIChhdCBsZWFzdCBub3csIHRoaW5ncyBtYXkgY2hhbmdlIGluIHRoZSBm dXR1cmUpLg0KDQogIEFjY29yZGluZyB0byBteSBxdWljayBzdHVkeSBvZiAxMDAgbW9iaWxlIHBo b25lIHVzZXJzLCBpdCBzZWVtcyB0aGF0IHdlIHNob3VsZCBleHBlY3QgZXZlbiBoaWdoZXIgcmF0 ZSBvZiBmcmVlIHJpZGVycyBpbiBtb2JpbGUgUDJQIGFwcGxpY2F0aW9ucy4gIA0KDQogIE1hcmNp bg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIEZyb206IGV4dCBNaWNoYWwgR2llcm1h c2luc2tpIFttYWlsdG86bWljaGFsLmdpZXJtYXNpbnNraUBnbWFpbC5jb21dIA0KICAgIFNlbnQ6 IDEwIEp1bHksIDIwMDcgMDA6MzcNCiAgICBUbzogZGJhcnJldHRAcXVpbnRoYXIuY29tOyBXaWxs ZWtlbnMgTWFyYyAoTlNOIC0gQkUvQmVsZ2l1bSAtIE1pbmlNRCkNCiAgICBDYzogcDJwc2lwQGll dGYub3JnDQogICAgU3ViamVjdDogUkU6IFtQMlBTSVBdIGRvIHdlIG5lZWQgYSBjbGllbnQgcHJv dG9jb2w/DQoNCg0KICAgIEhpIE1hcmMsIERhdmlkIQ0KDQogICAgVGhlcmUgaXMgYWxzbyBhbm90 aGVyIF9jb21tZXJjaWFsXyBpc3N1ZSB0aGF0IGlzIHByb2JhYmx5IHdvcnRoIHRvIHJlbWVtYmVy LiBXaGVuIHlvdSAiYXR0YWNoIiB0aGUgb3ZlcmxheSBhbmQgeW91IGJlY29tZSBhbiBhY3RpdmUg cGVlciBpbiBtZXNzYWdlIHJvdXRpbmcsIG1vYmlsZSBkZXZpY2UgbXVzdCB0YWtlIGNhcmUgb2Yg bWVzc2FnZXMgdGhhdCBhcmUgbm90IGFkZHJlc3NlZCB0byBpdC4gQ3VycmVudGx5IG1vc3Qgb2Yg dXNlcnMgdXNlIEdQUlMtbGlrZSBhY2Nlc3MgdG8gdGhlIGludGVybmV0IGFuZCB0ZWxjbyBvcGVy YXRvcnMgY2hhcmdlIHRoZW0gb24gdGhlIGFtb3VudCBvZiBwYWNrZXRzIGJhc2lzLiANCg0KICAg IFRoaXMgaXMgYW4gaXNzdWUgdGhhdCB1c2VycyBtYXkgbm90IGJlIGhhcHB5IHdpdGguIElmIHlv dSBoYXZlIGxldCBzYXkgdW5saW1pdGVkIGFjY2VzcyB0byB0aGUgaW50ZXJuZXQgeW91IGNhbiBt YWtlIHVzZSBvZiBQMlBQZWVyUHJvdG9jb2wgYW5kIHBsYXkgdGhlIHJvbGUgb2YgcmVndWxhciBw ZWVyIGluIHRoZSBvdmVybGF5LiBZb3UgY2FuIHB1dCBzb21lIHN0b3JlZ2UsIG1lc3NhZ2Ugcm91 dGluZyBhY3Rpb25zIHRvIHRoZSBvdmVybGF5LiANCiAgICBCdXQgaWYgYSB1c2VyIHN1ZmZlciBm cm9tIGhpcyBiaWxscyB3aGlsZSBoZSB3b3VsZCBsaWtlIHRvIHRha2Ugc29tZSBhZHZhbnRhZ2Vz IGZyb20gcDJwU2lwIG5ldHdvcmsgdGhlcmUgbXVzdCBiZSBzb21lIHdheSB0byBoZWxwIGhpbS4g VGhpcyBpcyBpbiBteSBvcHBpbmlvbiBvbmUgb2YgdGhlIHJlYXNvbnMgdGhhdCB0aGVyZSBzaG91 bGQgYmUgYSBjbGllbnQgcHJvdG9jb2wgZGVmaW5lZC4gDQoNCiAgICBXZWxsLCB0aGVyZSBpcyBh bHNvIGEgcHJvYmxlbSB0aGF0IG1vc3Qgb2YgdXNlcnMgd291bGQgbGlrZSBqdXN0IHRvIHRha2Ug YWR2YW50YWdlcyBmcm9tIHRoZSBhY2Nlc3MgdG8gdGhlIG5ldHdvcmsgdGhhbiB0byBwbGF5IHNv bWUgc2VydmluZyByb2xlcy4gVGhhdCdzIHRoZSByZWFzb24gd2h5IHVzZXJzIHJ1bm5pbmcgcGVl ciBwcm90b2NvbCBtdXN0IGJlIGZhdm91cmVkIGZyb20gdGhvc2UgdXNpbmcgY2xpZW50IHByb3Rv Y29sLiANCg0KICAgIERvIHlvdSBzZWUgYW55IHBvc3NpYmlsaXRpZXMgb2Ygc3VjaCBmYXZvdXJp bmc/DQoNCiAgICBCZXN0IHJlZ2FyZHMNCiAgICBNaWNoYWwNCg0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCg0KDQogIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogIFAyUFNJUCBtYWlsaW5nIGxpc3QNCiAgUDJQU0lQQGlldGYub3JnDQogIGh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0K ------=_NextPart_000_0015_01C7C33C.FAA722E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDYuMDAuMjkwMC4zMTMyIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPkhpLCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIw MzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7 JiMyMDMwNzsgc2l6ZT0yPklmIHRoZSBwcm9ibGVtcyB3ZXJlIHJlYWxseSZuYnNwO2NvbnNpZGVy ZWQgaW4gdGhpcyANCndheSwgcGVyaGFwcyB0aGVyZSBhcmUgc29tZSBvdGhlciBzaXR1YXRpb25z OjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj4x LiBzb21lIG1vYmlsZSB1c2VycyBoYXZlIGZpeGVkIGZlZSBwZXIgbW9udGgsIHNvIHRoZXkgDQpk byBub3QgY2FyZSB0aGUgYW1vdW50IG9mIHRyYWZmaWMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjIuIHNvbWUgbW9iaWxlIHVzZXJzJm5ic3A7 b2ZmZW4gdXNlIGFkYXB0b3IgY29ubmVjdGluZyANCnRvIHBvd2VyIHN1cHBseSBpbiBvZmZpY2Ug b3IgaG9tZSwgc28gdGhleSBkbyBub3QgY2FyZSBiYXR0ZXJ5LiA8L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+My4gc29tZSB1c2VycyBtYXkmbmJz cDtmb3J3YXJkIHRoZWlyIG1vYmlsZSBjYWxsIHRvIGEgDQpmaXhlZCBJU0ROIHRlcm1pbmFsLCZu YnNwO3doZXRoZXIgdGhlIHBhcnRpY2lwYW50IHdpbGwgYmUgdHJlYXRlZCBhcyBwZWVyIG9yIA0K Y2xpZW50IHdpdGhvdXQgYmF0dGVyeSBvciBiYW5kd2lkdGggbGltaXRhdGlvbj88L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+Jm5ic3A7Jm5ic3A7 IEluIHRoaXMgY2FzZSwmbmJzcDt0aGUgc2VydmljZSBjYXBhYmlsaXR5IA0KcHJvYmxlbSBtYXkg b2NjdXJzIGR1ZSB0byBtb2JpbGUgdXNlciBhdHRyaWJ1dGVzIG9yIElTRE4gdXNlciANCmF0dHJp YnV0ZXMuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6 ZT0yPiZuYnNwOyZuYnNwOyAoU29tZW9uZSBpbiB0aGUgbGlzdCBldmVyIG1ldGlvbmVkIA0Kc2Vy dmljZSBjYXBhYmlsaXkgcHJvYmxlbSk8L0ZPTlQ+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7 IHNpemU9Mj4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsg c2l6ZT0yPjQuIGludmVzdGlnYXRpb24gb2YgMTAwIHVzZXJzIGlzIG5vdCBzdWZmaWNpZW50LCBh cyANCm9uZSBtb2JpbGUgY2FycmllciBoZXJlJm5ic3A7aGF2ZSZuYnNwO21vcmUgdGhhbiAyMCww MDAsMDAwJm5ic3A7dXNlcnMuIA0KPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0 MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0m IzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5JZiB5b3UgdHJ5LCB5b3UgY291bGQgbGlzdCBtYW55IHBy b2JsZW1zIGluIG90aGVyIA0Kc2l0dWF0aW9ucy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9O VCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkhvd2V2ZXIsIG15IHN1Z2dlc3Rpb24gaXMg dGhhdCB3ZSBzaG91bGQgbm90IGNvbnNpZGVyIA0KdGhlbSBpbiB0aGlzIHN0YWdlLjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5BdCB0aGlzIGJl Z2luaW5nIHN0YWdlLCBQMlBTSVAmbmJzcDttYXkgZm9sbG93IHRoZSANCktJU1MgcHJpbmNpcGxl LCBpLmUuIGtlZXAgaXQgc2ltcGxlIGFuZCBzdHVwaWQuPC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj5SZWdhcmRzLCA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPkdlbmd5dTwvRk9O VD48L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElO Ry1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBz b2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgJiMyMzQz NTsmIzIwMzA3OyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBz dHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzs7IGZv bnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9tOjwvQj4gDQogIDxBIHRpdGxlPW1hcmNpbi5tYXR1c3pl d3NraUBub2tpYS5jb20gDQogIGhyZWY9Im1haWx0bzptYXJjaW4ubWF0dXN6ZXdza2lAbm9raWEu Y29tIj5tYXJjaW4ubWF0dXN6ZXdza2lAbm9raWEuY29tPC9BPiANCiAgPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5Ubzo8L0I+IDxBIHRpdGxlPW1p Y2hhbC5naWVybWFzaW5za2lAZ21haWwuY29tIA0KICBocmVmPSJtYWlsdG86bWljaGFsLmdpZXJt YXNpbnNraUBnbWFpbC5jb20iPm1pY2hhbC5naWVybWFzaW5za2lAZ21haWwuY29tPC9BPiANCiAg OyA8QSB0aXRsZT1kYmFycmV0dEBxdWludGhhci5jb20gDQogIGhyZWY9Im1haWx0bzpkYmFycmV0 dEBxdWludGhhci5jb20iPmRiYXJyZXR0QHF1aW50aGFyLmNvbTwvQT4gOyA8QSANCiAgdGl0bGU9 bWFyYy53aWxsZWtlbnNAbnNuLmNvbSANCiAgaHJlZj0ibWFpbHRvOm1hcmMud2lsbGVrZW5zQG5z bi5jb20iPm1hcmMud2lsbGVrZW5zQG5zbi5jb208L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJG T05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+Q2M6PC9CPiA8QSB0aXRsZT1wMnBzaXBAaWV0 Zi5vcmcgDQogIGhyZWY9Im1haWx0bzpwMnBzaXBAaWV0Zi5vcmciPnAycHNpcEBpZXRmLm9yZzwv QT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5T ZW50OjwvQj4gVHVlc2RheSwgSnVseSAxMCwgMjAwNyA1OjUxIFBNPC9ESVY+DQogIDxESVYgc3R5 bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUkU6IFtQMlBT SVBdIGRvIHdlIG5lZWQgYSBjbGllbnQgDQogIHByb3RvY29sPzwvRElWPg0KICA8RElWPjxGT05U IGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9JiMyMzQzNTsm IzIwMzA3OyBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyANCiAgc2l6 ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD48Rk9O VCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9OVD48Rk9OVCANCiAgZmFjZT0mIzIz NDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IHNp emU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAzMDc7IA0KICBzaXplPTI+PC9GT05U PjxGT05UIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9JiMy MzQzNTsmIzIwMzA3OyBzaXplPTI+PC9GT05UPjxGT05UIA0KICBmYWNlPSYjMjM0MzU7JiMyMDMw Nzsgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgc2l6ZT0yPjwvRk9O VD48Rk9OVCBmYWNlPSYjMjM0MzU7JiMyMDMwNzsgDQogIHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFj ZT0mIzIzNDM1OyYjMjAzMDc7IHNpemU9Mj48L0ZPTlQ+PEZPTlQgZmFjZT0mIzIzNDM1OyYjMjAz MDc7IHNpemU9Mj48L0ZPTlQ+PEZPTlQgDQogIGZhY2U9JiMyMzQzNTsmIzIwMzA3OyBzaXplPTI+ PC9GT05UPjxCUj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9MDE1NTgwMDA5LTEwMDcy MDA3PkhpIE1pY2hhbCw8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFz cz0wMTU1ODAwMDktMTAwNzIwMDc+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJViBk aXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48 U1BBTiANCiAgY2xhc3M9MDE1NTgwMDA5LTEwMDcyMDA3PllvdSBhcmUgcmlnaHQ6IGNoYXJnaW5n IGFuZCBiYXR0ZXJ5IGxpZmUgDQogIGFyZSZuYnNwO3ZlcnkgaW1wb3J0YW50IGlzc3VlcyBmcm9t IHRoZSBlbmQgdXNlciBwZXJzcGVjdGl2ZS4gQXMgeW91IHNhaWQgbW9zdCANCiAgb2YmbmJzcDtt b2JpbGUgcGhvbmUgdXNlcnMmbmJzcDtkbyBub3QgZW5qb3kgZmxhdCByYXRlIHN1YnNjcmlwdGlv bnMuIFRoZXkgDQogIGhhdmUgdG8gcGF5IGZvciBldmVyeSBiaXQgc2VudCBvdmVyIHRoZSBhaXIg aW50ZXJmYWNlIChyZWNlaXZlZCBhbmQgc2VudCkuIA0KICA8L1NQQU4+PC9GT05UPjwvRElWPg0K ICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0wMTU1ODAwMDktMTAwNzIwMDc+PC9TUEFOPjwvRk9OVD4m bmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9MDE1NTgwMDA5LTEwMDcyMDA3PkJl c2lkZXMgbWFueSBtb2JpbGUgcGhvbmVzIGFyZSBiZWhpbmQgZmlyZXdhbGxzIA0KICAoZG9uJ3Qg bWVudGlvbiBOQVRzKS4gSW4gb3JkZXIgdG8gYmUgcmVhY2hhYmxlIHRoZXkgaGF2ZSBzZW5kIGtl ZXBhbGl2ZXMgdG8gDQogIHNvbWUgcHJveHkvcmVsYXkvZXRjLiBJbiBhZGRpdGlvbiZuYnNwO3Ro ZXkgd291bGQgaGF2ZSB0byZuYnNwO21haW50YWluIERIVCwgDQogIGZvcndhcmQgc2VhcmNoIHF1 ZXJpZXMsIHJlc3BvbmQgdG8gR0VUL1BVVCByZXF1ZXN0cyBmb3IgUDJQU0lQIHJlc291cmNlICh1 c2VyKSANCiAgcmVjb3JkcyZuYnNwO3RoZXkgYXJlIHJlc3BvbnNpYmxlIGZvci4gVGh1cywmbmJz cDt3ZSB3b3VsZCByZXF1aXJlIG1vYmlsZSANCiAgcGhvbmUmbmJzcDt1c2VycyB0byBwYXkgZm9y Jm5ic3A7Im9ubHkgR29kIGtub3dzIHdoYXQiJm5ic3A7dHJhZmZpYyBhbmQgDQogIHJlY2hhcmdl IHRoZWlyIG1vYmlsZSBwaG9uZXMmbmJzcDttdWNoIG1vcmUgZnJlcXVlbnRseS48L1NQQU4+PC9G T05UPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0wMTU1ODAwMDktMTAwNzIwMDc+PC9T UEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9MDE1NTgwMDA5 LTEwMDcyMDA3PlllcyB0aGVyZSBpcyBzb21lIHBlcmNlbnRhZ2Ugb2YgbW9iaWxlIHBob25lIHVz ZXJzIA0KICB3aG8gd291bGQgZG8gdGhhdCBidXQgaWYgd2UgYXJlIHRhcmdldGluZyB0aGUgbWFz cyBtYXJrZXQgd2UgbmVlZCB0byBjb25zaWRlciANCiAgdGhvc2UgaXNzdWVzIChhdCBsZWFzdCBu b3csIHRoaW5ncyBtYXkgY2hhbmdlIGluIHRoZSANCiAgZnV0dXJlKS48L1NQQU4+PC9GT05UPjwv RElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz0wMTU1ODAwMDktMTAwNzIwMDc+PC9TUEFOPjwv Rk9OVD4mbmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9MDE1NTgwMDA5LTEwMDcy MDA3PkFjY29yZGluZyB0byBteSBxdWljayBzdHVkeSBvZiAxMDAgbW9iaWxlIHBob25lIA0KICB1 c2VycywgaXQgc2VlbXMgdGhhdCB3ZSBzaG91bGQgZXhwZWN0IGV2ZW4gaGlnaGVyJm5ic3A7cmF0 ZSBvZiZuYnNwO2ZyZWUgDQogIHJpZGVycyZuYnNwO2luIG1vYmlsZSBQMlAgYXBwbGljYXRpb25z LiZuYnNwOyZuYnNwOzwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1s ZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNz PTAxNTU4MDAwOS0xMDA3MjAwNz48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWIGRp cj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxT UEFOIA0KICBjbGFzcz0wMTU1ODAwMDktMTAwNzIwMDc+TWFyY2luPC9TUEFOPjwvRk9OVD48L0RJ Vj48QlI+DQogIDxCTE9DS1FVT1RFIGRpcj1sdHIgDQogIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVw eDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBNQVJH SU4tUklHSFQ6IDBweCI+DQogICAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5n PWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCiAgICA8SFIgdGFiSW5kZXg9LTE+DQogICAgPEZP TlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZyb206PC9CPiBleHQgTWljaGFsIEdpZXJtYXNpbnNr aSANCiAgICBbbWFpbHRvOm1pY2hhbC5naWVybWFzaW5za2lAZ21haWwuY29tXSA8QlI+PEI+U2Vu dDo8L0I+IDEwIEp1bHksIDIwMDcgDQogICAgMDA6Mzc8QlI+PEI+VG86PC9CPiBkYmFycmV0dEBx dWludGhhci5jb207IFdpbGxla2VucyBNYXJjIChOU04gLSBCRS9CZWxnaXVtIA0KICAgIC0gTWlu aU1EKTxCUj48Qj5DYzo8L0I+IHAycHNpcEBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUkU6 IFtQMlBTSVBdIGRvIA0KICAgIHdlIG5lZWQgYSBjbGllbnQgcHJvdG9jb2w/PEJSPjwvRk9OVD48 QlI+PC9ESVY+DQogICAgPERJVj48L0RJVj4NCiAgICA8RElWPkhpIE1hcmMsIERhdmlkITwvRElW Pg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj5UaGVyZSBpcyBhbHNvIGFub3RoZXIg X2NvbW1lcmNpYWxfIGlzc3VlIHRoYXQgaXMgcHJvYmFibHkgd29ydGggdG8gDQogICAgcmVtZW1i ZXIuIFdoZW4geW91ICJhdHRhY2giIHRoZSBvdmVybGF5IGFuZCB5b3UgYmVjb21lIGFuIGFjdGl2 ZSBwZWVyIGluIA0KICAgIG1lc3NhZ2Ugcm91dGluZywgbW9iaWxlIGRldmljZSBtdXN0IHRha2Ug Y2FyZSBvZiBtZXNzYWdlcyB0aGF0IGFyZSBub3QgDQogICAgYWRkcmVzc2VkIHRvIGl0LiBDdXJy ZW50bHkgbW9zdCBvZiB1c2VycyB1c2UgR1BSUy1saWtlIGFjY2VzcyB0byB0aGUgDQogICAgaW50 ZXJuZXQgYW5kIHRlbGNvIG9wZXJhdG9ycyBjaGFyZ2UgdGhlbSBvbiB0aGUgYW1vdW50IG9mIHBh Y2tldHMgYmFzaXMuIA0KICAgIDwvRElWPg0KICAgIDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJ Vj5UaGlzIGlzIGFuIGlzc3VlIHRoYXQgdXNlcnMgbWF5IG5vdCBiZSBoYXBweSB3aXRoLiBJZiB5 b3UgaGF2ZSBsZXQgc2F5IA0KICAgIHVubGltaXRlZCBhY2Nlc3MgdG8gdGhlIGludGVybmV0IHlv dSBjYW4gbWFrZSB1c2Ugb2YgUDJQUGVlclByb3RvY29sIGFuZCANCiAgICBwbGF5IHRoZSByb2xl IG9mIHJlZ3VsYXIgcGVlciBpbiB0aGUgb3ZlcmxheS4gWW91IGNhbiBwdXQgc29tZSBzdG9yZWdl LCANCiAgICBtZXNzYWdlIHJvdXRpbmcgYWN0aW9ucyB0byB0aGUgb3ZlcmxheS4gPC9ESVY+DQog ICAgPERJVj5CdXQgaWYgYSB1c2VyIHN1ZmZlciBmcm9tIGhpcyBiaWxscyB3aGlsZSBoZSB3b3Vs ZCBsaWtlIHRvIHRha2Ugc29tZSANCiAgICBhZHZhbnRhZ2VzIGZyb20gcDJwU2lwIG5ldHdvcmsg dGhlcmUgbXVzdCBiZSBzb21lIHdheSB0byBoZWxwIGhpbS4gVGhpcyBpcyANCiAgICBpbiBteSBv cHBpbmlvbiBvbmUgb2YgdGhlIHJlYXNvbnMgdGhhdCB0aGVyZSBzaG91bGQgYmUgYSBjbGllbnQg cHJvdG9jb2wgDQogICAgZGVmaW5lZC4gPC9ESVY+DQogICAgPERJVj4mbmJzcDs8L0RJVj4NCiAg ICA8RElWPldlbGwsIHRoZXJlIGlzIGFsc28gYSBwcm9ibGVtIHRoYXQgbW9zdCBvZiB1c2VycyB3 b3VsZCBsaWtlIGp1c3QgdG8gDQogICAgdGFrZSBhZHZhbnRhZ2VzIGZyb20gdGhlIGFjY2VzcyB0 byB0aGUgbmV0d29yayB0aGFuIHRvIHBsYXkgc29tZSBzZXJ2aW5nIA0KICAgIHJvbGVzLiBUaGF0 J3MgdGhlIHJlYXNvbiB3aHkgdXNlcnMgcnVubmluZyBwZWVyIHByb3RvY29sIG11c3QgYmUgZmF2 b3VyZWQgDQogICAgZnJvbSB0aG9zZSB1c2luZyBjbGllbnQgcHJvdG9jb2wuIDwvRElWPg0KICAg IDxESVY+Jm5ic3A7PC9ESVY+DQogICAgPERJVj5EbyB5b3Ugc2VlIGFueSBwb3NzaWJpbGl0aWVz IG9mIHN1Y2ggZmF2b3VyaW5nPzwvRElWPg0KICAgIDxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogICAgPERJVj5CZXN0IHJlZ2Fy ZHM8L0RJVj4NCiAgICA8RElWPk1pY2hhbDwvRElWPjwvQkxPQ0tRVU9URT4NCiAgPFA+DQogIDxI Uj4NCg0KICA8UD48L1A+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188QlI+UDJQU0lQIG1haWxpbmcgDQogIGxpc3Q8QlI+UDJQU0lQQGlldGYub3JnPEJSPmh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcDxCUj48L0JMT0NLUVVP VEU+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0015_01C7C33C.FAA722E0-- --===============1227912394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1227912394==-- From p2psip-bounces@ietf.org Tue Jul 10 10:10:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8GPy-000889-MK; Tue, 10 Jul 2007 10:10:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8GPx-000882-CX for p2psip@ietf.org; Tue, 10 Jul 2007 10:10:17 -0400 Received: from py-out-1112.google.com ([64.233.166.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8GPw-0005mX-Qf for p2psip@ietf.org; Tue, 10 Jul 2007 10:10:17 -0400 Received: by py-out-1112.google.com with SMTP id f31so4331489pyh for ; Tue, 10 Jul 2007 07:10:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=p26RSheHdKd8RC4cuKhyQvo7BBdx5YMPRwhkTyAHpQrdsW/E/6L6czClYKTb3Ow70bniLyYFyojAZDAX860fJdHHUoN0ximQz9PS6cj5AIzsDrr/KaYzx/VfIk9NstvFsr5Yfqh+vd6Wy/SuZFtAi5TdDC2/z7epaUH5sIB2WRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=GD3QcKdVkG5W2F6tR5PbZgLlXWFGLAQz/H/aGBQyNLGpW8lnxasAGY7OdTeZVdGrvnnTOZLaffrME2X7rOB8UhamjzMXwTuS1sXZkQSSO84jwb7/ddPcPuPlmKqXnL/HdCitpshDcrKg1elDfV+W3sY/FmGsZKetn9j1rQH5m2E= Received: by 10.64.21.6 with SMTP id 6mr2933214qbu.1184076615819; Tue, 10 Jul 2007 07:10:15 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Tue, 10 Jul 2007 07:10:15 -0700 (PDT) Message-ID: <4d4304a00707100710j7bb3d528q886d5a91ec074445@mail.gmail.com> Date: Tue, 10 Jul 2007 10:10:15 -0400 From: "David A. Bryan" To: "Wei Gengyu" Subject: Re: [P2PSIP] do we need a client protocol? In-Reply-To: <001801c7c2f9$ed8a2f50$a507740a@DELLWEI> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3F18E76823C95E4795181D74BAC7664F04BAFE71@esebe102.NOE.Nokia.com> <001801c7c2f9$ed8a2f50$a507740a@DELLWEI> X-Google-Sender-Auth: 3d5869125160c91a X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think another question to ask is do we really need a client protocol for P2P*SIP*? I can see the many arguments that for other things than SIP using the overlay, they may want to be able to get information and not have to SIP, but from a charter perspective, we are only chartered to do P2P specifically for SIP, and are supposed to keep it as simple as possible while meeting that goal. I think people can agree that getting a client protocol will eventually be a good goal, to enable other applications, but our immediate goal needs to be a system for P2P, SIP-based communications. So getting back to the question Brian Rosen raised in Prauge: Can anyone find a reason we need a client protocol for *SIP* using P2P? So for example, a mobile phone (which likely has SIP on it if it is IMS) -- can we find reasons that it won't work using just SIP as the client protocol for SIP functions (calls, presence, conference, whatever?) We know there are lots of non-SIP things we can do if we have a client protocol, but if we determine we don't need it to make SIP work, I would agree with Wei and try to keep it simple for now. Assuming the client protocol is a subset of the peer, we can always add it later and keep our work as simple as possible for now. David On 7/10/07, Wei Gengyu wrote: > > > Hi, > > If the problems were really considered in this way, perhaps there are some > other situations: > 1. some mobile users have fixed fee per month, so they do not care the > amount of traffic. > 2. some mobile users offen use adaptor connecting to power supply in office > or home, so they do not care battery. > 3. some users may forward their mobile call to a fixed ISDN terminal, > whether the participant will be treated as peer or client without battery or > bandwidth limitation? > In this case, the service capability problem may occurs due to mobile > user attributes or ISDN user attributes. > (Someone in the list ever metioned service capabiliy problem). > 4. investigation of 100 users is not sufficient, as one mobile carrier here > have more than 20,000,000 users. > > If you try, you could list many problems in other situations. > > However, my suggestion is that we should not consider them in this stage. > At this begining stage, P2PSIP may follow the KISS principle, i.e. keep it > simple and stupid. > > Regards, > > Gengyu > > ----- Original Message ----- > From: marcin.matuszewski@nokia.com > To: michal.giermasinski@gmail.com ; dbarrett@quinthar.com ; > marc.willekens@nsn.com > Cc: p2psip@ietf.org > > Sent: Tuesday, July 10, 2007 5:51 PM > Subject: RE: [P2PSIP] do we need a client protocol? > > > Hi Michal, > > You are right: charging and battery life are very important issues from the > end user perspective. As you said most of mobile phone users do not enjoy > flat rate subscriptions. They have to pay for every bit sent over the air > interface (received and sent). > > Besides many mobile phones are behind firewalls (don't mention NATs). In > order to be reachable they have send keepalives to some proxy/relay/etc. In > addition they would have to maintain DHT, forward search queries, respond to > GET/PUT requests for P2PSIP resource (user) records they are responsible > for. Thus, we would require mobile phone users to pay for "only God knows > what" traffic and recharge their mobile phones much more frequently. > > Yes there is some percentage of mobile phone users who would do that but if > we are targeting the mass market we need to consider those issues (at least > now, things may change in the future). > > According to my quick study of 100 mobile phone users, it seems that we > should expect even higher rate of free riders in mobile P2P applications. > > Marcin > > > ________________________________ > From: ext Michal Giermasinski [mailto:michal.giermasinski@gmail.com] > Sent: 10 July, 2007 00:37 > To: dbarrett@quinthar.com; Willekens Marc (NSN - BE/Belgium - MiniMD) > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] do we need a client protocol? > > > > Hi Marc, David! > > There is also another _commercial_ issue that is probably worth to remember. > When you "attach" the overlay and you become an active peer in message > routing, mobile device must take care of messages that are not addressed to > it. Currently most of users use GPRS-like access to the internet and telco > operators charge them on the amount of packets basis. > > This is an issue that users may not be happy with. If you have let say > unlimited access to the internet you can make use of P2PPeerProtocol and > play the role of regular peer in the overlay. You can put some storege, > message routing actions to the overlay. > But if a user suffer from his bills while he would like to take some > advantages from p2pSip network there must be some way to help him. This is > in my oppinion one of the reasons that there should be a client protocol > defined. > > Well, there is also a problem that most of users would like just to take > advantages from the access to the network than to play some serving roles. > That's the reason why users running peer protocol must be favoured from > those using client protocol. > > Do you see any possibilities of such favouring? > > Best regards > Michal > > ________________________________ > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 10 11:06:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HIZ-0002W7-Ne; Tue, 10 Jul 2007 11:06:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8HIY-0002W2-R8 for p2psip@ietf.org; Tue, 10 Jul 2007 11:06:42 -0400 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8HIY-0007Np-6a for p2psip@ietf.org; Tue, 10 Jul 2007 11:06:42 -0400 Received: from source ([192.150.11.134]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Tue, 10 Jul 2007 08:06:38 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6AF5Kot007193; Tue, 10 Jul 2007 08:05:20 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6AF4jI9029998; Tue, 10 Jul 2007 08:04:45 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 08:06:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] do we need a client protocol? Date: Tue, 10 Jul 2007 08:04:49 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22A6DA71@namail5.corp.adobe.com> In-Reply-To: <4d4304a00707100710j7bb3d528q886d5a91ec074445@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: AcfC/BERmtNWM/wyQc+8TF+QUKfpoQABpbwg References: <3F18E76823C95E4795181D74BAC7664F04BAFE71@esebe102.NOE.Nokia.com><001801c7c2f9$ed8a2f50$a507740a@DELLWEI> <4d4304a00707100710j7bb3d528q886d5a91ec074445@mail.gmail.com> From: "Henry Sinnreich" To: "David A. Bryan" X-OriginalArrivalTime: 10 Jul 2007 15:06:30.0323 (UTC) FILETIME=[E5552830:01C7C303] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >we are only chartered to do P2P specifically for SIP, and are=20 >supposed to keep it as simple as possible while meeting that goal. This is just as true as the fact that the charter has to be useful to the P2PSIP constituency and to end users. Since ample arguments have been provided for the client protocol, why not amend the charter? =20 This is a good topic to take a hum on during the meeting (though I don't believe majorities have anything to do with being right).=20 Or maybe better elevate the issue to the IESG? Failure to do so will only lead to the proliferation of incompatible mobile devices that claim to support SIP or P2PSIP. The IESG must be made aware of this. Thanks, Henry -----Original Message----- From: David A. Bryan [mailto:dbryan@sipeerior.com]=20 Sent: Tuesday, July 10, 2007 9:10 AM To: Wei Gengyu Cc: p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? I think another question to ask is do we really need a client protocol for P2P*SIP*? I can see the many arguments that for other things than SIP using the overlay, they may want to be able to get information and not have to SIP, but from a charter perspective, we are only chartered to do P2P specifically for SIP, and are supposed to keep it as simple as possible while meeting that goal. I think people can agree that getting a client protocol will eventually be a good goal, to enable other applications, but our immediate goal needs to be a system for P2P, SIP-based communications. So getting back to the question Brian Rosen raised in Prauge: Can anyone find a reason we need a client protocol for *SIP* using P2P? So for example, a mobile phone (which likely has SIP on it if it is IMS) -- can we find reasons that it won't work using just SIP as the client protocol for SIP functions (calls, presence, conference, whatever?) We know there are lots of non-SIP things we can do if we have a client protocol, but if we determine we don't need it to make SIP work, I would agree with Wei and try to keep it simple for now. Assuming the client protocol is a subset of the peer, we can always add it later and keep our work as simple as possible for now. David On 7/10/07, Wei Gengyu wrote: > > > Hi, > > If the problems were really considered in this way, perhaps there are some > other situations: > 1. some mobile users have fixed fee per month, so they do not care the > amount of traffic. > 2. some mobile users offen use adaptor connecting to power supply in office > or home, so they do not care battery. > 3. some users may forward their mobile call to a fixed ISDN terminal, > whether the participant will be treated as peer or client without battery or > bandwidth limitation? > In this case, the service capability problem may occurs due to mobile > user attributes or ISDN user attributes. > (Someone in the list ever metioned service capabiliy problem). > 4. investigation of 100 users is not sufficient, as one mobile carrier here > have more than 20,000,000 users. > > If you try, you could list many problems in other situations. > > However, my suggestion is that we should not consider them in this stage. > At this begining stage, P2PSIP may follow the KISS principle, i.e. keep it > simple and stupid. > > Regards, > > Gengyu > > ----- Original Message ----- > From: marcin.matuszewski@nokia.com > To: michal.giermasinski@gmail.com ; dbarrett@quinthar.com ; > marc.willekens@nsn.com > Cc: p2psip@ietf.org > > Sent: Tuesday, July 10, 2007 5:51 PM > Subject: RE: [P2PSIP] do we need a client protocol? > > > Hi Michal, > > You are right: charging and battery life are very important issues from the > end user perspective. As you said most of mobile phone users do not enjoy > flat rate subscriptions. They have to pay for every bit sent over the air > interface (received and sent). > > Besides many mobile phones are behind firewalls (don't mention NATs). In > order to be reachable they have send keepalives to some proxy/relay/etc. In > addition they would have to maintain DHT, forward search queries, respond to > GET/PUT requests for P2PSIP resource (user) records they are responsible > for. Thus, we would require mobile phone users to pay for "only God knows > what" traffic and recharge their mobile phones much more frequently. > > Yes there is some percentage of mobile phone users who would do that but if > we are targeting the mass market we need to consider those issues (at least > now, things may change in the future). > > According to my quick study of 100 mobile phone users, it seems that we > should expect even higher rate of free riders in mobile P2P applications. > > Marcin > > > ________________________________ > From: ext Michal Giermasinski [mailto:michal.giermasinski@gmail.com] > Sent: 10 July, 2007 00:37 > To: dbarrett@quinthar.com; Willekens Marc (NSN - BE/Belgium - MiniMD) > Cc: p2psip@ietf.org > Subject: RE: [P2PSIP] do we need a client protocol? > > > > Hi Marc, David! > > There is also another _commercial_ issue that is probably worth to remember. > When you "attach" the overlay and you become an active peer in message > routing, mobile device must take care of messages that are not addressed to > it. Currently most of users use GPRS-like access to the internet and telco > operators charge them on the amount of packets basis. > > This is an issue that users may not be happy with. If you have let say > unlimited access to the internet you can make use of P2PPeerProtocol and > play the role of regular peer in the overlay. You can put some storege, > message routing actions to the overlay. > But if a user suffer from his bills while he would like to take some > advantages from p2pSip network there must be some way to help him. This is > in my oppinion one of the reasons that there should be a client protocol > defined. > > Well, there is also a problem that most of users would like just to take > advantages from the access to the network than to play some serving roles. > That's the reason why users running peer protocol must be favoured from > those using client protocol. > > Do you see any possibilities of such favouring? > > Best regards > Michal > > ________________________________ > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 11 04:37:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8XhY-0000cb-HO; Wed, 11 Jul 2007 04:37:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8XhW-0000ai-NH for p2psip@ietf.org; Wed, 11 Jul 2007 04:37:34 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8XhR-0000mb-5o for p2psip@ietf.org; Wed, 11 Jul 2007 04:37:34 -0400 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 <0JL000D71AKYVQ@szxga02-in.huawei.com> for p2psip@ietf.org; Wed, 11 Jul 2007 16:36:34 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL000AAUAKXO6@szxga02-in.huawei.com> for p2psip@ietf.org; Wed, 11 Jul 2007 16:36:34 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL000LZGAKTNB@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 11 Jul 2007 16:36:33 +0800 (CST) Date: Wed, 11 Jul 2007 16:36:29 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] do we need a client protocol? In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D229E0B6A@namail5.corp.adobe.com> To: 'Henry Sinnreich' , 'Dean Willis' , "'David A. Bryan'" Message-id: <000601c7c396$93d21d40$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcevFVALGwr2HnkmTgepau8qUTVjvAIKfluAAxViG/A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: 'Avshalom Houri' , 'P2PSIP Mailing List' , 'Philip Matthews' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, A client protocol will be useful when some peers in the overlay do not support SIP, those peers are only responsible to provide distributed storage, location and transport services for information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and the hosting peer(s)? One client protocol is desirable at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com ---------------------------------------------------------------------------------------------------------------------------- --------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and - Other uses besides SIP. Business planning folks may not care about the WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so, for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly seems that a peer that moves between contributing and non-contributing might HAVE a peer ID, but whether it chooses to insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. Does this modality make it two different nodes? > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service. > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, a minimally contributing node will route a request it receives. It might ask nicely (perhaps a q-value mechanism) to not have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the peer. > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change it service offering. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 11 16:48:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8j7C-0005B2-Jg; Wed, 11 Jul 2007 16:48:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8j7B-0005Ax-Qy for p2psip@ietf.org; Wed, 11 Jul 2007 16:48:49 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8j77-0007Jv-AP for p2psip@ietf.org; Wed, 11 Jul 2007 16:48:49 -0400 Received: from source ([192.150.20.142]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Wed, 11 Jul 2007 13:48:38 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6BKmbWs002544; Wed, 11 Jul 2007 13:48:37 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6BKma0c011236; Wed, 11 Jul 2007 13:48:36 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 13:48:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2007 13:48:31 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AA9458@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on RELOAD-01 for P2PSIP Thread-Index: AcfD/Hir35RaX3q0TqSWcuGWKEoh6Q== From: "Henry Sinnreich" To: X-OriginalArrivalTime: 11 Jul 2007 20:48:35.0718 (UTC) FILETIME=[D9D5A260:01C7C3FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Subject: [P2PSIP] Comments on RELOAD-01 for P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The new version of "REsource LOcation And Discovery (RELOAD)" ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-bryan-p2psip-rel oad-01.txt is a welcome opportunity to clear up some issues regarding RELOAD itself, but also of larger interest to the P2PSIP WG. This is the reason for my posting these comments here to the list. This posting is not meant in any way to diminish the value of the RELOAD I-D, but as a suggestion for future versions. Section 3.3 P2PSIP "Unlike a conventional SIP architecture, P2PSIP systems require no central servers." This is not an accurate statement and maybe "essentially no servers" would be more accurate. The term "essentially no servers" must be explained by examples of servers such as: * Enrollment server(s) * Bootstrap servers * STUN/TURN relay servers * Resource servers such as SIP proxies, VM, etc. The importance of the enrollment server cannot be overstated, as mention by Cullen Jennings in http://www1.ietf.org/mail-archive/web/p2psip/current/msg02728.html=20 This would also apply to section 11.2. Protecting the ID Namespace. It may be also useful to state that all applications reside in the endpoints and this is a key differentiator with C-S SIP ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-sinnreich-sip-to ols-01.txt=20 BTW: A new version of this I-D will be published soon. 4.1. P2P Overlay Structure "For example, a simple SHA-1 hash of the IP address and the port of the peer could be used to generate the Peer-IDs". NO, NO, NO: As has been discussed here on the list and in the P2PSIP Requirements ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-bryan-p2psip-req uirements-00.txt the IP address MUST NOT be used to generate the peer ID since mobile devices with significant churn would generate frequent reorganizations of the overlay and this must be avoided so as to support _mobility_ in P2P SIP. 4.5. Routing in RELOAD It appears the routing procedures using SIP in RELOAD are duplicating the routing in the underlying DHT. If this is not the case, an explanation would be helpful. SIP itself and SIP messages are clearly not suitable for DHT routing and this is explained in emails to this list and also in=20 ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-baset-p2psip-p2p p-00.txt on page 60 in B.1.: To SIP or not to SIP. 11.4. Protecting the Routing Protecting the routing can be done effectively at the DHT level, such as described in "Secure routing for structured peer-to-peer overlay networks" by M. Castro et al. http://www.cs.rice.edu/~dwallach/pub/osdi2002.pdf=20 This should be mentioned. Concept Paper or Implementation Report? As a general comment, it is not clear to what extent this I-D is a conceptual memo or a proven implementation as indicated in the Introduction. If RELOAD is a proven implementation, I would expect to be able to download and inspect the code and see performance reports such as are available for example for Bamboo at http://opendht.org/=20 IMHO inspecting the code and seeing the performance reports by simulations and on the network is THE top requirement in deciding the selection of a P2PSIP protocol. Just reading an I-D will not enable us to make any judgment on the value of the proposal for real life product development. This is actually true for other interesting concepts and proposals as well, such as using HIP for P2PSIP. Even just for reading the RELOAD I-D, examples would be very helpful, especially for the more innovative aspects mentioned in=20 1.1. Evolution of RELOAD. We must recommend the authors for the excellent work done in the new version of the RELOAD I-D and suggest addressing these issues. And using the P2P SIP Requirements I-D first :-) Thanks, Henry Sinnreich _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 11 17:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jir-0006iq-LH; Wed, 11 Jul 2007 17:27:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jip-0006g5-Vb for p2psip@ietf.org; Wed, 11 Jul 2007 17:27:44 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8jip-0001Dr-Og for p2psip@ietf.org; Wed, 11 Jul 2007 17:27:43 -0400 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) (user=sa2086 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6BLR6Ve011970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2007 17:27:11 -0400 (EDT) Date: Wed, 11 Jul 2007 17:27:06 -0400 (EDT) From: Salman Abdul Baset To: p2psip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Dhruv Chopra Subject: [P2PSIP] P2PP Implementation with OpenWengo X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We will like to announce the developer-grade release of P2PP. It is based on the Peer-to-Peer Protocol (P2PP) draft. http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt We have a standalone implementation of P2PP available on Linux (FC6) and Windows XP. We have also integrated it with OpenWengo for Windows and Linux. The executables and instructions can be downloaded from: http://www1.cs.columbia.edu/~dc2378/setupp2pp.html The current implementation supports Chord and Kademlia, and can use different hash algorithms such as SHA-1, SHA-256, MD4 and MD5. As is true with any developer-grade release, this release is also not without bugs. A known issue with OpenWengo-P2PP for Linux is that sometimes the voice from one of the call peers cannot be heard. Please email the comments and bugs to salman@cs.columbia.edu. Thanks Salman _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 11 17:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jlk-0008Ha-ET; Wed, 11 Jul 2007 17:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8jlj-0008HV-Ul for p2psip@ietf.org; Wed, 11 Jul 2007 17:30:43 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8jlf-0008D2-6w for p2psip@ietf.org; Wed, 11 Jul 2007 17:30:43 -0400 Received: by py-out-1112.google.com with SMTP id f31so6048515pyh for ; Wed, 11 Jul 2007 14:30:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=RtwThMckROTKUxwmsWAKZqcetDIr4khIxdoDqaWXmoQVWsL6+0f5yKEdnJEnw1KoWxB8u646H305yGvuaiv1WYLr0sKyTun/M+ecMliSQBaKu67hFJEpZK8J/LKnQAA/katyNiANclDUVV38a9NFbUICcHPmvOip1KhgrJFPOvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=CsLYB+zb2K0/6/WUEsxhrry4qOkQgG1ITsDwusNbtnxO1dsel02EkANeKeOyfHcyvuma04DIPNiodc2V87XfcQfHCZBmmPr7X3+7nLVsuyrF6lwhFdF3O6zTidD/Dd+YkySPjZvAu6te5v3wrFjKZ3Kfzn+kAJVfSWJZUBcrK4g= Received: by 10.64.150.18 with SMTP id x18mr3239116qbd.1184189438385; Wed, 11 Jul 2007 14:30:38 -0700 (PDT) Received: by 10.65.185.14 with HTTP; Wed, 11 Jul 2007 14:30:38 -0700 (PDT) Message-ID: Date: Wed, 11 Jul 2007 23:30:38 +0200 From: "Michal Giermasinski" To: "Zheng Hewen" , p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? In-Reply-To: <000601c7c396$93d21d40$5105a40a@china.huawei.com> MIME-Version: 1.0 References: <24CCCC428EFEA2469BF046DB3C7A8D229E0B6A@namail5.corp.adobe.com> <000601c7c396$93d21d40$5105a40a@china.huawei.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1413965450==" Errors-To: p2psip-bounces@ietf.org --===============1413965450== Content-Type: multipart/alternative; boundary="----=_Part_9536_15051744.1184189438335" ------=_Part_9536_15051744.1184189438335 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi! Well, in my oppinion it is not a good for creating a new protocol. If a client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new one that will be designed especially for cooperation with p2psip overlay. If we follow this understanding we can assume that the better thing is to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is to create a proxy-like peer that will be able to help client to get benefits of the overlay. What we should consider is how to filter the traffic unwanted by regular client that do not want to take part in the routing decision. best regards Michal Giermasinski 2007/7/11, Zheng Hewen : > > Hi, > > A client protocol will be useful when some peers in the overlay do not > support SIP, those peers are only responsible to > provide distributed storage, location and transport services for > information about SIP, but those peers do not recognize any > SIP messages at all. > In this case, how to maintain the relation between clients (UA) and the > hosting peer(s)? One client protocol is desirable > at this time. > > > Zheng Hewen > HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo > > > Huihong Mansion > No.91 Baixia Road > NanJing, P.R.China > Tel: 025-84565467 > Fax: 025-84565354 > Mobile: 13611508264 > E-mail: hwzheng@huaweic.om > www.huawei.com > > ---------------------------------------------------------------------------------------------------------------------------- > --------- > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: 2007?6?26? 1:39 > To: Dean Willis; David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: [P2PSIP] do we need a client protocol? > > Folks, > > Given the length of the discussion on "do we need a client protocol?" > let me repeat the simple imperatives for the client: > > - Limited battery in mobile devices, and > > - Other uses besides SIP. Business planning folks may not care about the > WG charter, but about the return on the investment. > > Thanks, Henry > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, June 14, 2007 11:23 PM > To: David A. Bryan > Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews > Subject: Re: [P2PSIP] Concepts document: proposal for active/passive > peerterminology > > David A. Bryan wrote: > > If I understand this right, not sure I like it. Do these > "non-contributing > > peer" (I *do* like contributing better than active/passive) entities > have a > > Peer-ID? In otherwords, are they part of the overlay at all? If so, > for > > most > > DHTs, how do we allow you to be in the overlay and not store resources > (not > > typical for most current DHT algorithms) > > Well, that certainly depends on the DHT algorithm involved. It certainly > seems that a peer that moves between contributing > and non-contributing might HAVE a peer ID, but whether it chooses to > insert itself into the DHT "right now" might determine > whether it is contributing "right now" > or not. > > > My concern all along has been that I don't understand why something is > > a peer if it isn't doing anything other than talking to someone and > > making requests, hence why I supported client in the first place. > > I fail to see how something that isn't contributing anything, and > > instead talks to a peer to get resources, is in any way a peer. It > > seems completely not in keeping with the idea of P2P. I also worry it > > is likely to be very confusing since we've been using the other > > terminology for over a year now. Just looks like a souce of confusion. > > A node might sometimes have a high-bandwidth connection and wish to > contribute resources, and sometimes not have a > high-bandwidth connection and therefore not wish to offer resources. Does > this modality make it two different nodes? > > > If we do go this way, there is one subtle point. If I join the overlay > but > > don't happen to offer any services (other than maybe > storage...depending on > > how we definie it, that might or might not be mandatory), would I be > > contributing? If joining the overlay (in the sense that we have a > PeerID > > and > > we route traffic) doesn't require me to store, I could offer no > services > > That's "offer no other services", since routing is itself a service. > > > and > > still be a peer. How do we distinguish between this case and a > > "non-contributing peer" who isn't even part of the overlay (i.e., no > > Peer-ID) > > I think there's a range of "contributing" in play. For most DHT models, a > minimally contributing node will route a request > it receives. It might ask nicely (perhaps a q-value mechanism) to not have > to route requests, but would probably > mathematically still have to route something it gets. > > I think we distinguish based on the service advertisements from the peer. > > > If we are so opposed to client for confusion with SIP UAs, lets pick a > new > > name, but why some flavor of peer when it does nothing remotely peer > like? > > Because in 15 minutes it might roam onto a WiFi net and therefore change > it service offering. > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_9536_15051744.1184189438335 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. If a client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new one that will be designed especially for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing is to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is to create a proxy-like peer that will be able to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by regular client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:
Hi,

   A client protocol will be useful when some peers in the overlay do not support SIP, those peers are only responsible to
provide distributed storage, location and transport services for information about SIP, but those peers do not recognize any
SIP messages at all.
  In this case, how to maintain the relation between clients (UA) and the hosting peer(s)? One client protocol is desirable
at this time.


Zheng Hewen
HUAWEI TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel: 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------------------------------------------------------------------
---------
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!


-----Original Message-----
From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: 2007?6?26? 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
Subject: [P2PSIP] do we need a client protocol?

Folks,

Given the length of the discussion on "do we need a client protocol?"
let me repeat the simple imperatives for the client:

- Limited battery in mobile devices, and

- Other uses besides SIP. Business planning folks may not care about the WG charter, but about the return on the investment.

Thanks, Henry

-----Original Message-----
From: Dean Willis [mailto: dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology

David A. Bryan wrote:
> If I understand this right, not sure I like it. Do these
"non-contributing
> peer" (I *do* like contributing better than active/passive) entities
have a
> Peer-ID? In otherwords, are they part of the overlay at all? If so,
for
> most
> DHTs, how do we allow you to be in the overlay and not store resources
(not
> typical for most current DHT algorithms)

Well, that certainly depends on the DHT algorithm involved. It certainly seems that a peer that moves between contributing
and non-contributing might HAVE a peer ID, but whether it chooses to insert itself into the DHT "right now" might determine
whether it is contributing "right now"
or not.

> My concern all along has been that I don't understand why something is
> a peer if it isn't doing anything other than talking to someone and
> making requests, hence why I supported client in the first place.
>  I fail to see how something that isn't contributing anything, and
> instead talks to a peer to get resources, is in any way a peer. It
> seems completely not in keeping with the idea of P2P. I also worry it
> is likely to be very confusing since we've been using the other
> terminology for over a year now. Just looks like a souce of confusion.

A node might sometimes have a high-bandwidth connection and wish to contribute resources, and sometimes not have a
high-bandwidth connection and therefore not wish to offer resources. Does this modality make it two different nodes?

> If we do go this way, there is one subtle point. If I join the overlay
but
> don't happen to offer any services (other than maybe
storage...depending on
> how we definie it, that might or might not be mandatory), would I be
> contributing? If joining the overlay (in the sense that we have a
PeerID
> and
> we route traffic) doesn't require me to store, I could offer no
services

That's "offer no other services", since routing is itself a service.

> and
> still be a peer. How do we distinguish between this case and a
> "non-contributing peer" who isn't even part of the overlay (i.e., no
> Peer-ID)

I think there's a range of "contributing" in play. For most DHT models, a minimally contributing node will route a request
it receives. It might ask nicely (perhaps a q-value mechanism) to not have to route requests, but would probably
mathematically still have to route something it gets.

I think we distinguish based on the service advertisements from the peer.

> If we are so opposed to client for confusion with SIP UAs, lets pick a
new
> name, but why some flavor of peer when it does nothing remotely peer
like?

Because in 15 minutes it might roam onto a WiFi net and therefore change it service offering.

--
Dean

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip




_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_9536_15051744.1184189438335-- --===============1413965450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1413965450==-- From p2psip-bounces@ietf.org Wed Jul 11 18:42:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8kt8-0002JQ-QK; Wed, 11 Jul 2007 18:42:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8kt7-0002JL-E8 for p2psip@ietf.org; Wed, 11 Jul 2007 18:42:25 -0400 Received: from an-out-0708.google.com ([209.85.132.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8kt3-0001GO-2Q for p2psip@ietf.org; Wed, 11 Jul 2007 18:42:25 -0400 Received: by an-out-0708.google.com with SMTP id c17so386569anc for ; Wed, 11 Jul 2007 15:42:20 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=RYhAR0RdZtN1n7NFcxSj/swUP2jmmRQbMZ3o4qdlPDwDQT0xgQgUGSKoiHfTG6WfuuTupo53AEFl2N4mNfmSY0u6OKkA07IZWLZEh+fA7mbqtLrGIb6U0+kCmfSgydKpuKc9tUhO6twxb8u1u13OPzd3S34RQi0iwljG/Jt38u4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=MpbrGcShB2odOxFjq76lSj2PUjPmDEg7jl5/pAzywkp3Sf5UbdwmHQ+BVmp3GorkzOWusLgcyHUdjlN0BwPk+SnhKZ7huavumy6OmhhW1qyY2rapPgNQUy/I/b/LlNnQ7IGbgtw8/h5TUb/DQDGWnLDmTf7EbgeCUxW9cGS9Lvs= Received: by 10.100.47.9 with SMTP id u9mr3048997anu.1184193740644; Wed, 11 Jul 2007 15:42:20 -0700 (PDT) Received: by 10.100.112.12 with HTTP; Wed, 11 Jul 2007 15:42:20 -0700 (PDT) Message-ID: <20d2bdfb0707111542j47820225y5ed0e1d9ec8a4c0a@mail.gmail.com> Date: Wed, 11 Jul 2007 18:42:20 -0400 From: "Bruce Lowekamp" To: "Henry Sinnreich" Subject: Re: [P2PSIP] Comments on RELOAD-01 for P2PSIP In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AA9458@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <24CCCC428EFEA2469BF046DB3C7A8D22AA9458@namail5.corp.adobe.com> X-Google-Sender-Auth: cc562ad1a45d8458 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 7/11/07, Henry Sinnreich wrote: > The new version of "REsource LOcation And Discovery (RELOAD)" > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-bryan-p2psip-rel > oad-01.txt is a welcome opportunity to clear up some issues regarding > RELOAD itself, but also of larger interest to the P2PSIP WG. This is the > reason for my posting these comments here to the list. This posting is > not meant in any way to diminish the value of the RELOAD I-D, but as a > suggestion for future versions. > > Section 3.3 P2PSIP > > "Unlike a conventional SIP architecture, P2PSIP systems require no > central servers." > > This is not an accurate statement and maybe "essentially no servers" > would be more accurate. The term "essentially no servers" must be > explained by examples of servers such as: > > * Enrollment server(s) > * Bootstrap servers > * STUN/TURN relay servers > * Resource servers such as SIP proxies, VM, etc. Strictly speaking, none of those are required to be centralized for P2PSIP, especially in the small group ad hoc type of use cases. It's certainly true that for the more public cases, especially with security involved, enrollment servers are likely to be centralized. Bootstrap servers is an interesting question, as whether they can be "discovered" in a P2P way or must be registered in DNS depends a lot on the specifics of the deployment. I would argue that the functionality of STUN/TURN relay servers and the resource servers should be distributed among the peers. > 4.1. P2P Overlay Structure > "For example, a simple SHA-1 hash of the IP address and the port of the > peer could be used to generate the Peer-IDs". > > NO, NO, NO: As has been discussed here on the list and in the P2PSIP > Requirements > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-bryan-p2psip-req > uirements-00.txt the IP address MUST NOT be used to generate the peer ID > since mobile devices with significant churn would generate frequent > reorganizations of the overlay and this must be avoided so as to support > _mobility_ in P2P SIP. > Sorry, that was intended to be an example, but you're right it should probably be reworded in that section. Section 6.1.1 is where the draft talks about a few options for generating Peer-IDs. (specifically it says MAY use hashed IP and port but SHOULD use UUID-based PeerIDs.) UUIDs are much better for your (and many other) scenarios, but I think in a lot of cases you're still going to want the PeerIDs to come out of certificates, as in reload-security. > 4.5. Routing in RELOAD > It appears the routing procedures using SIP in RELOAD are duplicating > the routing in the underlying DHT. If this is not the case, an > explanation would be helpful. > > SIP itself and SIP messages are clearly not suitable for DHT routing and > this is explained in emails to this list and also in > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-baset-p2psip-p2p > p-00.txt on page 60 in B.1.: To SIP or not to SIP. Hmmm. I'm not sure where the draft is unclear, but we will work to clarify it and maybe we can talk in Chicago to make sure it's clearer. But to try again, RELOAD does not in any way base DHT routing on anything involving SIP. RELOAD offers the possibility of routing SIP on top of the DHT through the TRANSPORT-TUNNEL method, but that is intended primarily as a way of NAT traversal and the intention is that if two P2PSIP UAs wish to establish a SIP dialog for more than a small number of message exchanges, they will do so directly, possibly using TRANSPORT-OPEN methods to do ICE to open a direct SIP dialog. > Even just for reading the RELOAD I-D, examples would be very helpful, > especially for the more innovative aspects mentioned in > 1.1. Evolution of RELOAD. You're right, it definitely needs more examples. Maybe we'll get the time before Vancouver... Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 11 21:35:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8naS-0001PT-Kd; Wed, 11 Jul 2007 21:35:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8naR-0001JG-5d for p2psip@ietf.org; Wed, 11 Jul 2007 21:35:19 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8naL-0006HT-Jt for p2psip@ietf.org; Wed, 11 Jul 2007 21:35:19 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100N0RLP61N@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 09:34:18 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100JL2LOWAC@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 09:34:18 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL100FXQLOR7U@szxml03-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 09:34:08 +0800 (CST) Date: Thu, 12 Jul 2007 09:34:05 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] do we need a client protocol? In-reply-to: To: 'Michal Giermasinski' , p2psip@ietf.org Message-id: <027501c7c424$bc5285a0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6A X-Spam-Score: 0.5 (/) X-Scan-Signature: 8da0cbf8c1eef8eab03772f2044efec0 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1636636696==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1636636696== Content-type: multipart/related; boundary="Boundary_(ID_WJBCispFhnMq13XQx9DCCg)" This is a multi-part message in MIME format. --Boundary_(ID_WJBCispFhnMq13XQx9DCCg) Content-type: multipart/alternative; boundary="Boundary_(ID_JTikOQk2qr2U7ksD2cu1eA)" --Boundary_(ID_JTikOQk2qr2U7ksD2cu1eA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT services. IMHO, this case does not care those clients not supporting SIP. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com ---------------------------------------------------------------------------------------------------------------------------- --------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! _____ From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com] Sent: 2007?7?12? 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! Well, in my oppinion it is not a good for creating a new protocol. If a client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new one that will be designed especially for cooperation with p2psip overlay. If we follow this understanding we can assume that the better thing is to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is to create a proxy-like peer that will be able to help client to get benefits of the overlay. What we should consider is how to filter the traffic unwanted by regular client that do not want to take part in the routing decision. best regards Michal Giermasinski 2007/7/11, Zheng Hewen : Hi, A client protocol will be useful when some peers in the overlay do not support SIP, those peers are only responsible to provide distributed storage, location and transport services for information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and the hosting peer(s)? One client protocol is desirable at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com ---------------------------------------------------------------------------------------------------------------------------- --------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and - Other uses besides SIP. Business planning folks may not care about the WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: dean.willis@softarmor.com] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so, for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly seems that a peer that moves between contributing and non-contributing might HAVE a peer ID, but whether it chooses to insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. Does this modality make it two different nodes? > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service. > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, a minimally contributing node will route a request it receives. It might ask nicely (perhaps a q-value mechanism) to not have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the peer. > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change it service offering. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_JTikOQk2qr2U7ksD2cu1eA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi,
 
    Please let me describe the case in detail.
    In the case, all clients support SIP, but some peers in the overlay network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT services.
    IMHO, this case does not care those clients not supporting SIP.
 
Zheng Hewen
HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo


Huihong Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel: 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
 

From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]
Sent: 2007年7月12日 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: [P2PSIP] do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. If a client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new one that will be designed especially for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing is to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is to create a proxy-like peer that will be able to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by regular client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:
Hi,

   A client protocol will be useful when some peers in the overlay do not support SIP, those peers are only responsible to
provide distributed storage, location and transport services for information about SIP, but those peers do not recognize any
SIP messages at all.
  In this case, how to maintain the relation between clients (UA) and the hosting peer(s)? One client protocol is desirable
at this time.


Zheng Hewen
HUAWEI TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel: 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------------------------------------------------------------------
---------
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!


-----Original Message-----
From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: 2007?6?26? 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
Subject: [P2PSIP] do we need a client protocol?

Folks,

Given the length of the discussion on "do we need a client protocol?"
let me repeat the simple imperatives for the client:

- Limited battery in mobile devices, and

- Other uses besides SIP. Business planning folks may not care about the WG charter, but about the return on the investment.

Thanks, Henry

-----Original Message-----
From: Dean Willis [mailto: dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology

David A. Bryan wrote:
> If I understand this right, not sure I like it. Do these
"non-contributing
> peer" (I *do* like contributing better than active/passive) entities
have a
> Peer-ID? In otherwords, are they part of the overlay at all? If so,
for
> most
> DHTs, how do we allow you to be in the overlay and not store resources
(not
> typical for most current DHT algorithms)

Well, that certainly depends on the DHT algorithm involved. It certainly seems that a peer that moves between contributing
and non-contributing might HAVE a peer ID, but whether it chooses to insert itself into the DHT "right now" might determine
whether it is contributing "right now"
or not.

> My concern all along has been that I don't understand why something is
> a peer if it isn't doing anything other than talking to someone and
> making requests, hence why I supported client in the first place.
>  I fail to see how something that isn't contributing anything, and
> instead talks to a peer to get resources, is in any way a peer. It
> seems completely not in keeping with the idea of P2P. I also worry it
> is likely to be very confusing since we've been using the other
> terminology for over a year now. Just looks like a souce of confusion.

A node might sometimes have a high-bandwidth connection and wish to contribute resources, and sometimes not have a
high-bandwidth connection and therefore not wish to offer resources. Does this modality make it two different nodes?

> If we do go this way, there is one subtle point. If I join the overlay
but
> don't happen to offer any services (other than maybe
storage...depending on
> how we definie it, that might or might not be mandatory), would I be
> contributing? If joining the overlay (in the sense that we have a
PeerID
> and
> we route traffic) doesn't require me to store, I could offer no
services

That's "offer no other services", since routing is itself a service.

> and
> still be a peer. How do we distinguish between this case and a
> "non-contributing peer" who isn't even part of the overlay (i.e., no
> Peer-ID)

I think there's a range of "contributing" in play. For most DHT models, a minimally contributing node will route a request
it receives. It might ask nicely (perhaps a q-value mechanism) to not have to route requests, but would probably
mathematically still have to route something it gets.

I think we distinguish based on the service advertisements from the peer.

> If we are so opposed to client for confusion with SIP UAs, lets pick a
new
> name, but why some flavor of peer when it does nothing remotely peer
like?

Because in 15 minutes it might roam onto a WiFi net and therefore change it service offering.

--
Dean

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip




_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

--Boundary_(ID_JTikOQk2qr2U7ksD2cu1eA)-- --Boundary_(ID_WJBCispFhnMq13XQx9DCCg) Content-id: <318571601@12072007-297B> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_WJBCispFhnMq13XQx9DCCg)-- --===============1636636696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1636636696==-- From p2psip-bounces@ietf.org Wed Jul 11 21:37:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8nch-0002hC-9R; Wed, 11 Jul 2007 21:37:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ncg-0002gv-1g for p2psip@ietf.org; Wed, 11 Jul 2007 21:37:38 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8ncb-0006WE-OZ for p2psip@ietf.org; Wed, 11 Jul 2007 21:37:38 -0400 Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6C1bUQ7004888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Jul 2007 21:37:33 -0400 (EDT) Date: Wed, 11 Jul 2007 21:37:30 -0400 (EDT) From: Salman Abdul Baset To: p2psip@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Dhruv Chopra Subject: [P2PSIP] Re: P2PP Implementation with OpenWengo X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org An updated link for instructions and relevant downloads. This includes the correct link for P2PP-OpenWengo instructions. http://www1.cs.columbia.edu/~salman/p2pp/setupp2pp.html regards, salman On Wed, 11 Jul 2007, Salman Abdul Baset wrote: > > We will like to announce the developer-grade release of P2PP. It is based on > the Peer-to-Peer Protocol (P2PP) draft. > http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt > > We have a standalone implementation of P2PP available on Linux (FC6) and > Windows XP. We have also integrated it with OpenWengo for Windows and Linux. > The executables and instructions can be downloaded from: > http://www1.cs.columbia.edu/~dc2378/setupp2pp.html > > The current implementation supports Chord and Kademlia, and can use different > hash algorithms such as SHA-1, SHA-256, MD4 and MD5. > > As is true with any developer-grade release, this release is also not without > bugs. A known issue with OpenWengo-P2PP for Linux is that sometimes the voice > from one of the call peers cannot be heard. > > Please email the comments and bugs to salman@cs.columbia.edu. > > Thanks > Salman > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 11 22:21:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8oJT-0005Em-NH; Wed, 11 Jul 2007 22:21:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8oJR-0005ER-4x for p2psip@ietf.org; Wed, 11 Jul 2007 22:21:49 -0400 Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8oJL-00005A-DT for p2psip@ietf.org; Wed, 11 Jul 2007 22:21:49 -0400 Received: from cnshgsbhs02.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id l6C2IZJQ005746; Thu, 12 Jul 2007 10:18:35 +0800 Received: from CNSHGSMBS03.ad4.ad.alcatel.com ([172.24.146.173]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 12 Jul 2007 10:21:32 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [P2PSIP] do we need a client protocol? MIME-Version: 1.0 Date: Thu, 12 Jul 2007 10:21:31 +0800 Message-ID: <1DB91DF937A4544C81E636468B91C21C798380@CNSHGSMBS03.ad4.ad.alcatel.com> In-Reply-To: <027501c7c424$bc5285a0$5105a40a@china.huawei.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMA= References: <027501c7c424$bc5285a0$5105a40a@china.huawei.com> From: "HUANG Ping B" To: "Zheng Hewen" , "Michal Giermasinski" , X-OriginalArrivalTime: 12 Jul 2007 02:21:32.0355 (UTC) FILETIME=[5CD68930:01C7C42B] X-imss-version: 2.047 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.7 (/) X-Scan-Signature: 953c1b32cb44691090e7eb33ccb290af Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1699769184==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1699769184== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7C42B.5C866129" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C42B.5C866129 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7C42B.5C866129" ------_=_NextPart_002_01C7C42B.5C866129 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could = be peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to = peers in P2P overlay. when we discuss IMS, although legacy equipments = does not support SIP, but some AGWs do translation or agent for those = equipments. then, when we discuss P2PSIP, shall we involve all peers who = know SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, = and vice versa. and I think that Peers in P2PSIP overlay should have = some common base functionalitis such as SIP recognition. I think we = shall make P2PSIP more simple but not more complex. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which = do not support SIP, such as some PCs, they can provide all required DHT = services, but there is only a pity that they can not recognize any SIP = message, maybe they think that the capability is unnecessary. In this = case, some client protocol is desirable. Certainly this protocol may be = the subset of general Peer Protocol if we regard those clients as Lame = Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. =20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known = for years it obviously will not be able to use a new one that will be = designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and = the peer in the overlay). The only issue is to create a proxy-like peer = that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, =09 A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. =09 =09 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo =09 =09 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com = -------------------------------------------------------------------------= ---------------------------------------------------=20 --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 =09 =09 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? =09 Folks, =09 Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: =09 - Limited battery in mobile devices, and=20 =09 - Other uses besides SIP. Business planning folks may not care about = the WG charter, but about the return on the investment. =09 Thanks, Henry =09 -----Original Message----- From: Dean Willis [mailto: dean.willis@softarmor.com = ] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 =09 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store = resources (not > typical for most current DHT algorithms) =09 Well, that certainly depends on the DHT algorithm involved. It = certainly seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. =09 > My concern all along has been that I don't understand why something = is=20 > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of = confusion. =09 A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 =09 > If we do go this way, there is one subtle point. If I join the = overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services =09 That's "offer no other services", since routing is itself a service.=20 =09 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) =09 I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. =09 I think we distinguish based on the service advertisements from the = peer.=20 =09 > If we are so opposed to client for confusion with SIP UAs, lets pick = a new > name, but why some flavor of peer when it does nothing remotely peer like? =09 Because in 15 minutes it might roam onto a WiFi net and therefore = change it service offering.=20 =09 -- Dean =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 =09 =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 ------_=_NextPart_002_01C7C42B.5C866129 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi all
    P2P is great topic, but = P2PSIP is the=20 subset or certain instance of P2P. when we discuss P2PSIP, we shall not = involve=20 all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are=20 not equal to peers in P2P overlay. when we discuss IMS, although legacy=20 equipments does not support SIP, but some AGWs do translation or agent = for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers who = know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some common = base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more simple=20 but not more complex.
From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,
 
    Please let me describe the = case in=20 detail.
    In the case, all clients support SIP, but = some=20 peers in the overlay network do not support SIP and some support SIP. = For those=20 peers which do not support SIP, such as some PCs, they can provide all = required=20 DHT services, but there is only a pity that they can not recognize any = SIP=20 message, maybe they think that the capability is unnecessary. In this = case, some=20 client protocol is desirable. Certainly this protocol may be the subset = of=20 general Peer Protocol if we regard those clients as Lame Peers and = regard those=20 peers as Pure Peers who only provide required DHT=20 services.
    IMHO, this case does not care those = clients not=20 supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. 3Dhuawei_logo


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: = [P2PSIP]=20 do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. = If a=20 client application is not able to use SIP protocol that is well known = for years=20 it obviously will not be able to use a new one that will be designed = especially=20 for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing = is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that will = be able=20 to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do not = support=20 SIP, those peers are only responsible to
provide distributed = storage,=20 location and transport services for information about SIP, but those = peers do=20 not recognize any
SIP messages at all.
  In this case, = how to=20 maintain the relation between clients (UA) and the hosting peer(s)? = One client=20 protocol is desirable
at this time.


Zheng = Hewen
HUAWEI=20 TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong=20 Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel:=20 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
--------------------= -------------------------------------------------------------------------= -------------------------------=20
---------
This e-mail and its attachments contain confidential=20 information from HUAWEI, which
is intended only for the person or = entity=20 whose address is listed above. Any use of the
information contained = herein=20 in any way (including, but not limited to, total or partial =
disclosure,=20 reproduction, or dissemination) by persons other than the=20 intended
recipient(s) is prohibited. If you receive this e-mail in = error,=20 please notify the sender by
phone or email immediately and delete = it!=20


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26?=20 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP = Mailing=20 List; Philip Matthews
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives for = the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks, = Henry

-----Original=20 Message-----
From: Dean Willis [mailto:=20 dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better than=20 active/passive) entities
have a
> Peer-ID? In otherwords, are = they=20 part of the overlay at all? If so,
for
> most
> DHTs, = how do=20 we allow you to be in the overlay and not store = resources
(not
>=20 typical for most current DHT algorithms)

Well, that certainly = depends=20 on the DHT algorithm involved. It certainly seems that a peer that = moves=20 between contributing
and non-contributing might HAVE a peer ID, = but=20 whether it chooses to insert itself into the DHT "right now" might=20 determine
whether it is contributing "right now"
or = not.

> My=20 concern all along has been that I don't understand why something is =
> a=20 peer if it isn't doing anything other than talking to someone = and
>=20 making requests, hence why I supported client in the first=20 place.
>  I fail to see how something that isn't = contributing=20 anything, and
> instead talks to a peer to get resources, is in = any way=20 a peer. It
> seems completely not in keeping with the idea of = P2P. I=20 also worry it
> is likely to be very confusing since we've been = using=20 the other
> terminology for over a year now. Just looks like a = souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection and=20 wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality make=20 it two different nodes?

> If we do go this way, there is = one subtle=20 point. If I join the overlay
but
> don't happen to offer any = services=20 (other than maybe
storage...depending on
> how we definie it, = that=20 might or might not be mandatory), would I be
> contributing? If = joining=20 the overlay (in the sense that we have a
PeerID
> and
> = we=20 route traffic) doesn't require me to store, I could offer=20 no
services

That's "offer no other services", since routing = is=20 itself a service.

> and
> still be a peer. How do we=20 distinguish between this case and a
> "non-contributing peer" = who isn't=20 even part of the overlay (i.e., no
> Peer-ID)

I think = there's a=20 range of "contributing" in play. For most DHT models, a minimally = contributing=20 node will route a request
it receives. It might ask nicely = (perhaps a=20 q-value mechanism) to not have to route requests, but would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam onto = a WiFi=20 net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

_______________________________________________
P2PSIP = mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

------_=_NextPart_002_01C7C42B.5C866129-- ------_=_NextPart_001_01C7C42B.5C866129 Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <225190702@12072007-232E> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C42B.5C866129-- --===============1699769184== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1699769184==-- From p2psip-bounces@ietf.org Wed Jul 11 23:13:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8p7U-0000Ll-BD; Wed, 11 Jul 2007 23:13:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8p7S-0000Lb-E1 for p2psip@ietf.org; Wed, 11 Jul 2007 23:13:30 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8p7H-0002Lr-1l for p2psip@ietf.org; Wed, 11 Jul 2007 23:13:30 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com id BT-MMP-1727410; Wed, 11 Jul 2007 23:12:59 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2007071123125927932 ; Wed, 11 Jul 2007 23:12:59 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 23:12:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] do we need a client protocol? Date: Wed, 11 Jul 2007 23:08:53 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1D194@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAAiZ17g== References: <027501c7c424$bc5285a0$5105a40a@china.huawei.com> <1DB91DF937A4544C81E636468B91C21C798380@CNSHGSMBS03.ad4.ad.alcatel.com> From: "Roy, Radhika R." To: "HUANG Ping B" , "Zheng Hewen" , "Michal Giermasinski" , X-OriginalArrivalTime: 12 Jul 2007 03:12:59.0252 (UTC) FILETIME=[8CC5A340:01C7C432] X-Spam-Score: 3.4 (+++) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0366461745==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0366461745== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7C432.8C7FA3D6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C432.8C7FA3D6 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7C432.8C7FA3D6" ------_=_NextPart_002_01C7C432.8C7FA3D6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Huang: =20 Right. =20 Our focus should be P2PSIP and P2PSIP overlay. Because we are taking a = limited step considering the big picture of P2P. P2P is a very big area = and we are not chartered for this. =20 Best regards, Radhika ________________________________ From: p2psip-bounces@ietf.org on behalf of HUANG Ping B Sent: Wed 7/11/2007 10:21 PM To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could = be peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to = peers in P2P overlay. when we discuss IMS, although legacy equipments = does not support SIP, but some AGWs do translation or agent for those = equipments. then, when we discuss P2PSIP, shall we involve all peers who = know SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, = and vice versa. and I think that Peers in P2PSIP overlay should have = some common base functionalitis such as SIP recognition. I think we = shall make P2PSIP more simple but not more complex. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which = do not support SIP, such as some PCs, they can provide all required DHT = services, but there is only a pity that they can not recognize any SIP = message, maybe they think that the capability is unnecessary. In this = case, some client protocol is desirable. Certainly this protocol may be = the subset of general Peer Protocol if we regard those clients as Lame = Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. = huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ------_=_NextPart_002_01C7C432.8C7FA3D6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Hi, = Huang:
=0A=
 
=0A=
Right.
=0A=
 
=0A=
Our focus should be P2PSIP = and P2PSIP overlay. Because we are taking a limited step considering the = big picture of P2P. P2P is a very big area and we are not chartered for = this.
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: p2psip-bounces@ietf.org on = behalf of HUANG Ping B
Sent: Wed 7/11/2007 10:21 = PM
To: Zheng Hewen; Michal Giermasinski; = p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client = protocol?

=0A=
=0A=
Hi = all
=0A=
    P2P = is great topic, but P2PSIP is the subset or certain instance of P2P. = when we discuss P2PSIP, we shall not involve all nodes which could be = peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to peers = in P2P overlay. when we discuss IMS, although legacy equipments does not = support SIP, but some AGWs do translation or agent for those equipments. = then, when we discuss P2PSIP, shall we involve all peers who know SIP or = not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice = versa. and I think that Peers in P2PSIP overlay should have some common = base functionalitis such as SIP recognition. I think we shall make = P2PSIP more simple but not more complex.
=0A=
=0A=
=0A= From: Zheng Hewen = [mailto:hwzheng@huawei.com]
Sent: Thursday, July 12, 2007 = 9:34 AM
To: 'Michal Giermasinski'; = p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client = protocol?

=0A=
=0A=
Hi,
=0A=
 
=0A=
    Please let = me describe the case in detail.
    In the case, all = clients support SIP, but some peers in the overlay network do not = support SIP and some support SIP. For those peers which do not support = SIP, such as some PCs, they can provide all required DHT services, but = there is only a pity that they can not recognize any SIP message, maybe = they think that the capability is unnecessary. In this case, some client = protocol is desirable. Certainly this protocol may be the subset of = general Peer Protocol if we regard those clients as Lame Peers and = regard those peers as Pure Peers who only provide required DHT = services.
    IMHO, this case does not care those = clients not supporting SIP.
=0A=
 
=0A=
Zheng = Hewen
HUAWEI = TECHNOLOGIES CO.,LTD. 3Dhuawei_logo
=0A=


Huihong = Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel: = 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This e-mail and its attachments contain confidential information from = HUAWEI, which
is intended only for the person or entity whose = address is listed above. Any use of the
information contained herein = in any way (including, but not limited to, total or partial =
disclosure, reproduction, or dissemination) by persons other than = the intended
recipient(s) is prohibited. If you receive this e-mail = in error, please notify the sender by
phone or email immediately and = delete it!
=0A=
 

------_=_NextPart_002_01C7C432.8C7FA3D6-- ------_=_NextPart_001_01C7C432.8C7FA3D6 Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <225190702@12072007-232E> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C432.8C7FA3D6-- --===============0366461745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0366461745==-- From p2psip-bounces@ietf.org Thu Jul 12 02:02:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8rkX-0005h3-QW; Thu, 12 Jul 2007 02:02:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8rkW-0005gf-2A for p2psip@ietf.org; Thu, 12 Jul 2007 02:02:00 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8rkS-0007uZ-QW for p2psip@ietf.org; Thu, 12 Jul 2007 02:01:59 -0400 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 <0JL100HWLY1IIS@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 14:00:55 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL100BPLY1E6J@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 14:00:54 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL100270Y1AAV@szxml03-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 14:00:50 +0800 (CST) Date: Thu, 12 Jul 2007 14:00:46 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] do we need a client protocol? In-reply-to: <1DB91DF937A4544C81E636468B91C21C798380@CNSHGSMBS03.ad4.ad.alcatel.com> To: 'HUANG Ping B' , 'Michal Giermasinski' , p2psip@ietf.org Message-id: <028701c7c449$fd877c40$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4A== X-Spam-Score: 0.6 (/) X-Scan-Signature: 5596635830a5938fc94538b29441db99 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1245585045==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1245585045== Content-type: multipart/related; boundary="Boundary_(ID_Q1NbsE4i1agSX/kcnbVfhA)" This is a multi-part message in MIME format. --Boundary_(ID_Q1NbsE4i1agSX/kcnbVfhA) Content-type: multipart/alternative; boundary="Boundary_(ID_F/D4bRP1zKtDqHO5wYBXUQ)" --Boundary_(ID_F/D4bRP1zKtDqHO5wYBXUQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms = for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they = do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the = resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope = will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality." =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some = AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or = not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should = have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more = complex. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide = all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the = capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of = general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 _____ =20 From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new = one that will be designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is = to create a proxy-like peer that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and=20 - Other uses besides SIP. Business planning folks may not care about the = WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: = dean.willis@softarmor.com] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly = seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is = > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service.=20 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the = peer.=20 > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change = it service offering.=20 -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 --Boundary_(ID_F/D4bRP1zKtDqHO5wYBXUQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi,
 
  If I do not misunderstand, P2PSIP is not = equal to=20 SIP.
  Essentially in P2PSIP overlay, P2PSIP = peers have=20 nothing with SIP. Why must we bind SIP to P2PSIP peers?=20
 
  Here is the description about P2PSIP = peers in WG=20 charter, FYI.
  "The work focuses on collections of = nodes called=20 "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed = namespace in which overlay users are identified and provides mechanisms = for=20 locating users or resources within the P2PSIP overlay. P2PSIP clients = differ=20 from P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers=20 use the resolution services of the peers as an alternative to the SIP = discovery=20 process of RFC 3263. In this way, P2PSIP offers an alternative mechanism = for=20 determining the correct destination for SIP requests. The working = group's=20 initial charter scope will be to produce protocols to enable this = alternate=20 mechanism for RFC 3263 functionality."
 
  Nothing says that P2PSIP = peers must=20 support SIP or have anything with SIP.
  From the charter, functionality of = P2PSIP=20 peers is so clear and simple, why do we make it complicated? I = think we can=20 do it simpler, SIP is SIP, P2PSIP peer is P2PSIP = peer, let=20 them be.
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = 3Dhuawei_logo=20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 10:22
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi all
    P2P is great topic, but = P2PSIP is the=20 subset or certain instance of P2P. when we discuss P2PSIP, we shall not = involve=20 all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are=20 not equal to peers in P2P overlay. when we discuss IMS, although legacy=20 equipments does not support SIP, but some AGWs do translation or agent = for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers who = know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some common = base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more simple=20 but not more complex.
From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,
 
    Please let me describe the = case in=20 detail.
    In the case, all clients support SIP, but = some=20 peers in the overlay network do not support SIP and some support SIP. = For those=20 peers which do not support SIP, such as some PCs, they can provide all = required=20 DHT services, but there is only a pity that they can not recognize any = SIP=20 message, maybe they think that the capability is unnecessary. In this = case, some=20 client protocol is desirable. Certainly this protocol may be the subset = of=20 general Peer Protocol if we regard those clients as Lame Peers and = regard those=20 peers as Pure Peers who only provide required DHT=20 services.
    IMHO, this case does not care those = clients not=20 supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. 3Dhuawei_logo


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: = [P2PSIP]=20 do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. = If a=20 client application is not able to use SIP protocol that is well known = for years=20 it obviously will not be able to use a new one that will be designed = especially=20 for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing = is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that will = be able=20 to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do not = support=20 SIP, those peers are only responsible to
provide distributed = storage,=20 location and transport services for information about SIP, but those = peers do=20 not recognize any
SIP messages at all.
  In this case, = how to=20 maintain the relation between clients (UA) and the hosting peer(s)? = One client=20 protocol is desirable
at this time.


Zheng = Hewen
HUAWEI=20 TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong=20 Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel:=20 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
--------------------= -------------------------------------------------------------------------= -------------------------------=20
---------
This e-mail and its attachments contain confidential=20 information from HUAWEI, which
is intended only for the person or = entity=20 whose address is listed above. Any use of the
information contained = herein=20 in any way (including, but not limited to, total or partial =
disclosure,=20 reproduction, or dissemination) by persons other than the=20 intended
recipient(s) is prohibited. If you receive this e-mail in = error,=20 please notify the sender by
phone or email immediately and delete = it!=20


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26?=20 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP = Mailing=20 List; Philip Matthews
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives for = the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks, = Henry

-----Original=20 Message-----
From: Dean Willis [mailto:=20 dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better than=20 active/passive) entities
have a
> Peer-ID? In otherwords, are = they=20 part of the overlay at all? If so,
for
> most
> DHTs, = how do=20 we allow you to be in the overlay and not store = resources
(not
>=20 typical for most current DHT algorithms)

Well, that certainly = depends=20 on the DHT algorithm involved. It certainly seems that a peer that = moves=20 between contributing
and non-contributing might HAVE a peer ID, = but=20 whether it chooses to insert itself into the DHT "right now" might=20 determine
whether it is contributing "right now"
or = not.

> My=20 concern all along has been that I don't understand why something is =
> a=20 peer if it isn't doing anything other than talking to someone = and
>=20 making requests, hence why I supported client in the first=20 place.
>  I fail to see how something that isn't = contributing=20 anything, and
> instead talks to a peer to get resources, is in = any way=20 a peer. It
> seems completely not in keeping with the idea of = P2P. I=20 also worry it
> is likely to be very confusing since we've been = using=20 the other
> terminology for over a year now. Just looks like a = souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection and=20 wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality make=20 it two different nodes?

> If we do go this way, there is = one subtle=20 point. If I join the overlay
but
> don't happen to offer any = services=20 (other than maybe
storage...depending on
> how we definie it, = that=20 might or might not be mandatory), would I be
> contributing? If = joining=20 the overlay (in the sense that we have a
PeerID
> and
> = we=20 route traffic) doesn't require me to store, I could offer=20 no
services

That's "offer no other services", since routing = is=20 itself a service.

> and
> still be a peer. How do we=20 distinguish between this case and a
> "non-contributing peer" = who isn't=20 even part of the overlay (i.e., no
> Peer-ID)

I think = there's a=20 range of "contributing" in play. For most DHT models, a minimally = contributing=20 node will route a request
it receives. It might ask nicely = (perhaps a=20 q-value mechanism) to not have to route requests, but would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam onto = a WiFi=20 net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

_______________________________________________
P2PSIP = mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

--Boundary_(ID_F/D4bRP1zKtDqHO5wYBXUQ)-- --Boundary_(ID_Q1NbsE4i1agSX/kcnbVfhA) Content-id: <025534405@12072007-2982> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_Q1NbsE4i1agSX/kcnbVfhA) Content-id: <025534405@12072007-2989> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_Q1NbsE4i1agSX/kcnbVfhA)-- --===============1245585045== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1245585045==-- From p2psip-bounces@ietf.org Thu Jul 12 04:19:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ttC-0000s0-Lp; Thu, 12 Jul 2007 04:19:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ttB-0000qx-02 for p2psip@ietf.org; Thu, 12 Jul 2007 04:19:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8ttA-0002bU-MS for p2psip@ietf.org; Thu, 12 Jul 2007 04:19:04 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 013C720246; Thu, 12 Jul 2007 10:18:48 +0200 (CEST) X-AuditID: c1b4fb3e-ae831bb0000007e1-f2-4695e3e73772 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id CB0222017E; Thu, 12 Jul 2007 10:18:47 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 10:18:47 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 10:18:47 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5E0C72465; Thu, 12 Jul 2007 11:18:47 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1F3744DB9F; Thu, 12 Jul 2007 11:18:47 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C95474DB9E; Thu, 12 Jul 2007 11:18:46 +0300 (EEST) Message-ID: <4695E3EA.3080506@ericsson.com> Date: Thu, 12 Jul 2007 11:18:50 +0300 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 12 Jul 2007 08:18:47.0436 (UTC) FILETIME=[452454C0:01C7C45D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Subject: [P2PSIP] New draft: Utilizing HIP for P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, We have submitted a draft that describes the best current practices on how HIP can be utilized in P2PSIP networks: http://www.ietf.org/internet-drafts/draft-hautakorpi-p2psip-with-hip-00.txt The biggest difference to 'draft-matthews-p2psip-hip-hop-00' is that our draft does not propose changes to the HIP itself, it just utilizes the HIP as it is. Comments are welcomed! -- Jani _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 12 04:58:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8uUp-0005bN-OR; Thu, 12 Jul 2007 04:57:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8uUn-0005bD-Og for p2psip@ietf.org; Thu, 12 Jul 2007 04:57:57 -0400 Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8uUl-0003MG-53 for p2psip@ietf.org; Thu, 12 Jul 2007 04:57:57 -0400 Received: from cnshgsbhs01.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id l6C8rUYD017851; Thu, 12 Jul 2007 16:53:42 +0800 Received: from CNSHGSMBS03.ad4.ad.alcatel.com ([172.24.146.173]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 12 Jul 2007 16:56:33 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [P2PSIP] do we need a client protocol? MIME-Version: 1.0 Date: Thu, 12 Jul 2007 16:56:31 +0800 Message-ID: <1DB91DF937A4544C81E636468B91C21C863D77@CNSHGSMBS03.ad4.ad.alcatel.com> In-Reply-To: <028701c7c449$fd877c40$5105a40a@china.huawei.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQ References: <1DB91DF937A4544C81E636468B91C21C798380@CNSHGSMBS03.ad4.ad.alcat el.com> <028701c7c449$fd877c40$5105a40a@china.huawei.com> From: "HUANG Ping B" To: "Zheng Hewen" , "Michal Giermasinski" , X-OriginalArrivalTime: 12 Jul 2007 08:56:33.0166 (UTC) FILETIME=[8B9F4AE0:01C7C462] X-imss-version: 2.047 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 1.6 (+) X-Scan-Signature: 962517628a679322096a16b4fad0d0cd Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0816483893==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0816483893== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7C462.8B408D49" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C462.8B408D49 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7C462.8B408D49" ------_=_NextPart_002_01C7C462.8B408D49 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP = offers an alternative mechanism for determining the correct destination = for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of = cause, is you use another protocol, P2PSIP may be called another name, = such as P2PXXX. Peers in P2PSIP overlay are responsible not just for = location (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? = this name means that there is a relationship between P2PSIP and SIP, = maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. = then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize SIP = message. Ok, you can say that a tunnel protocol could be used to deliver = SIP protocol, this is a choice, but not good choice. if a tunnel = protocol is used, then SIP has nothing with P2P overlay, this tunnel = protocol could deliver any protocols besides SIP, then name "P2PSIP" = does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which = overlay users are identified and provides mechanisms for locating users = or resources within the P2PSIP overlay. P2PSIP clients differ from = P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers use the resolution services of the peers as an alternative to = the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP = requests. The working group's initial charter scope will be to produce = protocols to enable this alternate mechanism for RFC 3263 = functionality." =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP = is SIP, P2PSIP peer is P2PSIP peer, let them be. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. =20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could = be peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to = peers in P2P overlay. when we discuss IMS, although legacy equipments = does not support SIP, but some AGWs do translation or agent for those = equipments. then, when we discuss P2PSIP, shall we involve all peers who = know SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, = and vice versa. and I think that Peers in P2PSIP overlay should have = some common base functionalitis such as SIP recognition. I think we = shall make P2PSIP more simple but not more complex. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which = do not support SIP, such as some PCs, they can provide all required DHT = services, but there is only a pity that they can not recognize any SIP = message, maybe they think that the capability is unnecessary. In this = case, some client protocol is desirable. Certainly this protocol may be = the subset of general Peer Protocol if we regard those clients as Lame = Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. =20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known = for years it obviously will not be able to use a new one that will be = designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and = the peer in the overlay). The only issue is to create a proxy-like peer = that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, =09 A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. =09 =09 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo =09 =09 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com = -------------------------------------------------------------------------= ---------------------------------------------------=20 --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 =09 =09 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? =09 Folks, =09 Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: =09 - Limited battery in mobile devices, and=20 =09 - Other uses besides SIP. Business planning folks may not care about = the WG charter, but about the return on the investment. =09 Thanks, Henry =09 -----Original Message----- From: Dean Willis [mailto: dean.willis@softarmor.com = ] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 =09 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store = resources (not > typical for most current DHT algorithms) =09 Well, that certainly depends on the DHT algorithm involved. It = certainly seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. =09 > My concern all along has been that I don't understand why something = is=20 > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of = confusion. =09 A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 =09 > If we do go this way, there is one subtle point. If I join the = overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services =09 That's "offer no other services", since routing is itself a service.=20 =09 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) =09 I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. =09 I think we distinguish based on the service advertisements from the = peer.=20 =09 > If we are so opposed to client for confusion with SIP UAs, lets pick = a new > name, but why some flavor of peer when it does nothing remotely peer like? =09 Because in 15 minutes it might roam onto a WiFi net and therefore = change it service offering.=20 =09 -- Dean =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 =09 =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 ------_=_NextPart_002_01C7C462.8B408D49 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
I have never said that P2PSIP = is equal to=20 SIP, P2PSIP is just an overlay as an alternative to the SIP discovery = process of=20 RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct=20 destination for SIP requests. SIP is session layer protocol, P2PSIP is = under=20 SIP. of cause, is you use another protocol, P2PSIP may be called another = name,=20 such as P2PXXX. Peers in P2PSIP = overlay are=20 responsible not just for location (done by P2PSIP protocol). Why we = called=20 P2PSIP as "P2PSIP"?  this name means that there is a relationship = between=20 P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP = should be=20 used. then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize = SIP=20 message. Ok, you can say that a tunnel protocol could be used to deliver = SIP=20 protocol, this is a choice, but not good choice. if a tunnel protocol is = used,=20 then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any=20 protocols besides SIP, then name "P2PSIP" does not make=20 sense.
when peers in P2PSIP = overlay do not=20 recognize SIP message, then let them out of = overlay.

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
  If I do not misunderstand, P2PSIP is not = equal to=20 SIP.
  Essentially in P2PSIP overlay, P2PSIP = peers have=20 nothing with SIP. Why must we bind SIP to P2PSIP peers?=20
 
  Here is the description about P2PSIP = peers in WG=20 charter, FYI.
  "The work focuses on collections of = nodes called=20 "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed = namespace in which overlay users are identified and provides mechanisms = for=20 locating users or resources within the P2PSIP overlay. P2PSIP clients = differ=20 from P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers=20 use the resolution services of the peers as an alternative to the SIP = discovery=20 process of RFC 3263. In this way, P2PSIP offers an alternative mechanism = for=20 determining the correct destination for SIP requests. The working = group's=20 initial charter scope will be to produce protocols to enable this = alternate=20 mechanism for RFC 3263 functionality."
 
  Nothing says that P2PSIP = peers must=20 support SIP or have anything with SIP.
  From the charter, functionality of = P2PSIP=20 peers is so clear and simple, why do we make it complicated? I = think we can=20 do it simpler, SIP is SIP, P2PSIP peer is P2PSIP = peer, let=20 them be.
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = 3Dhuawei_logo=20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 10:22
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi all
    P2P is great topic, but = P2PSIP is the=20 subset or certain instance of P2P. when we discuss P2PSIP, we shall not = involve=20 all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are=20 not equal to peers in P2P overlay. when we discuss IMS, although legacy=20 equipments does not support SIP, but some AGWs do translation or agent = for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers who = know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some common = base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more simple=20 but not more complex.
From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,
 
    Please let me describe the = case in=20 detail.
    In the case, all clients support SIP, but = some=20 peers in the overlay network do not support SIP and some support SIP. = For those=20 peers which do not support SIP, such as some PCs, they can provide all = required=20 DHT services, but there is only a pity that they can not recognize any = SIP=20 message, maybe they think that the capability is unnecessary. In this = case, some=20 client protocol is desirable. Certainly this protocol may be the subset = of=20 general Peer Protocol if we regard those clients as Lame Peers and = regard those=20 peers as Pure Peers who only provide required DHT=20 services.
    IMHO, this case does not care those = clients not=20 supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. 3Dhuawei_logo


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: = [P2PSIP]=20 do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. = If a=20 client application is not able to use SIP protocol that is well known = for years=20 it obviously will not be able to use a new one that will be designed = especially=20 for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing = is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that will = be able=20 to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do not = support=20 SIP, those peers are only responsible to
provide distributed = storage,=20 location and transport services for information about SIP, but those = peers do=20 not recognize any
SIP messages at all.
  In this case, = how to=20 maintain the relation between clients (UA) and the hosting peer(s)? = One client=20 protocol is desirable
at this time.


Zheng = Hewen
HUAWEI=20 TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong=20 Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel:=20 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
--------------------= -------------------------------------------------------------------------= -------------------------------=20
---------
This e-mail and its attachments contain confidential=20 information from HUAWEI, which
is intended only for the person or = entity=20 whose address is listed above. Any use of the
information contained = herein=20 in any way (including, but not limited to, total or partial =
disclosure,=20 reproduction, or dissemination) by persons other than the=20 intended
recipient(s) is prohibited. If you receive this e-mail in = error,=20 please notify the sender by
phone or email immediately and delete = it!=20


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26?=20 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP = Mailing=20 List; Philip Matthews
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives for = the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks, = Henry

-----Original=20 Message-----
From: Dean Willis [mailto:=20 dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better than=20 active/passive) entities
have a
> Peer-ID? In otherwords, are = they=20 part of the overlay at all? If so,
for
> most
> DHTs, = how do=20 we allow you to be in the overlay and not store = resources
(not
>=20 typical for most current DHT algorithms)

Well, that certainly = depends=20 on the DHT algorithm involved. It certainly seems that a peer that = moves=20 between contributing
and non-contributing might HAVE a peer ID, = but=20 whether it chooses to insert itself into the DHT "right now" might=20 determine
whether it is contributing "right now"
or = not.

> My=20 concern all along has been that I don't understand why something is =
> a=20 peer if it isn't doing anything other than talking to someone = and
>=20 making requests, hence why I supported client in the first=20 place.
>  I fail to see how something that isn't = contributing=20 anything, and
> instead talks to a peer to get resources, is in = any way=20 a peer. It
> seems completely not in keeping with the idea of = P2P. I=20 also worry it
> is likely to be very confusing since we've been = using=20 the other
> terminology for over a year now. Just looks like a = souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection and=20 wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality make=20 it two different nodes?

> If we do go this way, there is = one subtle=20 point. If I join the overlay
but
> don't happen to offer any = services=20 (other than maybe
storage...depending on
> how we definie it, = that=20 might or might not be mandatory), would I be
> contributing? If = joining=20 the overlay (in the sense that we have a
PeerID
> and
> = we=20 route traffic) doesn't require me to store, I could offer=20 no
services

That's "offer no other services", since routing = is=20 itself a service.

> and
> still be a peer. How do we=20 distinguish between this case and a
> "non-contributing peer" = who isn't=20 even part of the overlay (i.e., no
> Peer-ID)

I think = there's a=20 range of "contributing" in play. For most DHT models, a minimally = contributing=20 node will route a request
it receives. It might ask nicely = (perhaps a=20 q-value mechanism) to not have to route requests, but would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam onto = a WiFi=20 net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

_______________________________________________
P2PSIP = mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

------_=_NextPart_002_01C7C462.8B408D49-- ------_=_NextPart_001_01C7C462.8B408D49 Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <559572608@12072007-2335> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C462.8B408D49 Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <559572608@12072007-233C> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en-1.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C462.8B408D49-- --===============0816483893== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0816483893==-- From p2psip-bounces@ietf.org Thu Jul 12 05:10:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ugd-0002Yi-0r; Thu, 12 Jul 2007 05:10:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ugc-0002YZ-0J for p2psip@ietf.org; Thu, 12 Jul 2007 05:10:10 -0400 Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8ugb-0003hD-8U for p2psip@ietf.org; Thu, 12 Jul 2007 05:10:09 -0400 Received: from cnshgsbhs02.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id l6C971BI024177; Thu, 12 Jul 2007 17:07:02 +0800 Received: from CNSHGSMBS03.ad4.ad.alcatel.com ([172.24.146.173]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 12 Jul 2007 17:09:58 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [P2PSIP] The client role in the Concepts and Terminology I-D MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Jul 2007 17:09:57 +0800 Message-ID: <1DB91DF937A4544C81E636468B91C21C863DB7@CNSHGSMBS03.ad4.ad.alcatel.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22A6D6B9@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] The client role in the Concepts and Terminology I-D Thread-Index: AcfCSAap3HCXUaAjRz621snxgDrWaQCG7Qlg References: <24CCCC428EFEA2469BF046DB3C7A8D22A6D6B9@namail5.corp.adobe.com> From: "HUANG Ping B" To: "Henry Sinnreich" , "P2PSIP Mailing List" X-OriginalArrivalTime: 12 Jul 2007 09:09:58.0670 (UTC) FILETIME=[6BBD72E0:01C7C464] X-imss-version: 2.047 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: bryan@sipeerior.com, Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I have a question: in section 5.2, in Option3 and option4, why Peer Y first contact Z, then Register to W? and is Y a "Peer " or "client"? on the other word, what's the scenario these options described? thanks! -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Tuesday, July 10, 2007 12:47 AM To: P2PSIP Mailing List Cc: bryan@sipeerior.com; Philip Matthews Subject: [P2PSIP] The client role in the Concepts and Terminology I-D Given the importance of "Concepts and Terminology for Peer to Peer SIP", ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-willis-p2psip-co ncepts-04.txt=20 I would suggest improving the text by introducing something like this to section 5.5. Possible Client Behavior: "One of the main motivations for the client protocol is to avoid the 'always talking' mode for mobile devices that would participate as full peers and contribute the IP messages required for the overlay maintenance. The continuous IP packet exchange may contribute to the depletion of the battery and possibly also to increase the charges for certain mobile services. As a consequence, it is desirable for certain mobile devices to benefit from the P2PSIP overlay but not to contribute to its maintenance or to the routing and data storage functions of P2P SIP. The client protocol is a subset of the peer protocol that allows the client to store and retrieve data from the P2PSIP overlay and also to exercise the overlay for message routing. The client protocol should be flexible enough to also be extensible for non-SIP applications, such as search, multicast, streaming media and content distribution." Delete on page 19 the following and similar on other pages: "In essence, the client contributes its storage capacity to its associated peer."... Replace with: "Due to their high churn and low bandwidth, certain mobile devices are not only lesser capable peers, but actually would degrade the performance of the P2P SIP overlay network as a whole." Thanks, Henry Sinnreich _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 12 05:22:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8us7-0000TI-44; Thu, 12 Jul 2007 05:22:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8us4-0000Sk-Vg for p2psip@ietf.org; Thu, 12 Jul 2007 05:22:01 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8us1-0003z4-2d for p2psip@ietf.org; Thu, 12 Jul 2007 05:22:00 -0400 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 <0JL2000CH7APKE@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 17:20:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL2000187AKAR@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 17:20:49 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL20095T7AGPQ@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 17:20:44 +0800 (CST) Date: Thu, 12 Jul 2007 17:20:40 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] do we need a client protocol? In-reply-to: <1DB91DF937A4544C81E636468B91C21C863D77@CNSHGSMBS03.ad4.ad.alcatel.com> To: 'HUANG Ping B' , 'Michal Giermasinski' , p2psip@ietf.org Message-id: <02a401c7c465$ea84ef30$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQAAFOeVA= X-Spam-Score: 0.6 (/) X-Scan-Signature: 497d1d6fe10a928b905d544fc4341388 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0088850976==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0088850976== Content-type: multipart/related; boundary="Boundary_(ID_QTt6EyHu/RAREjTng2B+Tg)" This is a multi-part message in MIME format. --Boundary_(ID_QTt6EyHu/RAREjTng2B+Tg) Content-type: multipart/alternative; boundary="Boundary_(ID_Quw/8xF0woQuBMf1fc0JRQ)" --Boundary_(ID_Quw/8xF0woQuBMf1fc0JRQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Oh, I do not agree that "SIP should be used" in the P2PSIP overlay or = "Peers in P2PSIP overlay should recognize SIP message". Why did we call P2PSIP as "P2PSIP"?=20 IMHO, the true and only cause is that we try to provide a method to = determine the correct destination for SIP requests using not RFC3263(DNS-based) but P2P technology, just as the description of WG = charter, this is the current and only relation between SIP and P2PSIP. No any assumption about that all peers in P2PSIP overlay must recognize = SIP exists in the charter. P2PSIP serves SIP, it does not mean that peers in P2PSIP overlay must = support SIP.=20 Why not reject those participated non-SIP-enabled peers? Jut for = personal sensation? Those peers work in P2PSIP overlay. Certainly, P2PSIP do not refuse some peers supporting SIP as it should = not refuse those peers not support SIP when P2PSIP can serve SIP as description of the charter. =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct destination for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of cause, is you use another = protocol, P2PSIP may be called another name, such as P2PXXX. Peers in P2PSIP overlay are responsible not just for location = (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? this name means that there is a relationship between P2PSIP = and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. then Peers in P2PSIP overlay( not P2PXXX = overlay) should recognize SIP message. Ok, you can say that a tunnel protocol could be used to deliver SIP protocol, this is a = choice, but not good choice. if a tunnel protocol is used, then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any protocols besides SIP, then name "P2PSIP" does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms = for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they = do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the = resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope = will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality." =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some = AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or = not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should = have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more = complex. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide = all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the = capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of = general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 _____ =20 From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new = one that will be designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is = to create a proxy-like peer that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and=20 - Other uses besides SIP. Business planning folks may not care about the = WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: = dean.willis@softarmor.com] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly = seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is = > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service.=20 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the = peer.=20 > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change = it service offering.=20 -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 --Boundary_(ID_Quw/8xF0woQuBMf1fc0JRQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Oh, I do not agree that "SIP should be used" = in the=20 P2PSIP overlay or "Peers in P2PSIP overlay should recognize SIP = message".
Why=20 did we call P2PSIP as "P2PSIP"?
IMHO, the true and only cause is = that we try=20 to provide a method to determine the correct destination for SIP = requests using=20 not RFC3263(DNS-based) but P2P technology, just as the description of WG = charter, this is the current and only relation between SIP and = P2PSIP.
No any=20 assumption about that all peers in P2PSIP overlay must recognize SIP = exists in=20 the charter.
P2PSIP serves SIP, it does not mean that peers in P2PSIP = overlay=20 must support SIP.
Why not reject those participated non-SIP-enabled = peers?=20 Jut for personal sensation? Those peers work in P2PSIP = overlay.
Certainly,=20 P2PSIP do not refuse some peers supporting SIP as it should not refuse = those=20 peers not support SIP when P2PSIP can serve SIP as description of the=20 charter.
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 16:57
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

I have never said that P2PSIP = is equal to=20 SIP, P2PSIP is just an overlay as an alternative to the SIP discovery = process of=20 RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct=20 destination for SIP requests. SIP is session layer protocol, P2PSIP is = under=20 SIP. of cause, is you use another protocol, P2PSIP may be called another = name,=20 such as P2PXXX. Peers in P2PSIP = overlay are=20 responsible not just for location (done by P2PSIP protocol). Why we = called=20 P2PSIP as "P2PSIP"?  this name means that there is a relationship = between=20 P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP = should be=20 used. then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize = SIP=20 message. Ok, you can say that a tunnel protocol could be used to deliver = SIP=20 protocol, this is a choice, but not good choice. if a tunnel protocol is = used,=20 then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any=20 protocols besides SIP, then name "P2PSIP" does not make=20 sense.
when peers in P2PSIP = overlay do not=20 recognize SIP message, then let them out of = overlay.

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
  If I do not misunderstand, P2PSIP is not = equal to=20 SIP.
  Essentially in P2PSIP overlay, P2PSIP = peers have=20 nothing with SIP. Why must we bind SIP to P2PSIP peers?=20
 
  Here is the description about P2PSIP = peers in WG=20 charter, FYI.
  "The work focuses on collections of = nodes called=20 "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed = namespace in which overlay users are identified and provides mechanisms = for=20 locating users or resources within the P2PSIP overlay. P2PSIP clients = differ=20 from P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers=20 use the resolution services of the peers as an alternative to the SIP = discovery=20 process of RFC 3263. In this way, P2PSIP offers an alternative mechanism = for=20 determining the correct destination for SIP requests. The working = group's=20 initial charter scope will be to produce protocols to enable this = alternate=20 mechanism for RFC 3263 functionality."
 
  Nothing says that P2PSIP = peers must=20 support SIP or have anything with SIP.
  From the charter, functionality of = P2PSIP=20 peers is so clear and simple, why do we make it complicated? I = think we can=20 do it simpler, SIP is SIP, P2PSIP peer is P2PSIP = peer, let=20 them be.
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = 3Dhuawei_logo=20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 10:22
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi all
    P2P is great topic, but = P2PSIP is the=20 subset or certain instance of P2P. when we discuss P2PSIP, we shall not = involve=20 all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are=20 not equal to peers in P2P overlay. when we discuss IMS, although legacy=20 equipments does not support SIP, but some AGWs do translation or agent = for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers who = know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some common = base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more simple=20 but not more complex.
From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,
 
    Please let me describe the = case in=20 detail.
    In the case, all clients support SIP, but = some=20 peers in the overlay network do not support SIP and some support SIP. = For those=20 peers which do not support SIP, such as some PCs, they can provide all = required=20 DHT services, but there is only a pity that they can not recognize any = SIP=20 message, maybe they think that the capability is unnecessary. In this = case, some=20 client protocol is desirable. Certainly this protocol may be the subset = of=20 general Peer Protocol if we regard those clients as Lame Peers and = regard those=20 peers as Pure Peers who only provide required DHT=20 services.
    IMHO, this case does not care those = clients not=20 supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. 3Dhuawei_logo


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: = [P2PSIP]=20 do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. = If a=20 client application is not able to use SIP protocol that is well known = for years=20 it obviously will not be able to use a new one that will be designed = especially=20 for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing = is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that will = be able=20 to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do not = support=20 SIP, those peers are only responsible to
provide distributed = storage,=20 location and transport services for information about SIP, but those = peers do=20 not recognize any
SIP messages at all.
  In this case, = how to=20 maintain the relation between clients (UA) and the hosting peer(s)? = One client=20 protocol is desirable
at this time.


Zheng = Hewen
HUAWEI=20 TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong=20 Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel:=20 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
--------------------= -------------------------------------------------------------------------= -------------------------------=20
---------
This e-mail and its attachments contain confidential=20 information from HUAWEI, which
is intended only for the person or = entity=20 whose address is listed above. Any use of the
information contained = herein=20 in any way (including, but not limited to, total or partial =
disclosure,=20 reproduction, or dissemination) by persons other than the=20 intended
recipient(s) is prohibited. If you receive this e-mail in = error,=20 please notify the sender by
phone or email immediately and delete = it!=20


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26?=20 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP = Mailing=20 List; Philip Matthews
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives for = the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks, = Henry

-----Original=20 Message-----
From: Dean Willis [mailto:=20 dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better than=20 active/passive) entities
have a
> Peer-ID? In otherwords, are = they=20 part of the overlay at all? If so,
for
> most
> DHTs, = how do=20 we allow you to be in the overlay and not store = resources
(not
>=20 typical for most current DHT algorithms)

Well, that certainly = depends=20 on the DHT algorithm involved. It certainly seems that a peer that = moves=20 between contributing
and non-contributing might HAVE a peer ID, = but=20 whether it chooses to insert itself into the DHT "right now" might=20 determine
whether it is contributing "right now"
or = not.

> My=20 concern all along has been that I don't understand why something is =
> a=20 peer if it isn't doing anything other than talking to someone = and
>=20 making requests, hence why I supported client in the first=20 place.
>  I fail to see how something that isn't = contributing=20 anything, and
> instead talks to a peer to get resources, is in = any way=20 a peer. It
> seems completely not in keeping with the idea of = P2P. I=20 also worry it
> is likely to be very confusing since we've been = using=20 the other
> terminology for over a year now. Just looks like a = souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection and=20 wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality make=20 it two different nodes?

> If we do go this way, there is = one subtle=20 point. If I join the overlay
but
> don't happen to offer any = services=20 (other than maybe
storage...depending on
> how we definie it, = that=20 might or might not be mandatory), would I be
> contributing? If = joining=20 the overlay (in the sense that we have a
PeerID
> and
> = we=20 route traffic) doesn't require me to store, I could offer=20 no
services

That's "offer no other services", since routing = is=20 itself a service.

> and
> still be a peer. How do we=20 distinguish between this case and a
> "non-contributing peer" = who isn't=20 even part of the overlay (i.e., no
> Peer-ID)

I think = there's a=20 range of "contributing" in play. For most DHT models, a minimally = contributing=20 node will route a request
it receives. It might ask nicely = (perhaps a=20 q-value mechanism) to not have to route requests, but would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam onto = a WiFi=20 net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

_______________________________________________
P2PSIP = mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

--Boundary_(ID_Quw/8xF0woQuBMf1fc0JRQ)-- --Boundary_(ID_QTt6EyHu/RAREjTng2B+Tg) Content-id: <899210409@12072007-2990> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_QTt6EyHu/RAREjTng2B+Tg) Content-id: <899210409@12072007-2997> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_QTt6EyHu/RAREjTng2B+Tg)-- --===============0088850976== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0088850976==-- From p2psip-bounces@ietf.org Thu Jul 12 05:30:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8v0a-0003XQ-MO; Thu, 12 Jul 2007 05:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8v0Y-0003XJ-RT for p2psip@ietf.org; Thu, 12 Jul 2007 05:30:46 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8v0S-0004Yv-Fg for p2psip@ietf.org; Thu, 12 Jul 2007 05:30:46 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6C9TXGI030130; Thu, 12 Jul 2007 12:29:50 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 12:29:36 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 12:29:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] do we need a client protocol? Date: Thu, 12 Jul 2007 12:32:35 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04BB04AF@esebe102.NOE.Nokia.com> In-Reply-To: <1DB91DF937A4544C81E636468B91C21C863D77@CNSHGSMBS03.ad4.ad.alcatel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQAAFk5tA= References: <1DB91DF937A4544C81E636468B91C21C798380@CNSHGSMBS03.ad4.ad.alcatel.com> <028701c7c449$fd877c40$5105a40a@china.huawei.com> <1DB91DF937A4544C81E636468B91C21C863D77@CNSHGSMBS03.ad4.ad.alcatel.com> From: To: , , , X-OriginalArrivalTime: 12 Jul 2007 09:29:35.0204 (UTC) FILETIME=[29024A40:01C7C467] X-Nokia-AV: Clean X-Spam-Score: 1.3 (+) X-Scan-Signature: 97901e96c4dacf0263335ebc3a004b57 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1162261189==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1162261189== Content-class: urn:content-classes:message Content-Type: multipart/related; boundary="----_=_NextPart_001_01C7C467.2812F376"; type="multipart/alternative" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C467.2812F376 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7C467.2812F376" ------_=_NextPart_002_01C7C467.2812F376 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Some comments inline... ________________________________ From: ext HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn] Sent: 12 July, 2007 11:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay as an alternative to the SIP discovery process of RFC 3263, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. Do you need SIP to offer an alternative mechanism for determining a correct destination for SIP requests? SIP is session layer protocol, P2PSIP is under SIP. of cause, is you use another protocol, P2PSIP may be called another name, such as P2PXXX. Peers in P2PSIP overlay are responsible not just for location (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? this name means that there is a relationship between P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. SIP is a session initiation protocol. In some cases it may be used only between SIP UAs. then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize SIP message. Ok, you can say that a tunnel protocol could be used to deliver SIP protocol, this is a choice, but not good choice. if a tunnel protocol is used, then SIP has nothing with P2P overlay, this tunnel protocol could deliver any protocols besides SIP, then name "P2PSIP" does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them out of overlay. I would like to encourage you to read the following drafts: http://www.p2psip.org/drafts/draft-bryan-p2psip-requirements-00.txt http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt http://www.p2psip.org/drafts/draft-jennings-p2psip-asp-00.txt Marcin ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com] Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why must we bind SIP to P2PSIP peers? Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality." Nothing says that P2PSIP peers must support SIP or have anything with SIP. From the charter, functionality of P2PSIP peers is so clear and simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com ------------------------------------------------------------------------------------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn] Sent: 2007$BG/(J7$B7n(J12$BF|(J 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more complex. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com] Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT services. IMHO, this case does not care those clients not supporting SIP. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com ------------------------------------------------------------------------------------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ________________________________ From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com] Sent: 2007$BG/(J7$B7n(J12$BF|(J 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! Well, in my oppinion it is not a good for creating a new protocol. If a client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new one that will be designed especially for cooperation with p2psip overlay. If we follow this understanding we can assume that the better thing is to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is to create a proxy-like peer that will be able to help client to get benefits of the overlay. What we should consider is how to filter the traffic unwanted by regular client that do not want to take part in the routing decision. best regards Michal Giermasinski 2007/7/11, Zheng Hewen : Hi, A client protocol will be useful when some peers in the overlay do not support SIP, those peers are only responsible to provide distributed storage, location and transport services for information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and the hosting peer(s)? One client protocol is desirable at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com ---------------------------------------------------------------------------------------------------------------------------- --------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and - Other uses besides SIP. Business planning folks may not care about the WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: dean.willis@softarmor.com ] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so, for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly seems that a peer that moves between contributing and non-contributing might HAVE a peer ID, but whether it chooses to insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. Does this modality make it two different nodes? > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service. > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, a minimally contributing node will route a request it receives. It might ask nicely (perhaps a q-value mechanism) to not have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the peer. > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change it service offering. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------_=_NextPart_002_01C7C467.2812F376 Content-Type: text/html; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit
Some comments inline...

From: ext HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: 12 July, 2007 11:57
To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client protocol?

I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay as an alternative to the SIP discovery process of RFC 3263, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. 
 
Do you need SIP to offer an alternative mechanism for determining a correct destination for SIP requests?
 
SIP is session layer protocol, P2PSIP is under SIP. of cause, is you use another protocol, P2PSIP may be called another name, such as P2PXXX. Peers in P2PSIP overlay are responsible not just for location (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"?  this name means that there is a relationship between P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. 
 
SIP is a session initiation protocol. In some cases it may be used only between SIP UAs.
 
  then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize SIP message. Ok, you can say that a tunnel protocol could be used to deliver SIP protocol, this is a choice, but not good choice. if a tunnel protocol is used, then SIP has nothing with P2P overlay, this tunnel protocol could deliver any protocols besides SIP, then name "P2PSIP" does not make sense.
when peers in P2PSIP overlay do not recognize SIP message, then let them out of overlay. 
 
I would like to encourage you to read the following drafts:
 
Marcin
 

From: Zheng Hewen [mailto:hwzheng@huawei.com]
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client protocol?

Hi,
 
  If I do not misunderstand, P2PSIP is not equal to SIP.
  Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why must we bind SIP to P2PSIP peers?
 
  Here is the description about P2PSIP peers in WG charter, FYI.
  "The work focuses on collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality."
 
  Nothing says that P2PSIP peers must support SIP or have anything with SIP.
  From the charter, functionality of P2PSIP peers is so clear and simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be.
 

Zheng Hewen
HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo


Huihong Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel: 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
 

From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: 2007$BG/(B7$B7n(B12$BF|(B 10:22
To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client protocol?

Hi all
    P2P is great topic, but P2PSIP is the subset or certain instance of P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more complex.
From: Zheng Hewen [mailto:hwzheng@huawei.com]
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client protocol?

Hi,
 
    Please let me describe the case in detail.
    In the case, all clients support SIP, but some peers in the overlay network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT services.
    IMHO, this case does not care those clients not supporting SIP.
 
Zheng Hewen
HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo


Huihong Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel: 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
 

From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]
Sent: 2007$BG/(B7$B7n(B12$BF|(B 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: [P2PSIP] do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. If a client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new one that will be designed especially for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing is to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is to create a proxy-like peer that will be able to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by regular client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:
Hi,

   A client protocol will be useful when some peers in the overlay do not support SIP, those peers are only responsible to
provide distributed storage, location and transport services for information about SIP, but those peers do not recognize any
SIP messages at all.
  In this case, how to maintain the relation between clients (UA) and the hosting peer(s)? One client protocol is desirable
at this time.


Zheng Hewen
HUAWEI TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel: 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------------------------------------------------------------------
---------
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!


-----Original Message-----
From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: 2007?6?26? 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
Subject: [P2PSIP] do we need a client protocol?

Folks,

Given the length of the discussion on "do we need a client protocol?"
let me repeat the simple imperatives for the client:

- Limited battery in mobile devices, and

- Other uses besides SIP. Business planning folks may not care about the WG charter, but about the return on the investment.

Thanks, Henry

-----Original Message-----
From: Dean Willis [mailto: dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for active/passive peerterminology

David A. Bryan wrote:
> If I understand this right, not sure I like it. Do these
"non-contributing
> peer" (I *do* like contributing better than active/passive) entities
have a
> Peer-ID? In otherwords, are they part of the overlay at all? If so,
for
> most
> DHTs, how do we allow you to be in the overlay and not store resources
(not
> typical for most current DHT algorithms)

Well, that certainly depends on the DHT algorithm involved. It certainly seems that a peer that moves between contributing
and non-contributing might HAVE a peer ID, but whether it chooses to insert itself into the DHT "right now" might determine
whether it is contributing "right now"
or not.

> My concern all along has been that I don't understand why something is
> a peer if it isn't doing anything other than talking to someone and
> making requests, hence why I supported client in the first place.
>  I fail to see how something that isn't contributing anything, and
> instead talks to a peer to get resources, is in any way a peer. It
> seems completely not in keeping with the idea of P2P. I also worry it
> is likely to be very confusing since we've been using the other
> terminology for over a year now. Just looks like a souce of confusion.

A node might sometimes have a high-bandwidth connection and wish to contribute resources, and sometimes not have a
high-bandwidth connection and therefore not wish to offer resources. Does this modality make it two different nodes?

> If we do go this way, there is one subtle point. If I join the overlay
but
> don't happen to offer any services (other than maybe
storage...depending on
> how we definie it, that might or might not be mandatory), would I be
> contributing? If joining the overlay (in the sense that we have a
PeerID
> and
> we route traffic) doesn't require me to store, I could offer no
services

That's "offer no other services", since routing is itself a service.

> and
> still be a peer. How do we distinguish between this case and a
> "non-contributing peer" who isn't even part of the overlay (i.e., no
> Peer-ID)

I think there's a range of "contributing" in play. For most DHT models, a minimally contributing node will route a request
it receives. It might ask nicely (perhaps a q-value mechanism) to not have to route requests, but would probably
mathematically still have to route something it gets.

I think we distinguish based on the service advertisements from the peer.

> If we are so opposed to client for confusion with SIP UAs, lets pick a
new
> name, but why some flavor of peer when it does nothing remotely peer
like?

Because in 15 minutes it might roam onto a WiFi net and therefore change it service offering.

--
Dean

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip




_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------_=_NextPart_002_01C7C467.2812F376-- ------_=_NextPart_001_01C7C467.2812F376 Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <484520609@12072007-1EC3> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C467.2812F376 Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <484520609@12072007-1ECA> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en-1.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C467.2812F376-- --===============1162261189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1162261189==-- From p2psip-bounces@ietf.org Thu Jul 12 05:34:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8v4M-0007f6-0E; Thu, 12 Jul 2007 05:34:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8v4K-0007ev-Fm for p2psip@ietf.org; Thu, 12 Jul 2007 05:34:40 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8v4E-0004gA-28 for p2psip@ietf.org; Thu, 12 Jul 2007 05:34:40 -0400 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 <0JL200MEZ7UHZG@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 17:32:41 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL200B9N7UCTE@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 17:32:41 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL2004QE7U8N9@szxml03-in.huawei.com> for p2psip@ietf.org; Thu, 12 Jul 2007 17:32:36 +0800 (CST) Date: Thu, 12 Jul 2007 17:32:32 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] do we need a client protocol? In-reply-to: <1DB91DF937A4544C81E636468B91C21C863D77@CNSHGSMBS03.ad4.ad.alcatel.com> To: 'HUANG Ping B' , 'Michal Giermasinski' , p2psip@ietf.org Message-id: <02b001c7c467$93056b70$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQAAIh/DA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 1459dca363a7eac530b0f3f218abff0f Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1662216546==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1662216546== Content-type: multipart/related; boundary="Boundary_(ID_AgaSn7544snMp5q0+7Ml1g)" This is a multi-part message in MIME format. --Boundary_(ID_AgaSn7544snMp5q0+7Ml1g) Content-type: multipart/alternative; boundary="Boundary_(ID_NQOmo+xJPYLcB2f+f4gA/g)" --Boundary_(ID_NQOmo+xJPYLcB2f+f4gA/g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi, =20 One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT = service but not recognize SIP messages should be admitted as one member/peer of P2PSIP overlay, we do not have to update = the device to support SIP and then provide DHT service, the cost introduced due to the update is unnecessary. =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct destination for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of cause, is you use another = protocol, P2PSIP may be called another name, such as P2PXXX. Peers in P2PSIP overlay are responsible not just for location = (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? this name means that there is a relationship between P2PSIP = and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. then Peers in P2PSIP overlay( not P2PXXX = overlay) should recognize SIP message. Ok, you can say that a tunnel protocol could be used to deliver SIP protocol, this is a = choice, but not good choice. if a tunnel protocol is used, then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any protocols besides SIP, then name "P2PSIP" does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms = for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they = do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the = resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope = will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality." =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some = AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or = not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should = have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more = complex. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide = all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the = capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of = general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 _____ =20 From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new = one that will be designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is = to create a proxy-like peer that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and=20 - Other uses besides SIP. Business planning folks may not care about the = WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: = dean.willis@softarmor.com] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly = seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is = > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service.=20 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the = peer.=20 > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change = it service offering.=20 -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 --Boundary_(ID_NQOmo+xJPYLcB2f+f4gA/g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi,
 
   One supplement, = FYI.
   In the future P2PSIP = deployment, one=20 device that can provide DHT service but not recognize SIP messages = should be=20 admitted as one member/peer of P2PSIP overlay, we do not have to update = the=20 device to support SIP and then provide DHT service, the cost = introduced due=20 to the update is unnecessary.
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 16:57
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

I have never said that P2PSIP = is equal to=20 SIP, P2PSIP is just an overlay as an alternative to the SIP discovery = process of=20 RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct=20 destination for SIP requests. SIP is session layer protocol, P2PSIP is = under=20 SIP. of cause, is you use another protocol, P2PSIP may be called another = name,=20 such as P2PXXX. Peers in P2PSIP = overlay are=20 responsible not just for location (done by P2PSIP protocol). Why we = called=20 P2PSIP as "P2PSIP"?  this name means that there is a relationship = between=20 P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP = should be=20 used. then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize = SIP=20 message. Ok, you can say that a tunnel protocol could be used to deliver = SIP=20 protocol, this is a choice, but not good choice. if a tunnel protocol is = used,=20 then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any=20 protocols besides SIP, then name "P2PSIP" does not make=20 sense.
when peers in P2PSIP = overlay do not=20 recognize SIP message, then let them out of = overlay.

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
  If I do not misunderstand, P2PSIP is not = equal to=20 SIP.
  Essentially in P2PSIP overlay, P2PSIP = peers have=20 nothing with SIP. Why must we bind SIP to P2PSIP peers?=20
 
  Here is the description about P2PSIP = peers in WG=20 charter, FYI.
  "The work focuses on collections of = nodes called=20 "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed = namespace in which overlay users are identified and provides mechanisms = for=20 locating users or resources within the P2PSIP overlay. P2PSIP clients = differ=20 from P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers=20 use the resolution services of the peers as an alternative to the SIP = discovery=20 process of RFC 3263. In this way, P2PSIP offers an alternative mechanism = for=20 determining the correct destination for SIP requests. The working = group's=20 initial charter scope will be to produce protocols to enable this = alternate=20 mechanism for RFC 3263 functionality."
 
  Nothing says that P2PSIP = peers must=20 support SIP or have anything with SIP.
  From the charter, functionality of = P2PSIP=20 peers is so clear and simple, why do we make it complicated? I = think we can=20 do it simpler, SIP is SIP, P2PSIP peer is P2PSIP = peer, let=20 them be.
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = 3Dhuawei_logo=20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 10:22
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi all
    P2P is great topic, but = P2PSIP is the=20 subset or certain instance of P2P. when we discuss P2PSIP, we shall not = involve=20 all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are=20 not equal to peers in P2P overlay. when we discuss IMS, although legacy=20 equipments does not support SIP, but some AGWs do translation or agent = for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers who = know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some common = base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more simple=20 but not more complex.
From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,
 
    Please let me describe the = case in=20 detail.
    In the case, all clients support SIP, but = some=20 peers in the overlay network do not support SIP and some support SIP. = For those=20 peers which do not support SIP, such as some PCs, they can provide all = required=20 DHT services, but there is only a pity that they can not recognize any = SIP=20 message, maybe they think that the capability is unnecessary. In this = case, some=20 client protocol is desirable. Certainly this protocol may be the subset = of=20 general Peer Protocol if we regard those clients as Lame Peers and = regard those=20 peers as Pure Peers who only provide required DHT=20 services.
    IMHO, this case does not care those = clients not=20 supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. 3Dhuawei_logo


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: = [P2PSIP]=20 do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. = If a=20 client application is not able to use SIP protocol that is well known = for years=20 it obviously will not be able to use a new one that will be designed = especially=20 for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing = is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that will = be able=20 to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do not = support=20 SIP, those peers are only responsible to
provide distributed = storage,=20 location and transport services for information about SIP, but those = peers do=20 not recognize any
SIP messages at all.
  In this case, = how to=20 maintain the relation between clients (UA) and the hosting peer(s)? = One client=20 protocol is desirable
at this time.


Zheng = Hewen
HUAWEI=20 TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong=20 Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel:=20 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
--------------------= -------------------------------------------------------------------------= -------------------------------=20
---------
This e-mail and its attachments contain confidential=20 information from HUAWEI, which
is intended only for the person or = entity=20 whose address is listed above. Any use of the
information contained = herein=20 in any way (including, but not limited to, total or partial =
disclosure,=20 reproduction, or dissemination) by persons other than the=20 intended
recipient(s) is prohibited. If you receive this e-mail in = error,=20 please notify the sender by
phone or email immediately and delete = it!=20


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26?=20 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP = Mailing=20 List; Philip Matthews
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives for = the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks, = Henry

-----Original=20 Message-----
From: Dean Willis [mailto:=20 dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better than=20 active/passive) entities
have a
> Peer-ID? In otherwords, are = they=20 part of the overlay at all? If so,
for
> most
> DHTs, = how do=20 we allow you to be in the overlay and not store = resources
(not
>=20 typical for most current DHT algorithms)

Well, that certainly = depends=20 on the DHT algorithm involved. It certainly seems that a peer that = moves=20 between contributing
and non-contributing might HAVE a peer ID, = but=20 whether it chooses to insert itself into the DHT "right now" might=20 determine
whether it is contributing "right now"
or = not.

> My=20 concern all along has been that I don't understand why something is =
> a=20 peer if it isn't doing anything other than talking to someone = and
>=20 making requests, hence why I supported client in the first=20 place.
>  I fail to see how something that isn't = contributing=20 anything, and
> instead talks to a peer to get resources, is in = any way=20 a peer. It
> seems completely not in keeping with the idea of = P2P. I=20 also worry it
> is likely to be very confusing since we've been = using=20 the other
> terminology for over a year now. Just looks like a = souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection and=20 wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality make=20 it two different nodes?

> If we do go this way, there is = one subtle=20 point. If I join the overlay
but
> don't happen to offer any = services=20 (other than maybe
storage...depending on
> how we definie it, = that=20 might or might not be mandatory), would I be
> contributing? If = joining=20 the overlay (in the sense that we have a
PeerID
> and
> = we=20 route traffic) doesn't require me to store, I could offer=20 no
services

That's "offer no other services", since routing = is=20 itself a service.

> and
> still be a peer. How do we=20 distinguish between this case and a
> "non-contributing peer" = who isn't=20 even part of the overlay (i.e., no
> Peer-ID)

I think = there's a=20 range of "contributing" in play. For most DHT models, a minimally = contributing=20 node will route a request
it receives. It might ask nicely = (perhaps a=20 q-value mechanism) to not have to route requests, but would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam onto = a WiFi=20 net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

_______________________________________________
P2PSIP = mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

--Boundary_(ID_NQOmo+xJPYLcB2f+f4gA/g)-- --Boundary_(ID_AgaSn7544snMp5q0+7Ml1g) Content-id: <338012809@12072007-299E> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_AgaSn7544snMp5q0+7Ml1g) Content-id: <338012809@12072007-29A5> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_AgaSn7544snMp5q0+7Ml1g)-- --===============1662216546== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1662216546==-- From p2psip-bounces@ietf.org Thu Jul 12 07:32:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8wuN-00045N-1r; Thu, 12 Jul 2007 07:32:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8wuL-00043L-Dm for p2psip@ietf.org; Thu, 12 Jul 2007 07:32:29 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8wuL-0006st-2F for p2psip@ietf.org; Thu, 12 Jul 2007 07:32:29 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1I8wto-0006b3-1R; Thu, 12 Jul 2007 07:31:56 -0400 In-Reply-To: <1DB91DF937A4544C81E636468B91C21C863DB7@CNSHGSMBS03.ad4.ad.alcatel.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22A6D6B9@namail5.corp.adobe.com> <1DB91DF937A4544C81E636468B91C21C863DB7@CNSHGSMBS03.ad4.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] The client role in the Concepts and Terminology I-D Date: Thu, 12 Jul 2007 07:31:49 -0400 To: HUANG Ping B X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: bryan@sipeerior.com, Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org If you didn't already do so, please look at the latest version of the draft draft-ietf-p2psip-concepts-00 We added a bit extra here in the latest version to try to make these options clearer. Options 3 and 4 illustrate a proposal by Kundan Singh and Henning Schulzrinne called the "service model". In that model, Y designates some other peer W to always act as a proxy for it. Peer W is explicitly chosen by Y, and is presumably more trusted by Y than peer Z, which is chosen automatically by the Distributed Database algorithm. According to Kundan and Henning, having all calls go through W makes it easier to implement certain forms of call handling. The working group hasn't really discussed the pros and cons of the four options yet. We are still working on more basic stuff. - Philip On 12-Jul-07, at 05:09 , HUANG Ping B wrote: > I have a question: > in section 5.2, in Option3 and option4, why Peer Y first contact Z, > then > Register to W? and is Y a "Peer " or "client"? on the other word, > what's > the scenario these options described? thanks! > > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Tuesday, July 10, 2007 12:47 AM > To: P2PSIP Mailing List > Cc: bryan@sipeerior.com; Philip Matthews > Subject: [P2PSIP] The client role in the Concepts and Terminology I-D > > Given the importance of "Concepts and Terminology for Peer to Peer > SIP", > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-willis- > p2psip-co > ncepts-04.txt > > I would suggest improving the text by introducing something like > this to > section 5.5. Possible Client Behavior: > > "One of the main motivations for the client protocol is to avoid the > 'always talking' mode for mobile devices that would participate as > full > peers and contribute the IP messages required for the overlay > maintenance. The continuous IP packet exchange may contribute to the > depletion of the battery and possibly also to increase the charges for > certain mobile services. > > As a consequence, it is desirable for certain mobile devices to > benefit > from the P2PSIP overlay but not to contribute to its maintenance or to > the routing and data storage functions of P2P SIP. > > The client protocol is a subset of the peer protocol that allows the > client to store and retrieve data from the P2PSIP overlay and also to > exercise the overlay for message routing. > > The client protocol should be flexible enough to also be extensible > for > non-SIP applications, such as search, multicast, streaming media and > content distribution." > > Delete on page 19 the following and similar on other pages: > > "In essence, the client contributes its storage capacity to its > associated peer."... > > Replace with: > > "Due to their high churn and low bandwidth, certain mobile devices are > not only lesser capable peers, but actually would degrade the > performance of the P2P SIP overlay network as a whole." > > Thanks, > > Henry Sinnreich > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 12 10:27:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zdv-0005LW-FQ; Thu, 12 Jul 2007 10:27:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zdt-0005Kz-DX for p2psip@ietf.org; Thu, 12 Jul 2007 10:27:41 -0400 Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8zdn-00049a-G3 for p2psip@ietf.org; Thu, 12 Jul 2007 10:27:41 -0400 Received: from cnshgsbhs02.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id l6CEOOUH006941; Thu, 12 Jul 2007 22:24:25 +0800 Received: from CNSHGSMBS03.ad4.ad.alcatel.com ([172.24.146.173]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 12 Jul 2007 22:27:22 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [P2PSIP] do we need a client protocol? MIME-Version: 1.0 Date: Thu, 12 Jul 2007 22:27:21 +0800 Message-ID: <1DB91DF937A4544C81E636468B91C21C863E5F@CNSHGSMBS03.ad4.ad.alcatel.com> In-Reply-To: <02b001c7c467$93056b70$5105a40a@china.huawei.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQAAIh/D AACaerMA== References: <1DB91DF937A4544C81E636468B91C21C863D77@CNSHGSMBS03.ad4.ad.alcat el.com> <02b001c7c467$93056b70$5105a40a@china.huawei.com> From: "HUANG Ping B" To: "Zheng Hewen" , "Michal Giermasinski" , , X-OriginalArrivalTime: 12 Jul 2007 14:27:22.0723 (UTC) FILETIME=[C2E15330:01C7C490] X-imss-version: 2.047 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.3 (/) X-Scan-Signature: a2010529d86d8cb33607793afc74e283 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1089983817==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1089983817== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7C490.C286F24D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C490.C286F24D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7C490.C286F24D" ------_=_NextPart_002_01C7C490.C286F24D Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Zheng and marcin I have never said that P2PSIP is IP or use SIP. as we know, there are = two mode in P2PSIP, one is SIP over P2P and the other is P2P over = SIP.SIP is just in application layer and P2P or P2PSIP are more like = transport layer. in SIP over P2P, SIP is just one of the protocols = interacting with P2P or P2PSIP overlay. in P2P over SIP, SIP is made = some extension. I have never said that P2PSIP peer protocol shall use = SIP, SIP is over P2PSIP! And as I said, peers "SHOULD" not "SHALL" recognize SIP. maybe you = "SHALL" read RFC2119 ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 5:33 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT = service but not recognize SIP messages should be admitted as one = member/peer of P2PSIP overlay, we do not have to update the device to = support SIP and then provide DHT service, the cost introduced due to the = update is unnecessary. =20 ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP = offers an alternative mechanism for determining the correct destination = for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of = cause, is you use another protocol, P2PSIP may be called another name, = such as P2PXXX. Peers in P2PSIP overlay are responsible not just for = location (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? = this name means that there is a relationship between P2PSIP and SIP, = maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. = then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize SIP = message. Ok, you can say that a tunnel protocol could be used to deliver = SIP protocol, this is a choice, but not good choice. if a tunnel = protocol is used, then SIP has nothing with P2P overlay, this tunnel = protocol could deliver any protocols besides SIP, then name "P2PSIP" = does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which = overlay users are identified and provides mechanisms for locating users = or resources within the P2PSIP overlay. P2PSIP clients differ from = P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers use the resolution services of the peers as an alternative to = the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP = requests. The working group's initial charter scope will be to produce = protocols to enable this alternate mechanism for RFC 3263 = functionality." =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP = is SIP, P2PSIP peer is P2PSIP peer, let them be. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. =20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could = be peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to = peers in P2P overlay. when we discuss IMS, although legacy equipments = does not support SIP, but some AGWs do translation or agent for those = equipments. then, when we discuss P2PSIP, shall we involve all peers who = know SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, = and vice versa. and I think that Peers in P2PSIP overlay should have = some common base functionalitis such as SIP recognition. I think we = shall make P2PSIP more simple but not more complex. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which = do not support SIP, such as some PCs, they can provide all required DHT = services, but there is only a pity that they can not recognize any SIP = message, maybe they think that the capability is unnecessary. In this = case, some client protocol is desirable. Certainly this protocol may be = the subset of general Peer Protocol if we regard those clients as Lame = Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. =20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known = for years it obviously will not be able to use a new one that will be = designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and = the peer in the overlay). The only issue is to create a proxy-like peer = that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, =09 A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. =09 =09 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo =09 =09 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com = -------------------------------------------------------------------------= ---------------------------------------------------=20 --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 =09 =09 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? =09 Folks, =09 Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: =09 - Limited battery in mobile devices, and=20 =09 - Other uses besides SIP. Business planning folks may not care about = the WG charter, but about the return on the investment. =09 Thanks, Henry =09 -----Original Message----- From: Dean Willis [mailto: dean.willis@softarmor.com = ] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 =09 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store = resources (not > typical for most current DHT algorithms) =09 Well, that certainly depends on the DHT algorithm involved. It = certainly seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. =09 > My concern all along has been that I don't understand why something = is=20 > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of = confusion. =09 A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 =09 > If we do go this way, there is one subtle point. If I join the = overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services =09 That's "offer no other services", since routing is itself a service.=20 =09 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) =09 I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. =09 I think we distinguish based on the service advertisements from the = peer.=20 =09 > If we are so opposed to client for confusion with SIP UAs, lets pick = a new > name, but why some flavor of peer when it does nothing remotely peer like? =09 Because in 15 minutes it might roam onto a WiFi net and therefore = change it service offering.=20 =09 -- Dean =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 =09 =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 ------_=_NextPart_002_01C7C490.C286F24D Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Zheng and marcin
   I have never said that P2PSIP is = IP or use=20 SIP. as we know, there are two mode in P2PSIP, one is SIP over P2P and = the other=20 is P2P over SIP.SIP is just in application layer and P2P or P2PSIP are = more like=20 transport layer. in SIP over P2P, SIP is just one of the protocols = interacting=20 with P2P or P2PSIP overlay. in P2P over SIP, SIP is made some extension. = I have=20 never said that P2PSIP peer protocol shall use SIP, SIP is over=20 P2PSIP!
   And as I said, peers "SHOULD" = not "SHALL"=20 recognize SIP. maybe you "SHALL" read RFC2119

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 5:33 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
   One supplement, = FYI.
   In the future P2PSIP = deployment, one=20 device that can provide DHT service but not recognize SIP messages = should be=20 admitted as one member/peer of P2PSIP overlay, we do not have to update = the=20 device to support SIP and then provide DHT service, the cost = introduced due=20 to the update is unnecessary.
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 16:57
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

I have never said that P2PSIP = is equal to=20 SIP, P2PSIP is just an overlay as an alternative to the SIP discovery = process of=20 RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct=20 destination for SIP requests. SIP is session layer protocol, P2PSIP is = under=20 SIP. of cause, is you use another protocol, P2PSIP may be called another = name,=20 such as P2PXXX. Peers in P2PSIP = overlay are=20 responsible not just for location (done by P2PSIP protocol). Why we = called=20 P2PSIP as "P2PSIP"?  this name means that there is a relationship = between=20 P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP = should be=20 used. then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize = SIP=20 message. Ok, you can say that a tunnel protocol could be used to deliver = SIP=20 protocol, this is a choice, but not good choice. if a tunnel protocol is = used,=20 then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any=20 protocols besides SIP, then name "P2PSIP" does not make=20 sense.
when peers in P2PSIP = overlay do not=20 recognize SIP message, then let them out of = overlay.

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
  If I do not misunderstand, P2PSIP is not = equal to=20 SIP.
  Essentially in P2PSIP overlay, P2PSIP = peers have=20 nothing with SIP. Why must we bind SIP to P2PSIP peers?=20
 
  Here is the description about P2PSIP = peers in WG=20 charter, FYI.
  "The work focuses on collections of = nodes called=20 "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed = namespace in which overlay users are identified and provides mechanisms = for=20 locating users or resources within the P2PSIP overlay. P2PSIP clients = differ=20 from P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers=20 use the resolution services of the peers as an alternative to the SIP = discovery=20 process of RFC 3263. In this way, P2PSIP offers an alternative mechanism = for=20 determining the correct destination for SIP requests. The working = group's=20 initial charter scope will be to produce protocols to enable this = alternate=20 mechanism for RFC 3263 functionality."
 
  Nothing says that P2PSIP = peers must=20 support SIP or have anything with SIP.
  From the charter, functionality of = P2PSIP=20 peers is so clear and simple, why do we make it complicated? I = think we can=20 do it simpler, SIP is SIP, P2PSIP peer is P2PSIP = peer, let=20 them be.
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = 3Dhuawei_logo=20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 10:22
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi all
    P2P is great topic, but = P2PSIP is the=20 subset or certain instance of P2P. when we discuss P2PSIP, we shall not = involve=20 all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are=20 not equal to peers in P2P overlay. when we discuss IMS, although legacy=20 equipments does not support SIP, but some AGWs do translation or agent = for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers who = know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some common = base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more simple=20 but not more complex.
From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,
 
    Please let me describe the = case in=20 detail.
    In the case, all clients support SIP, but = some=20 peers in the overlay network do not support SIP and some support SIP. = For those=20 peers which do not support SIP, such as some PCs, they can provide all = required=20 DHT services, but there is only a pity that they can not recognize any = SIP=20 message, maybe they think that the capability is unnecessary. In this = case, some=20 client protocol is desirable. Certainly this protocol may be the subset = of=20 general Peer Protocol if we regard those clients as Lame Peers and = regard those=20 peers as Pure Peers who only provide required DHT=20 services.
    IMHO, this case does not care those = clients not=20 supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. 3Dhuawei_logo


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: = [P2PSIP]=20 do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. = If a=20 client application is not able to use SIP protocol that is well known = for years=20 it obviously will not be able to use a new one that will be designed = especially=20 for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing = is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that will = be able=20 to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do not = support=20 SIP, those peers are only responsible to
provide distributed = storage,=20 location and transport services for information about SIP, but those = peers do=20 not recognize any
SIP messages at all.
  In this case, = how to=20 maintain the relation between clients (UA) and the hosting peer(s)? = One client=20 protocol is desirable
at this time.


Zheng = Hewen
HUAWEI=20 TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong=20 Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel:=20 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
--------------------= -------------------------------------------------------------------------= -------------------------------=20
---------
This e-mail and its attachments contain confidential=20 information from HUAWEI, which
is intended only for the person or = entity=20 whose address is listed above. Any use of the
information contained = herein=20 in any way (including, but not limited to, total or partial =
disclosure,=20 reproduction, or dissemination) by persons other than the=20 intended
recipient(s) is prohibited. If you receive this e-mail in = error,=20 please notify the sender by
phone or email immediately and delete = it!=20


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26?=20 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP = Mailing=20 List; Philip Matthews
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives for = the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks, = Henry

-----Original=20 Message-----
From: Dean Willis [mailto:=20 dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better than=20 active/passive) entities
have a
> Peer-ID? In otherwords, are = they=20 part of the overlay at all? If so,
for
> most
> DHTs, = how do=20 we allow you to be in the overlay and not store = resources
(not
>=20 typical for most current DHT algorithms)

Well, that certainly = depends=20 on the DHT algorithm involved. It certainly seems that a peer that = moves=20 between contributing
and non-contributing might HAVE a peer ID, = but=20 whether it chooses to insert itself into the DHT "right now" might=20 determine
whether it is contributing "right now"
or = not.

> My=20 concern all along has been that I don't understand why something is =
> a=20 peer if it isn't doing anything other than talking to someone = and
>=20 making requests, hence why I supported client in the first=20 place.
>  I fail to see how something that isn't = contributing=20 anything, and
> instead talks to a peer to get resources, is in = any way=20 a peer. It
> seems completely not in keeping with the idea of = P2P. I=20 also worry it
> is likely to be very confusing since we've been = using=20 the other
> terminology for over a year now. Just looks like a = souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection and=20 wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality make=20 it two different nodes?

> If we do go this way, there is = one subtle=20 point. If I join the overlay
but
> don't happen to offer any = services=20 (other than maybe
storage...depending on
> how we definie it, = that=20 might or might not be mandatory), would I be
> contributing? If = joining=20 the overlay (in the sense that we have a
PeerID
> and
> = we=20 route traffic) doesn't require me to store, I could offer=20 no
services

That's "offer no other services", since routing = is=20 itself a service.

> and
> still be a peer. How do we=20 distinguish between this case and a
> "non-contributing peer" = who isn't=20 even part of the overlay (i.e., no
> Peer-ID)

I think = there's a=20 range of "contributing" in play. For most DHT models, a minimally = contributing=20 node will route a request
it receives. It might ask nicely = (perhaps a=20 q-value mechanism) to not have to route requests, but would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam onto = a WiFi=20 net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

_______________________________________________
P2PSIP = mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

------_=_NextPart_002_01C7C490.C286F24D-- ------_=_NextPart_001_01C7C490.C286F24D Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <953290414@12072007-357B> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C490.C286F24D Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <953290414@12072007-3582> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en-1.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C490.C286F24D-- --===============1089983817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1089983817==-- From p2psip-bounces@ietf.org Thu Jul 12 11:01:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90A7-0000B8-HS; Thu, 12 Jul 2007 11:00:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90A5-0000Au-In for p2psip@ietf.org; Thu, 12 Jul 2007 11:00:57 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I90A4-0003SO-Q1 for p2psip@ietf.org; Thu, 12 Jul 2007 11:00:57 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com id BT-MMP-1674488; Thu, 12 Jul 2007 11:00:41 -0400 Received: from 0015-its-exbh02.us.saic.com ([10.43.229.22]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2007071211004100934 ; Thu, 12 Jul 2007 11:00:41 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-its-exbh02.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 11:00:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] do we need a client protocol? Date: Thu, 12 Jul 2007 11:00:33 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1D195@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQAAIh/DAACaerMAABttiJ References: <1DB91DF937A4544C81E636468B91C21C863D77@CNSHGSMBS03.ad4.ad.alcatel.com> <02b001c7c467$93056b70$5105a40a@china.huawei.com> <1DB91DF937A4544C81E636468B91C21C863E5F@CNSHGSMBS03.ad4.ad.alcatel.com> From: "Roy, Radhika R." To: "HUANG Ping B" , "Zheng Hewen" , "Michal Giermasinski" , , X-OriginalArrivalTime: 12 Jul 2007 15:00:40.0146 (UTC) FILETIME=[696FE320:01C7C495] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fbd8e9750b9803d5a057a470865c963 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0308874105==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0308874105== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7C495.65A3186B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C495.65A3186B Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7C495.65A3186B" ------_=_NextPart_002_01C7C495.65A3186B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Huang: =20 I also think, as you have said, P2PSIP peers should not recognize SIP. = It means that if SIP is used, P2PSIP peers may understand SIP as well. =20 However, would please clarify with some examples, as you have said, the = following? =20 1.=09 SIP is an application layer 2.=09 P2PSIP is like a transport layer 3.=09 SIP is just one application interacting with P2PSIP overlay =20 Best regards, Radhika ________________________________ From: p2psip-bounces@ietf.org on behalf of HUANG Ping B Sent: Thu 7/12/2007 10:27 AM To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org; = marcin.matuszewski@nokia.com Subject: RE: [P2PSIP] do we need a client protocol? Hi Zheng and marcin I have never said that P2PSIP is IP or use SIP. as we know, there are = two mode in P2PSIP, one is SIP over P2P and the other is P2P over = SIP.SIP is just in application layer and P2P or P2PSIP are more like = transport layer. in SIP over P2P, SIP is just one of the protocols = interacting with P2P or P2PSIP overlay. in P2P over SIP, SIP is made = some extension. I have never said that P2PSIP peer protocol shall use = SIP, SIP is over P2PSIP! And as I said, peers "SHOULD" not "SHALL" recognize SIP. maybe you = "SHALL" read RFC2119 ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 5:33 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT = service but not recognize SIP messages should be admitted as one = member/peer of P2PSIP overlay, we do not have to update the device to = support SIP and then provide DHT service, the cost introduced due to the = update is unnecessary. =20 ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007?7?12? 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP = offers an alternative mechanism for determining the correct destination = for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of = cause, is you use another protocol, P2PSIP may be called another name, = such as P2PXXX. Peers in P2PSIP overlay are responsible not just for = location (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? = this name means that there is a relationship between P2PSIP and SIP, = maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. = then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize SIP = message. Ok, you can say that a tunnel protocol could be used to deliver = SIP protocol, this is a choice, but not good choice. if a tunnel = protocol is used, then SIP has nothing with P2P overlay, this tunnel = protocol could deliver any protocols besides SIP, then name "P2PSIP" = does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which = overlay users are identified and provides mechanisms for locating users = or resources within the P2PSIP overlay. P2PSIP clients differ from = P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers use the resolution services of the peers as an alternative to = the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP = requests. The working group's initial charter scope will be to produce = protocols to enable this alternate mechanism for RFC 3263 = functionality." =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP = is SIP, P2PSIP peer is P2PSIP peer, let them be. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. = huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007?7?12? 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could = be peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to = peers in P2P overlay. when we discuss IMS, although legacy equipments = does not support SIP, but some AGWs do translation or agent for those = equipments. then, when we discuss P2PSIP, shall we involve all peers who = know SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, = and vice versa. and I think that Peers in P2PSIP overlay should have = some common base functionalitis such as SIP recognition. I think we = shall make P2PSIP more simple but not more complex. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which = do not support SIP, such as some PCs, they can provide all required DHT = services, but there is only a pity that they can not recognize any SIP = message, maybe they think that the capability is unnecessary. In this = case, some client protocol is desirable. Certainly this protocol may be = the subset of general Peer Protocol if we regard those clients as Lame = Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. = huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007?7?12? 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known = for years it obviously will not be able to use a new one that will be = designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and = the peer in the overlay). The only issue is to create a proxy-like peer = that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, =09 A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. =09 =09 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo =09 =09 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 = -------------------------------------------------------------------------= ---------------------------------------------------=20 --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 =09 =09 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? =09 Folks, =09 Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: =09 - Limited battery in mobile devices, and=20 =09 - Other uses besides SIP. Business planning folks may not care about = the WG charter, but about the return on the investment. =09 Thanks, Henry =09 -----Original Message----- From: Dean Willis [mailto: dean.willis@softarmor.com = ] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 =09 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store = resources (not > typical for most current DHT algorithms) =09 Well, that certainly depends on the DHT algorithm involved. It = certainly seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. =09 > My concern all along has been that I don't understand why something = is=20 > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of = confusion. =09 A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 =09 > If we do go this way, there is one subtle point. If I join the = overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services =09 That's "offer no other services", since routing is itself a service.=20 =09 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) =09 I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. =09 I think we distinguish based on the service advertisements from the = peer.=20 =09 > If we are so opposed to client for confusion with SIP UAs, lets pick = a new > name, but why some flavor of peer when it does nothing remotely peer like? =09 Because in 15 minutes it might roam onto a WiFi net and therefore = change it service offering.=20 =09 -- Dean =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 =09 =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 ------_=_NextPart_002_01C7C495.65A3186B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Huang:
=0A=
 
=0A=
I also think, as you have = said, P2PSIP peers should not recognize SIP. It means that if SIP is = used, P2PSIP peers may understand SIP as well.
=0A=
 
=0A=
However, would please clarify = with some examples, as you have said, the following?
=0A=
 
=0A=
    =0A=
  1. =0A=
    SIP is an application = layer
    2. =0A=
  2. =0A=
    P2PSIP is like a transport = layer
    3. =0A=
  3. =0A=
    SIP is just one application interacting = with P2PSIP overlay
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A= From: p2psip-bounces@ietf.org on = behalf of HUANG Ping B
Sent: Thu 7/12/2007 10:27 = AM
To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org; = marcin.matuszewski@nokia.com
Subject: RE: [P2PSIP] do we need = a client protocol?

=0A=
=0A=
Hi Zheng and marcin
=0A=
   I have never said that P2PSIP is = IP or use SIP. as we know, there are two mode in P2PSIP, one is SIP over = P2P and the other is P2P over SIP.SIP is just in application layer and = P2P or P2PSIP are more like transport layer. in SIP over P2P, SIP is = just one of the protocols interacting with P2P or P2PSIP overlay. in P2P = over SIP, SIP is made some extension. I have never said that P2PSIP peer = protocol shall use SIP, SIP is over P2PSIP!
=0A=
   And as I said, peers "SHOULD" = not "SHALL" recognize SIP. maybe you "SHALL" read = RFC2119

=0A=
=0A=
=0A= From: Zheng Hewen = [mailto:hwzheng@huawei.com]
Sent: Thursday, July 12, 2007 = 5:33 PM
To: HUANG Ping B; 'Michal Giermasinski'; = p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client = protocol?

=0A=
=0A=
Hi,
=0A=
 
=0A=
   One supplement, = FYI.
=0A=
   In the = future P2PSIP deployment, one device that can provide DHT service but = not recognize SIP messages should be admitted as one member/peer of = P2PSIP overlay, we do not have to update the device to support SIP and = then provide DHT service, the cost introduced due to the update is = unnecessary.
=0A=
 

=0A=
=0A=
=0A= From: HUANG Ping B = [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007年7月12日 16:57
To: Zheng Hewen; Michal = Giermasinski; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need = a client protocol?

=0A=
=0A=
I have never = said that P2PSIP is equal to SIP, P2PSIP is just an overlay as an = alternative to the SIP discovery process of RFC 3263, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP = requests. SIP is session layer protocol, P2PSIP is under SIP. of cause, = is you use another protocol, P2PSIP may be called another name, such as = P2PXXX. Peers in P2PSIP = overlay are responsible not just for location (done by P2PSIP = protocol). Why we called P2PSIP as "P2PSIP"?  this name means that = there is a relationship between P2PSIP and SIP, maybe SIP over P2P or = P2P over SIP. but any way, SIP should be used. then Peers in P2PSIP = overlay( not P2PXXX overlay) should recognize SIP message. Ok, you can = say that a tunnel protocol could be used to deliver SIP protocol, this = is a choice, but not good choice. if a tunnel protocol is used, then SIP = has nothing with P2P overlay, this tunnel protocol could deliver any = protocols besides SIP, then name "P2PSIP" does not make = sense.
=0A=
when peers in P2PSIP = overlay do not recognize SIP message, then let them out of = overlay.

=0A=
=0A=
=0A= From: Zheng Hewen = [mailto:hwzheng@huawei.com]
Sent: Thursday, July 12, 2007 = 2:01 PM
To: HUANG Ping B; 'Michal Giermasinski'; = p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client = protocol?

=0A=
=0A=
Hi,
=0A=
 
=0A=
  If I do not misunderstand, = P2PSIP is not equal to SIP.
=0A=
  Essentially in P2PSIP = overlay, P2PSIP peers have nothing with SIP. Why must we bind = SIP to P2PSIP peers?
=0A=
 
=0A=
  Here is the description = about P2PSIP peers in WG charter, FYI.
=0A=
  "The work focuses on = collections of nodes called "P2PSIP peers" and "P2PSIP clients". P2PSIP = peers manifest a distributed namespace in which overlay users are = identified and provides mechanisms for locating users or resources = within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers = primarily in that they do not store information in the overlay, but only = use it to locate users and resources. P2PSIP clients and peers use the = resolution services of the peers as an alternative to the SIP discovery = process of RFC 3263. In this way, P2PSIP offers an alternative mechanism = for determining the correct destination for SIP requests. The working = group's initial charter scope will be to produce protocols to enable = this alternate mechanism for RFC 3263 = functionality."
=0A=
 
=0A=
  Nothing says = that P2PSIP peers must support SIP or have anything with = SIP.
=0A=
  From the charter, = functionality of P2PSIP peers is so clear and simple, why do we = make it complicated? I think we can do it simpler, SIP is = SIP, P2PSIP peer is P2PSIP peer, let them = be.
=0A=
 
=0A=

=0A=

Zheng = Hewen
HUAWEI = TECHNOLOGIES CO.,LTD. 3Dhuawei_logo =0A=


Huihong = Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel: = 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This e-mail and its attachments contain confidential information from = HUAWEI, which
is intended only for the person or entity whose = address is listed above. Any use of the
information contained herein = in any way (including, but not limited to, total or partial =
disclosure, reproduction, or dissemination) by persons other than = the intended
recipient(s) is prohibited. If you receive this e-mail = in error, please notify the sender by
phone or email immediately and = delete it!
=0A=
 

=0A=
=0A=
=0A= From: HUANG Ping B = [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007年7月12日 10:22
To: Zheng Hewen; Michal = Giermasinski; p2psip@ietf.org
Subject: RE: [P2PSIP] do we need = a client protocol?

=0A=
=0A=
Hi = all
=0A=
    P2P = is great topic, but P2PSIP is the subset or certain instance of P2P. = when we discuss P2PSIP, we shall not involve all nodes which could be = peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to peers = in P2P overlay. when we discuss IMS, although legacy equipments does not = support SIP, but some AGWs do translation or agent for those equipments. = then, when we discuss P2PSIP, shall we involve all peers who know SIP or = not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice = versa. and I think that Peers in P2PSIP overlay should have some common = base functionalitis such as SIP recognition. I think we shall make = P2PSIP more simple but not more complex.
=0A=
=0A=
=0A= From: Zheng Hewen = [mailto:hwzheng@huawei.com]
Sent: Thursday, July 12, 2007 = 9:34 AM
To: 'Michal Giermasinski'; = p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client = protocol?

=0A=
=0A=
Hi,
=0A=
 
=0A=
    Please let = me describe the case in detail.
    In the case, all = clients support SIP, but some peers in the overlay network do not = support SIP and some support SIP. For those peers which do not support = SIP, such as some PCs, they can provide all required DHT services, but = there is only a pity that they can not recognize any SIP message, maybe = they think that the capability is unnecessary. In this case, some client = protocol is desirable. Certainly this protocol may be the subset of = general Peer Protocol if we regard those clients as Lame Peers and = regard those peers as Pure Peers who only provide required DHT = services.
    IMHO, this case does not care those = clients not supporting SIP.
=0A=
 
=0A=
Zheng = Hewen
HUAWEI = TECHNOLOGIES CO.,LTD. 3Dhuawei_logo
=0A=


Huihong = Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel: = 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This e-mail and its attachments contain confidential information from = HUAWEI, which
is intended only for the person or entity whose = address is listed above. Any use of the
information contained herein = in any way (including, but not limited to, total or partial =
disclosure, reproduction, or dissemination) by persons other than = the intended
recipient(s) is prohibited. If you receive this e-mail = in error, please notify the sender by
phone or email immediately and = delete it!
=0A=
 

=0A=
=0A=
=0A= From: Michal Giermasinski = [mailto:michal.giermasinski@gmail.com]
Sent: = 2007年7月12日 5:31
To: Zheng Hewen; = p2psip@ietf.org
Subject: Re: [P2PSIP] do we need a client = protocol?

=0A=
=0A=
Hi!
=0A=
 
=0A=
Well, in my oppinion it is not a good for creating a new protocol. = If a client application is not able to use SIP protocol that is well = known for years it obviously will not be able to use a new one that will = be designed especially for cooperation with p2psip overlay.
=0A=
 
=0A=
If we follow this understanding we can assume that the better thing = is to use SIP on this interface (between client outstanding the overlay = and the peer in the overlay). The only issue is to create a proxy-like = peer that will be able to help client to get benefits of the overlay. =
=0A=
 
=0A=
What we should consider is how to filter the traffic unwanted by = regular client that do not want to take part in the routing = decision.
=0A=
 
=0A=
best regards
=0A=
Michal Giermasinski
=0A=


 
=0A=
2007/7/11, Zheng Hewen <hwzheng@huawei.com>: =0A=
Hi,

   A = client protocol will be useful when some peers in the overlay do not = support SIP, those peers are only responsible to
provide distributed = storage, location and transport services for information about SIP, but = those peers do not recognize any
SIP messages at = all.
  In this case, how to maintain the relation between = clients (UA) and the hosting peer(s)? One client protocol is desirable =
at this time.


Zheng Hewen
HUAWEI TECHNOLOGIES = CO.,LTD.  huawei_logo


Huihong Mansion
No.91 = Baixia Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
-------------------= -------------------------------------------------------------------------= --------------------------------
---------
This e-mail and its = attachments contain confidential information from HUAWEI, which
is = intended only for the person or entity whose address is listed above. = Any use of the
information contained herein in any way (including, = but not limited to, total or partial
disclosure, reproduction, or = dissemination) by persons other than the intended
recipient(s) is = prohibited. If you receive this e-mail in error, please notify the = sender by
phone or email immediately and delete it! =


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26? 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom = Houri; P2PSIP Mailing List; Philip Matthews
Subject: [P2PSIP] do we = need a client protocol?

Folks,

Given the length of the = discussion on "do we need a client protocol?"
let me repeat the = simple imperatives for the client:

- Limited battery in mobile = devices, and

- Other uses besides SIP. Business planning folks = may not care about the WG charter, but about the return on the = investment.

Thanks, Henry

-----Original = Message-----
From: Dean Willis [mailto: = dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23 = PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for = active/passive peerterminology

David A. Bryan wrote:
> If = I understand this right, not sure I like it. Do = these
"non-contributing
> peer" (I *do* like contributing = better than active/passive) entities
have a
> Peer-ID? In = otherwords, are they part of the overlay at all? If so,
for
> = most
> DHTs, how do we allow you to be in the overlay and not = store resources
(not
> typical for most current DHT = algorithms)

Well, that certainly depends on the DHT algorithm = involved. It certainly seems that a peer that moves between contributing =
and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine
whether it is = contributing "right now"
or not.

> My concern all along has = been that I don't understand why something is
> a peer if it = isn't doing anything other than talking to someone and
> making = requests, hence why I supported client in the first = place.
>  I fail to see how something that isn't = contributing anything, and
> instead talks to a peer to get = resources, is in any way a peer. It
> seems completely not in = keeping with the idea of P2P. I also worry it
> is likely to be = very confusing since we've been using the other
> terminology for = over a year now. Just looks like a souce of confusion.

A node = might sometimes have a high-bandwidth connection and wish to contribute = resources, and sometimes not have a
high-bandwidth connection and = therefore not wish to offer resources. Does this modality make it two = different nodes?

> If we do go this way, there is one subtle = point. If I join the overlay
but
> don't happen to offer any = services (other than maybe
storage...depending on
> how we = definie it, that might or might not be mandatory), would I be
> = contributing? If joining the overlay (in the sense that we have = a
PeerID
> and
> we route traffic) doesn't require me to = store, I could offer no
services

That's "offer no other = services", since routing is itself a service.

> and
> = still be a peer. How do we distinguish between this case and a
> = "non-contributing peer" who isn't even part of the overlay (i.e., = no
> Peer-ID)

I think there's a range of "contributing" in = play. For most DHT models, a minimally contributing node will route a = request
it receives. It might ask nicely (perhaps a q-value = mechanism) to not have to route requests, but would = probably
mathematically still have to route something it = gets.

I think we distinguish based on the service advertisements = from the peer.

> If we are so opposed to client for confusion = with SIP UAs, lets pick a
new
> name, but why some flavor of = peer when it does nothing remotely peer
like?

Because in 15 = minutes it might roam onto a WiFi net and therefore change it service = offering. =

--
Dean

_______________________________________________=
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip =

_______________________________________________
P2PSIP = mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip =




_______________________________________________P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip =

------_=_NextPart_002_01C7C495.65A3186B-- ------_=_NextPart_001_01C7C495.65A3186B Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <953290414@12072007-357B> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C495.65A3186B Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <953290414@12072007-3582> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en-1.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C495.65A3186B-- --===============0308874105== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0308874105==-- From p2psip-bounces@ietf.org Thu Jul 12 21:32:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9A1O-0001Ou-FT; Thu, 12 Jul 2007 21:32:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9A1L-0001On-Bk for p2psip@ietf.org; Thu, 12 Jul 2007 21:32:35 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9A1G-00041O-TZ for p2psip@ietf.org; Thu, 12 Jul 2007 21:32:35 -0400 Received: by py-out-1112.google.com with SMTP id f31so889496pyh for ; Thu, 12 Jul 2007 18:32:30 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fYHPscigFFoei/xHOpbb3PtziDIC9mSzSCL2kR9RgRNkwdDgiI/Aonrpy9hSuiRRTPmH4reHRrrR5zA46/+BQjw9b3gqoXGW+ZXveFpA2YGOiQO005FbQMOzUolsHkqUpHTIgGwcHz9EXq+dMUYbje2Fd3gREQ63cvNKYPP4OV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=LWH196P9JlTV31nIZFgSD1nG2z36PqgST4NLrBarytjKtL++Bk0TZJI3dQvCo0aYaSlG0VdPpFaNYC2AetKtHm5u9xBU5ukAZbh36UWl3ThousV2LW42gbC0eDicyMHwPRzBtzkJ4uwPc4FsbAKe351n9uGlqnoPldynPsI3vZY= Received: by 10.65.240.17 with SMTP id s17mr2132433qbr.1184290350258; Thu, 12 Jul 2007 18:32:30 -0700 (PDT) Received: by 10.65.133.13 with HTTP; Thu, 12 Jul 2007 18:32:30 -0700 (PDT) Message-ID: Date: Fri, 13 Jul 2007 09:32:30 +0800 From: "Duan Chen" To: "HUANG Ping B" Subject: Re: [P2PSIP] do we need a client protocol? In-Reply-To: <1DB91DF937A4544C81E636468B91C21C863E5F@CNSHGSMBS03.ad4.ad.alcatel.com> MIME-Version: 1.0 References: <02b001c7c467$93056b70$5105a40a@china.huawei.com> <1DB91DF937A4544C81E636468B91C21C863E5F@CNSHGSMBS03.ad4.ad.alcatel.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7742ab7d8f94ae8c6013d3682e631edb Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1688374643==" Errors-To: p2psip-bounces@ietf.org --===============1688374643== Content-Type: multipart/related; boundary="----=_Part_20759_11002465.1184290350123" ------=_Part_20759_11002465.1184290350123 Content-Type: multipart/alternative; boundary="----=_Part_20758_8641315.1184290350123" ------=_Part_20758_8641315.1184290350123 Content-Type: text/plain; charset=GB2312; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksIEh1YW5nICYgWmhlbmc6CgpPbmUgY29tbWVudDoKCiAgSWYgSSB1bmRlcnN0YW5kIGNvcnJl Y3RseSwgdGhlIFAyUFNJUCBvdmVybGF5IHNob3VsZCBiZSBhYmxlIHRvIHRyYW5zcG9ydAp0aGUg U0lQIG1lc3NhZ2UgYmVjYXVzZSBvZiB0aGUgTkFUIHRyYXZlcnNhbCBpc3N1ZSBiZXR3ZWVuIHBl ZXJzLiBJZiBpdCBkb2VzCm5vdCwgdGhlcmUgaXMgbm8gcmVsaWFibGUgd2F5IGZvciBhIHBlZXIg YmVoaW5kIG9uZSBOQVQgdG8gc2VuZCBhIFNJUCBJTlZJVEUKdG8gYSBwZWVyIGJlaGluZCBhbm90 aGVyIE5BVCAoc2VlIHNlY3Rpb24gNS4zIG9mCmRyYWZ0LWlldGYtcDJwc2lwLWNvbmNlcHRzLTAw LnR4dCksIGEgUDJQU0lQIHBlZXIgbWF5IG9yIG1heSBub3QgYmUgY291cGxlZAp3aXRoIGEgU0lQ IGVudGl0eSwgYnV0IGl0IHNob3VsZCBiZSBhYmxlIHRvIHJlY29nbml6ZSB0aGUgU0lQIG1lc3Nh Z2U7IG9yCmhvdyBjYW4gaXQgZW5jYXBzdWxhdGUgb3IgbXVsdGlwbGV4IGEgU0lQIG1lc3NhZ2Ug YWxvbmcgdGhlIHBlZXIgdG8gcGVlcgpjb25uZWN0aW9ucz8KClRodXMgaWYgdGhlcmUgaXMgYSBk ZXZpY2Ugam9pbmluZyB0aGUgREhUIG92ZXJsYXkgYnV0IG5vdCBhYmxlIHRvIHJlY29nbml6ZQp0 aGUgU0lQIG1lc3NhZ2UsIGl0IHdvdWxkIHByZWNsdWRlIHRoZSBhcHByb2FjaCBtZW50aW9uZWQg YWJvdmUgdG8gc29sdmUgdGhlCk5BVCBpc3N1ZS4KCnRoYW5rcyBhbmQgcmVnYXJkcyEKCgpPbiA3 LzEyLzA3LCBIVUFORyBQaW5nIEIgPFBpbmcuYi5IdWFuZ0BhbGNhdGVsLXNiZWxsLmNvbS5jbj4g d3JvdGU6Cj4KPiAgSGkgWmhlbmcgYW5kIG1hcmNpbgo+ICAgIEkgaGF2ZSBuZXZlciBzYWlkIHRo YXQgUDJQU0lQIGlzIElQIG9yIHVzZSBTSVAuIGFzIHdlIGtub3csIHRoZXJlIGFyZQo+IHR3byBt b2RlIGluIFAyUFNJUCwgb25lIGlzIFNJUCBvdmVyIFAyUCBhbmQgdGhlIG90aGVyIGlzIFAyUCBv dmVyIFNJUC5TSVBpcyBqdXN0IGluIGFwcGxpY2F0aW9uIGxheWVyIGFuZCBQMlAgb3IgUDJQU0lQ IGFyZSBtb3JlIGxpa2UgdHJhbnNwb3J0Cj4gbGF5ZXIuIGluIFNJUCBvdmVyIFAyUCwgU0lQIGlz IGp1c3Qgb25lIG9mIHRoZSBwcm90b2NvbHMgaW50ZXJhY3Rpbmcgd2l0aAo+IFAyUCBvciBQMlBT SVAgb3ZlcmxheS4gaW4gUDJQIG92ZXIgU0lQLCBTSVAgaXMgbWFkZSBzb21lIGV4dGVuc2lvbi4g SSBoYXZlCj4gbmV2ZXIgc2FpZCB0aGF0IFAyUFNJUCBwZWVyIHByb3RvY29sIHNoYWxsIHVzZSBT SVAsIFNJUCBpcyBvdmVyIFAyUFNJUCEKPiAgICBBbmQgYXMgSSBzYWlkLCBwZWVycyAiU0hPVUxE IiBub3QgIlNIQUxMIiByZWNvZ25pemUgU0lQLiBtYXliZSB5b3UKPiAiU0hBTEwiIHJlYWQgUkZD MjExOQo+Cj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ICpGcm9tOiogWmhlbmcg SGV3ZW4gW21haWx0bzpod3poZW5nQGh1YXdlaS5jb21dCj4gKlNlbnQ6KiBUaHVyc2RheSwgSnVs eSAxMiwgMjAwNyA1OjMzIFBNCj4gKlRvOiogSFVBTkcgUGluZyBCOyAnTWljaGFsIEdpZXJtYXNp bnNraSc7IHAycHNpcEBpZXRmLm9yZwo+ICpTdWJqZWN0OiogUkU6IFtQMlBTSVBdIGRvIHdlIG5l ZWQgYSBjbGllbnQgcHJvdG9jb2w/Cj4KPgo+ICBIaSwKPgo+ICAgIE9uZSBzdXBwbGVtZW50LCBG WUkuCj4gICAgSW4gdGhlIGZ1dHVyZSBQMlBTSVAgZGVwbG95bWVudCwgb25lIGRldmljZSB0aGF0 IGNhbiBwcm92aWRlIERIVAo+IHNlcnZpY2UgYnV0IG5vdCByZWNvZ25pemUgU0lQIG1lc3NhZ2Vz IHNob3VsZCBiZSBhZG1pdHRlZCBhcyBvbmUgbWVtYmVyL3BlZXIKPiBvZiBQMlBTSVAgb3Zlcmxh eSwgd2UgZG8gbm90IGhhdmUgdG8gdXBkYXRlIHRoZSBkZXZpY2UgdG8gc3VwcG9ydCBTSVAgYW5k Cj4gdGhlbiBwcm92aWRlIERIVCBzZXJ2aWNlLCB0aGUgY29zdCBpbnRyb2R1Y2VkIGR1ZSB0byB0 aGUgdXBkYXRlIGlzCj4gdW5uZWNlc3NhcnkuCj4KPgo+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KPiAqRnJvbToqIEhVQU5HIFBpbmcgQiBbbWFpbHRvOlBpbmcuYi5IdWFuZ0BhbGNh dGVsLXNiZWxsLmNvbS5jbl0KPiAqU2VudDoqIDIwMDfE6jfUwjEyyNUgMTY6NTcKPiAqVG86KiBa aGVuZyBIZXdlbjsgTWljaGFsIEdpZXJtYXNpbnNraTsgcDJwc2lwQGlldGYub3JnCj4gKlN1Ympl Y3Q6KiBSRTogW1AyUFNJUF0gZG8gd2UgbmVlZCBhIGNsaWVudCBwcm90b2NvbD8KPgo+Cj4gIEkg aGF2ZSBuZXZlciBzYWlkIHRoYXQgUDJQU0lQIGlzIGVxdWFsIHRvIFNJUCwgUDJQU0lQIGlzIGp1 c3QgYW4gb3ZlcmxheQo+IGFzIGFuIGFsdGVybmF0aXZlIHRvIHRoZSBTSVAgZGlzY292ZXJ5IHBy b2Nlc3Mgb2YgUkZDIDMyNjMsIFAyUFNJUCBvZmZlcnMgYW4KPiBhbHRlcm5hdGl2ZSBtZWNoYW5p c20gZm9yIGRldGVybWluaW5nIHRoZSBjb3JyZWN0IGRlc3RpbmF0aW9uIGZvciBTSVAKPiByZXF1 ZXN0cy4gU0lQIGlzIHNlc3Npb24gbGF5ZXIgcHJvdG9jb2wsIFAyUFNJUCBpcyB1bmRlciBTSVAu IG9mIGNhdXNlLCBpcwo+IHlvdSB1c2UgYW5vdGhlciBwcm90b2NvbCwgUDJQU0lQIG1heSBiZSBj YWxsZWQgYW5vdGhlciBuYW1lLCBzdWNoIGFzIFAyUFhYWC4KPiBQZWVycyBpbiBQMlBTSVAgb3Zl cmxheSBhcmUgcmVzcG9uc2libGUgbm90IGp1c3QgZm9yIGxvY2F0aW9uIChkb25lIGJ5Cj4gUDJQ U0lQIHByb3RvY29sKS4gV2h5IHdlIGNhbGxlZCBQMlBTSVAgYXMgIlAyUFNJUCI/ICB0aGlzIG5h bWUgbWVhbnMgdGhhdAo+IHRoZXJlIGlzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4gUDJQU0lQIGFu ZCBTSVAsIG1heWJlIFNJUCBvdmVyIFAyUCBvciBQMlAKPiBvdmVyIFNJUC4gYnV0IGFueSB3YXks IFNJUCBzaG91bGQgYmUgdXNlZC4gdGhlbiBQZWVycyBpbiBQMlBTSVAgb3ZlcmxheSggbm90Cj4g UDJQWFhYIG92ZXJsYXkpIHNob3VsZCByZWNvZ25pemUgU0lQIG1lc3NhZ2UuIE9rLCB5b3UgY2Fu IHNheSB0aGF0IGEgdHVubmVsCj4gcHJvdG9jb2wgY291bGQgYmUgdXNlZCB0byBkZWxpdmVyIFNJ UCBwcm90b2NvbCwgdGhpcyBpcyBhIGNob2ljZSwgYnV0IG5vdAo+IGdvb2QgY2hvaWNlLiBpZiBh IHR1bm5lbCBwcm90b2NvbCBpcyB1c2VkLCB0aGVuIFNJUCBoYXMgbm90aGluZyB3aXRoIFAyUAo+ IG92ZXJsYXksIHRoaXMgdHVubmVsIHByb3RvY29sIGNvdWxkIGRlbGl2ZXIgYW55IHByb3RvY29s cyBiZXNpZGVzIFNJUCwgdGhlbgo+IG5hbWUgIlAyUFNJUCIgZG9lcyBub3QgbWFrZSBzZW5zZS4K PiB3aGVuIHBlZXJzIGluIFAyUFNJUCBvdmVybGF5IGRvIG5vdCByZWNvZ25pemUgU0lQIG1lc3Nh Z2UsIHRoZW4gbGV0IHRoZW0KPiBvdXQgb2Ygb3ZlcmxheS4KPgo+ICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KPiAqRnJvbToqIFpoZW5nIEhld2VuIFttYWlsdG86aHd6aGVuZ0BodWF3 ZWkuY29tXQo+ICpTZW50OiogVGh1cnNkYXksIEp1bHkgMTIsIDIwMDcgMjowMSBQTQo+ICpUbzoq IEhVQU5HIFBpbmcgQjsgJ01pY2hhbCBHaWVybWFzaW5za2knOyBwMnBzaXBAaWV0Zi5vcmcKPiAq U3ViamVjdDoqIFJFOiBbUDJQU0lQXSBkbyB3ZSBuZWVkIGEgY2xpZW50IHByb3RvY29sPwo+Cj4K PiAgSGksCj4KPiAgIElmIEkgZG8gbm90IG1pc3VuZGVyc3RhbmQsIFAyUFNJUCBpcyBub3QgZXF1 YWwgdG8gU0lQLgo+ICAgRXNzZW50aWFsbHkgaW4gUDJQU0lQIG92ZXJsYXksIFAyUFNJUCBwZWVy cyBoYXZlIG5vdGhpbmcgd2l0aCBTSVAuCj4gV2h5IG11c3Qgd2UgYmluZCBTSVAgdG8gUDJQU0lQ IHBlZXJzPwo+Cj4gICBIZXJlIGlzIHRoZSBkZXNjcmlwdGlvbiBhYm91dCBQMlBTSVAgcGVlcnMg aW4gV0cgY2hhcnRlciwgRllJLgo+ICAgKiJUaGUgd29yayBmb2N1c2VzIG9uIGNvbGxlY3Rpb25z IG9mIG5vZGVzIGNhbGxlZCAiUDJQU0lQIHBlZXJzIiBhbmQKPiAiUDJQU0lQIGNsaWVudHMiLiBQ MlBTSVAgcGVlcnMgbWFuaWZlc3QgYSBkaXN0cmlidXRlZCBuYW1lc3BhY2UgaW4gd2hpY2gKPiBv dmVybGF5IHVzZXJzIGFyZSBpZGVudGlmaWVkIGFuZCBwcm92aWRlcyBtZWNoYW5pc21zIGZvciBs b2NhdGluZyB1c2VycyBvcgo+IHJlc291cmNlcyB3aXRoaW4gdGhlIFAyUFNJUCBvdmVybGF5LiBQ MlBTSVAgY2xpZW50cyBkaWZmZXIgZnJvbSBQMlBTSVAgcGVlcnMKPiBwcmltYXJpbHkgaW4gdGhh dCB0aGV5IGRvIG5vdCBzdG9yZSBpbmZvcm1hdGlvbiBpbiB0aGUgb3ZlcmxheSwgYnV0IG9ubHkg dXNlCj4gaXQgdG8gbG9jYXRlIHVzZXJzIGFuZCByZXNvdXJjZXMuIFAyUFNJUCBjbGllbnRzIGFu ZCBwZWVycyB1c2UgdGhlCj4gcmVzb2x1dGlvbiBzZXJ2aWNlcyBvZiB0aGUgcGVlcnMgYXMgYW4g YWx0ZXJuYXRpdmUgdG8gdGhlIFNJUCBkaXNjb3ZlcnkKPiBwcm9jZXNzIG9mIFJGQyAzMjYzLiBJ biB0aGlzIHdheSwgUDJQU0lQIG9mZmVycyBhbiBhbHRlcm5hdGl2ZSBtZWNoYW5pc20gZm9yCj4g ZGV0ZXJtaW5pbmcgdGhlIGNvcnJlY3QgZGVzdGluYXRpb24gZm9yIFNJUCByZXF1ZXN0cy4gVGhl IHdvcmtpbmcgZ3JvdXAncwo+IGluaXRpYWwgY2hhcnRlciBzY29wZSB3aWxsIGJlIHRvIHByb2R1 Y2UgcHJvdG9jb2xzIHRvIGVuYWJsZSB0aGlzIGFsdGVybmF0ZQo+IG1lY2hhbmlzbSBmb3IgUkZD IDMyNjMgZnVuY3Rpb25hbGl0eS4iKgo+ICoqCj4gKiAgKk5vdGhpbmcgc2F5cyB0aGF0IFAyUFNJ UCBwZWVycyBtdXN0IHN1cHBvcnQgU0lQIG9yIGhhdmUgYW55dGhpbmcgd2l0aAo+IFNJUC4KPiAg IEZyb20gdGhlIGNoYXJ0ZXIsIGZ1bmN0aW9uYWxpdHkgb2YgUDJQU0lQIHBlZXJzIGlzIHNvIGNs ZWFyIGFuZCBzaW1wbGUsCj4gd2h5IGRvIHdlIG1ha2UgaXQgY29tcGxpY2F0ZWQ/IEkgdGhpbmsg d2UgY2FuIGRvIGl0IHNpbXBsZXIsIFNJUCBpcwo+IFNJUCwgUDJQU0lQIHBlZXIgaXMgUDJQU0lQ IHBlZXIsIGxldCB0aGVtIGJlLgo+Cj4KPiBaaGVuZyBIZXdlbgo+IEhVQVdFSSBURUNITk9MT0dJ RVMgQ08uLExURC4gW2ltYWdlOiBodWF3ZWlfbG9nb10KPgo+Cj4gSHVpaG9uZyBNYW5zaW9uCj4g Tm8uOTEgQmFpeGlhIFJvYWQKPiBOYW5KaW5nLCBQLlIuQ2hpbmEKPiBUZWw6IDAyNS04NDU2NTQ2 Nwo+IEZheDogMDI1LTg0NTY1MzU0Cj4gTW9iaWxlOiAxMzYxMTUwODI2NAo+IEUtbWFpbDogaHd6 aGVuZ0BodWF3ZWljLm9tCj4gd3d3Lmh1YXdlaS5jb20KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K PiBUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGZyb20KPiBIVUFXRUksIHdoaWNoCj4gaXMgaW50ZW5kZWQgb25seSBmb3IgdGhl IHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuCj4gQW55IHVz ZSBvZiB0aGUKPiBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1 ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLAo+IHRvdGFsIG9yIHBhcnRpYWwKPiBkaXNjbG9zdXJl LCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0 aGUKPiBpbnRlbmRlZAo+IHJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2 ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlCj4gbm90aWZ5IHRoZSBzZW5kZXIgYnkKPiBw aG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0IQo+Cj4KPiAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gKkZyb206KiBIVUFORyBQaW5nIEIgW21haWx0bzpQaW5n LmIuSHVhbmdAYWxjYXRlbC1zYmVsbC5jb20uY25dCj4gKlNlbnQ6KiAyMDA3xOo31MIxMsjVIDEw OjIyCj4gKlRvOiogWmhlbmcgSGV3ZW47IE1pY2hhbCBHaWVybWFzaW5za2k7IHAycHNpcEBpZXRm Lm9yZwo+ICpTdWJqZWN0OiogUkU6IFtQMlBTSVBdIGRvIHdlIG5lZWQgYSBjbGllbnQgcHJvdG9j b2w/Cj4KPgo+ICBIaSBhbGwKPiAgICAgUDJQIGlzIGdyZWF0IHRvcGljLCBidXQgUDJQU0lQIGlz IHRoZSBzdWJzZXQgb3IgY2VydGFpbiBpbnN0YW5jZSBvZgo+IFAyUC4gd2hlbiB3ZSBkaXNjdXNz IFAyUFNJUCwgd2Ugc2hhbGwgbm90IGludm9sdmUgYWxsIG5vZGVzIHdoaWNoIGNvdWxkIGJlCj4g cGVlcnMgaW4gUDJQU0lQIG92ZXJsYXkuIHBlZXJzIGluIFAyUFNJUCBvdmVybGF5IGFyZSBub3Qg ZXF1YWwgdG8gcGVlcnMgaW4KPiBQMlAgb3ZlcmxheS4gd2hlbiB3ZSBkaXNjdXNzIElNUywgYWx0 aG91Z2ggbGVnYWN5IGVxdWlwbWVudHMgZG9lcyBub3QKPiBzdXBwb3J0IFNJUCwgYnV0IHNvbWUg QUdXcyBkbyB0cmFuc2xhdGlvbiBvciBhZ2VudCBmb3IgdGhvc2UgZXF1aXBtZW50cy4KPiB0aGVu LCB3aGVuIHdlIGRpc2N1c3MgUDJQU0lQLCBzaGFsbCB3ZSBpbnZvbHZlIGFsbCBwZWVycyB3aG8g a25vdyBTSVAgb3Igbm90Cj4gaW4gUDJQU0lQIG92ZXJsYXk/IEkgdGhpbmsgUDJQIGlzIG5vdCBl cXVhbCB0byBQMlBTSVAsIGFuZCB2aWNlIHZlcnNhLiBhbmQgSQo+IHRoaW5rIHRoYXQgUGVlcnMg aW4gUDJQU0lQIG92ZXJsYXkgc2hvdWxkIGhhdmUgc29tZSBjb21tb24gYmFzZQo+IGZ1bmN0aW9u YWxpdGlzIHN1Y2ggYXMgU0lQIHJlY29nbml0aW9uLiBJIHRoaW5rIHdlIHNoYWxsIG1ha2UgUDJQ U0lQIG1vcmUKPiBzaW1wbGUgYnV0IG5vdCBtb3JlIGNvbXBsZXguCj4KPiAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCj4gKkZyb206KiBaaGVuZyBIZXdlbiBbbWFpbHRvOmh3emhlbmdA aHVhd2VpLmNvbV0KPiAqU2VudDoqIFRodXJzZGF5LCBKdWx5IDEyLCAyMDA3IDk6MzQgQU0KPiAq VG86KiAnTWljaGFsIEdpZXJtYXNpbnNraSc7IHAycHNpcEBpZXRmLm9yZwo+ICpTdWJqZWN0Oiog UkU6IFtQMlBTSVBdIGRvIHdlIG5lZWQgYSBjbGllbnQgcHJvdG9jb2w/Cj4KPgo+ICBIaSwKPgo+ ICAgICBQbGVhc2UgbGV0IG1lIGRlc2NyaWJlIHRoZSBjYXNlIGluIGRldGFpbC4KPiAgICAgSW4g dGhlIGNhc2UsIGFsbCBjbGllbnRzIHN1cHBvcnQgU0lQLCBidXQgc29tZSBwZWVycyBpbiB0aGUg b3ZlcmxheQo+IG5ldHdvcmsgZG8gbm90IHN1cHBvcnQgU0lQIGFuZCBzb21lIHN1cHBvcnQgU0lQ LiBGb3IgdGhvc2UgcGVlcnMgd2hpY2ggZG8KPiBub3Qgc3VwcG9ydCBTSVAsIHN1Y2ggYXMgc29t ZSBQQ3MsIHRoZXkgY2FuIHByb3ZpZGUgYWxsIHJlcXVpcmVkIERIVAo+IHNlcnZpY2VzLCBidXQg dGhlcmUgaXMgb25seSBhIHBpdHkgdGhhdCB0aGV5IGNhbiBub3QgcmVjb2duaXplIGFueSBTSVAK PiBtZXNzYWdlLCBtYXliZSB0aGV5IHRoaW5rIHRoYXQgdGhlIGNhcGFiaWxpdHkgaXMgdW5uZWNl c3NhcnkuIEluIHRoaXMgY2FzZSwKPiBzb21lIGNsaWVudCBwcm90b2NvbCBpcyBkZXNpcmFibGUu IENlcnRhaW5seSB0aGlzIHByb3RvY29sIG1heSBiZSB0aGUgc3Vic2V0Cj4gb2YgZ2VuZXJhbCBQ ZWVyIFByb3RvY29sIGlmIHdlIHJlZ2FyZCB0aG9zZSBjbGllbnRzIGFzIExhbWUgUGVlcnMgYW5k IHJlZ2FyZAo+IHRob3NlIHBlZXJzIGFzIFB1cmUgUGVlcnMgd2hvIG9ubHkgcHJvdmlkZSByZXF1 aXJlZCBESFQgc2VydmljZXMuCj4gICAgIElNSE8sIHRoaXMgY2FzZSBkb2VzIG5vdCBjYXJlIHRo b3NlIGNsaWVudHMgbm90IHN1cHBvcnRpbmcgU0lQLgo+Cj4gWmhlbmcgSGV3ZW4KPiBIVUFXRUkg VEVDSE5PTE9HSUVTIENPLixMVEQuIFtpbWFnZTogaHVhd2VpX2xvZ29dCj4KPgo+IEh1aWhvbmcg TWFuc2lvbgo+IE5vLjkxIEJhaXhpYSBSb2FkCj4gTmFuSmluZywgUC5SLkNoaW5hCj4gVGVsOiAw MjUtODQ1NjU0NjcKPiBGYXg6IDAyNS04NDU2NTM1NAo+IE1vYmlsZTogMTM2MTE1MDgyNjQKPiBF LW1haWw6IGh3emhlbmdAaHVhd2VpYy5vbQo+IHd3dy5odWF3ZWkuY29tCj4KPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tCj4gVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZp ZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tCj4gSFVBV0VJLCB3aGljaAo+IGlzIGludGVuZGVkIG9u bHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3Zl Lgo+IEFueSB1c2Ugb2YgdGhlCj4gaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkg d2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywKPiB0b3RhbCBvciBwYXJ0aWFsCj4g ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90 aGVyIHRoYW4gdGhlCj4gaW50ZW5kZWQKPiByZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYg eW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZQo+IG5vdGlmeSB0aGUgc2Vu ZGVyIGJ5Cj4gcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCEKPgo+Cj4g IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+ICpGcm9tOiogTWljaGFsIEdpZXJtYXNp bnNraSBbbWFpbHRvOm1pY2hhbC5naWVybWFzaW5za2lAZ21haWwuY29tXQo+ICpTZW50OiogMjAw N8TqN9TCMTLI1SA1OjMxCj4gKlRvOiogWmhlbmcgSGV3ZW47IHAycHNpcEBpZXRmLm9yZwo+ICpT dWJqZWN0OiogUmU6IFtQMlBTSVBdIGRvIHdlIG5lZWQgYSBjbGllbnQgcHJvdG9jb2w/Cj4KPgo+ ICBIaSEKPgo+IFdlbGwsIGluIG15IG9wcGluaW9uIGl0IGlzIG5vdCBhIGdvb2QgZm9yIGNyZWF0 aW5nIGEgbmV3IHByb3RvY29sLiBJZiBhCj4gY2xpZW50IGFwcGxpY2F0aW9uIGlzIG5vdCBhYmxl IHRvIHVzZSBTSVAgcHJvdG9jb2wgdGhhdCBpcyB3ZWxsIGtub3duIGZvcgo+IHllYXJzIGl0IG9i dmlvdXNseSB3aWxsIG5vdCBiZSBhYmxlIHRvIHVzZSBhIG5ldyBvbmUgdGhhdCB3aWxsIGJlIGRl c2lnbmVkCj4gZXNwZWNpYWxseSBmb3IgY29vcGVyYXRpb24gd2l0aCBwMnBzaXAgb3ZlcmxheS4K Pgo+IElmIHdlIGZvbGxvdyB0aGlzIHVuZGVyc3RhbmRpbmcgd2UgY2FuIGFzc3VtZSB0aGF0IHRo ZSBiZXR0ZXIgdGhpbmcgaXMgdG8KPiB1c2UgU0lQIG9uIHRoaXMgaW50ZXJmYWNlIChiZXR3ZWVu IGNsaWVudCBvdXRzdGFuZGluZyB0aGUgb3ZlcmxheSBhbmQgdGhlCj4gcGVlciBpbiB0aGUgb3Zl cmxheSkuIFRoZSBvbmx5IGlzc3VlIGlzIHRvIGNyZWF0ZSBhIHByb3h5LWxpa2UgcGVlciB0aGF0 Cj4gd2lsbCBiZSBhYmxlIHRvIGhlbHAgY2xpZW50IHRvIGdldCBiZW5lZml0cyBvZiB0aGUgb3Zl cmxheS4KPgo+IFdoYXQgd2Ugc2hvdWxkIGNvbnNpZGVyIGlzIGhvdyB0byBmaWx0ZXIgdGhlIHRy YWZmaWMgdW53YW50ZWQgYnkgcmVndWxhcgo+IGNsaWVudCB0aGF0IGRvIG5vdCB3YW50IHRvIHRh a2UgcGFydCBpbiB0aGUgcm91dGluZyBkZWNpc2lvbi4KPgo+IGJlc3QgcmVnYXJkcwo+IE1pY2hh bCBHaWVybWFzaW5za2kKPgo+Cj4KPiAyMDA3LzcvMTEsIFpoZW5nIEhld2VuIDxod3poZW5nQGh1 YXdlaS5jb20+Ogo+ID4KPiA+IEhpLAo+ID4KPiA+ICAgIEEgY2xpZW50IHByb3RvY29sIHdpbGwg YmUgdXNlZnVsIHdoZW4gc29tZSBwZWVycyBpbiB0aGUgb3ZlcmxheSBkbwo+ID4gbm90IHN1cHBv cnQgU0lQLCB0aG9zZSBwZWVycyBhcmUgb25seSByZXNwb25zaWJsZSB0bwo+ID4gcHJvdmlkZSBk aXN0cmlidXRlZCBzdG9yYWdlLCBsb2NhdGlvbiBhbmQgdHJhbnNwb3J0IHNlcnZpY2VzIGZvcgo+ ID4gaW5mb3JtYXRpb24gYWJvdXQgU0lQLCBidXQgdGhvc2UgcGVlcnMgZG8gbm90IHJlY29nbml6 ZSBhbnkKPiA+IFNJUCBtZXNzYWdlcyBhdCBhbGwuCj4gPiAgIEluIHRoaXMgY2FzZSwgaG93IHRv IG1haW50YWluIHRoZSByZWxhdGlvbiBiZXR3ZWVuIGNsaWVudHMgKFVBKSBhbmQKPiA+IHRoZSBo b3N0aW5nIHBlZXIocyk/IE9uZSBjbGllbnQgcHJvdG9jb2wgaXMgZGVzaXJhYmxlCj4gPiBhdCB0 aGlzIHRpbWUuCj4gPgo+ID4KPiA+IFpoZW5nIEhld2VuCj4gPiBIVUFXRUkgVEVDSE5PTE9HSUVT IENPLixMVEQuICBodWF3ZWlfbG9nbwo+ID4KPiA+Cj4gPiBIdWlob25nIE1hbnNpb24KPiA+IE5v LjkxIEJhaXhpYSBSb2FkCj4gPiBOYW5KaW5nLCBQLlIuQ2hpbmEKPiA+IFRlbDogMDI1LTg0NTY1 NDY3Cj4gPiBGYXg6IDAyNS04NDU2NTM1NAo+ID4gTW9iaWxlOiAxMzYxMTUwODI2NAo+ID4gRS1t YWlsOiBod3poZW5nQGh1YXdlaWMub20KPiA+IHd3dy5odWF3ZWkuY29tCj4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Cj4gPgo+ID4gLS0tLS0tLS0tCj4gPiBUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNv bnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20KPiA+IEhVQVdFSSwgd2hpY2gKPiA+ IGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3Mg aXMgbGlzdGVkIGFib3ZlLgo+ID4gQW55IHVzZSBvZiB0aGUKPiA+IGluZm9ybWF0aW9uIGNvbnRh aW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sCj4g PiB0b3RhbCBvciBwYXJ0aWFsCj4gPiBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIG9yIGRpc3Nl bWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUKPiA+IGludGVuZGVkCj4gPiByZWNp cGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJy b3IsIHBsZWFzZQo+ID4gbm90aWZ5IHRoZSBzZW5kZXIgYnkKPiA+IHBob25lIG9yIGVtYWlsIGlt bWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhCj4gPgo+ID4KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tCj4gPiBGcm9tOiBIZW5yeSBTaW5ucmVpY2ggW21haWx0bzpoc2lubnJlaUBhZG9iZS5j b21dCj4gPiBTZW50OiAyMDA3PzY/MjY/IDE6MzkKPiA+IFRvOiBEZWFuIFdpbGxpczsgRGF2aWQg QS4gQnJ5YW4KPiA+IENjOiBBdnNoYWxvbSBIb3VyaTsgUDJQU0lQIE1haWxpbmcgTGlzdDsgUGhp bGlwIE1hdHRoZXdzCj4gPiBTdWJqZWN0OiBbUDJQU0lQXSBkbyB3ZSBuZWVkIGEgY2xpZW50IHBy b3RvY29sPwo+ID4KPiA+IEZvbGtzLAo+ID4KPiA+IEdpdmVuIHRoZSBsZW5ndGggb2YgdGhlIGRp c2N1c3Npb24gb24gImRvIHdlIG5lZWQgYSBjbGllbnQgcHJvdG9jb2w/Igo+ID4gbGV0IG1lIHJl cGVhdCB0aGUgc2ltcGxlIGltcGVyYXRpdmVzIGZvciB0aGUgY2xpZW50Ogo+ID4KPiA+IC0gTGlt aXRlZCBiYXR0ZXJ5IGluIG1vYmlsZSBkZXZpY2VzLCBhbmQKPiA+Cj4gPiAtIE90aGVyIHVzZXMg YmVzaWRlcyBTSVAuIEJ1c2luZXNzIHBsYW5uaW5nIGZvbGtzIG1heSBub3QgY2FyZSBhYm91dCB0 aGUKPiA+IFdHIGNoYXJ0ZXIsIGJ1dCBhYm91dCB0aGUgcmV0dXJuIG9uIHRoZSBpbnZlc3RtZW50 Lgo+ID4KPiA+IFRoYW5rcywgSGVucnkKPiA+Cj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQo+ID4gRnJvbTogRGVhbiBXaWxsaXMgW21haWx0bzogZGVhbi53aWxsaXNAc29mdGFybW9yLmNv bV0KPiA+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE0LCAyMDA3IDExOjIzIFBNCj4gPiBUbzogRGF2 aWQgQS4gQnJ5YW4KPiA+IENjOiBBdnNoYWxvbSBIb3VyaTsgUDJQU0lQIE1haWxpbmcgTGlzdDsg UGhpbGlwIE1hdHRoZXdzCj4gPiBTdWJqZWN0OiBSZTogW1AyUFNJUF0gQ29uY2VwdHMgZG9jdW1l bnQ6IHByb3Bvc2FsIGZvciBhY3RpdmUvcGFzc2l2ZQo+ID4gcGVlcnRlcm1pbm9sb2d5Cj4gPgo+ ID4gRGF2aWQgQS4gQnJ5YW4gd3JvdGU6Cj4gPiA+IElmIEkgdW5kZXJzdGFuZCB0aGlzIHJpZ2h0 LCBub3Qgc3VyZSBJIGxpa2UgaXQuIERvIHRoZXNlCj4gPiAibm9uLWNvbnRyaWJ1dGluZwo+ID4g PiBwZWVyIiAoSSAqZG8qIGxpa2UgY29udHJpYnV0aW5nIGJldHRlciB0aGFuIGFjdGl2ZS9wYXNz aXZlKSBlbnRpdGllcwo+ID4gaGF2ZSBhCj4gPiA+IFBlZXItSUQ/IEluIG90aGVyd29yZHMsIGFy ZSB0aGV5IHBhcnQgb2YgdGhlIG92ZXJsYXkgYXQgYWxsPyBJZiBzbywKPiA+IGZvcgo+ID4gPiBt b3N0Cj4gPiA+IERIVHMsIGhvdyBkbyB3ZSBhbGxvdyB5b3UgdG8gYmUgaW4gdGhlIG92ZXJsYXkg YW5kIG5vdCBzdG9yZSByZXNvdXJjZXMKPiA+IChub3QKPiA+ID4gdHlwaWNhbCBmb3IgbW9zdCBj dXJyZW50IERIVCBhbGdvcml0aG1zKQo+ID4KPiA+IFdlbGwsIHRoYXQgY2VydGFpbmx5IGRlcGVu ZHMgb24gdGhlIERIVCBhbGdvcml0aG0gaW52b2x2ZWQuIEl0IGNlcnRhaW5seQo+ID4gc2VlbXMg dGhhdCBhIHBlZXIgdGhhdCBtb3ZlcyBiZXR3ZWVuIGNvbnRyaWJ1dGluZwo+ID4gYW5kIG5vbi1j b250cmlidXRpbmcgbWlnaHQgSEFWRSBhIHBlZXIgSUQsIGJ1dCB3aGV0aGVyIGl0IGNob29zZXMg dG8KPiA+IGluc2VydCBpdHNlbGYgaW50byB0aGUgREhUICJyaWdodCBub3ciIG1pZ2h0IGRldGVy bWluZQo+ID4gd2hldGhlciBpdCBpcyBjb250cmlidXRpbmcgInJpZ2h0IG5vdyIKPiA+IG9yIG5v dC4KPiA+Cj4gPiA+IE15IGNvbmNlcm4gYWxsIGFsb25nIGhhcyBiZWVuIHRoYXQgSSBkb24ndCB1 bmRlcnN0YW5kIHdoeSBzb21ldGhpbmcgaXMKPiA+Cj4gPiA+IGEgcGVlciBpZiBpdCBpc24ndCBk b2luZyBhbnl0aGluZyBvdGhlciB0aGFuIHRhbGtpbmcgdG8gc29tZW9uZSBhbmQKPiA+ID4gbWFr aW5nIHJlcXVlc3RzLCBoZW5jZSB3aHkgSSBzdXBwb3J0ZWQgY2xpZW50IGluIHRoZSBmaXJzdCBw bGFjZS4KPiA+ID4gIEkgZmFpbCB0byBzZWUgaG93IHNvbWV0aGluZyB0aGF0IGlzbid0IGNvbnRy aWJ1dGluZyBhbnl0aGluZywgYW5kCj4gPiA+IGluc3RlYWQgdGFsa3MgdG8gYSBwZWVyIHRvIGdl dCByZXNvdXJjZXMsIGlzIGluIGFueSB3YXkgYSBwZWVyLiBJdAo+ID4gPiBzZWVtcyBjb21wbGV0 ZWx5IG5vdCBpbiBrZWVwaW5nIHdpdGggdGhlIGlkZWEgb2YgUDJQLiBJIGFsc28gd29ycnkgaXQK PiA+ID4gaXMgbGlrZWx5IHRvIGJlIHZlcnkgY29uZnVzaW5nIHNpbmNlIHdlJ3ZlIGJlZW4gdXNp bmcgdGhlIG90aGVyCj4gPiA+IHRlcm1pbm9sb2d5IGZvciBvdmVyIGEgeWVhciBub3cuIEp1c3Qg bG9va3MgbGlrZSBhIHNvdWNlIG9mIGNvbmZ1c2lvbi4KPiA+Cj4gPiBBIG5vZGUgbWlnaHQgc29t ZXRpbWVzIGhhdmUgYSBoaWdoLWJhbmR3aWR0aCBjb25uZWN0aW9uIGFuZCB3aXNoIHRvCj4gPiBj b250cmlidXRlIHJlc291cmNlcywgYW5kIHNvbWV0aW1lcyBub3QgaGF2ZSBhCj4gPiBoaWdoLWJh bmR3aWR0aCBjb25uZWN0aW9uIGFuZCB0aGVyZWZvcmUgbm90IHdpc2ggdG8gb2ZmZXIgcmVzb3Vy Y2VzLgo+ID4gRG9lcyB0aGlzIG1vZGFsaXR5IG1ha2UgaXQgdHdvIGRpZmZlcmVudCBub2Rlcz8K PiA+Cj4gPiA+IElmIHdlIGRvIGdvIHRoaXMgd2F5LCB0aGVyZSBpcyBvbmUgc3VidGxlIHBvaW50 LiBJZiBJIGpvaW4gdGhlIG92ZXJsYXkKPiA+IGJ1dAo+ID4gPiBkb24ndCBoYXBwZW4gdG8gb2Zm ZXIgYW55IHNlcnZpY2VzIChvdGhlciB0aGFuIG1heWJlCj4gPiBzdG9yYWdlLi4uZGVwZW5kaW5n IG9uCj4gPiA+IGhvdyB3ZSBkZWZpbmllIGl0LCB0aGF0IG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBt YW5kYXRvcnkpLCB3b3VsZCBJIGJlCj4gPiA+IGNvbnRyaWJ1dGluZz8gSWYgam9pbmluZyB0aGUg b3ZlcmxheSAoaW4gdGhlIHNlbnNlIHRoYXQgd2UgaGF2ZSBhCj4gPiBQZWVySUQKPiA+ID4gYW5k Cj4gPiA+IHdlIHJvdXRlIHRyYWZmaWMpIGRvZXNuJ3QgcmVxdWlyZSBtZSB0byBzdG9yZSwgSSBj b3VsZCBvZmZlciBubwo+ID4gc2VydmljZXMKPiA+Cj4gPiBUaGF0J3MgIm9mZmVyIG5vIG90aGVy IHNlcnZpY2VzIiwgc2luY2Ugcm91dGluZyBpcyBpdHNlbGYgYSBzZXJ2aWNlLgo+ID4KPiA+ID4g YW5kCj4gPiA+IHN0aWxsIGJlIGEgcGVlci4gSG93IGRvIHdlIGRpc3Rpbmd1aXNoIGJldHdlZW4g dGhpcyBjYXNlIGFuZCBhCj4gPiA+ICJub24tY29udHJpYnV0aW5nIHBlZXIiIHdobyBpc24ndCBl dmVuIHBhcnQgb2YgdGhlIG92ZXJsYXkgKGkuZS4sIG5vCj4gPiA+IFBlZXItSUQpCj4gPgo+ID4g SSB0aGluayB0aGVyZSdzIGEgcmFuZ2Ugb2YgImNvbnRyaWJ1dGluZyIgaW4gcGxheS4gRm9yIG1v c3QgREhUIG1vZGVscywKPiA+IGEgbWluaW1hbGx5IGNvbnRyaWJ1dGluZyBub2RlIHdpbGwgcm91 dGUgYSByZXF1ZXN0Cj4gPiBpdCByZWNlaXZlcy4gSXQgbWlnaHQgYXNrIG5pY2VseSAocGVyaGFw cyBhIHEtdmFsdWUgbWVjaGFuaXNtKSB0byBub3QKPiA+IGhhdmUgdG8gcm91dGUgcmVxdWVzdHMs IGJ1dCB3b3VsZCBwcm9iYWJseQo+ID4gbWF0aGVtYXRpY2FsbHkgc3RpbGwgaGF2ZSB0byByb3V0 ZSBzb21ldGhpbmcgaXQgZ2V0cy4KPiA+Cj4gPiBJIHRoaW5rIHdlIGRpc3Rpbmd1aXNoIGJhc2Vk IG9uIHRoZSBzZXJ2aWNlIGFkdmVydGlzZW1lbnRzIGZyb20gdGhlCj4gPiBwZWVyLgo+ID4KPiA+ ID4gSWYgd2UgYXJlIHNvIG9wcG9zZWQgdG8gY2xpZW50IGZvciBjb25mdXNpb24gd2l0aCBTSVAg VUFzLCBsZXRzIHBpY2sgYQo+ID4gbmV3Cj4gPiA+IG5hbWUsIGJ1dCB3aHkgc29tZSBmbGF2b3Ig b2YgcGVlciB3aGVuIGl0IGRvZXMgbm90aGluZyByZW1vdGVseSBwZWVyCj4gPiBsaWtlPwo+ID4K PiA+IEJlY2F1c2UgaW4gMTUgbWludXRlcyBpdCBtaWdodCByb2FtIG9udG8gYSBXaUZpIG5ldCBh bmQgdGhlcmVmb3JlIGNoYW5nZQo+ID4gaXQgc2VydmljZSBvZmZlcmluZy4KPiA+Cj4gPiAtLQo+ ID4gRGVhbgo+ID4KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCj4gPiBQMlBTSVAgbWFpbGluZyBsaXN0Cj4gPiBQMlBTSVBAaWV0Zi5vcmcKPiA+IGh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcAo+ID4KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBQMlBTSVAgbWFp bGluZyBsaXN0Cj4gPiBQMlBTSVBAaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3AycHNpcAo+ID4KPiA+Cj4gPgo+ID4KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gPiBQMlBTSVAgbWFpbGluZyBsaXN0 Cj4gPiBQMlBTSVBAaWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3AycHNpcAo+ID4KPgo+Cj4KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+IFAyUFNJUCBtYWlsaW5nIGxpc3QKPiBQMlBTSVBAaWV0Zi5vcmcK PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXAKPgo+Cg== ------=_Part_20758_8641315.1184290350123 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSwgSHVhbmcgJmFtcDsgWmhlbmc6PC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+ T25lIGNvbW1lbnQ6PC9kaXY+CjxkaXY+Jm5ic3A7IDwvZGl2Pgo8ZGl2PiZuYnNwOyBJZiBJIHVu ZGVyc3RhbmQgY29ycmVjdGx5LCB0aGUgUDJQU0lQIG92ZXJsYXkgc2hvdWxkIGJlIGFibGUgdG8g dHJhbnNwb3J0IHRoZSBTSVAgbWVzc2FnZSBiZWNhdXNlIG9mIHRoZSBOQVQgdHJhdmVyc2FsIGlz c3VlIGJldHdlZW4gcGVlcnMuIElmIGl0IGRvZXMgbm90LCB0aGVyZSBpcyBubyByZWxpYWJsZSB3 YXkgZm9yIGEgcGVlciBiZWhpbmQgb25lIE5BVCB0byBzZW5kIGEgU0lQIElOVklURSB0byBhIHBl ZXIgYmVoaW5kIGFub3RoZXIgTkFUIChzZWUgc2VjdGlvbiAKNS4zIG9mJm5ic3A7ZHJhZnQtaWV0 Zi1wMnBzaXAtY29uY2VwdHMtMDAudHh0KSwgYSBQMlBTSVAgcGVlciBtYXkgb3IgbWF5IG5vdCBi ZSBjb3VwbGVkIHdpdGggYSBTSVAgZW50aXR5LCBidXQgaXQgc2hvdWxkIGJlIGFibGUgdG8gcmVj b2duaXplIHRoZSBTSVAgbWVzc2FnZTsgb3IgaG93IGNhbiBpdCBlbmNhcHN1bGF0ZSBvciBtdWx0 aXBsZXggYSBTSVAgbWVzc2FnZSZuYnNwO2Fsb25nIHRoZSBwZWVyIHRvIHBlZXIgY29ubmVjdGlv bnM/CjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PlRodXMgaWYgdGhlcmUgaXMgYSBkZXZp Y2Ugam9pbmluZyB0aGUgREhUIG92ZXJsYXkgYnV0IG5vdCBhYmxlIHRvIHJlY29nbml6ZSB0aGUg U0lQIG1lc3NhZ2UsIGl0IHdvdWxkIHByZWNsdWRlIHRoZSBhcHByb2FjaCBtZW50aW9uZWQgYWJv dmUgdG8gc29sdmUgdGhlIE5BVCBpc3N1ZS48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj50 aGFua3MgYW5kIHJlZ2FyZHMhPGJyPjxicj4mbmJzcDs8L2Rpdj4KPGRpdj48c3BhbiBjbGFzcz0i Z21haWxfcXVvdGUiPk9uIDcvMTIvMDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5IVUFO RyBQaW5nIEI8L2I+ICZsdDs8YSBocmVmPSJtYWlsdG86UGluZy5iLkh1YW5nQGFsY2F0ZWwtc2Jl bGwuY29tLmNuIj5QaW5nLmIuSHVhbmdAYWxjYXRlbC1zYmVsbC5jb20uY248L2E+Jmd0OyB3cm90 ZTo8L3NwYW4+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkct TEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAx cHggc29saWQiPgo8ZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9 IiMwMDAwZmYiIHNpemU9IjIiPjxzcGFuPkhpIFpoZW5nIGFuZCBtYXJjaW48L3NwYW4+PC9mb250 PjwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PGZvbnQgY29sb3I9IiMwMDAwZmYi IHNpemU9IjIiPjxzcGFuPiZuYnNwOyZuYnNwOyBJIGhhdmUgbmV2ZXIgc2FpZCB0aGF0IFAyUFNJ UCBpcyBJUCBvciB1c2UgU0lQLiBhcyB3ZSBrbm93LCB0aGVyZSBhcmUgdHdvIG1vZGUgaW4gUDJQ U0lQLCBvbmUgaXMgU0lQIG92ZXIgUDJQIGFuZCB0aGUgb3RoZXIgaXMgUDJQIG92ZXIgU0lQLlNJ UCBpcyBqdXN0IGluIGFwcGxpY2F0aW9uIGxheWVyIGFuZCBQMlAgb3IgUDJQU0lQIGFyZSBtb3Jl IGxpa2UgdHJhbnNwb3J0IGxheWVyLiBpbiBTSVAgb3ZlciBQMlAsIFNJUCBpcyBqdXN0IG9uZSBv ZiB0aGUgcHJvdG9jb2xzIGludGVyYWN0aW5nIHdpdGggUDJQIG9yIFAyUFNJUCBvdmVybGF5LiBp biBQMlAgb3ZlciBTSVAsIFNJUCBpcyBtYWRlIHNvbWUgZXh0ZW5zaW9uLiBJIGhhdmUgbmV2ZXIg c2FpZCB0aGF0IFAyUFNJUCBwZWVyIHByb3RvY29sIHNoYWxsIHVzZSBTSVAsIFNJUCBpcyZuYnNw O292ZXIgUDJQU0lQIQo8L3NwYW4+PC9mb250PjwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0i bGVmdCI+PGZvbnQgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPjxzcGFuPiZuYnNwOyZuYnNwOyBB bmQgYXMgSSBzYWlkLCBwZWVycyAmcXVvdDtTSE9VTEQmcXVvdDsgbm90ICZxdW90O1NIQUxMJnF1 b3Q7IHJlY29nbml6ZSBTSVAuIG1heWJlIHlvdSAmcXVvdDtTSEFMTCZxdW90OyByZWFkIFJGQzIx MTk8L3NwYW4+PC9mb250PjwvZGl2Pjxicj4KPGRpdiBsYW5nPSJlbi11cyIgZGlyPSJsdHIiIGFs aWduPSJsZWZ0Ij4KPGhyPgo8Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxiPkZyb206PC9i PiBaaGVuZyBIZXdlbiBbbWFpbHRvOjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExp bmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86aHd6aGVuZ0BodWF3ZWkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+aHd6aGVuZ0BodWF3ZWkuY29tPC9hPl0gPGJyPjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSnVseSAxMiwgMjAwNyA1OjMzIFBNCjxicj48Yj5Ubzo8L2I+IEhVQU5HIFBpbmcg QjsgJiMzOTtNaWNoYWwgR2llcm1hc2luc2tpJiMzOTs7IDxhIG9uY2xpY2s9InJldHVybiB0b3Au anMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86cDJwc2lwQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cDJwc2lwQGlldGYub3JnPC9hPjxicj48Yj5TdWJqZWN0 OjwvYj4gUkU6IFtQMlBTSVBdIGRvIHdlIG5lZWQgYSBjbGllbnQgcHJvdG9jb2w/Cjxicj48L2Zv bnQ+PGJyPiZuYnNwOzwvZGl2Pgo8ZGl2PjwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVm dCI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIj48c3Bhbj5IaSw8 L3NwYW4+PC9mb250PjwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFj ZT0iQXJpYWwiIGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIj48c3Bhbj48L3NwYW4+PC9mb250PiZu YnNwOzwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iQXJpYWwi IGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIj48c3Bhbj4mbmJzcDsmbmJzcDsgT25lIHN1cHBsZW1l bnQsIEZZSS48L3NwYW4+PC9mb250PjwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+ PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIj48c3Bhbj4mbmJzcDsm bmJzcDsgSW4mbmJzcDt0aGUgZnV0dXJlIFAyUFNJUCBkZXBsb3ltZW50LCBvbmUgZGV2aWNlIHRo YXQgY2FuIHByb3ZpZGUgREhUIHNlcnZpY2UgYnV0IG5vdCByZWNvZ25pemUgU0lQIG1lc3NhZ2Vz IHNob3VsZCBiZSBhZG1pdHRlZCBhcyBvbmUgbWVtYmVyL3BlZXIgb2YgUDJQU0lQIG92ZXJsYXks IHdlIGRvIG5vdCBoYXZlIHRvIHVwZGF0ZSB0aGUgZGV2aWNlIHRvIHN1cHBvcnQgU0lQIGFuZCB0 aGVuIHByb3ZpZGUgREhUIHNlcnZpY2UsIHRoZSZuYnNwO2Nvc3QgaW50cm9kdWNlZCBkdWUgdG8g dGhlIHVwZGF0ZSBpcyB1bm5lY2Vzc2FyeS4KPC9zcGFuPjwvZm9udD48L2Rpdj4KPGRpdiBkaXI9 Imx0ciIgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6 ZT0iMiI+PHNwYW4+PC9zcGFuPjwvZm9udD4mbmJzcDs8L2Rpdj48YnI+CjxkaXYgbGFuZz0iZW4t dXMiIGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+Cjxocj4KPGZvbnQgZmFjZT0iVGFob21hIiBzaXpl PSIyIj48Yj5Gcm9tOjwvYj4gSFVBTkcgUGluZyBCIFttYWlsdG86PGEgb25jbGljaz0icmV0dXJu IHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpQaW5n LmIuSHVhbmdAYWxjYXRlbC1zYmVsbC5jb20uY24iIHRhcmdldD0iX2JsYW5rIj5QaW5nLmIuSHVh bmdAYWxjYXRlbC1zYmVsbC5jb20uY248L2E+Cl0gPGJyPjxiPlNlbnQ6PC9iPiAyMDA3xOo31MIx MsjVIDE2OjU3PGJyPjxiPlRvOjwvYj4gWmhlbmcgSGV3ZW47IE1pY2hhbCBHaWVybWFzaW5za2k7 IDxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp IiBocmVmPSJtYWlsdG86cDJwc2lwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cDJwc2lwQGll dGYub3JnPC9hPjxicj48Yj5TdWJqZWN0Ogo8L2I+IFJFOiBbUDJQU0lQXSBkbyB3ZSBuZWVkIGEg Y2xpZW50IHByb3RvY29sPzxicj48L2ZvbnQ+PGJyPiZuYnNwOzwvZGl2Pgo8ZGl2PjwvZGl2Pgo8 ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4+PGZvbnQgY29sb3I9IiMwMDAwZmYiIHNp emU9IjIiPjxmb250IGZhY2U9IkFyaWFsIFVuaWNvZGUgTVMiPkkgaGF2ZSBuZXZlciBzYWlkIHRo YXQgUDJQU0lQIGlzIGVxdWFsIHRvIFNJUCwgUDJQU0lQIGlzIGp1c3QgYW4gb3ZlcmxheSBhcyBh biBhbHRlcm5hdGl2ZSB0byB0aGUgU0lQIGRpc2NvdmVyeSBwcm9jZXNzIG9mIFJGQyAzMjYzLCBQ MlBTSVAgb2ZmZXJzIGFuIGFsdGVybmF0aXZlIG1lY2hhbmlzbSBmb3IgZGV0ZXJtaW5pbmcgdGhl IGNvcnJlY3QgZGVzdGluYXRpb24gZm9yIFNJUCByZXF1ZXN0cy4gU0lQIGlzIHNlc3Npb24gbGF5 ZXIgcHJvdG9jb2wsIFAyUFNJUCBpcyB1bmRlciBTSVAuIG9mIGNhdXNlLCBpcyB5b3UgdXNlIGFu b3RoZXIgcHJvdG9jb2wsIFAyUFNJUCBtYXkgYmUgY2FsbGVkIGFub3RoZXIgbmFtZSwgc3VjaCBh cyBQMlBYWFguIFAKPC9mb250PjwvZm9udD48L3NwYW4+PHNwYW4+PGZvbnQgZmFjZT0iQXJpYWwg VW5pY29kZSBNUyIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPmVlcnMgaW4gUDJQU0lQIG92ZXJs YXkgYXJlIHJlc3BvbnNpYmxlJm5ic3A7bm90IGp1c3QgZm9yIGxvY2F0aW9uIChkb25lIGJ5IFAy UFNJUCBwcm90b2NvbCkuIFdoeSB3ZSBjYWxsZWQgUDJQU0lQIGFzICZxdW90O1AyUFNJUCZxdW90 Oz8mbmJzcDsgdGhpcyBuYW1lIG1lYW5zIHRoYXQgdGhlcmUgaXMgYSByZWxhdGlvbnNoaXAgYmV0 d2VlbiBQMlBTSVAgYW5kIFNJUCwgbWF5YmUgU0lQIG92ZXIgUDJQIG9yIFAyUCBvdmVyIFNJUC4g YnV0IGFueSB3YXksIFNJUCBzaG91bGQgYmUgdXNlZC4gdGhlbiBQZWVycyBpbiBQMlBTSVAgb3Zl cmxheSggbm90IFAyUFhYWCBvdmVybGF5KSBzaG91bGQgcmVjb2duaXplIFNJUCBtZXNzYWdlLiBP aywgeW91IGNhbiBzYXkgdGhhdCBhIHR1bm5lbCBwcm90b2NvbCBjb3VsZCBiZSB1c2VkIHRvIGRl bGl2ZXIgU0lQIHByb3RvY29sLCB0aGlzIGlzIGEgY2hvaWNlLCBidXQgbm90IGdvb2QgY2hvaWNl LiBpZiBhIHR1bm5lbCBwcm90b2NvbCBpcyB1c2VkLCB0aGVuIFNJUCBoYXMgbm90aGluZyB3aXRo IFAyUCBvdmVybGF5LCB0aGlzIHR1bm5lbCBwcm90b2NvbCBjb3VsZCBkZWxpdmVyIGFueSBwcm90 b2NvbHMgYmVzaWRlcyBTSVAsIHRoZW4gbmFtZSAmcXVvdDtQMlBTSVAmcXVvdDsgZG9lcyBub3Qg bWFrZSBzZW5zZS4KPC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRpdiBkaXI9Imx0ciIgYWxpZ249Imxl ZnQiPjxzcGFuPjxmb250IGZhY2U9IkFyaWFsIFVuaWNvZGUgTVMiIGNvbG9yPSIjMDAwMGZmIiBz aXplPSIyIj53aGVuIHBlZXJzIGluIFAyUFNJUCBvdmVybGF5IGRvIG5vdCByZWNvZ25pemUgU0lQ IG1lc3NhZ2UsIHRoZW4gbGV0IHRoZW0gb3V0IG9mIG92ZXJsYXkuPC9mb250Pjwvc3Bhbj48L2Rp dj48YnI+CjxkaXYgbGFuZz0iZW4tdXMiIGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+Cjxocj4KPGZv bnQgZmFjZT0iVGFob21hIiBzaXplPSIyIj48Yj5Gcm9tOjwvYj4gWmhlbmcgSGV3ZW4gW21haWx0 bzo8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSIgaHJlZj0ibWFpbHRvOmh3emhlbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh3emhl bmdAaHVhd2VpLmNvbTwvYT5dIDxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMTIsIDIw MDcgMjowMSBQTQo8YnI+PGI+VG86PC9iPiBIVUFORyBQaW5nIEI7ICYjMzk7TWljaGFsIEdpZXJt YXNpbnNraSYjMzk7OyA8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRv dyxldmVudCx0aGlzKSIgaHJlZj0ibWFpbHRvOnAycHNpcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnAycHNpcEBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbUDJQU0lQXSBk byB3ZSBuZWVkIGEgY2xpZW50IHByb3RvY29sPwo8YnI+PC9mb250Pjxicj4mbmJzcDs8L2Rpdj4K PGRpdj48L2Rpdj4KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFuPjxmb250IGZhY2U9 IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+SGksPC9mb250Pjwvc3Bhbj48L2Rpdj4K PGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFuPjxmb250IGZhY2U9IkFyaWFsIiBjb2xv cj0iIzAwMDBmZiIgc2l6ZT0iMiI+PC9mb250Pjwvc3Bhbj4mbmJzcDs8L2Rpdj4KPGRpdiBkaXI9 Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFuPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBm ZiIgc2l6ZT0iMiI+Jm5ic3A7IElmIEkgZG8gbm90IG1pc3VuZGVyc3RhbmQsIFAyUFNJUCBpcyBu b3QgZXF1YWwgdG8gU0lQLjwvZm9udD48L3NwYW4+PC9kaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWdu PSJsZWZ0Ij48c3Bhbj48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIi PiZuYnNwOyBFc3NlbnRpYWxseSBpbiBQMlBTSVAgb3ZlcmxheSwgUDJQU0lQIHBlZXJzIGhhdmUg bm90aGluZyB3aXRoIFNJUC4gV2h5Jm5ic3A7bXVzdCB3ZSBiaW5kIFNJUCZuYnNwO3RvIFAyUFNJ UCBwZWVycz8gPC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQi Pjxmb250IGZhY2U9IkFyaWFsIj48Zm9udCBzaXplPSIyIj48Zm9udCBjb2xvcj0iIzAwMDBmZiI+ PHNwYW4+Jm5ic3A7IDwvc3Bhbj48c3Bhbj48L3NwYW4+PC9mb250PjwvZm9udD48L2ZvbnQ+PC9k aXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3Bhbj48Zm9udCBmYWNlPSJBcmlhbCIg Y29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPiZuYnNwOyBIZXJlIGlzIHRoZSBkZXNjcmlwdGlvbiBh Ym91dCBQMlBTSVAgcGVlcnMgaW4gV0cgY2hhcnRlciwgRllJLjwvZm9udD48L3NwYW4+PC9kaXY+ CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3Bhbj48Zm9udCBmYWNlPSJBcmlhbCIgY29s b3I9IiMwMDAwZmYiIHNpemU9IjIiPiZuYnNwOyA8ZW0+JnF1b3Q7VGhlIHdvcmsgZm9jdXNlcyBv biBjb2xsZWN0aW9ucyBvZiBub2RlcyBjYWxsZWQgJnF1b3Q7UDJQU0lQIHBlZXJzJnF1b3Q7IGFu ZCAmcXVvdDtQMlBTSVAgY2xpZW50cyZxdW90Oy4gUDJQU0lQIHBlZXJzIG1hbmlmZXN0IGEgZGlz dHJpYnV0ZWQgbmFtZXNwYWNlIGluIHdoaWNoIG92ZXJsYXkgdXNlcnMgYXJlIGlkZW50aWZpZWQg YW5kIHByb3ZpZGVzIG1lY2hhbmlzbXMgZm9yIGxvY2F0aW5nIHVzZXJzIG9yIHJlc291cmNlcyB3 aXRoaW4gdGhlIFAyUFNJUCBvdmVybGF5LiBQMlBTSVAgY2xpZW50cyBkaWZmZXIgZnJvbSBQMlBT SVAgcGVlcnMgcHJpbWFyaWx5IGluIHRoYXQgdGhleSBkbyBub3Qgc3RvcmUgaW5mb3JtYXRpb24g aW4gdGhlIG92ZXJsYXksIGJ1dCBvbmx5IHVzZSBpdCB0byBsb2NhdGUgdXNlcnMgYW5kIHJlc291 cmNlcy4gUDJQU0lQIGNsaWVudHMgYW5kIHBlZXJzIHVzZSB0aGUgcmVzb2x1dGlvbiBzZXJ2aWNl cyBvZiB0aGUgcGVlcnMgYXMgYW4gYWx0ZXJuYXRpdmUgdG8gdGhlIFNJUCBkaXNjb3ZlcnkgcHJv Y2VzcyBvZiBSRkMgMzI2My4gSW4gdGhpcyB3YXksIFAyUFNJUCBvZmZlcnMgYW4gYWx0ZXJuYXRp dmUgbWVjaGFuaXNtIGZvciBkZXRlcm1pbmluZyB0aGUgY29ycmVjdCBkZXN0aW5hdGlvbiBmb3Ig U0lQIHJlcXVlc3RzLiBUaGUgd29ya2luZyBncm91cCYjMzk7cyBpbml0aWFsIGNoYXJ0ZXIgc2Nv cGUgd2lsbCBiZSB0byBwcm9kdWNlIHByb3RvY29scyB0byBlbmFibGUgdGhpcyBhbHRlcm5hdGUg bWVjaGFuaXNtIGZvciBSRkMgMzI2MyBmdW5jdGlvbmFsaXR5LiZxdW90Owo8L2VtPjwvZm9udD48 L3NwYW4+PC9kaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3Bhbj48Zm9udCBmYWNl PSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPjxlbT48L2VtPjwvZm9udD48L3NwYW4+ Jm5ic3A7PC9kaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3Bhbj48Zm9udCBmYWNl PSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPjxlbT4mbmJzcDsgPC9lbT5Ob3RoaW5n Jm5ic3A7c2F5cyB0aGF0IFAyUFNJUCBwZWVycyBtdXN0IHN1cHBvcnQgU0lQIG9yIGhhdmUgYW55 dGhpbmcgd2l0aCBTSVAuPC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRpdiBkaXI9Imx0ciIgYWxpZ249 ImxlZnQiPjxzcGFuPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+ Jm5ic3A7IEZyb20gdGhlIGNoYXJ0ZXIsIGZ1bmN0aW9uYWxpdHkgb2YgUDJQU0lQIHBlZXJzJm5i c3A7aXMgc28gY2xlYXIgYW5kIHNpbXBsZSwgd2h5IGRvIHdlIG1ha2UgaXQgY29tcGxpY2F0ZWQ/ IEkgdGhpbmsgd2UgY2FuIGRvIGl0IHNpbXBsZXIsJm5ic3A7U0lQJm5ic3A7aXMgU0lQLCZuYnNw O1AyUFNJUCBwZWVyIGlzJm5ic3A7UDJQU0lQIHBlZXIsIGxldCB0aGVtIGJlLgo8L2ZvbnQ+PC9z cGFuPjwvZGl2Pgo8ZGl2Pjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0i MiI+PC9mb250PiZuYnNwOzwvZGl2Pgo8cD48L3A+CjxwPjwvcD48Zm9udCBmYWNlPSJBcmlhbCIg Y29sb3I9ImJsYWNrIiBzaXplPSIyIj5aaGVuZyBIZXdlbjxicj48L2ZvbnQ+PGZvbnQgZmFjZT0i QXJpYWwiIGNvbG9yPSJncmF5IiBzaXplPSIyIj5IVUFXRUkgVEVDSE5PTE9HSUVTIENPLixMVEQu IDwvZm9udD48aW1nIGFsdD0iaHVhd2VpX2xvZ28iIGhzcGFjZT0iMCIgc3JjPSJjaWQ6OTUzMjkw NDE0QDEyMDcyMDA3LTM1N0IiIGFsaWduPSJsZWZ0Ij4KIAo8cD48L3A+PGJyPjxmb250IGZhY2U9 IkFyaWFsIiBjb2xvcj0iZ3JheSIgc2l6ZT0iMSI+SHVpaG9uZyBNYW5zaW9uPGJyPk5vLjkxIEJh aXhpYSBSb2FkPGJyPk5hbkppbmcsIFAuUi5DaGluYTxicj5UZWw6IDAyNS04NDU2NTQ2Nzxicj5G YXg6IDAyNS04NDU2NTM1NDxicj5Nb2JpbGU6IDEzNjExNTA4MjY0PGJyPkUtbWFpbDogPGEgb25j bGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9 Im1haWx0bzpod3poZW5nQGh1YXdlaWMub20iIHRhcmdldD0iX2JsYW5rIj4KaHd6aGVuZ0BodWF3 ZWljLm9tPC9hPjxicj48YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRv dyxldmVudCx0aGlzKSIgaHJlZj0iaHR0cDovL3d3dy5odWF3ZWkuY29tLyIgdGFyZ2V0PSJfYmxh bmsiPnd3dy5odWF3ZWkuY29tPC9hPjxicj48L2ZvbnQ+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9y PSJncmF5IiBzaXplPSIxIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCjxicj5UaGlzIGUtbWFpbCBhbmQg aXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gSFVB V0VJLCB3aGljaCA8YnI+aXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkg d2hvc2UgYWRkcmVzcyBpcyBsaXN0ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIDxicj5pbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1p dGVkIHRvLCB0b3RhbCBvciBwYXJ0aWFsIAo8YnI+ZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBv ciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIDxicj5y ZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSA8YnI+cGhvbmUgb3IgZW1haWwgaW1t ZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCEKPGJyPjwvZm9udD4KPGRpdj4mbmJzcDs8L2Rpdj48YnI+ CjxkaXYgbGFuZz0iZW4tdXMiIGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+Cjxocj4KPGZvbnQgZmFj ZT0iVGFob21hIiBzaXplPSIyIj48Yj5Gcm9tOjwvYj4gSFVBTkcgUGluZyBCIFttYWlsdG86PGEg b25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhy ZWY9Im1haWx0bzpQaW5nLmIuSHVhbmdAYWxjYXRlbC1zYmVsbC5jb20uY24iIHRhcmdldD0iX2Js YW5rIj5QaW5nLmIuSHVhbmdAYWxjYXRlbC1zYmVsbC5jb20uY248L2E+Cl0gPGJyPjxiPlNlbnQ6 PC9iPiAyMDA3xOo31MIxMsjVIDEwOjIyPGJyPjxiPlRvOjwvYj4gWmhlbmcgSGV3ZW47IE1pY2hh bCBHaWVybWFzaW5za2k7IDxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86cDJwc2lwQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+cDJwc2lwQGlldGYub3JnPC9hPjxicj48Yj5TdWJqZWN0Ogo8L2I+IFJFOiBbUDJQU0lQ XSBkbyB3ZSBuZWVkIGEgY2xpZW50IHByb3RvY29sPzxicj48L2ZvbnQ+PGJyPiZuYnNwOzwvZGl2 Pgo8ZGl2PjwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4+PGZvbnQgZmFj ZT0iy87M5SIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPkhpIGFsbDwvZm9udD48L3NwYW4+PC9k aXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3Bhbj48Zm9udCBmYWNlPSLLzszlIiBj b2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFAyUCBpcyBncmVhdCB0 b3BpYywgYnV0IFAyUFNJUCBpcyB0aGUgc3Vic2V0IG9yIGNlcnRhaW4gaW5zdGFuY2Ugb2YgUDJQ LiB3aGVuIHdlIGRpc2N1c3MgUDJQU0lQLCB3ZSBzaGFsbCBub3QgaW52b2x2ZSBhbGwgbm9kZXMg d2hpY2ggY291bGQgYmUgcGVlcnMgaW4gUDJQU0lQIG92ZXJsYXkuIHBlZXJzIGluIFAyUFNJUCBv dmVybGF5IGFyZSBub3QgZXF1YWwgdG8gcGVlcnMgaW4gUDJQIG92ZXJsYXkuIHdoZW4gd2UgZGlz Y3VzcyBJTVMsIGFsdGhvdWdoIGxlZ2FjeSBlcXVpcG1lbnRzIGRvZXMgbm90IHN1cHBvcnQgU0lQ LCBidXQgc29tZSBBR1dzIGRvIHRyYW5zbGF0aW9uIG9yIGFnZW50IGZvciB0aG9zZSBlcXVpcG1l bnRzLiB0aGVuLCB3aGVuIHdlIGRpc2N1c3MgUDJQU0lQLCBzaGFsbCB3ZSBpbnZvbHZlIGFsbCBw ZWVycyB3aG8ga25vdyBTSVAgb3Igbm90IGluIFAyUFNJUCBvdmVybGF5PyBJIHRoaW5rIFAyUCBp cyBub3QgZXF1YWwgdG8gUDJQU0lQLCBhbmQgdmljZSB2ZXJzYS4gYW5kIEkgdGhpbmsgdGhhdCBQ ZWVycyBpbiBQMlBTSVAgb3ZlcmxheSBzaG91bGQgaGF2ZSBzb21lIGNvbW1vbiBiYXNlIGZ1bmN0 aW9uYWxpdGlzIHN1Y2ggYXMgU0lQIHJlY29nbml0aW9uLiBJIHRoaW5rIHdlIHNoYWxsIG1ha2Ug UDJQU0lQIG1vcmUgc2ltcGxlIGJ1dCBub3QgbW9yZSBjb21wbGV4Lgo8L2ZvbnQ+PC9zcGFuPjxi cj4mbmJzcDs8L2Rpdj4KPGRpdiBsYW5nPSJlbi11cyIgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij4K PGhyPgo8Zm9udCBmYWNlPSJUYWhvbWEiIHNpemU9IjIiPjxiPkZyb206PC9iPiBaaGVuZyBIZXdl biBbbWFpbHRvOjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2 ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86aHd6aGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFu ayI+aHd6aGVuZ0BodWF3ZWkuY29tPC9hPl0gPGJyPjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVs eSAxMiwgMjAwNyA5OjM0IEFNCjxicj48Yj5Ubzo8L2I+ICYjMzk7TWljaGFsIEdpZXJtYXNpbnNr aSYjMzk7OyA8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVu dCx0aGlzKSIgaHJlZj0ibWFpbHRvOnAycHNpcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnAy cHNpcEBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBbUDJQU0lQXSBkbyB3ZSBu ZWVkIGEgY2xpZW50IHByb3RvY29sPwo8YnI+PC9mb250Pjxicj4mbmJzcDs8L2Rpdj4KPGRpdj48 L2Rpdj4KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xv cj0iIzAwMDBmZiIgc2l6ZT0iMiI+PHNwYW4+SGksPC9zcGFuPjwvZm9udD48L2Rpdj4KPGRpdiBk aXI9Imx0ciIgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIg c2l6ZT0iMiI+PHNwYW4+PC9zcGFuPjwvZm9udD4mbmJzcDs8L2Rpdj4KPGRpdiBkaXI9Imx0ciIg YWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+ PHNwYW4+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBsZWFzZSBsZXQgbWUgZGVzY3JpYmUgdGhlIGNhc2Ug aW4gZGV0YWlsLjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgSW4gdGhlIGNhc2UsIGFsbCBjbGllbnRz IHN1cHBvcnQgU0lQLCBidXQgc29tZSBwZWVycyBpbiB0aGUgb3ZlcmxheSBuZXR3b3JrIGRvIG5v dCBzdXBwb3J0IFNJUCBhbmQgc29tZSBzdXBwb3J0IFNJUC4gRm9yIHRob3NlIHBlZXJzIHdoaWNo IGRvIG5vdCBzdXBwb3J0IFNJUCwgc3VjaCBhcyBzb21lIFBDcywgdGhleSBjYW4gcHJvdmlkZSBh bGwgcmVxdWlyZWQgREhUIHNlcnZpY2VzLCBidXQgdGhlcmUgaXMgb25seSBhIHBpdHkgdGhhdCB0 aGV5IGNhbiBub3QgcmVjb2duaXplIGFueSBTSVAgbWVzc2FnZSwgbWF5YmUgdGhleSB0aGluayB0 aGF0IHRoZSBjYXBhYmlsaXR5IGlzIHVubmVjZXNzYXJ5LiBJbiB0aGlzIGNhc2UsIHNvbWUgY2xp ZW50IHByb3RvY29sIGlzIGRlc2lyYWJsZS4gQ2VydGFpbmx5IHRoaXMgcHJvdG9jb2wgbWF5IGJl IHRoZSBzdWJzZXQgb2YgZ2VuZXJhbCBQZWVyIFByb3RvY29sIGlmIHdlIHJlZ2FyZCB0aG9zZSBj bGllbnRzIGFzIExhbWUgUGVlcnMgYW5kIHJlZ2FyZCB0aG9zZSBwZWVycyBhcyBQdXJlIFBlZXJz IHdobyBvbmx5IHByb3ZpZGUgcmVxdWlyZWQgREhUIHNlcnZpY2VzLgo8YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IElNSE8sIHRoaXMgY2FzZSBkb2VzIG5vdCBjYXJlIHRob3NlIGNsaWVudHMgbm90IHN1 cHBvcnRpbmcgU0lQLjwvc3Bhbj48L2ZvbnQ+PC9kaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJs ZWZ0Ij48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPjxzcGFuPjwv c3Bhbj48L2ZvbnQ+Jm5ic3A7PC9kaXY+CjxkaXY+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSJi bGFjayIgc2l6ZT0iMiI+WmhlbmcgSGV3ZW48YnI+PC9mb250Pjxmb250IGZhY2U9IkFyaWFsIiBj b2xvcj0iZ3JheSIgc2l6ZT0iMiI+SFVBV0VJIFRFQ0hOT0xPR0lFUyBDTy4sTFRELiA8L2ZvbnQ+ PGltZyBhbHQ9Imh1YXdlaV9sb2dvIiBoc3BhY2U9IjAiIHNyYz0iY2lkOjk1MzI5MDQxNEAxMjA3 MjAwNy0zNTgyIiBhbGlnbj0ibGVmdCI+CiA8L2Rpdj4KPHA+PC9wPjxicj48Zm9udCBmYWNlPSJB cmlhbCIgY29sb3I9ImdyYXkiIHNpemU9IjEiPkh1aWhvbmcgTWFuc2lvbjxicj5Oby45MSBCYWl4 aWEgUm9hZDxicj5OYW5KaW5nLCBQLlIuQ2hpbmE8YnI+VGVsOiAwMjUtODQ1NjU0Njc8YnI+RmF4 OiAwMjUtODQ1NjUzNTQ8YnI+TW9iaWxlOiAxMzYxMTUwODI2NDxicj5FLW1haWw6IDxhIG9uY2xp Y2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJt YWlsdG86aHd6aGVuZ0BodWF3ZWljLm9tIiB0YXJnZXQ9Il9ibGFuayI+Cmh3emhlbmdAaHVhd2Vp Yy5vbTwvYT48YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3cs ZXZlbnQsdGhpcykiIGhyZWY9Imh0dHA6Ly93d3cuaHVhd2VpLmNvbS8iIHRhcmdldD0iX2JsYW5r Ij53d3cuaHVhd2VpLmNvbTwvYT48YnI+PC9mb250Pjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0i Z3JheSIgc2l6ZT0iMSI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo8YnI+VGhpcyBlLW1haWwgYW5kIGl0 cyBhdHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdF SSwgd2hpY2ggPGJyPmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdo b3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSA8YnI+aW5mb3JtYXRp b24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRl ZCB0bywgdG90YWwgb3IgcGFydGlhbCAKPGJyPmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3Ig ZGlzc2VtaW5hdGlvbikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCA8YnI+cmVj aXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkgPGJyPnBob25lIG9yIGVtYWlsIGltbWVk aWF0ZWx5IGFuZCBkZWxldGUgaXQhCjxicj48L2ZvbnQ+CjxkaXY+Jm5ic3A7PC9kaXY+PGJyPgo8 ZGl2IGxhbmc9ImVuLXVzIiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPgo8aHI+Cjxmb250IGZhY2U9 IlRhaG9tYSIgc2l6ZT0iMiI+PGI+RnJvbTo8L2I+IE1pY2hhbCBHaWVybWFzaW5za2kgW21haWx0 bzo8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlz KSIgaHJlZj0ibWFpbHRvOm1pY2hhbC5naWVybWFzaW5za2lAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+bWljaGFsLmdpZXJtYXNpbnNraUBnbWFpbC5jb208L2E+Cl0gPGJyPjxiPlNlbnQ6PC9i PiAyMDA3xOo31MIxMsjVIDU6MzE8YnI+PGI+VG86PC9iPiBaaGVuZyBIZXdlbjsgPGEgb25jbGlj az0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1h aWx0bzpwMnBzaXBAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5wMnBzaXBAaWV0Zi5vcmc8L2E+ PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW1AyUFNJUF0gZG8gd2UgbmVlZCBhIGNsaWVudCBwcm90 b2NvbD8KPGJyPjwvZm9udD48YnI+Jm5ic3A7PC9kaXY+CjxkaXY+PC9kaXY+CjxkaXY+SGkhPC9k aXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+V2VsbCwgaW4gbXkgb3BwaW5pb24gaXQgaXMgbm90 IGEgZ29vZCBmb3IgY3JlYXRpbmcgYSBuZXcgcHJvdG9jb2wuIElmIGEgY2xpZW50IGFwcGxpY2F0 aW9uIGlzIG5vdCBhYmxlIHRvIHVzZSBTSVAgcHJvdG9jb2wgdGhhdCBpcyB3ZWxsIGtub3duIGZv ciB5ZWFycyBpdCBvYnZpb3VzbHkgd2lsbCBub3QgYmUgYWJsZSB0byB1c2UgYSBuZXcgb25lIHRo YXQgd2lsbCBiZSBkZXNpZ25lZCBlc3BlY2lhbGx5IGZvciBjb29wZXJhdGlvbiB3aXRoIHAycHNp cCBvdmVybGF5LiAKPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+SWYgd2UgZm9sbG93IHRo aXMgdW5kZXJzdGFuZGluZyB3ZSBjYW4gYXNzdW1lIHRoYXQgdGhlIGJldHRlciB0aGluZyBpcyB0 byB1c2UgU0lQIG9uIHRoaXMgaW50ZXJmYWNlIChiZXR3ZWVuIGNsaWVudCBvdXRzdGFuZGluZyB0 aGUgb3ZlcmxheSBhbmQgdGhlIHBlZXIgaW4gdGhlIG92ZXJsYXkpLiBUaGUgb25seSBpc3N1ZSBp cyB0byBjcmVhdGUgYSBwcm94eS1saWtlIHBlZXIgdGhhdCB3aWxsIGJlIGFibGUgdG8gaGVscCBj bGllbnQgdG8gZ2V0IGJlbmVmaXRzIG9mIHRoZSBvdmVybGF5LiAKPC9kaXY+CjxkaXY+Jm5ic3A7 PC9kaXY+CjxkaXY+V2hhdCB3ZSBzaG91bGQgY29uc2lkZXIgaXMgaG93IHRvIGZpbHRlciB0aGUg dHJhZmZpYyB1bndhbnRlZCBieSByZWd1bGFyIGNsaWVudCB0aGF0IGRvIG5vdCB3YW50IHRvIHRh a2UgcGFydCBpbiB0aGUgcm91dGluZyBkZWNpc2lvbi48L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4K PGRpdj5iZXN0IHJlZ2FyZHM8L2Rpdj4KPGRpdj5NaWNoYWwgR2llcm1hc2luc2tpPC9kaXY+Cjxk aXY+PGJyPjxicj4mbmJzcDs8L2Rpdj4KPGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPjIw MDcvNy8xMSwgWmhlbmcgSGV3ZW4gJmx0OzxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4 dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86aHd6aGVuZ0BodWF3ZWkuY29t IiB0YXJnZXQ9Il9ibGFuayI+aHd6aGVuZ0BodWF3ZWkuY29tPC9hPiZndDs6PC9zcGFuPiAKPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iUEFERElORy1MRUZUOiAxZXg7IE1B UkdJTjogMHB4IDBweCAwcHggMC44ZXg7IEJPUkRFUi1MRUZUOiAjY2NjIDFweCBzb2xpZCI+SGks PGJyPjxicj4mbmJzcDsmbmJzcDsgQSBjbGllbnQgcHJvdG9jb2wgd2lsbCBiZSB1c2VmdWwgd2hl biBzb21lIHBlZXJzIGluIHRoZSBvdmVybGF5IGRvIG5vdCBzdXBwb3J0IFNJUCwgdGhvc2UgcGVl cnMgYXJlIG9ubHkgcmVzcG9uc2libGUgdG8gCjxicj5wcm92aWRlIGRpc3RyaWJ1dGVkIHN0b3Jh Z2UsIGxvY2F0aW9uIGFuZCB0cmFuc3BvcnQgc2VydmljZXMgZm9yIGluZm9ybWF0aW9uIGFib3V0 IFNJUCwgYnV0IHRob3NlIHBlZXJzIGRvIG5vdCByZWNvZ25pemUgYW55PGJyPlNJUCBtZXNzYWdl cyBhdCBhbGwuPGJyPiZuYnNwOyZuYnNwO0luIHRoaXMgY2FzZSwgaG93IHRvIG1haW50YWluIHRo ZSByZWxhdGlvbiBiZXR3ZWVuIGNsaWVudHMgKFVBKSBhbmQgdGhlIGhvc3RpbmcgcGVlcihzKT8g T25lIGNsaWVudCBwcm90b2NvbCBpcyBkZXNpcmFibGUgCjxicj5hdCB0aGlzIHRpbWUuPGJyPjxi cj48YnI+WmhlbmcgSGV3ZW48YnI+SFVBV0VJIFRFQ0hOT0xPR0lFUyBDTy4sTFRELiZuYnNwOyZu YnNwO2h1YXdlaV9sb2dvPGJyPjxicj48YnI+SHVpaG9uZyBNYW5zaW9uPGJyPk5vLjkxIEJhaXhp YSBSb2FkPGJyPk5hbkppbmcsIFAuUi5DaGluYTxicj5UZWw6IDAyNS04NDU2NTQ2Nzxicj5GYXg6 IDAyNS04NDU2NTM1NDxicj5Nb2JpbGU6IDEzNjExNTA4MjY0PGJyPgpFLW1haWw6IDxhIG9uY2xp Y2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJt YWlsdG86aHd6aGVuZ0BodWF3ZWljLm9tIiB0YXJnZXQ9Il9ibGFuayI+aHd6aGVuZ0BodWF3ZWlj Lm9tPC9hPjxicj48YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxl dmVudCx0aGlzKSIgaHJlZj0iaHR0cDovL3d3dy5odWF3ZWkuY29tLyIgdGFyZ2V0PSJfYmxhbmsi Pgp3d3cuaHVhd2VpLmNvbTwvYT48YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+LS0tLS0tLS0tPGJyPlRoaXMg ZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRp b24gZnJvbSBIVUFXRUksIHdoaWNoCjxicj5pcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29u IG9yIGVudGl0eSB3aG9zZSBhZGRyZXNzIGlzIGxpc3RlZCBhYm92ZS4gQW55IHVzZSBvZiB0aGU8 YnI+aW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1 dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlhbCA8YnI+ZGlzY2xvc3VyZSwgcmVwcm9k dWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVu ZGVkCjxicj5yZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBl LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieTxicj5waG9uZSBvciBl bWFpbCBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGl0ISA8YnI+PGJyPjxicj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj5Gcm9tOiBIZW5yeSBTaW5ucmVpY2ggW21haWx0bzo8YSBvbmNsaWNr PSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJlZj0ibWFp bHRvOmhzaW5ucmVpQGFkb2JlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPgpoc2lubnJlaUBhZG9iZS5j b208L2E+XTxicj5TZW50OiAyMDA3PzY/MjY/IDE6Mzk8YnI+VG86IERlYW4gV2lsbGlzOyBEYXZp ZCBBLiBCcnlhbjxicj5DYzogQXZzaGFsb20gSG91cmk7IFAyUFNJUCBNYWlsaW5nIExpc3Q7IFBo aWxpcCBNYXR0aGV3cyA8YnI+U3ViamVjdDogW1AyUFNJUF0gZG8gd2UgbmVlZCBhIGNsaWVudCBw cm90b2NvbD88YnI+PGJyPkZvbGtzLDxicj48YnI+R2l2ZW4gdGhlIGxlbmd0aCBvZiB0aGUgZGlz Y3Vzc2lvbiBvbiAmcXVvdDtkbyB3ZSBuZWVkIGEgY2xpZW50IHByb3RvY29sPyZxdW90Owo8YnI+ bGV0IG1lIHJlcGVhdCB0aGUgc2ltcGxlIGltcGVyYXRpdmVzIGZvciB0aGUgY2xpZW50Ojxicj48 YnI+LSBMaW1pdGVkIGJhdHRlcnkgaW4gbW9iaWxlIGRldmljZXMsIGFuZCA8YnI+PGJyPi0gT3Ro ZXIgdXNlcyBiZXNpZGVzIFNJUC4gQnVzaW5lc3MgcGxhbm5pbmcgZm9sa3MgbWF5IG5vdCBjYXJl IGFib3V0IHRoZSBXRyBjaGFydGVyLCBidXQgYWJvdXQgdGhlIHJldHVybiBvbiB0aGUgaW52ZXN0 bWVudC4KPGJyPjxicj5UaGFua3MsIEhlbnJ5PGJyPjxicj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj5Gcm9tOiBEZWFuIFdpbGxpcyBbbWFpbHRvOjxhIG9uY2xpY2s9InJldHVybiB0b3Au anMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86ZGVhbi53aWxs aXNAc29mdGFybW9yLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPiBkZWFuLndpbGxpc0Bzb2Z0YXJtb3Iu Y29tCjwvYT5dPGJyPlNlbnQ6IFRodXJzZGF5LCBKdW5lIDE0LCAyMDA3IDExOjIzIFBNPGJyPlRv OiBEYXZpZCBBLiBCcnlhbjxicj5DYzogQXZzaGFsb20gSG91cmk7IFAyUFNJUCBNYWlsaW5nIExp c3Q7IFBoaWxpcCBNYXR0aGV3czxicj5TdWJqZWN0OiBSZTogW1AyUFNJUF0gQ29uY2VwdHMgZG9j dW1lbnQ6IHByb3Bvc2FsIGZvciBhY3RpdmUvcGFzc2l2ZSBwZWVydGVybWlub2xvZ3kgPGJyPgo8 YnI+RGF2aWQgQS4gQnJ5YW4gd3JvdGU6PGJyPiZndDsgSWYgSSB1bmRlcnN0YW5kIHRoaXMgcmln aHQsIG5vdCBzdXJlIEkgbGlrZSBpdC4gRG8gdGhlc2U8YnI+JnF1b3Q7bm9uLWNvbnRyaWJ1dGlu Zzxicj4mZ3Q7IHBlZXImcXVvdDsgKEkgKmRvKiBsaWtlIGNvbnRyaWJ1dGluZyBiZXR0ZXIgdGhh biBhY3RpdmUvcGFzc2l2ZSkgZW50aXRpZXM8YnI+aGF2ZSBhPGJyPiZndDsgUGVlci1JRD8gSW4g b3RoZXJ3b3JkcywgYXJlIHRoZXkgcGFydCBvZiB0aGUgb3ZlcmxheSBhdCBhbGw/IElmIHNvLCAK PGJyPmZvcjxicj4mZ3Q7IG1vc3Q8YnI+Jmd0OyBESFRzLCBob3cgZG8gd2UgYWxsb3cgeW91IHRv IGJlIGluIHRoZSBvdmVybGF5IGFuZCBub3Qgc3RvcmUgcmVzb3VyY2VzPGJyPihub3Q8YnI+Jmd0 OyB0eXBpY2FsIGZvciBtb3N0IGN1cnJlbnQgREhUIGFsZ29yaXRobXMpPGJyPjxicj5XZWxsLCB0 aGF0IGNlcnRhaW5seSBkZXBlbmRzIG9uIHRoZSBESFQgYWxnb3JpdGhtIGludm9sdmVkLiBJdCBj ZXJ0YWlubHkgc2VlbXMgdGhhdCBhIHBlZXIgdGhhdCBtb3ZlcyBiZXR3ZWVuIGNvbnRyaWJ1dGlu ZyAKPGJyPmFuZCBub24tY29udHJpYnV0aW5nIG1pZ2h0IEhBVkUgYSBwZWVyIElELCBidXQgd2hl dGhlciBpdCBjaG9vc2VzIHRvIGluc2VydCBpdHNlbGYgaW50byB0aGUgREhUICZxdW90O3JpZ2h0 IG5vdyZxdW90OyBtaWdodCBkZXRlcm1pbmU8YnI+d2hldGhlciBpdCBpcyBjb250cmlidXRpbmcg JnF1b3Q7cmlnaHQgbm93JnF1b3Q7PGJyPm9yIG5vdC48YnI+PGJyPiZndDsgTXkgY29uY2VybiBh bGwgYWxvbmcgaGFzIGJlZW4gdGhhdCBJIGRvbiYjMzk7dCB1bmRlcnN0YW5kIHdoeSBzb21ldGhp bmcgaXMgCjxicj4mZ3Q7IGEgcGVlciBpZiBpdCBpc24mIzM5O3QgZG9pbmcgYW55dGhpbmcgb3Ro ZXIgdGhhbiB0YWxraW5nIHRvIHNvbWVvbmUgYW5kPGJyPiZndDsgbWFraW5nIHJlcXVlc3RzLCBo ZW5jZSB3aHkgSSBzdXBwb3J0ZWQgY2xpZW50IGluIHRoZSBmaXJzdCBwbGFjZS48YnI+Jmd0OyZu YnNwOyZuYnNwO0kgZmFpbCB0byBzZWUgaG93IHNvbWV0aGluZyB0aGF0IGlzbiYjMzk7dCBjb250 cmlidXRpbmcgYW55dGhpbmcsIGFuZCAKPGJyPiZndDsgaW5zdGVhZCB0YWxrcyB0byBhIHBlZXIg dG8gZ2V0IHJlc291cmNlcywgaXMgaW4gYW55IHdheSBhIHBlZXIuIEl0PGJyPiZndDsgc2VlbXMg Y29tcGxldGVseSBub3QgaW4ga2VlcGluZyB3aXRoIHRoZSBpZGVhIG9mIFAyUC4gSSBhbHNvIHdv cnJ5IGl0PGJyPiZndDsgaXMgbGlrZWx5IHRvIGJlIHZlcnkgY29uZnVzaW5nIHNpbmNlIHdlJiMz OTt2ZSBiZWVuIHVzaW5nIHRoZSBvdGhlciAKPGJyPiZndDsgdGVybWlub2xvZ3kgZm9yIG92ZXIg YSB5ZWFyIG5vdy4gSnVzdCBsb29rcyBsaWtlIGEgc291Y2Ugb2YgY29uZnVzaW9uLjxicj48YnI+ QSBub2RlIG1pZ2h0IHNvbWV0aW1lcyBoYXZlIGEgaGlnaC1iYW5kd2lkdGggY29ubmVjdGlvbiBh bmQgd2lzaCB0byBjb250cmlidXRlIHJlc291cmNlcywgYW5kIHNvbWV0aW1lcyBub3QgaGF2ZSBh PGJyPmhpZ2gtYmFuZHdpZHRoIGNvbm5lY3Rpb24gYW5kIHRoZXJlZm9yZSBub3Qgd2lzaCB0byBv ZmZlciByZXNvdXJjZXMuIERvZXMgdGhpcyBtb2RhbGl0eSBtYWtlIGl0IHR3byBkaWZmZXJlbnQg bm9kZXM/IAo8YnI+PGJyPiZndDsgSWYgd2UgZG8gZ28gdGhpcyB3YXksIHRoZXJlIGlzIG9uZSBz dWJ0bGUgcG9pbnQuIElmIEkgam9pbiB0aGUgb3ZlcmxheTxicj5idXQ8YnI+Jmd0OyBkb24mIzM5 O3QgaGFwcGVuIHRvIG9mZmVyIGFueSBzZXJ2aWNlcyAob3RoZXIgdGhhbiBtYXliZTxicj5zdG9y YWdlLi4uZGVwZW5kaW5nIG9uPGJyPiZndDsgaG93IHdlIGRlZmluaWUgaXQsIHRoYXQgbWlnaHQg b3IgbWlnaHQgbm90IGJlIG1hbmRhdG9yeSksIHdvdWxkIEkgYmUgCjxicj4mZ3Q7IGNvbnRyaWJ1 dGluZz8gSWYgam9pbmluZyB0aGUgb3ZlcmxheSAoaW4gdGhlIHNlbnNlIHRoYXQgd2UgaGF2ZSBh PGJyPlBlZXJJRDxicj4mZ3Q7IGFuZDxicj4mZ3Q7IHdlIHJvdXRlIHRyYWZmaWMpIGRvZXNuJiMz OTt0IHJlcXVpcmUgbWUgdG8gc3RvcmUsIEkgY291bGQgb2ZmZXIgbm88YnI+c2VydmljZXM8YnI+ PGJyPlRoYXQmIzM5O3MgJnF1b3Q7b2ZmZXIgbm8gb3RoZXIgc2VydmljZXMmcXVvdDssIHNpbmNl IHJvdXRpbmcgaXMgaXRzZWxmIGEgc2VydmljZS4gCjxicj48YnI+Jmd0OyBhbmQ8YnI+Jmd0OyBz dGlsbCBiZSBhIHBlZXIuIEhvdyBkbyB3ZSBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoaXMgY2FzZSBh bmQgYTxicj4mZ3Q7ICZxdW90O25vbi1jb250cmlidXRpbmcgcGVlciZxdW90OyB3aG8gaXNuJiMz OTt0IGV2ZW4gcGFydCBvZiB0aGUgb3ZlcmxheSAoaS5lLiwgbm88YnI+Jmd0OyBQZWVyLUlEKTxi cj48YnI+SSB0aGluayB0aGVyZSYjMzk7cyBhIHJhbmdlIG9mICZxdW90O2NvbnRyaWJ1dGluZyZx dW90OyBpbiBwbGF5LiBGb3IgbW9zdCBESFQgbW9kZWxzLCBhIG1pbmltYWxseSBjb250cmlidXRp bmcgbm9kZSB3aWxsIHJvdXRlIGEgcmVxdWVzdCAKPGJyPml0IHJlY2VpdmVzLiBJdCBtaWdodCBh c2sgbmljZWx5IChwZXJoYXBzIGEgcS12YWx1ZSBtZWNoYW5pc20pIHRvIG5vdCBoYXZlIHRvIHJv dXRlIHJlcXVlc3RzLCBidXQgd291bGQgcHJvYmFibHk8YnI+bWF0aGVtYXRpY2FsbHkgc3RpbGwg aGF2ZSB0byByb3V0ZSBzb21ldGhpbmcgaXQgZ2V0cy48YnI+PGJyPkkgdGhpbmsgd2UgZGlzdGlu Z3Vpc2ggYmFzZWQgb24gdGhlIHNlcnZpY2UgYWR2ZXJ0aXNlbWVudHMgZnJvbSB0aGUgcGVlci4g Cjxicj48YnI+Jmd0OyBJZiB3ZSBhcmUgc28gb3Bwb3NlZCB0byBjbGllbnQgZm9yIGNvbmZ1c2lv biB3aXRoIFNJUCBVQXMsIGxldHMgcGljayBhPGJyPm5ldzxicj4mZ3Q7IG5hbWUsIGJ1dCB3aHkg c29tZSBmbGF2b3Igb2YgcGVlciB3aGVuIGl0IGRvZXMgbm90aGluZyByZW1vdGVseSBwZWVyPGJy Pmxpa2U/PGJyPjxicj5CZWNhdXNlIGluIDE1IG1pbnV0ZXMgaXQgbWlnaHQgcm9hbSBvbnRvIGEg V2lGaSBuZXQgYW5kIHRoZXJlZm9yZSBjaGFuZ2UgaXQgc2VydmljZSBvZmZlcmluZy4gCjxicj48 YnI+LS08YnI+RGVhbjxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+UDJQU0lQIG1haWxpbmcgbGlzdDxicj48YSBvbmNsaWNrPSJyZXR1cm4g dG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJlZj0ibWFpbHRvOlAyUFNJ UEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlAyUFNJUEBpZXRmLm9yZzwvYT4KPGJyPjxhIG9u Y2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVm PSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXAiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXAgPC9h Pjxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K PGJyPlAyUFNJUCBtYWlsaW5nIGxpc3Q8YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVu RXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpQMlBTSVBAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5QMlBTSVBAaWV0Zi5vcmc8L2E+PGJyPjxhIG9uY2xpY2s9InJldHVy biB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXAiIHRhcmdldD0iX2JsYW5rIj4KaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwIDwvYT48YnI+PGJyPjxi cj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPlAyUFNJUCBtYWlsaW5nIGxpc3Q8YnI+PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVu RXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpQMlBTSVBAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj4KUDJQU0lQQGlldGYub3JnPC9hPjxicj48YSBvbmNsaWNrPSJyZXR1 cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJlZj0iaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJwc2lwIDwvYT48YnI+PC9ibG9j a3F1b3RlPjwvZGl2Pgo8YnI+Jm5ic3A7PC9kaXY+PGJyPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPlAyUFNJUCBtYWlsaW5nIGxpc3Q8YnI+PGEgb25j bGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9 Im1haWx0bzpQMlBTSVBAaWV0Zi5vcmciPlAyUFNJUEBpZXRmLm9yZzwvYT48YnI+PGEgb25jbGlj az0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Imh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcCIgdGFyZ2V0PSJfYmxh bmsiPgpodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXA8L2E+PGJy Pjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPgo= ------=_Part_20758_8641315.1184290350123-- ------=_Part_20759_11002465.1184290350123 Content-Type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-Transfer-Encoding: base64 Content-ID: <953290414@12072007-357B> Content-Location: outlook_huawei_logo_en.jpg X-Attachment-Id: 0.0.1 Content-Disposition: inline; filename="outlook_huawei_logo_en.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------=_Part_20759_11002465.1184290350123 Content-Type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-Transfer-Encoding: base64 Content-ID: <953290414@12072007-3582> Content-Location: outlook_huawei_logo_en-1.jpg X-Attachment-Id: 0.0.2 Content-Disposition: inline; filename="outlook_huawei_logo_en.jpg" /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------=_Part_20759_11002465.1184290350123-- --===============1688374643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1688374643==-- From p2psip-bounces@ietf.org Thu Jul 12 21:38:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9A7L-0001mu-Sj; Thu, 12 Jul 2007 21:38:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9A7K-0001mo-VG for p2psip@ietf.org; Thu, 12 Jul 2007 21:38:46 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9A7D-0004H9-Dm for p2psip@ietf.org; Thu, 12 Jul 2007 21:38:46 -0400 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 <0JL300AZ4GIW9C@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 13 Jul 2007 09:37:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL300CY2GIRLE@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 13 Jul 2007 09:37:44 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL300AR7GIMOF@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 13 Jul 2007 09:37:39 +0800 (CST) Date: Fri, 13 Jul 2007 09:37:35 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] do we need a client protocol? In-reply-to: <1DB91DF937A4544C81E636468B91C21C863E5F@CNSHGSMBS03.ad4.ad.alcatel.com> To: 'HUANG Ping B' , 'Michal Giermasinski' , p2psip@ietf.org, marcin.matuszewski@nokia.com Message-id: <039301c7c4ee$6397ecf0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQAAIh/DAACaerMAAXkVEg X-Spam-Score: 0.1 (/) X-Scan-Signature: e8ea636ec013593313c7b28da6453598 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1385927368==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1385927368== Content-type: multipart/related; boundary="Boundary_(ID_xeOgfUF9NllS2BOo0y5wDA)" This is a multi-part message in MIME format. --Boundary_(ID_xeOgfUF9NllS2BOo0y5wDA) Content-type: multipart/alternative; boundary="Boundary_(ID_qwbx7sNPmJyhrtvWWUpVlg)" --Boundary_(ID_qwbx7sNPmJyhrtvWWUpVlg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Huang =20 Your reply puzzled me. Our discussion focus is whether all peers in P2PSIP overlay must = recognize SIP. You think that all peers must recognize SIP messages, but I think that some peers may not recognize SIP = messages, do I misunderstand? By the way, in detail, there are three modes compatible with the = P2PSIP WG charter. As you said, the first is SIP over P2P, P2P provides transport service such as tunneling SIP; the second is = P2P over SIP, SIP is extended so that P2P is embedded in SIP messages; the last is that P2P is independent of SIP and = SIP is independent of P2P at the same time, P2P only provides the service determining the correct destination for SIP = requests to SIP terminals, it is the simplest and clearest. I suggest that you might read these drafts as Marcin's advice. http://www.p2psip.org/drafts/draft-bryan-p2psip-requirements-00.txt http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt http://www.p2psip.org/drafts/draft-jennings-p2psip-asp-00.txt=20 =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 22:27 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org; = marcin.matuszewski@nokia.com Subject: RE: [P2PSIP] do we need a client protocol? Hi Zheng and marcin I have never said that P2PSIP is IP or use SIP. as we know, there are = two mode in P2PSIP, one is SIP over P2P and the other is P2P over SIP.SIP is just in application layer and P2P or P2PSIP = are more like transport layer. in SIP over P2P, SIP is just one of the protocols interacting with P2P or P2PSIP overlay. in = P2P over SIP, SIP is made some extension. I have never said that P2PSIP peer protocol shall use SIP, SIP is over P2PSIP! And as I said, peers "SHOULD" not "SHALL" recognize SIP. maybe you = "SHALL" read RFC2119 _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 5:33 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT = service but not recognize SIP messages should be admitted as one member/peer of P2PSIP overlay, we do not have to update = the device to support SIP and then provide DHT service, the cost introduced due to the update is unnecessary.=20 =20 =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct destination for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of cause, is you use another = protocol, P2PSIP may be called another name, such as P2PXXX. Peers in P2PSIP overlay are responsible not just for location = (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? this name means that there is a relationship between P2PSIP = and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. then Peers in P2PSIP overlay( not P2PXXX = overlay) should recognize SIP message. Ok, you can say that a tunnel protocol could be used to deliver SIP protocol, this is a = choice, but not good choice. if a tunnel protocol is used, then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any protocols besides SIP, then name "P2PSIP" does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms = for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they = do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the = resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope = will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality." =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some = AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or = not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should = have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more = complex. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide = all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the = capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of = general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 _____ =20 From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new = one that will be designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is = to create a proxy-like peer that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and=20 - Other uses besides SIP. Business planning folks may not care about the = WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: = dean.willis@softarmor.com] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly = seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is = > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service.=20 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the = peer.=20 > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change = it service offering.=20 -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 --Boundary_(ID_qwbx7sNPmJyhrtvWWUpVlg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi Huang
 
    Your reply puzzled=20 me.
    Our discussion focus is = whether all=20 peers in P2PSIP overlay must recognize SIP. You think that all peers = must=20 recognize SIP messages, but I think that some peers may not recognize = SIP=20 messages, do I misunderstand?
    By the way, in detail, = there are=20 three modes compatible with the P2PSIP WG charter. As=20 you said, the first is = SIP=20 over P2P, P2P provides transport service such as = tunneling SIP;=20 the second is P2P over SIP, SIP is extended so that P2P is embedded = in SIP=20 messages; the last is that P2P is independent of SIP and SIP is = independent=20 of P2P at the same time, P2P only provides the service determining = the=20 correct destination for SIP requests to SIP terminals, it is the = simplest and=20 clearest.
    I suggest that you might = read these=20 drafts as Marcin's advice.
   http://www.p2psip.org/drafts/draft-bryan-p2psip-requirements-00.txt
  =20 http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt=
  =20 ht= tp://www.p2psip.org/drafts/draft-jennings-p2psip-asp-00.txt=20
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 22:27
To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org;=20 marcin.matuszewski@nokia.com
Subject: RE: [P2PSIP] do we need = a client=20 protocol?

Hi Zheng and marcin
   I have never said that P2PSIP is = IP or use=20 SIP. as we know, there are two mode in P2PSIP, one is SIP over P2P and = the other=20 is P2P over SIP.SIP is just in application layer and P2P or P2PSIP are = more like=20 transport layer. in SIP over P2P, SIP is just one of the protocols = interacting=20 with P2P or P2PSIP overlay. in P2P over SIP, SIP is made some extension. = I have=20 never said that P2PSIP peer protocol shall use SIP, SIP is over=20 P2PSIP!
   And as I said, peers "SHOULD" = not "SHALL"=20 recognize SIP. maybe you "SHALL" read RFC2119

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 5:33 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
   One supplement, = FYI.
   In the future P2PSIP = deployment,=20 one device that can provide DHT service but not recognize SIP messages = should be=20 admitted as one member/peer of P2PSIP overlay, we do not have to update = the=20 device to support SIP and then provide DHT service, the cost = introduced due=20 to the update is unnecessary. 
 
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 16:57
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

I have never said that P2PSIP = is equal to=20 SIP, P2PSIP is just an overlay as an alternative to the SIP discovery = process of=20 RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct=20 destination for SIP requests. SIP is session layer protocol, P2PSIP is = under=20 SIP. of cause, is you use another protocol, P2PSIP may be called another = name,=20 such as P2PXXX. Peers in P2PSIP = overlay are=20 responsible not just for location (done by P2PSIP protocol). Why we = called=20 P2PSIP as "P2PSIP"?  this name means that there is a relationship = between=20 P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP = should be=20 used. then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize = SIP=20 message. Ok, you can say that a tunnel protocol could be used to deliver = SIP=20 protocol, this is a choice, but not good choice. if a tunnel protocol is = used,=20 then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any=20 protocols besides SIP, then name "P2PSIP" does not make=20 sense.
when peers in P2PSIP = overlay do not=20 recognize SIP message, then let them out of = overlay.

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
  If I do not misunderstand, P2PSIP is not = equal to=20 SIP.
  Essentially in P2PSIP overlay, P2PSIP = peers have=20 nothing with SIP. Why must we bind SIP to P2PSIP peers?=20
 
  Here is the description about P2PSIP = peers in WG=20 charter, FYI.
  "The work focuses on collections of = nodes called=20 "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed = namespace in which overlay users are identified and provides mechanisms = for=20 locating users or resources within the P2PSIP overlay. P2PSIP clients = differ=20 from P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers=20 use the resolution services of the peers as an alternative to the SIP = discovery=20 process of RFC 3263. In this way, P2PSIP offers an alternative mechanism = for=20 determining the correct destination for SIP requests. The working = group's=20 initial charter scope will be to produce protocols to enable this = alternate=20 mechanism for RFC 3263 functionality."
 
  Nothing says that P2PSIP = peers must=20 support SIP or have anything with SIP.
  From the charter, functionality of = P2PSIP=20 peers is so clear and simple, why do we make it complicated? I = think we can=20 do it simpler, SIP is SIP, P2PSIP peer is P2PSIP = peer, let=20 them be.
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = 3Dhuawei_logo=20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 10:22
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi all
    P2P is great topic, but = P2PSIP is the=20 subset or certain instance of P2P. when we discuss P2PSIP, we shall not = involve=20 all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are=20 not equal to peers in P2P overlay. when we discuss IMS, although legacy=20 equipments does not support SIP, but some AGWs do translation or agent = for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers who = know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some common = base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more simple=20 but not more complex.
From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,
 
    Please let me describe the = case in=20 detail.
    In the case, all clients support SIP, but = some=20 peers in the overlay network do not support SIP and some support SIP. = For those=20 peers which do not support SIP, such as some PCs, they can provide all = required=20 DHT services, but there is only a pity that they can not recognize any = SIP=20 message, maybe they think that the capability is unnecessary. In this = case, some=20 client protocol is desirable. Certainly this protocol may be the subset = of=20 general Peer Protocol if we regard those clients as Lame Peers and = regard those=20 peers as Pure Peers who only provide required DHT=20 services.
    IMHO, this case does not care those = clients not=20 supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. 3Dhuawei_logo


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: = [P2PSIP]=20 do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. = If a=20 client application is not able to use SIP protocol that is well known = for years=20 it obviously will not be able to use a new one that will be designed = especially=20 for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing = is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that will = be able=20 to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do not = support=20 SIP, those peers are only responsible to
provide distributed = storage,=20 location and transport services for information about SIP, but those = peers do=20 not recognize any
SIP messages at all.
  In this case, = how to=20 maintain the relation between clients (UA) and the hosting peer(s)? = One client=20 protocol is desirable
at this time.


Zheng = Hewen
HUAWEI=20 TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong=20 Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel:=20 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
--------------------= -------------------------------------------------------------------------= -------------------------------=20
---------
This e-mail and its attachments contain confidential=20 information from HUAWEI, which
is intended only for the person or = entity=20 whose address is listed above. Any use of the
information contained = herein=20 in any way (including, but not limited to, total or partial =
disclosure,=20 reproduction, or dissemination) by persons other than the=20 intended
recipient(s) is prohibited. If you receive this e-mail in = error,=20 please notify the sender by
phone or email immediately and delete = it!=20


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26?=20 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP = Mailing=20 List; Philip Matthews
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives for = the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks, = Henry

-----Original=20 Message-----
From: Dean Willis [mailto:=20 dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better than=20 active/passive) entities
have a
> Peer-ID? In otherwords, are = they=20 part of the overlay at all? If so,
for
> most
> DHTs, = how do=20 we allow you to be in the overlay and not store = resources
(not
>=20 typical for most current DHT algorithms)

Well, that certainly = depends=20 on the DHT algorithm involved. It certainly seems that a peer that = moves=20 between contributing
and non-contributing might HAVE a peer ID, = but=20 whether it chooses to insert itself into the DHT "right now" might=20 determine
whether it is contributing "right now"
or = not.

> My=20 concern all along has been that I don't understand why something is =
> a=20 peer if it isn't doing anything other than talking to someone = and
>=20 making requests, hence why I supported client in the first=20 place.
>  I fail to see how something that isn't = contributing=20 anything, and
> instead talks to a peer to get resources, is in = any way=20 a peer. It
> seems completely not in keeping with the idea of = P2P. I=20 also worry it
> is likely to be very confusing since we've been = using=20 the other
> terminology for over a year now. Just looks like a = souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection and=20 wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality make=20 it two different nodes?

> If we do go this way, there is = one subtle=20 point. If I join the overlay
but
> don't happen to offer any = services=20 (other than maybe
storage...depending on
> how we definie it, = that=20 might or might not be mandatory), would I be
> contributing? If = joining=20 the overlay (in the sense that we have a
PeerID
> and
> = we=20 route traffic) doesn't require me to store, I could offer=20 no
services

That's "offer no other services", since routing = is=20 itself a service.

> and
> still be a peer. How do we=20 distinguish between this case and a
> "non-contributing peer" = who isn't=20 even part of the overlay (i.e., no
> Peer-ID)

I think = there's a=20 range of "contributing" in play. For most DHT models, a minimally = contributing=20 node will route a request
it receives. It might ask nicely = (perhaps a=20 q-value mechanism) to not have to route requests, but would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam onto = a WiFi=20 net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

_______________________________________________
P2PSIP = mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

--Boundary_(ID_qwbx7sNPmJyhrtvWWUpVlg)-- --Boundary_(ID_xeOgfUF9NllS2BOo0y5wDA) Content-id: <398171901@13072007-2F20> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_xeOgfUF9NllS2BOo0y5wDA) Content-id: <398171901@13072007-2F27> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_xeOgfUF9NllS2BOo0y5wDA)-- --===============1385927368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1385927368==-- From p2psip-bounces@ietf.org Fri Jul 13 00:15:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9CYr-0000KD-Ji; Fri, 13 Jul 2007 00:15:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9CYr-0000K5-0H for p2psip@ietf.org; Fri, 13 Jul 2007 00:15:21 -0400 Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9CYo-0002aP-AH for p2psip@ietf.org; Fri, 13 Jul 2007 00:15:20 -0400 Received: from cnshgsbhs02.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id l6D4Bhcj014108; Fri, 13 Jul 2007 12:11:44 +0800 Received: from CNSHGSMBS03.ad4.ad.alcatel.com ([172.24.146.173]) by cnshgsbhs02.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 13 Jul 2007 12:14:42 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [P2PSIP] do we need a client protocol? MIME-Version: 1.0 Date: Fri, 13 Jul 2007 12:14:40 +0800 Message-ID: <1DB91DF937A4544C81E636468B91C21C86410D@CNSHGSMBS03.ad4.ad.alcatel.com> In-Reply-To: <62D92A9A02BCC845B202323D49A48426E1D195@0591-ITS-EXMP02.us.saic .com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQAAIh/D AACaerMAABttiJABnsewA= References: <1DB91DF937A4544C81E636468B91C21C863D77@CNSHGSMBS03.ad4.ad.alcat el.com> <02b001c7c467$93056b70$5105a40a@china.huawei.com> <1DB91DF937A4544C81E636468B91C21C863E5F@CNSHGSMBS03.ad4.ad.alcatel.com> <62D92A9A02BCC845B202323D49A48426E1D195@0591-ITS-EXMP02.us.saic.com> From: "HUANG Ping B" To: "Roy, Radhika R." , "Zheng Hewen" , "Michal Giermasinski" , , X-OriginalArrivalTime: 13 Jul 2007 04:14:42.0287 (UTC) FILETIME=[565DAFF0:01C7C504] X-imss-version: 2.047 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 0.6 (/) X-Scan-Signature: 3c3f5218b222da1e73e850f1438da613 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0165759679==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0165759679== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C504.560B8E43" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C504.560B8E43 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Ranhika pls refer inline. ________________________________ From: Roy, Radhika R. [mailto:RADHIKA.R.ROY@saic.com]=20 Sent: Thursday, July 12, 2007 11:01 PM To: HUANG Ping B; Zheng Hewen; Michal Giermasinski; p2psip@ietf.org; = marcin.matuszewski@nokia.com Subject: RE: [P2PSIP] do we need a client protocol? Huang: =20 I also think, as you have said, P2PSIP peers should not recognize SIP. = It means that if SIP is used, P2PSIP peers may understand SIP as well.=20 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"peers = "SHOULD" not "SHALL" recognize SIP. " has some spelling mistake, I mean = Peers "SHOULD"( not "SHALL") recognize SIP, parenthesis is missing. =20 However, would please clarify with some examples, as you have said, the = following? =20 1.=09 SIP is an application layer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~V 2.=09 P2PSIP is like a transport layer ~~~~~~~~~~~~~~~~~~~~~~~~~|=20 3.=09 SIP is just one application interacting with P2PSIP overlay V 4.=09 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~pls refer to = "draft-hautakorpi-p2psip-with-hip-00 " =20 =20 Best regards, Radhika ________________________________ From: p2psip-bounces@ietf.org on behalf of HUANG Ping B Sent: Thu 7/12/2007 10:27 AM To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org; = marcin.matuszewski@nokia.com Subject: RE: [P2PSIP] do we need a client protocol? Hi Zheng and marcin I have never said that P2PSIP is IP or use SIP. as we know, there are = two mode in P2PSIP, one is SIP over P2P and the other is P2P over = SIP.SIP is just in application layer and P2P or P2PSIP are more like = transport layer. in SIP over P2P, SIP is just one of the protocols = interacting with P2P or P2PSIP overlay. in P2P over SIP, SIP is made = some extension. I have never said that P2PSIP peer protocol shall use = SIP, SIP is over P2PSIP! And as I said, peers "SHOULD" not "SHALL" recognize SIP. maybe you = "SHALL" read RFC2119 ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 5:33 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT = service but not recognize SIP messages should be admitted as one = member/peer of P2PSIP overlay, we do not have to update the device to = support SIP and then provide DHT service, the cost introduced due to the = update is unnecessary. =20 ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP = offers an alternative mechanism for determining the correct destination = for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of = cause, is you use another protocol, P2PSIP may be called another name, = such as P2PXXX. Peers in P2PSIP overlay are responsible not just for = location (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? = this name means that there is a relationship between P2PSIP and SIP, = maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. = then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize SIP = message. Ok, you can say that a tunnel protocol could be used to deliver = SIP protocol, this is a choice, but not good choice. if a tunnel = protocol is used, then SIP has nothing with P2P overlay, this tunnel = protocol could deliver any protocols besides SIP, then name "P2PSIP" = does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which = overlay users are identified and provides mechanisms for locating users = or resources within the P2PSIP overlay. P2PSIP clients differ from = P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers use the resolution services of the peers as an alternative to = the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP = requests. The working group's initial charter scope will be to produce = protocols to enable this alternate mechanism for RFC 3263 = functionality." =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP = is SIP, P2PSIP peer is P2PSIP peer, let them be. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. = huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could = be peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to = peers in P2P overlay. when we discuss IMS, although legacy equipments = does not support SIP, but some AGWs do translation or agent for those = equipments. then, when we discuss P2PSIP, shall we involve all peers who = know SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, = and vice versa. and I think that Peers in P2PSIP overlay should have = some common base functionalitis such as SIP recognition. I think we = shall make P2PSIP more simple but not more complex. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which = do not support SIP, such as some PCs, they can provide all required DHT = services, but there is only a pity that they can not recognize any SIP = message, maybe they think that the capability is unnecessary. In this = case, some client protocol is desirable. Certainly this protocol may be = the subset of general Peer Protocol if we regard those clients as Lame = Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. = huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known = for years it obviously will not be able to use a new one that will be = designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and = the peer in the overlay). The only issue is to create a proxy-like peer = that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, =09 A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. =09 =09 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo =09 =09 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 = -------------------------------------------------------------------------= ---------------------------------------------------=20 --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 =09 =09 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? =09 Folks, =09 Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: =09 - Limited battery in mobile devices, and=20 =09 - Other uses besides SIP. Business planning folks may not care about = the WG charter, but about the return on the investment. =09 Thanks, Henry =09 -----Original Message----- From: Dean Willis [mailto: dean.willis@softarmor.com = ] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 =09 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store = resources (not > typical for most current DHT algorithms) =09 Well, that certainly depends on the DHT algorithm involved. It = certainly seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. =09 > My concern all along has been that I don't understand why something = is=20 > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of = confusion. =09 A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 =09 > If we do go this way, there is one subtle point. If I join the = overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services =09 That's "offer no other services", since routing is itself a service.=20 =09 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) =09 I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. =09 I think we distinguish based on the service advertisements from the = peer.=20 =09 > If we are so opposed to client for confusion with SIP UAs, lets pick = a new > name, but why some flavor of peer when it does nothing remotely peer like? =09 Because in 15 minutes it might roam onto a WiFi net and therefore = change it service offering.=20 =09 -- Dean =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 =09 =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 ------_=_NextPart_001_01C7C504.560B8E43 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Ranhika
   pls = refer=20 inline.

From: Roy, Radhika R.=20 [mailto:RADHIKA.R.ROY@saic.com]
Sent: Thursday, July 12, 2007 = 11:01=20 PM
To: HUANG Ping B; Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org; marcin.matuszewski@nokia.com
Subject: RE: = [P2PSIP] do=20 we need a client protocol?

Huang:
 
I also think, as you = have said,=20 P2PSIP peers should not recognize SIP. It means that if SIP is used, = P2PSIP=20 peers may understand SIP as well. 
         &nb= sp;           &nbs= p;   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"peers=20 "SHOULD" not "SHALL" recognize SIP. " has some spelling mistake, I mean = Peers=20 "SHOULD"( not "SHALL")=20 recognize SIP, parenthesis is=20 missing.
 
However, would please clarify = with some=20 examples, as you have said, the following?
 
  1. SIP is an application = layer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~V=
  2. P2PSIP is like a transport layer ~~~~~~~~~~~~~~~~~~~~~~~~~| 
  3. SIP is just one application = interacting=20 with P2PSIP overlay    V
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~pls=20 refer to "draft-hautakorpi-p2psip-with-hip-00 "  
 
Best regards,
Radhika

From: p2psip-bounces@ietf.org on = behalf of HUANG=20 Ping B
Sent: Thu 7/12/2007 10:27 AM
To: Zheng Hewen; = Michal=20 Giermasinski; p2psip@ietf.org; = marcin.matuszewski@nokia.com
Subject:=20 RE: [P2PSIP] do we need a client protocol?

Hi Zheng and marcin
   I have never said that P2PSIP is = IP or use=20 SIP. as we know, there are two mode in P2PSIP, one is SIP over P2P and = the other=20 is P2P over SIP.SIP is just in application layer and P2P or P2PSIP are = more like=20 transport layer. in SIP over P2P, SIP is just one of the protocols = interacting=20 with P2P or P2PSIP overlay. in P2P over SIP, SIP is made some extension. = I have=20 never said that P2PSIP peer protocol shall use SIP, SIP is over=20 P2PSIP!
   And as I said, peers "SHOULD" = not "SHALL"=20 recognize SIP. maybe you "SHALL" read RFC2119

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 5:33 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
   One supplement, = FYI.
   In the future P2PSIP = deployment, one=20 device that can provide DHT service but not recognize SIP messages = should be=20 admitted as one member/peer of P2PSIP overlay, we do not have to update = the=20 device to support SIP and then provide DHT service, the cost = introduced due=20 to the update is unnecessary.
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 16:57
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

I have never said that P2PSIP = is equal to=20 SIP, P2PSIP is just an overlay as an alternative to the SIP discovery = process of=20 RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct=20 destination for SIP requests. SIP is session layer protocol, P2PSIP is = under=20 SIP. of cause, is you use another protocol, P2PSIP may be called another = name,=20 such as P2PXXX. Peers in P2PSIP = overlay are=20 responsible not just for location (done by P2PSIP protocol). Why we = called=20 P2PSIP as "P2PSIP"?  this name means that there is a relationship = between=20 P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP = should be=20 used. then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize = SIP=20 message. Ok, you can say that a tunnel protocol could be used to deliver = SIP=20 protocol, this is a choice, but not good choice. if a tunnel protocol is = used,=20 then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any=20 protocols besides SIP, then name "P2PSIP" does not make=20 sense.
when peers in P2PSIP = overlay do not=20 recognize SIP message, then let them out of = overlay.

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
  If I do not misunderstand, P2PSIP is not = equal to=20 SIP.
  Essentially in P2PSIP overlay, P2PSIP = peers have=20 nothing with SIP. Why must we bind SIP to P2PSIP peers?=20
 
  Here is the description about P2PSIP = peers in WG=20 charter, FYI.
  "The work focuses on collections of = nodes called=20 "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed = namespace in which overlay users are identified and provides mechanisms = for=20 locating users or resources within the P2PSIP overlay. P2PSIP clients = differ=20 from P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers=20 use the resolution services of the peers as an alternative to the SIP = discovery=20 process of RFC 3263. In this way, P2PSIP offers an alternative mechanism = for=20 determining the correct destination for SIP requests. The working = group's=20 initial charter scope will be to produce protocols to enable this = alternate=20 mechanism for RFC 3263 functionality."
 
  Nothing says that P2PSIP = peers must=20 support SIP or have anything with SIP.
  From the charter, functionality of = P2PSIP=20 peers is so clear and simple, why do we make it complicated? I = think we can=20 do it simpler, SIP is SIP, P2PSIP peer is P2PSIP = peer, let=20 them be.
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = 3Dhuawei_logo=20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 10:22
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi all
    P2P is great topic, but = P2PSIP is the=20 subset or certain instance of P2P. when we discuss P2PSIP, we shall not = involve=20 all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are=20 not equal to peers in P2P overlay. when we discuss IMS, although legacy=20 equipments does not support SIP, but some AGWs do translation or agent = for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers who = know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some common = base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more simple=20 but not more complex.
From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,
 
    Please let me describe the = case in=20 detail.
    In the case, all clients support SIP, but = some=20 peers in the overlay network do not support SIP and some support SIP. = For those=20 peers which do not support SIP, such as some PCs, they can provide all = required=20 DHT services, but there is only a pity that they can not recognize any = SIP=20 message, maybe they think that the capability is unnecessary. In this = case, some=20 client protocol is desirable. Certainly this protocol may be the subset = of=20 general Peer Protocol if we regard those clients as Lame Peers and = regard those=20 peers as Pure Peers who only provide required DHT=20 services.
    IMHO, this case does not care those = clients not=20 supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. 3Dhuawei_logo


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: = [P2PSIP]=20 do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. = If a=20 client application is not able to use SIP protocol that is well known = for years=20 it obviously will not be able to use a new one that will be designed = especially=20 for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing = is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that will = be able=20 to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do not = support=20 SIP, those peers are only responsible to
provide distributed = storage,=20 location and transport services for information about SIP, but those = peers do=20 not recognize any
SIP messages at all.
  In this case, = how to=20 maintain the relation between clients (UA) and the hosting peer(s)? = One client=20 protocol is desirable
at this time.


Zheng = Hewen
HUAWEI=20 TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong=20 Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel:=20 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
-------------------= -------------------------------------------------------------------------= --------------------------------=20
---------
This e-mail and its attachments contain confidential=20 information from HUAWEI, which
is intended only for the person or = entity=20 whose address is listed above. Any use of the
information contained = herein=20 in any way (including, but not limited to, total or partial =
disclosure,=20 reproduction, or dissemination) by persons other than the=20 intended
recipient(s) is prohibited. If you receive this e-mail in = error,=20 please notify the sender by
phone or email immediately and delete = it!=20


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26?=20 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP = Mailing=20 List; Philip Matthews
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives for = the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks, = Henry

-----Original=20 Message-----
From: Dean Willis [mailto:=20 dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better than=20 active/passive) entities
have a
> Peer-ID? In otherwords, are = they=20 part of the overlay at all? If so,
for
> most
> DHTs, = how do=20 we allow you to be in the overlay and not store = resources
(not
>=20 typical for most current DHT algorithms)

Well, that certainly = depends=20 on the DHT algorithm involved. It certainly seems that a peer that = moves=20 between contributing
and non-contributing might HAVE a peer ID, = but=20 whether it chooses to insert itself into the DHT "right now" might=20 determine
whether it is contributing "right now"
or = not.

> My=20 concern all along has been that I don't understand why something is =
> a=20 peer if it isn't doing anything other than talking to someone = and
>=20 making requests, hence why I supported client in the first=20 place.
>  I fail to see how something that isn't = contributing=20 anything, and
> instead talks to a peer to get resources, is in = any way=20 a peer. It
> seems completely not in keeping with the idea of = P2P. I=20 also worry it
> is likely to be very confusing since we've been = using=20 the other
> terminology for over a year now. Just looks like a = souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection and=20 wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality make=20 it two different nodes?

> If we do go this way, there is = one subtle=20 point. If I join the overlay
but
> don't happen to offer any = services=20 (other than maybe
storage...depending on
> how we definie it, = that=20 might or might not be mandatory), would I be
> contributing? If = joining=20 the overlay (in the sense that we have a
PeerID
> and
> = we=20 route traffic) doesn't require me to store, I could offer=20 no
services

That's "offer no other services", since routing = is=20 itself a service.

> and
> still be a peer. How do we=20 distinguish between this case and a
> "non-contributing peer" = who isn't=20 even part of the overlay (i.e., no
> Peer-ID)

I think = there's a=20 range of "contributing" in play. For most DHT models, a minimally = contributing=20 node will route a request
it receives. It might ask nicely = (perhaps a=20 q-value mechanism) to not have to route requests, but would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam onto = a WiFi=20 net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

_______________________________________________
P2PSIP = mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

------_=_NextPart_001_01C7C504.560B8E43-- --===============0165759679== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0165759679==-- From p2psip-bounces@ietf.org Fri Jul 13 04:26:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9GTL-0004wE-S9; Fri, 13 Jul 2007 04:25:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9GTK-0004w1-Oa for P2PSIP@ietf.org; Fri, 13 Jul 2007 04:25:54 -0400 Received: from biscayne-one-station.mit.edu ([18.7.7.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9GTE-0000zG-5P for P2PSIP@ietf.org; Fri, 13 Jul 2007 04:25:54 -0400 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id l6D8P8uG019478; Fri, 13 Jul 2007 04:25:08 -0400 (EDT) Received: from [192.168.1.101] (adsl-84-227-137-83.adslplus.ch [84.227.137.83]) (authenticated bits=0) (User authenticated as baford@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id l6D8P513007828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Jul 2007 04:25:07 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: From: Bryan Ford Date: Fri, 13 Jul 2007 10:25:03 +0200 To: enrico.marocco@telecomitalia.it, emcho@sip-communicator.org X-Mailer: Apple Mail (2.752.3) X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: P2PSIP@ietf.org Subject: [P2PSIP] comment on draft-marocco-p2psip-xpp-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Enrico and Emil, I happened to be browsing through your draft-marocco-p2psip- xpp-00.txt, and noticed your statement in section 1.1: It is true that the definition of three-way TCP [RFC0793] handshake, also provides semantics that could be used for simultaneous connection establishment; however, this mechanism is defined for resolving race conditions and is not meant for use as a common practice. Such a mechanism is likely to only work in certain situations (i.e. when both peers are located behind NATs). In a case where both endpoints have public addresses and are able to communicate directly, any attempt to simultaneously establish a connection will almost always fail as the reception of a first SYN request would usually trigger an RST response before the application has had the chance of sending a second corresponding SYN. This statement is incorrect, and seems to be a common misconception regarding TCP nat traversal. As long as the applications on both endpoints first bind a listen socket to the TCP port they will use before starting the hole punching process (via outgoing connect sockets from the same ports), and as long as the OS implements the TCP state machine correctly (which all major OSes do now, the only known recent exception being Windows XP before SP2), the applications will connect reliably in the no-NAT case with no spurious RSTs. The only potential problem with spurious RSTs occurs if there *are* NATs on the path, and at least one of them is "poorly behaved". For details, see for example my p2p-over-NAT paper from USENIX 2005 (http://www.brynosaurus.com/pub/net/p2pnat/). UDP still may be a better choice than TCP for a protocol that wants to traverse NATs, just because more existing NATs in the wild are already NAT traversal friendly for UDP than for TCP (see the same paper for example, or Guha and Francis's more detailed analysis of specific NATs). So you don't need the incorrect statement above to motivate your work anyway. I see this Internet-Draft is a bit old, so apologies if this error has already been pointed out. Cheers, Bryan _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 05:45:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9HiX-0003os-1n; Fri, 13 Jul 2007 05:45:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9HiV-0003on-Bv for p2psip@ietf.org; Fri, 13 Jul 2007 05:45:39 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9HiU-0003FM-TG for p2psip@ietf.org; Fri, 13 Jul 2007 05:45:39 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6D9jEQo004797 for ; Fri, 13 Jul 2007 12:45:29 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 12:45:27 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 12:45:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 13 Jul 2007 12:48:29 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04CC5916@esebe102.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-matuszewski-p2psip-security-requirements-01 Thread-Index: AcfFMvenUoIet4UqQjS8FRK9BKbXQw== From: To: X-OriginalArrivalTime: 13 Jul 2007 09:45:27.0346 (UTC) FILETIME=[8AF16120:01C7C532] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: jan-erik.ekberg@nokia.com, pekka.laitinen@nokia.com Subject: [P2PSIP] draft-matuszewski-p2psip-security-requirements-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1012519096==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1012519096== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C532.8AE7213C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C532.8AE7213C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, We have submitted an update to the security requirements draft: http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-re quirements-01.txt. We updated the draft according to the received comments. In addition we clarified requirements and extended the security threats section.=20 We would appreciate your comments! Marcin ------_=_NextPart_001_01C7C532.8AE7213C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable draft-matuszewski-p2psip-security-requirements-01

Hi,

We have submitted an update to the = security requirements draft:
http://www.ietf.org/internet-drafts/draft-matuszewski-p2ps= ip-security-requirements-01.txt.

We updated the draft according to the = received comments. In addition we clarified requirements and extended = the security threats section.

We would appreciate your = comments!

Marcin


------_=_NextPart_001_01C7C532.8AE7213C-- --===============1012519096== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1012519096==-- From p2psip-bounces@ietf.org Fri Jul 13 06:36:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9IVL-0004C8-F9; Fri, 13 Jul 2007 06:36:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9IVJ-0004C2-Q9 for P2PSIP@ietf.org; Fri, 13 Jul 2007 06:36:05 -0400 Received: from mailm.telecomitalia.it ([217.169.121.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9IVE-00028K-JO for P2PSIP@ietf.org; Fri, 13 Jul 2007 06:36:05 -0400 Received: from ptpxch009rm001.idc.cww.telecomitalia.it ([156.54.205.171]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 12:35:59 +0200 Received: from ptpxch004rm001.idc.cww.telecomitalia.it ([156.54.205.166]) by ptpxch009rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 12:35:59 +0200 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch004rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 12:35:58 +0200 Message-ID: <4697558C.5000702@telecomitalia.it> Date: Fri, 13 Jul 2007 12:35:56 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070622) MIME-Version: 1.0 To: Bryan Ford References: In-Reply-To: X-OriginalArrivalTime: 13 Jul 2007 10:35:58.0965 (UTC) FILETIME=[99EDBA50:01C7C539] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: P2PSIP@ietf.org Subject: [P2PSIP] Re: comment on draft-marocco-p2psip-xpp-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0377587829==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0377587829== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090503060202090901040600" This is a cryptographically signed message in MIME format. --------------ms090503060202090901040600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bryan Ford wrote: > Dear Enrico and Emil, > > I happened to be browsing through your draft-marocco-p2psip-xpp-00.txt, > and noticed your statement in section 1.1: > > It is true that the definition of three-way TCP [RFC0793] handshake, > also provides semantics that could be used for simultaneous > connection establishment; however, this mechanism is defined for > resolving race conditions and is not meant for use as a common > practice. Such a mechanism is likely to only work in certain > situations (i.e. when both peers are located behind NATs). In a case > where both endpoints have public addresses and are able to > communicate directly, any attempt to simultaneously establish a > connection will almost always fail as the reception of a first SYN > request would usually trigger an RST response before the application > has had the chance of sending a second corresponding SYN. > > This statement is incorrect, and seems to be a common misconception > regarding TCP nat traversal. As long as the applications on both > endpoints first bind a listen socket to the TCP port they will use > before starting the hole punching process (via outgoing connect sockets > from the same ports), and as long as the OS implements the TCP state > machine correctly (which all major OSes do now, the only known recent > exception being Windows XP before SP2), the applications will connect > reliably in the no-NAT case with no spurious RSTs. The only potential > problem with spurious RSTs occurs if there *are* NATs on the path, and > at least one of them is "poorly behaved". For details, see for example > my p2p-over-NAT paper from USENIX 2005 > (http://www.brynosaurus.com/pub/net/p2pnat/). > > UDP still may be a better choice than TCP for a protocol that wants to > traverse NATs, just because more existing NATs in the wild are already > NAT traversal friendly for UDP than for TCP (see the same paper for > example, or Guha and Francis's more detailed analysis of specific > NATs). So you don't need the incorrect statement above to motivate your > work anyway. Yep, Bryan, you are right. SO_REUSEADDR socket option can be used to open a socket in listen state on a port which can later be bound by another socket for connecting, and this would prevent the OS to answer RSTs to SYNs. Thank you for pointing out the bogus statement, we'll fix it. -- Ciao, Enrico --------------ms090503060202090901040600 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcwNzEzMTAzNTU2WjAjBgkqhkiG9w0BCQQxFgQU+TUrNpPV SlXsuDoPSfkgTPdRoV0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAJEF7RBKncYEN0h+xQDlccGoiKirzM+8+HgpuQ6zqE+F6p8Xil4SPo4f JmWK5zd2/WsmFJkbrvCadUTDHH1oQsBghMuB654dDLs8OTMdldIlSvqIFEwHnygXtyWk45rj 2kBgjpZq1pBgUamraWAqYmAgOJpATeRN2vecZpnJVV7bm/5/4bsuJLFhfLUr4bvfeMrSf7ye 7epNQFLE7GIZ/axt8VojamP1DTmVEt6w2nkMnZcXtQqvEx+re4MQox9fDnvsOpgPiH0I/zS9 rZv2xqnw9DHiInslQHiqBJkTgwVUwAsZ0xrWj5HxeGJ3CvJ5jlefmqomZfcektKnERIWQq0A AAAAAAA= --------------ms090503060202090901040600-- --===============0377587829== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0377587829==-- From p2psip-bounces@ietf.org Fri Jul 13 06:45:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Iel-0008G1-5l; Fri, 13 Jul 2007 06:45:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Iej-000868-VA for p2psip@ietf.org; Fri, 13 Jul 2007 06:45:50 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Ief-0004uV-T3 for p2psip@ietf.org; Fri, 13 Jul 2007 06:45:49 -0400 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 <0JL400DSX5F58X@szxga02-in.huawei.com> for p2psip@ietf.org; Fri, 13 Jul 2007 18:35:30 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL400FBR5EZT9@szxga02-in.huawei.com> for p2psip@ietf.org; Fri, 13 Jul 2007 18:35:29 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL400C545EVXQ@szxml03-in.huawei.com> for p2psip@ietf.org; Fri, 13 Jul 2007 18:35:23 +0800 (CST) Date: Fri, 13 Jul 2007 18:35:19 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] do we need a client protocol? In-reply-to: To: 'Duan Chen' , 'HUANG Ping B' Message-id: <03ae01c7c539$82979b50$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfE7bz3jyA9r9lcQ+WMHEJaYkThEwASRQJw X-Spam-Score: 0.6 (/) X-Scan-Signature: 4120a90b86e256a7465e9d130cb2a242 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0294159839==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0294159839== Content-type: multipart/related; boundary="Boundary_(ID_qopbzGmEi7eLz/W6J99HLQ)" This is a multi-part message in MIME format. --Boundary_(ID_qopbzGmEi7eLz/W6J99HLQ) Content-type: multipart/alternative; boundary="Boundary_(ID_nsSVohyUSHfFlCh4EeVpQA)" --Boundary_(ID_nsSVohyUSHfFlCh4EeVpQA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Dear Chen, =20 As you pointed out, section 5.3 of draft-ietf-p2psip-concepts-00 = says: "In addition to Peer Protocol and Client Protocol messages, a P2PSIP = Overlay must also provide a solution to the NAT Traversal problem for SIP messages. If it does not, there is no reliable = way for a peer behind one NAT to send a SIP INVITE to a peer behind another NAT. One way to solve this problem is to = transport SIP messages along Peer and Client Protocol connections: this could be done either by encapsulating the SIP messages = inside Peer and Client Protocol messages or by multiplexing SIP with the Peer (resp.Client) Protocol on a Peer (resp. = Client) Protocol connection." =20 In this case, those end-point peers (i.e., source and sink peers = transmitting SIP Invite) at least must be able to determine whether the received packets are SIP message, but please pay = attention to this point, it does not mean that all the peers support SIP (i.e., providing SIP functions such as proxy). The peers can forward those SIP messages by some mechanism such as = RELOAD TRANSPORT-TUNNEL method, at this time those messages are transparent for intermediate peers, it is not necessary to = recognize SIP messages for those intermediate peers because those intermediate peers only provide P2P distributed = storage/lookup/routing services not requiring SIP. P2PSIP Peers can support SIP, but it not required that P2PSIP Peers = must support SIP. Best regards, Zheng Hewen _____ =20 From: Duan Chen [mailto:duan.chen@gmail.com]=20 Sent: 2007=C4=EA7=D4=C213=C8=D5 9:33 To: HUANG Ping B Cc: p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi, Huang & Zheng: =20 One comment: If I understand correctly, the P2PSIP overlay should be able to = transport the SIP message because of the NAT traversal issue between peers. If it does not, there is no reliable way for a peer = behind one NAT to send a SIP INVITE to a peer behind another NAT (see section 5.3 of = draft-ietf-p2psip-concepts-00.txt), a P2PSIP peer may or may not be = coupled with a SIP entity, but it should be able to recognize the SIP message; or how = can it encapsulate or multiplex a SIP message along the peer to peer connections?=20 =20 Thus if there is a device joining the DHT overlay but not able to = recognize the SIP message, it would preclude the approach mentioned above to solve the NAT issue. =20 thanks and regards! =20 On 7/12/07, HUANG Ping B wrote:=20 Hi Zheng and marcin I have never said that P2PSIP is IP or use SIP. as we know, there are = two mode in P2PSIP, one is SIP over P2P and the other is P2P over SIP.SIP is just in application layer and P2P or P2PSIP = are more like transport layer. in SIP over P2P, SIP is just one of the protocols interacting with P2P or P2PSIP overlay. in = P2P over SIP, SIP is made some extension. I have never said that P2PSIP peer protocol shall use SIP, SIP is over P2PSIP!=20 And as I said, peers "SHOULD" not "SHALL" recognize SIP. maybe you = "SHALL" read RFC2119 _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 5:33 PM=20 To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol?=20 =20 Hi, =20 One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT = service but not recognize SIP messages should be admitted as one member/peer of P2PSIP overlay, we do not have to update = the device to support SIP and then provide DHT service, the cost introduced due to the update is unnecessary.=20 =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct destination for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of cause, is you use another = protocol, P2PSIP may be called another name, such as P2PXXX. P eers in P2PSIP overlay are responsible not just for location = (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? this name means that there is a relationship between P2PSIP = and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. then Peers in P2PSIP overlay( not P2PXXX = overlay) should recognize SIP message. Ok, you can say that a tunnel protocol could be used to deliver SIP protocol, this is a = choice, but not good choice. if a tunnel protocol is used, then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any protocols besides SIP, then name "P2PSIP" does not make sense.=20 when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM=20 To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol?=20 =20 Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms = for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they = do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the = resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope = will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality."=20 =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be.=20 =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 -------------------------------------------------------------------------= --------------------------------------------------- ---------=20 This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it!=20 =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some = AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or = not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should = have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more = complex.=20 =20 _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM=20 To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol?=20 =20 Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide = all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the = capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of = general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT = services.=20 IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 -------------------------------------------------------------------------= --------------------------------------------------- ---------=20 This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it!=20 =20 _____ =20 From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com ]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol?=20 =20 Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new = one that will be designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is = to create a proxy-like peer that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 -----Original Message----- From: Henry Sinnreich [mailto: = hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?"=20 let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and=20 - Other uses besides SIP. Business planning folks may not care about the = WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: = dean.willis@softarmor.com ] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly = seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is = > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service.=20 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the = peer.=20 > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change = it service offering.=20 -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org=20 https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________=20 P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_nsSVohyUSHfFlCh4EeVpQA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Dear Chen,
 
   As you = pointed=20 out, section 5.3 of draft-ietf-p2psip-concepts-00 says:
   = "In=20 addition to Peer Protocol and Client Protocol messages, a P2PSIP Overlay = must=20 also provide a solution to the NAT Traversal problem for SIP messages. = If it=20 does not, there is no reliable way for a peer behind one NAT to send a = SIP=20 INVITE to a peer behind another NAT. One way to solve this problem is to = transport SIP messages along Peer and Client Protocol connections: this = could be=20 done either by encapsulating the SIP messages inside Peer and Client = Protocol=20 messages or by multiplexing SIP with the Peer (resp.Client) Protocol on = a Peer=20 (resp. Client) Protocol connection."
  
   In = this=20 case, those end-point peers (i.e., source and sink peers transmitting = SIP=20 Invite) at least must be able to determine whether the received packets = are SIP=20 message, but please pay attention to this point, it does not mean that = all the=20 peers support SIP (i.e., providing SIP functions such as = proxy).
  =20 The peers can forward those SIP messages by some mechanism such as = RELOAD=20 TRANSPORT-TUNNEL method, at this time those messages are transparent for = intermediate peers, it is not necessary to recognize SIP messages for = those=20 intermediate peers because those intermediate peers only provide P2P = distributed=20 storage/lookup/routing services not requiring SIP.
  P2PSIP = Peers can=20 support SIP, but it not required that P2PSIP Peers must support = SIP.

Best=20 regards,
Zheng Hewen

From: Duan Chen = [mailto:duan.chen@gmail.com]=20
Sent: 2007=C4=EA7=D4=C213=C8=D5 9:33
To: HUANG Ping = B
Cc:=20 p2psip@ietf.org
Subject: Re: [P2PSIP] do we need a client=20 protocol?

Hi, Huang & Zheng:
 
One comment:
  If I understand correctly, the P2PSIP overlay should be able = to=20 transport the SIP message because of the NAT traversal issue between = peers. If=20 it does not, there is no reliable way for a peer behind one NAT to send = a SIP=20 INVITE to a peer behind another NAT (see section 5.3=20 of draft-ietf-p2psip-concepts-00.txt), a P2PSIP peer may or may not = be=20 coupled with a SIP entity, but it should be able to recognize the SIP = message;=20 or how can it encapsulate or multiplex a SIP message along the peer = to peer=20 connections?
 
Thus if there is a device joining the DHT overlay but not able to = recognize=20 the SIP message, it would preclude the approach mentioned above to solve = the NAT=20 issue.
 
thanks and regards!

 
On 7/12/07, HUANG Ping=20 B <Ping.b.Huang@alcatel-sb= ell.com.cn>=20 wrote:=20
Hi = Zheng and=20 marcin
   I have=20 never said that P2PSIP is IP or use SIP. as we know, there are two = mode in=20 P2PSIP, one is SIP over P2P and the other is P2P over SIP.SIP is just = in=20 application layer and P2P or P2PSIP are more like transport layer. in = SIP over=20 P2P, SIP is just one of the protocols interacting with P2P or P2PSIP = overlay.=20 in P2P over SIP, SIP is made some extension. I have never said that = P2PSIP=20 peer protocol shall use SIP, SIP is over P2PSIP! =
   And as I=20 said, peers "SHOULD" not "SHALL" recognize SIP. maybe you "SHALL" read = RFC2119

From: Zheng Hewen [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 5:33 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a=20 client protocol?

 
Hi,
 
   One supplement, FYI.
   In the future P2PSIP deployment, one = device=20 that can provide DHT service but not recognize SIP messages should be = admitted=20 as one member/peer of P2PSIP overlay, we do not have to update the = device to=20 support SIP and then provide DHT service, the cost introduced due = to the=20 update is unnecessary.
 

From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ] =
Sent:=20 2007=C4=EA7=D4=C212=C8=D5 16:57
To: Zheng Hewen; Michal = Giermasinski; p2psip@ietf.org
Subject:=20 RE: [P2PSIP] do we need a client = protocol?

 
I have never said that P2PSIP is equal to = SIP, P2PSIP=20 is just an overlay as an alternative to the SIP discovery process of = RFC 3263,=20 P2PSIP offers an alternative mechanism for determining the correct = destination=20 for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. = of=20 cause, is you use another protocol, P2PSIP may be called another name, = such as=20 P2PXXX. P eers in P2PSIP overlay are = responsible not just for=20 location (done by P2PSIP protocol). Why we called P2PSIP as = "P2PSIP"? =20 this name means that there is a relationship between P2PSIP and SIP, = maybe SIP=20 over P2P or P2P over SIP. but any way, SIP should be used. then Peers = in=20 P2PSIP overlay( not P2PXXX overlay) should recognize SIP message. Ok, = you can=20 say that a tunnel protocol could be used to deliver SIP protocol, this = is a=20 choice, but not good choice. if a tunnel protocol is used, then SIP = has=20 nothing with P2P overlay, this tunnel protocol could deliver any = protocols=20 besides SIP, then name "P2PSIP" does not make sense. =
when peers in P2PSIP overlay do not recognize SIP message, = then let=20 them out of overlay.

From: Zheng Hewen [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a=20 client protocol?

 
Hi,
 
  If=20 I do not misunderstand, P2PSIP is not equal to = SIP.
 =20 Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP.=20 Why must we bind SIP to P2PSIP peers?
  =
 =20 Here is the description about P2PSIP peers in WG charter,=20 FYI.
 =20 "The work focuses on collections of nodes called "P2PSIP peers" = and=20 "P2PSIP clients". P2PSIP peers manifest a distributed namespace in = which=20 overlay users are identified and provides mechanisms for locating = users or=20 resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP = peers=20 primarily in that they do not store information in the overlay, but = only use=20 it to locate users and resources. P2PSIP clients and peers use the = resolution=20 services of the peers as an alternative to the SIP discovery process = of RFC=20 3263. In this way, P2PSIP offers an alternative mechanism for = determining the=20 correct destination for SIP requests. The working group's initial = charter=20 scope will be to produce protocols to enable this alternate mechanism = for RFC=20 3263 functionality."
 
 =20 Nothing says that P2PSIP peers must support SIP or have = anything=20 with SIP.
 =20 From the charter, functionality of P2PSIP peers is so clear and = simple,=20 why do we make it complicated? I think we can do it = simpler, SIP is=20 SIP, P2PSIP peer is P2PSIP peer, let them be. =
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = =20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax:=20 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------=20
This e-mail and its attachments contain confidential information = from=20 HUAWEI, which
is intended only for the person or entity whose = address is=20 listed above. Any use of the
information contained herein in any = way=20 (including, but not limited to, total or partial
disclosure, = reproduction,=20 or dissemination) by persons other than the intended
recipient(s) = is=20 prohibited. If you receive this e-mail in error, please notify the = sender by=20
phone or email immediately and delete it!
 

From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ] =
Sent:=20 2007=C4=EA7=D4=C212=C8=D5 10:22
To: Zheng Hewen; Michal = Giermasinski; p2psip@ietf.org
Subject:=20 RE: [P2PSIP] do we need a client = protocol?

 
Hi=20 all
    P2P is great topic, but P2PSIP is the = subset or=20 certain instance of P2P. when we discuss P2PSIP, we shall not involve = all=20 nodes which could be peers in P2PSIP overlay. peers in P2PSIP overlay = are not=20 equal to peers in P2P overlay. when we discuss IMS, although legacy = equipments=20 does not support SIP, but some AGWs do translation or agent for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers = who know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some = common base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more=20 simple but not more complex.
 
From: Zheng Hewen [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: = 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a=20 client protocol?

 
Hi,
 
    Please let me describe the case in=20 detail.
    In the case, all clients support SIP, = but some=20 peers in the overlay network do not support SIP and some support SIP. = For=20 those peers which do not support SIP, such as some PCs, they can = provide all=20 required DHT services, but there is only a pity that they can not = recognize=20 any SIP message, maybe they think that the capability is unnecessary. = In this=20 case, some client protocol is desirable. Certainly this protocol may = be the=20 subset of general Peer Protocol if we regard those clients as Lame = Peers and=20 regard those peers as Pure Peers who only provide required DHT = services.=20
    IMHO, this case does not care those clients not = supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. =


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax:=20 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------=20
This e-mail and its attachments contain confidential information = from=20 HUAWEI, which
is intended only for the person or entity whose = address is=20 listed above. Any use of the
information contained herein in any = way=20 (including, but not limited to, total or partial
disclosure, = reproduction,=20 or dissemination) by persons other than the intended
recipient(s) = is=20 prohibited. If you receive this e-mail in error, please notify the = sender by=20
phone or email immediately and delete it!
 

From: Michal Giermasinski = [mailto:michal.giermasinski@gmail.com ]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: [P2PSIP] do = we need a=20 client protocol?

 
Hi!
 
Well, in my oppinion it is not a good for creating a new = protocol. If a=20 client application is not able to use SIP protocol that is well known = for=20 years it obviously will not be able to use a new one that will be = designed=20 especially for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better = thing is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that = will be=20 able to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do = not=20 support SIP, those peers are only responsible to
provide = distributed=20 storage, location and transport services for information about SIP, = but=20 those peers do not recognize any
SIP messages at = all.
  In=20 this case, how to maintain the relation between clients (UA) and the = hosting=20 peer(s)? One client protocol is desirable
at this = time.


Zheng=20 Hewen
HUAWEI TECHNOLOGIES=20 CO.,LTD.  huawei_logo


Huihong Mansion
No.91 = Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax:=20 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
-----------------------------------= -------------------------------------------------------------------------= ----------------=20
---------
This e-mail and its attachments contain = confidential=20 information from HUAWEI, which
is intended only for the person = or entity=20 whose address is listed above. Any use of the
information = contained=20 herein in any way (including, but not limited to, total or partial=20
disclosure, reproduction, or dissemination) by persons other = than the=20 intended
recipient(s) is prohibited. If you receive this e-mail = in=20 error, please notify the sender by
phone or email immediately and = delete=20 it!


-----Original Message-----
From: Henry Sinnreich=20 [mailto:=20 hsinnrei@adobe.com]
Sent: 2007?6?26? 1:39
To: Dean Willis; = David=20 A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews =
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives = for the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks,=20 Henry

-----Original Message-----
From: Dean Willis = [mailto:=20 dean.willis@softarmor.com ]
Sent: Thursday, June 14, 2007 = 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better=20 than active/passive) entities
have a
> Peer-ID? In = otherwords, are=20 they part of the overlay at all? If so,
for
> most
> = DHTs,=20 how do we allow you to be in the overlay and not store=20 resources
(not
> typical for most current DHT=20 algorithms)

Well, that certainly depends on the DHT algorithm = involved. It certainly seems that a peer that moves between = contributing=20
and non-contributing might HAVE a peer ID, but whether it = chooses to=20 insert itself into the DHT "right now" might determine
whether it = is=20 contributing "right now"
or not.

> My concern all along = has=20 been that I don't understand why something is
> a peer if it = isn't=20 doing anything other than talking to someone and
> making = requests,=20 hence why I supported client in the first = place.
>  I fail=20 to see how something that isn't contributing anything, and
> = instead=20 talks to a peer to get resources, is in any way a peer. It
> = seems=20 completely not in keeping with the idea of P2P. I also worry = it
> is=20 likely to be very confusing since we've been using the other =
>=20 terminology for over a year now. Just looks like a souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection=20 and wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality=20 make it two different nodes?

> If we do go this way, = there is one=20 subtle point. If I join the overlay
but
> don't happen to = offer any=20 services (other than maybe
storage...depending on
> how we = definie=20 it, that might or might not be mandatory), would I be
> = contributing?=20 If joining the overlay (in the sense that we have = a
PeerID
>=20 and
> we route traffic) doesn't require me to store, I could = offer=20 no
services

That's "offer no other services", since = routing is=20 itself a service.

> and
> still be a peer. How do = we=20 distinguish between this case and a
> "non-contributing peer" = who=20 isn't even part of the overlay (i.e., no
> Peer-ID)

I = think=20 there's a range of "contributing" in play. For most DHT models, a = minimally=20 contributing node will route a request
it receives. It might ask = nicely=20 (perhaps a q-value mechanism) to not have to route requests, but = would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam = onto a=20 WiFi net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org =
https://www1.ietf.org/mailman/listinfo/p2psip=20

_______________________________________________ =
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip=20 =

 

__________________________= _____________________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

=

--Boundary_(ID_nsSVohyUSHfFlCh4EeVpQA)-- --Boundary_(ID_qopbzGmEi7eLz/W6J99HLQ) Content-id: <898021610@13072007-2F3C> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_qopbzGmEi7eLz/W6J99HLQ) Content-id: <898021610@13072007-2F43> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_qopbzGmEi7eLz/W6J99HLQ)-- --===============0294159839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0294159839==-- From p2psip-bounces@ietf.org Fri Jul 13 13:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9PGX-0008T2-Hl; Fri, 13 Jul 2007 13:49:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9PGV-0008Sn-Qq for p2psip@ietf.org; Fri, 13 Jul 2007 13:49:15 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9PGA-0002Wb-P1 for p2psip@ietf.org; Fri, 13 Jul 2007 13:49:15 -0400 Received: from 206-176-144-212.waymark.net ([206.176.144.212]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I9PFb-0005Fc-Uz; Fri, 13 Jul 2007 12:48:20 -0500 In-Reply-To: <4d4304a00707100710j7bb3d528q886d5a91ec074445@mail.gmail.com> References: <3F18E76823C95E4795181D74BAC7664F04BAFE71@esebe102.NOE.Nokia.com> <001801c7c2f9$ed8a2f50$a507740a@DELLWEI> <4d4304a00707100710j7bb3d528q886d5a91ec074445@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <14C8E3BD-5C43-4F22-9AD0-C5B39DB5623B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Fri, 13 Jul 2007 12:48:08 -0500 To: David A. Bryan X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: p2psip@ietf.org Subject: [P2PSIP] Restated question: do we need a client protocol? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jul 10, 2007, at 9:10 AM, David A. Bryan wrote: > > So getting back to the question Brian Rosen raised in Prauge: > > Can anyone find a reason we need a client protocol for *SIP* using > P2P? Clearly we have a reason to have some nodes that have lesser capacity and therefore offer fewer resources or services or whatever we might call them to the overlay. There's absolutely no doubt about this in my mind -- I think we can take it as a postulate. So we're not asking the right question. Let's see if we can get some better questions: 1) Can the range of capacities of nodes be accommodated by one protocol that includes the ability to turn certain capabilities on and off (so that lesser-capable nodes could just not offer the things that are hard for them) or do we need an entirely different protocol for some class of nodes? 2) Assuming that we do need an entirely different protocol for the least-capable nodes, is there a requirement for the least-capable nodes to do anything that cannot already be done with SIP? How could we make this decision? If the peer protocol requires participation in a DHT, such that the node must store data hashed to its peer-ID, OR if the peer protocol requires message-passing capability in all peers, then we probably have a protocol that isn't suitable for nodes connected via 2.5G mobile or something similar. We can either fix this by 1) changing the protocol for all peers such that not all peers require these capabilities, or 2) using a different protocol for peers with these constraints. The current concepts-and-terminology document allows for both approaches, but I'd very much like to come to consensus on a path here, because I think this is going to drive a lot of the work going forward. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 17:36:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9So1-0006p7-Bz; Fri, 13 Jul 2007 17:36:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Snz-0006ov-91 for p2psip@ietf.org; Fri, 13 Jul 2007 17:36:03 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Sny-0001rZ-TJ for p2psip@ietf.org; Fri, 13 Jul 2007 17:36:03 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2007 14:35:44 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALGMl0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175497200"; d="scan'208"; a="8544738:sNHT15283248" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6DLZiL6024117 for ; Fri, 13 Jul 2007 14:35:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6DLZPTD023376 for ; Fri, 13 Jul 2007 21:35:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 14:35:34 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 14:35:33 -0700 Message-ID: <4697F02B.4030506@cisco.com> Date: Fri, 13 Jul 2007 17:35:39 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 21:35:34.0036 (UTC) FILETIME=[BE825540:01C7C595] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3404; t=1184362544; x=1185226544; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Mandatory-to-implement=20DHTs=20-=20a=20dissenting=20opinion |Sender:=20; bh=BoZPxWtaTFYQqwaH1dNZGT8q/GBvcoGTxGe9u9IdQaI=; b=i+T4B1AZTBZJgit5eU51rB4F3pZY3bOJHvynRJqomSeCmc4Fso2euPT7cA5wIhHOqUB+ByRN WrUoR2ggA6qeghINrys8mTXnoBn9vgiCIPSX61tO6RYq/t21tPdHwfKT; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I've read draft-bryan-p2psip-requirements-00, and have a bunch of comments. But a few items came to mind I wanted to discuss which merit their own threads. First, is the concept of mandatory-to-implement DHT. The requirements document talks a lot about requirements around selecting a mandatory to implement DHT. Its something we've discussed in the meeting and on the list. I think everyone agrees also that we need to allow for multiple DHT and all of the recent protocol proposals support it. However, I do not think we should have a mandatory-to-implement DHT at all. There are several reasons for this. First of all, its important to understand the reason why IETF has mandatory-to-implement functionality in its protocols. The one and only reason is that it ensures interoperability. It ensures that, independent of the optional features selected by a pair of entities, when you connect them together, they can still interoperate. This property will NOT be retained with a mandatory-to-implement DHT. Once the ring forms, the DHT protocol is chosen and locked. Thus, if any DHT besides the 'mandatory-to-implement' one has been selected for the DHT, a new node not supporting that DHT will not be able to join the ring even if it implements the mandatory-to-implement one. Thus, the entire purpose of mandatory-to-implement is eliminated - we don't actually get interoperability. Indeed, to get this kind of interoperability, we'd need to pick one and only one DHT that ever gets used with p2psip. I think that is a mistake. This is an evolving area and is one where agility is important. Instead, what I think happens is that a 'provider' that deploys a p2p network will need to pick a DHT, and make sure that the clients all support that DHT. This is something the market should drive, not us. Secondly, I think its important to realize that we are picking up work in an area that is well trod. There are lots and lots of papers and protocols and software written around P2P networks. I don't think anyone looks at an IETF protocol and says, "IETF are the guys who know about DHTs, lets go with their recommendation". What IETF is really good at, and what this group has expertise in, is SIP, and on designing good, scalable protocols in general - things that have security, extensibility, good performance, and so on. So I think the greatest value we can bring to the table is to create a protocol that allows others to take DHTs and easily turn them into a real wire protocol that you can actually deploy, on the Internet, to support SIP and ideally other things too. Interestingly, this is exactly what all of the protocol proposals do. That kind of focus goes hand-in-hand with saying, let someone else figure out which DHT to use. I think its perfectly reasonable for us, and for others, to write documents on how to use our protocol with various DHTs. But I think we should be out of the business of picking one or recommending one (or ones) to be used. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 17:48:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9T0K-0007gw-LX; Fri, 13 Jul 2007 17:48:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9T0I-0007gl-Um for p2psip@ietf.org; Fri, 13 Jul 2007 17:48:46 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9T0E-0000y3-Cf for p2psip@ietf.org; Fri, 13 Jul 2007 17:48:46 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Fri, 13 Jul 2007 14:48:40 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6DLmZWs022911; Fri, 13 Jul 2007 14:48:39 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6DLmL0g004559; Fri, 13 Jul 2007 14:48:34 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 14:48:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Fri, 13 Jul 2007 14:48:11 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AA9C89@namail5.corp.adobe.com> In-Reply-To: <4697F02B.4030506@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfFldfv+lDlyVkuRK+lCoF3Daj8pQAAPI3g References: <4697F02B.4030506@cisco.com> From: "Henry Sinnreich" To: "Jonathan Rosenberg" , "P2PSIP WG" X-OriginalArrivalTime: 13 Jul 2007 21:48:23.0413 (UTC) FILETIME=[8917F250:01C7C597] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Jonathan, Would it make sense to replace "mandatory" with "default"? After all, there are just as many advantages in having a good chance of interoperability as in flexibility for the future. It's also useful to have a smallest common denominator to measure and compare various implementations. Henry -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Friday, July 13, 2007 2:36 PM To: P2PSIP WG Subject: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion I've read draft-bryan-p2psip-requirements-00, and have a bunch of=20 comments. But a few items came to mind I wanted to discuss which merit=20 their own threads. First, is the concept of mandatory-to-implement DHT. The requirements=20 document talks a lot about requirements around selecting a mandatory to=20 implement DHT. Its something we've discussed in the meeting and on the=20 list. I think everyone agrees also that we need to allow for multiple=20 DHT and all of the recent protocol proposals support it. However, I do not think we should have a mandatory-to-implement DHT at all. There are several reasons for this. First of all, its important to=20 understand the reason why IETF has mandatory-to-implement functionality=20 in its protocols. The one and only reason is that it ensures=20 interoperability. It ensures that, independent of the optional features=20 selected by a pair of entities, when you connect them together, they can still interoperate. This property will NOT be retained with a mandatory-to-implement DHT.=20 Once the ring forms, the DHT protocol is chosen and locked. Thus, if any DHT besides the 'mandatory-to-implement' one has been selected for the DHT, a new node not supporting that DHT will not be able to join the=20 ring even if it implements the mandatory-to-implement one. Thus, the=20 entire purpose of mandatory-to-implement is eliminated - we don't=20 actually get interoperability. Indeed, to get this kind of interoperability, we'd need to pick one and=20 only one DHT that ever gets used with p2psip. I think that is a mistake. This is an evolving area and is one where agility is important. Instead, what I think happens is that a 'provider' that deploys a p2p=20 network will need to pick a DHT, and make sure that the clients all=20 support that DHT. This is something the market should drive, not us. Secondly, I think its important to realize that we are picking up work=20 in an area that is well trod. There are lots and lots of papers and=20 protocols and software written around P2P networks. I don't think anyone looks at an IETF protocol and says, "IETF are the guys who know about=20 DHTs, lets go with their recommendation". What IETF is really good at,=20 and what this group has expertise in, is SIP, and on designing good,=20 scalable protocols in general - things that have security,=20 extensibility, good performance, and so on. So I think the greatest=20 value we can bring to the table is to create a protocol that allows=20 others to take DHTs and easily turn them into a real wire protocol that=20 you can actually deploy, on the Internet, to support SIP and ideally=20 other things too. Interestingly, this is exactly what all of the=20 protocol proposals do. That kind of focus goes hand-in-hand with saying, let someone else figure out which DHT to use. I think its perfectly=20 reasonable for us, and for others, to write documents on how to use our=20 protocol with various DHTs. But I think we should be out of the business of picking one or recommending one (or ones) to be used. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 17:49:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9T0w-00081G-Cj; Fri, 13 Jul 2007 17:49:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9T0u-00080m-F3 for p2psip@ietf.org; Fri, 13 Jul 2007 17:49:24 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9T0u-0002EP-3D for p2psip@ietf.org; Fri, 13 Jul 2007 17:49:24 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2007 14:49:23 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACqQl0arR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175497200"; d="scan'208"; a="8547300:sNHT14259180" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6DLnNOQ007989 for ; Fri, 13 Jul 2007 14:49:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6DLnN6M018996 for ; Fri, 13 Jul 2007 21:49:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 14:49:21 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 14:49:21 -0700 Message-ID: <4697F367.6000809@cisco.com> Date: Fri, 13 Jul 2007 17:49:27 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 21:49:21.0762 (UTC) FILETIME=[ABDF4C20:01C7C597] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3316; t=1184363363; x=1185227363; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20HBH=20vs.=20E2E=20SIP=20in=20P2PSIP |Sender:=20; bh=2Qa8KnwxbxE6lOQihpUQk5Y+tkMzeAUnYAqnObUpg4A=; b=hj3Q5/G1aLltKMLq7sj+Y4hrCrSFUgaf1vfXkQf0HLEl8PUo7j7BCVsSobXwgrcgq49ixiYe MhGMTEReH/GrSH8oPHlP53VQDi/LfRE2OfT9GTHzohEFXyzr9Tatpqg9; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [P2PSIP] HBH vs. E2E SIP in P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org draft-bryan-p2psip-requirements-00 talks about how SIP relates to the P2P protocol. It says: > The above discussion suggests at least two paradigms for SIP > operation in a p2p setting: the end-to-end paradigm where a SIP user > agent uses the p2p location service to discover the location of > callee, and then send the SIP message directly to the callee, or a > hop-by-hop paradigm where each peer forwards the SIP request to a > peer which is more 'closer' to the callee. The former can be thought > of as a RPC whereas the later can be thought of as a local procedure > call to determine the next hop. I'd like to propose that, any model which views the peers in the p2p network as proxies (things that add Via headers, follow proxy rules as defined in RFC 3261, and so on), is basically fatally flawed from a security perspective. SIP was not designed on a model of untrusted proxies. I know this keeps coming up time and time again in the core SIP mailing list. The problem is, the design of SIP quite purposefully gives SIP proxies pretty wide latitude in manipulating message contents and doing things. We have some limited protection, if you believe in things like S/MIME, but by its very definition, SIP allows proxies to do lots of stuff. They can send requests to different places, they can fork, they can send responses, they can add and remove headers, they can change the destination of a request. All of it is legal and makes sense in a proxy-routed model. However, in P2PSIP, if you think of the peers as proxies, you enter a use case where you trust none of the proxies, and in fact every call has a whole lot of them on the signaling path (O(logN)). I guarantee you that these untrusted proxies will launch attacks that are hard to fix without basically completely changing the way the SIP protocol works. So, don't do it. The way you limit what peers can do is by using a protocol to communicate with peers whose very design limits what can be done. A protocol built from the ground up to do nothing but give an intermediary the ability to move a message around based on DHT topology. You wouldn't need to worry about things modifying media destinations since there is no SDP. You needn't worry about spoofing caller ID since there is no caller ID in the protocol. All you do is use this protocol to allow you to set up a secure, e2e, TLS connection between you and the UA you want to talk to, and then run SIP over that. The great benefit is that SIP already allows UA to UA communications. It always has. P2PSIP then slides in as a pure, clean replacement for RFC3263, allowing you to identify the target UA that you want to connect to, and provide a means for connecting to them through firewalls and NATs. Thus I'd like to suggest that the E2E SIP model described in the requirements document be the one we are shooting for. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 17:58:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9TA2-0004AH-WC; Fri, 13 Jul 2007 17:58:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9TA0-000409-T5 for p2psip@ietf.org; Fri, 13 Jul 2007 17:58:48 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9TA0-0002SA-EJ for p2psip@ietf.org; Fri, 13 Jul 2007 17:58:48 -0400 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Fri, 13 Jul 2007 14:57:37 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6DLvaWs023992; Fri, 13 Jul 2007 14:57:36 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6DLvF0o005296; Fri, 13 Jul 2007 14:57:35 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 14:57:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] HBH vs. E2E SIP in P2PSIP Date: Fri, 13 Jul 2007 14:56:56 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AA9C91@namail5.corp.adobe.com> In-Reply-To: <4697F367.6000809@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] HBH vs. E2E SIP in P2PSIP Thread-Index: AcfFl7NYzqLvFgqITFy5hvfWvFHWMwAAG7tg References: <4697F367.6000809@cisco.com> From: "Henry Sinnreich" To: "Jonathan Rosenberg" , "P2PSIP WG" X-OriginalArrivalTime: 13 Jul 2007 21:57:18.0587 (UTC) FILETIME=[C81504B0:01C7C598] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Jonathan, Though I have co-authored the document, I believe you are right here: >> hop-by-hop paradigm where each peer forwards the SIP request to a=20 >> peer which is more 'closer' to the callee. > is basically fatally flawed from a security perspective. On 2nd thought it is also not desirable for other reasons, such call setup delay, higher risk of packet loss and more bandwidth/computing consumption. Good catch. Henry -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Friday, July 13, 2007 2:49 PM To: P2PSIP WG Subject: [P2PSIP] HBH vs. E2E SIP in P2PSIP draft-bryan-p2psip-requirements-00 talks about how SIP relates to the=20 P2P protocol. It says: > The above discussion suggests at least two paradigms for SIP=20 > operation in a p2p setting: the end-to-end paradigm where a SIP user=20 > agent uses the p2p location service to discover the location of=20 > callee, and then send the SIP message directly to the callee, or a=20 > hop-by-hop paradigm where each peer forwards the SIP request to a=20 > peer which is more 'closer' to the callee. The former can be thought=20 > of as a RPC whereas the later can be thought of as a local procedure=20 > call to determine the next hop.=20 I'd like to propose that, any model which views the peers in the p2p=20 network as proxies (things that add Via headers, follow proxy rules as=20 defined in RFC 3261, and so on), is basically fatally flawed from a=20 security perspective. SIP was not designed on a model of untrusted proxies. I know this keeps=20 coming up time and time again in the core SIP mailing list. The problem=20 is, the design of SIP quite purposefully gives SIP proxies pretty wide=20 latitude in manipulating message contents and doing things. We have some limited protection, if you believe in things like S/MIME, but by its=20 very definition, SIP allows proxies to do lots of stuff. They can send=20 requests to different places, they can fork, they can send responses,=20 they can add and remove headers, they can change the destination of a=20 request. All of it is legal and makes sense in a proxy-routed model. However, in P2PSIP, if you think of the peers as proxies, you enter a=20 use case where you trust none of the proxies, and in fact every call has a whole lot of them on the signaling path (O(logN)). I guarantee you=20 that these untrusted proxies will launch attacks that are hard to fix=20 without basically completely changing the way the SIP protocol works. So, don't do it. The way you limit what peers can do is by using a protocol to=20 communicate with peers whose very design limits what can be done. A=20 protocol built from the ground up to do nothing but give an intermediary the ability to move a message around based on DHT topology. You wouldn't need to worry about things modifying media destinations since there is=20 no SDP. You needn't worry about spoofing caller ID since there is no=20 caller ID in the protocol. All you do is use this protocol to allow you=20 to set up a secure, e2e, TLS connection between you and the UA you want=20 to talk to, and then run SIP over that. The great benefit is that SIP already allows UA to UA communications. It always has. P2PSIP then slides in as a pure, clean replacement for=20 RFC3263, allowing you to identify the target UA that you want to connect to, and provide a means for connecting to them through firewalls and NATs. Thus I'd like to suggest that the E2E SIP model described in the=20 requirements document be the one we are shooting for. Thanks, Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 18:02:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9TDA-00068H-5F; Fri, 13 Jul 2007 18:02:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9TD9-00068C-H0 for p2psip@ietf.org; Fri, 13 Jul 2007 18:02:03 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9TD9-0002fb-0n for p2psip@ietf.org; Fri, 13 Jul 2007 18:02:03 -0400 Received: (qmail 26964 invoked for bounce); 14 Jul 2007 00:03:48 -0000 Received: from unknown (HELO ?192.168.0.1?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 14 Jul 2007 00:03:48 -0000 Message-ID: <4697F643.1040204@sip-communicator.org> Date: Sat, 14 Jul 2007 00:01:39 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070622) MIME-Version: 1.0 To: P2PSIP Mailing List References: <4697558C.5000702@telecomitalia.it> In-Reply-To: <4697558C.5000702@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Bryan Ford Subject: [P2PSIP] Re: comment on draft-marocco-p2psip-xpp-00 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hey Bryan, (inline) Enrico Marocco wrote: > Bryan Ford wrote: >> Dear Enrico and Emil, >> ... >> This statement is incorrect, and seems to be a common misconception >> regarding TCP nat traversal. As long as the applications on both >> endpoints first bind a listen socket to the TCP port they will use >> before starting the hole punching process (via outgoing connect sockets >> from the same ports), and as long as the OS implements the TCP state >> machine correctly (which all major OSes do now, the only known recent >> exception being Windows XP before SP2), the applications will connect >> reliably in the no-NAT case with no spurious RSTs. Good point. Actually I was already having doubts about this after I saw a related discussion on MMUSIC. You are of course right, and this will when both peers are public. Still, the whole thing is quite tricky to implement and obliges developers to follow routines that they shouldn't be required to care about. In order to have this working for two sockets one has to: Instead of simply opening a socket, a programmer would have to have at least two of them. Then declaration , initilization (setsockopt), binding, connecting and accepting a connection for these 2sockets have to be executed in a strict order. And in the end, before the connection is established, you are manipulating the different socket instances without knowing which one you are actually going to be using. Even if we get APIs that do this transparently for the programmer, it'll still mean an extra layer and a number of abstractions that are being used without a good reason. It does make sense to have such techniques used in ICE-TCP, so that they could be employed for existing solutions when necessary, but we should keep in mind that this is a workaround (not a design choice), and probably something that would be best to avoid relying on when standardizing new protocols. I think you are also making a similar point in your paper, and I guess we need to mention this in the draft. > The only potential >> problem with spurious RSTs occurs if there *are* NATs on the path, and >> at least one of them is "poorly behaved". For details, see for example >> my p2p-over-NAT paper from USENIX 2005 >> (http://www.brynosaurus.com/pub/net/p2pnat/). >> >> UDP still may be a better choice than TCP for a protocol that wants to >> traverse NATs, just because more existing NATs in the wild are already >> NAT traversal friendly for UDP than for TCP (see the same paper for >> example, or Guha and Francis's more detailed analysis of specific >> NATs). So you don't need the incorrect statement above to motivate your >> work anyway. Thanks for the tip! We'll make sure it gets in xpp's next version. Cheers Emil > > Yep, Bryan, you are right. SO_REUSEADDR socket option can be used to > open a socket in listen state on a port which can later be bound by > another socket for connecting, and this would prevent the OS to answer > RSTs to SYNs. Thank you for pointing out the bogus statement, we'll fix it. > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 18:16:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9TRE-0001R7-W8; Fri, 13 Jul 2007 18:16:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9TRB-0001QQ-J9 for p2psip@ietf.org; Fri, 13 Jul 2007 18:16:33 -0400 Received: from py-out-1112.google.com ([64.233.166.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9TR7-0001no-44 for p2psip@ietf.org; Fri, 13 Jul 2007 18:16:33 -0400 Received: by py-out-1112.google.com with SMTP id f31so1830784pyh for ; Fri, 13 Jul 2007 15:16:28 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=glWyXShA13lb5devQbaDMOquH8LlDcuLlkr2N6MXTHvTo4kWKceUgkaVb6RGgQINUI2P89nFiRbrA00GQ4cmyCpCouDtM4HFpz4k7xrxfoURGzJjn0MUaA5rPsFaXjrrlXsNIZksYor3zFKlWjouHBCQtIVbWPM4lgyF9BZs2sQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=j1E0orPyu2paHBnhZ3KCfYM7RUeqiuE5dDHkgQET3ZJxRS5dR9X1tEqFFViCKQ/vc6AyldZlnl8OU2FIZdeHLKXQFu/X+mlSzR5e1AJb9JlX5svZM96r0bxxwZP3yTNGq2op6O26FFLKvWpxKbZpnoG9ovbjlkyI2X44jHNpPD4= Received: by 10.65.121.9 with SMTP id y9mr3825057qbm.1184364988567; Fri, 13 Jul 2007 15:16:28 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Fri, 13 Jul 2007 15:16:28 -0700 (PDT) Message-ID: <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> Date: Fri, 13 Jul 2007 15:16:28 -0700 From: "David A. Bryan" To: "Jonathan Rosenberg" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <4697F02B.4030506@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4697F02B.4030506@cisco.com> X-Google-Sender-Auth: f6cf23fd466a56c8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think this likely to be a source of serious discussion. At least for now (maybe Jonathan can convince me), I'm inclined to disagree. I think the problem is that if we don't specify a mandatory to implement, there may be many devices from different vendors that don't even implement a common DHT. Each will pick and choose which DHTs to implement, and in the end, there won't be a common DHT all can even run if they want to. I think looking at it from the perspective of "once the DHT chosen it is locked" is the wrong way to look at it. The idea isn't that any device can join any already established overlay, but that if I deploy a system of heterogeneous devices, there is at least one that I can select when I start and know that all "P2PSIP endpoints" (assuming that term means anything) will at least support that and I can form an overlay with them. Maybe not the ideal DHT for my overlay, but something I know all devices can support, and if I run it in that mode, it works. Personally, I think if we don't do that, many DHTs will be standardized for different environments (good) but each vendor will implement a (potentially disjoint) subset, and there may be no way to use two endpoints from different vendors together at all. I agree that if a user selects a non-mandatory DHT, they may risk not being fully interoperable, but I think if we don't pick one at all, we almost guarantee things won't be interoperable. And I (and I think nearly everyone) is 100% in the camp of "we should allow pluggable DHTs". I think it is safe to say that one is a done deal, but I would personally have thought a mandatory was as well. In any case, my vote is definitely for pluggable DHTs. David On 7/13/07, Jonathan Rosenberg wrote: > I've read draft-bryan-p2psip-requirements-00, and have a bunch of > comments. But a few items came to mind I wanted to discuss which merit > their own threads. > > First, is the concept of mandatory-to-implement DHT. The requirements > document talks a lot about requirements around selecting a mandatory to > implement DHT. Its something we've discussed in the meeting and on the > list. I think everyone agrees also that we need to allow for multiple > DHT and all of the recent protocol proposals support it. > > However, I do not think we should have a mandatory-to-implement DHT at all. > > There are several reasons for this. First of all, its important to > understand the reason why IETF has mandatory-to-implement functionality > in its protocols. The one and only reason is that it ensures > interoperability. It ensures that, independent of the optional features > selected by a pair of entities, when you connect them together, they can > still interoperate. > > This property will NOT be retained with a mandatory-to-implement DHT. > Once the ring forms, the DHT protocol is chosen and locked. Thus, if any > DHT besides the 'mandatory-to-implement' one has been selected for the > DHT, a new node not supporting that DHT will not be able to join the > ring even if it implements the mandatory-to-implement one. Thus, the > entire purpose of mandatory-to-implement is eliminated - we don't > actually get interoperability. > > Indeed, to get this kind of interoperability, we'd need to pick one and > only one DHT that ever gets used with p2psip. I think that is a mistake. > This is an evolving area and is one where agility is important. > > Instead, what I think happens is that a 'provider' that deploys a p2p > network will need to pick a DHT, and make sure that the clients all > support that DHT. This is something the market should drive, not us. > > Secondly, I think its important to realize that we are picking up work > in an area that is well trod. There are lots and lots of papers and > protocols and software written around P2P networks. I don't think anyone > looks at an IETF protocol and says, "IETF are the guys who know about > DHTs, lets go with their recommendation". What IETF is really good at, > and what this group has expertise in, is SIP, and on designing good, > scalable protocols in general - things that have security, > extensibility, good performance, and so on. So I think the greatest > value we can bring to the table is to create a protocol that allows > others to take DHTs and easily turn them into a real wire protocol that > you can actually deploy, on the Internet, to support SIP and ideally > other things too. Interestingly, this is exactly what all of the > protocol proposals do. That kind of focus goes hand-in-hand with saying, > let someone else figure out which DHT to use. I think its perfectly > reasonable for us, and for others, to write documents on how to use our > protocol with various DHTs. But I think we should be out of the business > of picking one or recommending one (or ones) to be used. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 18:30:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Tf5-0005Jo-Ke; Fri, 13 Jul 2007 18:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Tf2-0005GK-PI for p2psip@ietf.org; Fri, 13 Jul 2007 18:30:52 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Tey-0002Fo-Cm for p2psip@ietf.org; Fri, 13 Jul 2007 18:30:52 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6DMUjQi032061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jul 2007 15:30:46 -0700 Received: from [76.102.92.155] (carbuncle.qualcomm.com [129.46.226.38]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6DMUi9l016102; Fri, 13 Jul 2007 15:30:45 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> References: <4697F02B.4030506@cisco.com> <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> Date: Fri, 13 Jul 2007 15:30:43 -0700 To: "David A. Bryan" , "Jonathan Rosenberg" From: Ted Hardie Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At 3:16 PM -0700 7/13/07, David A. Bryan wrote: >Personally, I think if we don't do that, many DHTs will be >standardized for different environments (good) but each vendor will >implement a (potentially disjoint) subset, and there may be no way to >use two endpoints from different vendors together at all. I had understood a design goal of this work to be that endpoints could speak SIP from an overlay to a SIP user attached to a proxy. I also understood communication between overlays to be in scope. Did I get that wrong? >I agree that if a user selects a non-mandatory DHT, they may risk not >being fully interoperable, but I think if we don't pick one at all, we >almost guarantee things won't be interoperable. > >And I (and I think nearly everyone) is 100% in the camp of "we should >allow pluggable DHTs". I think it is safe to say that one is a done >deal, but I would personally have thought a mandatory was as well. In >any case, my vote is definitely for pluggable DHTs. I'm strongly in favor of a framework-based approach. I think Jonathan makes a good case that a mandatory-to-implement mechanism for forming overlays has fewer benefits than it might appear. There seem to be a couple of ways past that. I tend to think extending the design goals for the interchange mechanism to make inter-overlay communication a very explicit goal seems like that way to go; *that* becomes mandatory to implement, where the overlay formation remains agile. Two cents from, Ted Hardie _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 19:11:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9UIo-0000z7-7Z; Fri, 13 Jul 2007 19:11:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9UIm-0000yx-93 for p2psip@ietf.org; Fri, 13 Jul 2007 19:11:56 -0400 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9UIl-0004em-Qj for p2psip@ietf.org; Fri, 13 Jul 2007 19:11:56 -0400 Received: (qmail 27312 invoked for bounce); 14 Jul 2007 01:13:17 -0000 Received: from unknown (HELO ?192.168.0.1?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 14 Jul 2007 01:13:17 -0000 Message-ID: <4698068B.8010101@sip-communicator.org> Date: Sat, 14 Jul 2007 01:11:07 +0200 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.4 (X11/20070622) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion References: <4697F02B.4030506@cisco.com> <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Ted Hardie wrote: > I'm strongly in favor of a framework-based approach. I think Jonathan > makes a good case that a mandatory-to-implement mechanism for > forming overlays has fewer benefits than it might appear. There seem > to be a couple of ways past that. I tend to think extending the design > goals for the interchange mechanism to make inter-overlay communication > a very explicit goal seems like that way to go. I find that David has made quite a good point here. What happens when you have a Grandstream, a Linksys and some softphone all running in your office? Are they supposed to establish 3 different overlays and then try to maintain inter-overlay communication with each other? I'd personally expect to be able to configure every one of them and find at least one entry in a DHT combo box, that all three are bound have. Emil ; *that* becomes mandatory > to implement, where the overlay formation remains agile. > > Two cents from, > Ted Hardie > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 20:03:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9V6E-0008GR-Ka; Fri, 13 Jul 2007 20:03:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9V6D-0008GC-F1 for p2psip@ietf.org; Fri, 13 Jul 2007 20:03:01 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9V6D-0006GQ-1n for p2psip@ietf.org; Fri, 13 Jul 2007 20:03:01 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6E02EOg010492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Jul 2007 20:02:15 -0400 (EDT) In-Reply-To: <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> References: <4697F02B.4030506@cisco.com> <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Fri, 13 Jul 2007 20:02:12 -0400 To: "David A. Bryan" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Lack of a common DHT does not necessarily interfere with interoperability. The client protocol, at least in our thinking, is independent of the DHT, so a node that doesn't implement the DHT algorithm of the overlay it wants to talk to can still reach others, it just can't be a full peer. Since typically only a small fraction of nodes need to act as peers at any given time, this may not be much of a problem. You could design a system that essentially replicated the key-data mappings across two DHT algorithm, a baseline universal one and the "fancy"/"better" one less universally spoken. This incurs significantly more overhead and probably yields some strange partial reachability cases particularly as new nodes are added, but it could be done. Henning On Jul 13, 2007, at 6:16 PM, David A. Bryan wrote: > I think this likely to be a source of serious discussion. At least for > now (maybe Jonathan can convince me), I'm inclined to disagree. > > I think the problem is that if we don't specify a mandatory to > implement, there may be many devices from different vendors that don't > even implement a common DHT. Each will pick and choose which DHTs to > implement, and in the end, there won't be a common DHT all can even > run if they want to. > > I think looking at it from the perspective of "once the DHT chosen it > is locked" is the wrong way to look at it. The idea isn't that any > device can join any already established overlay, but that if I deploy > a system of heterogeneous devices, there is at least one that I can > select when I start and know that all "P2PSIP endpoints" (assuming > that term means anything) will at least support that and I can form an > overlay with them. Maybe not the ideal DHT for my overlay, but > something I know all devices can support, and if I run it in that > mode, it works. > > Personally, I think if we don't do that, many DHTs will be > standardized for different environments (good) but each vendor will > implement a (potentially disjoint) subset, and there may be no way to > use two endpoints from different vendors together at all. > > I agree that if a user selects a non-mandatory DHT, they may risk not > being fully interoperable, but I think if we don't pick one at all, we > almost guarantee things won't be interoperable. > > And I (and I think nearly everyone) is 100% in the camp of "we should > allow pluggable DHTs". I think it is safe to say that one is a done > deal, but I would personally have thought a mandatory was as well. In > any case, my vote is definitely for pluggable DHTs. > > David > > On 7/13/07, Jonathan Rosenberg wrote: >> I've read draft-bryan-p2psip-requirements-00, and have a bunch of >> comments. But a few items came to mind I wanted to discuss which >> merit >> their own threads. >> >> First, is the concept of mandatory-to-implement DHT. The requirements >> document talks a lot about requirements around selecting a >> mandatory to >> implement DHT. Its something we've discussed in the meeting and on >> the >> list. I think everyone agrees also that we need to allow for multiple >> DHT and all of the recent protocol proposals support it. >> >> However, I do not think we should have a mandatory-to-implement >> DHT at all. >> >> There are several reasons for this. First of all, its important to >> understand the reason why IETF has mandatory-to-implement >> functionality >> in its protocols. The one and only reason is that it ensures >> interoperability. It ensures that, independent of the optional >> features >> selected by a pair of entities, when you connect them together, >> they can >> still interoperate. >> >> This property will NOT be retained with a mandatory-to-implement DHT. >> Once the ring forms, the DHT protocol is chosen and locked. Thus, >> if any >> DHT besides the 'mandatory-to-implement' one has been selected >> for the >> DHT, a new node not supporting that DHT will not be able to join the >> ring even if it implements the mandatory-to-implement one. Thus, the >> entire purpose of mandatory-to-implement is eliminated - we don't >> actually get interoperability. >> >> Indeed, to get this kind of interoperability, we'd need to pick >> one and >> only one DHT that ever gets used with p2psip. I think that is a >> mistake. >> This is an evolving area and is one where agility is important. >> >> Instead, what I think happens is that a 'provider' that deploys a p2p >> network will need to pick a DHT, and make sure that the clients all >> support that DHT. This is something the market should drive, not us. >> >> Secondly, I think its important to realize that we are picking up >> work >> in an area that is well trod. There are lots and lots of papers and >> protocols and software written around P2P networks. I don't think >> anyone >> looks at an IETF protocol and says, "IETF are the guys who know about >> DHTs, lets go with their recommendation". What IETF is really good >> at, >> and what this group has expertise in, is SIP, and on designing good, >> scalable protocols in general - things that have security, >> extensibility, good performance, and so on. So I think the greatest >> value we can bring to the table is to create a protocol that allows >> others to take DHTs and easily turn them into a real wire protocol >> that >> you can actually deploy, on the Internet, to support SIP and ideally >> other things too. Interestingly, this is exactly what all of the >> protocol proposals do. That kind of focus goes hand-in-hand with >> saying, >> let someone else figure out which DHT to use. I think its perfectly >> reasonable for us, and for others, to write documents on how to >> use our >> protocol with various DHTs. But I think we should be out of the >> business >> of picking one or recommending one (or ones) to be used. >> >> -Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 20:06:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9V9D-0006yB-5w; Fri, 13 Jul 2007 20:06:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9V9B-0006xw-VP for p2psip@ietf.org; Fri, 13 Jul 2007 20:06:06 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9V9B-0006Jc-K6 for p2psip@ietf.org; Fri, 13 Jul 2007 20:06:05 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6E04whQ008140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jul 2007 17:04:59 -0700 Received: from [76.102.92.155] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6E04vpt020640; Fri, 13 Jul 2007 17:04:58 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4698068B.8010101@sip-communicator.org> References: <4697F02B.4030506@cisco.com> <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <4698068B.8010101@sip-communicator.org> Date: Fri, 13 Jul 2007 17:04:56 -0700 To: Emil Ivov From: Ted Hardie Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At 1:11 AM +0200 7/14/07, Emil Ivov wrote: >Ted Hardie wrote: >> I'm strongly in favor of a framework-based approach. I think Jonathan >> makes a good case that a mandatory-to-implement mechanism for >> forming overlays has fewer benefits than it might appear. There seem >> to be a couple of ways past that. I tend to think extending the design >> goals for the interchange mechanism to make inter-overlay communication >> a very explicit goal seems like that way to go. > >I find that David has made quite a good point here. What happens when >you have a Grandstream, a Linksys and some softphone all running in your >office? Are they supposed to establish 3 different overlays and then try >to maintain inter-overlay communication with each other? > >I'd personally expect to be able to configure every one of them and find >at least one entry in a DHT combo box, that all three are bound have. > Given a plug-in architecture, you would presumably plug in the same one to each of these when you created the overlay. For static devices, yes, you might have to create more than one overly and do inter-overlay devices (for three, I'd buy new, but I'm reckless that way). That would be bad, especially if static-capability devices were ubiquitous and had chosen competing methods for setting up overlays. But should we really be aiming at either static devices or a long-term least common denominator? The Security area is currently talking up the value of algorithm agility, because they are discovering that things that don't have that built in are wicked hard to change when they need to. Having agility here seems something that needs to be built in now and a built-in default seems to me to push against that in some bad ways. (I'm out of cents, as it is the weekend, so accept my) regards, Ted _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 13 20:21:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9VNm-0002zn-LO; Fri, 13 Jul 2007 20:21:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9VNg-0002zM-QV for p2psip@ietf.org; Fri, 13 Jul 2007 20:21:04 -0400 Received: from wa-out-1112.google.com ([209.85.146.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9VNb-0005sH-Ml for p2psip@ietf.org; Fri, 13 Jul 2007 20:21:04 -0400 Received: by wa-out-1112.google.com with SMTP id k17so902750waf for ; Fri, 13 Jul 2007 17:20:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=jNi00ejICbhyLV6qwicY1Kwc+nLr1S7VsI2X/7wFH1m1CwYNJY+Hx0xB2/aTrI1mtTa+25RjO2qtGasKPC9ppaG0+/hH+6pK/ruKHWm8aJi+iR8FLf4QRFehB3EsnPiew3rKwZ5n7mxEuXCF8/+QMufawEKlwWi2/3sf1oxWALU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=WNnKydWdS/c7WISWfT9SsdQUwpGuTptFG5WUsJOxP52s4+2fVsmTD0OWQ5+Uf8iKNKdRzQeaeHVqJF6y1IYbhli7aauLDFJ+Isiss6stGXckrD6AEhfcKhiCevBr90G1G99Yzc6xBpFRTmAmIrvb+qvh99s33V3Bl8jy56MUf3w= Received: by 10.114.108.15 with SMTP id g15mr2129831wac.1184372458267; Fri, 13 Jul 2007 17:20:58 -0700 (PDT) Received: by 10.114.171.10 with HTTP; Fri, 13 Jul 2007 17:20:58 -0700 (PDT) Message-ID: <894e079b0707131720u2760c42am83c9c9789855dec9@mail.gmail.com> Date: Fri, 13 Jul 2007 20:20:58 -0400 From: "Medhavi Bhatia" To: "Henning Schulzrinne" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> MIME-Version: 1.0 References: <4697F02B.4030506@cisco.com> <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> X-Google-Sender-Auth: 9eb0b0016f89e26f X-Spam-Score: 0.5 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0389135471==" Errors-To: p2psip-bounces@ietf.org --===============0389135471== Content-Type: multipart/alternative; boundary="----=_Part_36994_27561682.1184372458221" ------=_Part_36994_27561682.1184372458221 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't think the DHT is something which gets negotiated between two nodes. So I don't think we need to look at the mandatory DHT in the same way as we look as at a mandatory codec. The requirement here is to prevent a situation where all vendors implement their own DHT to gain commercial advantage. If we don't pick a mandatory DHT, someone else outside this group will end up doing that anyway - maybe Skype ;) On 7/13/07, Henning Schulzrinne wrote: > > Lack of a common DHT does not necessarily interfere with > interoperability. The client protocol, at least in our thinking, is > independent of the DHT, so a node that doesn't implement the DHT > algorithm of the overlay it wants to talk to can still reach others, > it just can't be a full peer. Since typically only a small fraction > of nodes need to act as peers at any given time, this may not be much > of a problem. > > You could design a system that essentially replicated the key-data > mappings across two DHT algorithm, a baseline universal one and the > "fancy"/"better" one less universally spoken. This incurs > significantly more overhead and probably yields some strange partial > reachability cases particularly as new nodes are added, but it could > be done. > > Henning > > On Jul 13, 2007, at 6:16 PM, David A. Bryan wrote: > > > I think this likely to be a source of serious discussion. At least for > > now (maybe Jonathan can convince me), I'm inclined to disagree. > > > > I think the problem is that if we don't specify a mandatory to > > implement, there may be many devices from different vendors that don't > > even implement a common DHT. Each will pick and choose which DHTs to > > implement, and in the end, there won't be a common DHT all can even > > run if they want to. > > > > I think looking at it from the perspective of "once the DHT chosen it > > is locked" is the wrong way to look at it. The idea isn't that any > > device can join any already established overlay, but that if I deploy > > a system of heterogeneous devices, there is at least one that I can > > select when I start and know that all "P2PSIP endpoints" (assuming > > that term means anything) will at least support that and I can form an > > overlay with them. Maybe not the ideal DHT for my overlay, but > > something I know all devices can support, and if I run it in that > > mode, it works. > > > > Personally, I think if we don't do that, many DHTs will be > > standardized for different environments (good) but each vendor will > > implement a (potentially disjoint) subset, and there may be no way to > > use two endpoints from different vendors together at all. > > > > I agree that if a user selects a non-mandatory DHT, they may risk not > > being fully interoperable, but I think if we don't pick one at all, we > > almost guarantee things won't be interoperable. > > > > And I (and I think nearly everyone) is 100% in the camp of "we should > > allow pluggable DHTs". I think it is safe to say that one is a done > > deal, but I would personally have thought a mandatory was as well. In > > any case, my vote is definitely for pluggable DHTs. > > > > David > > > > On 7/13/07, Jonathan Rosenberg wrote: > >> I've read draft-bryan-p2psip-requirements-00, and have a bunch of > >> comments. But a few items came to mind I wanted to discuss which > >> merit > >> their own threads. > >> > >> First, is the concept of mandatory-to-implement DHT. The requirements > >> document talks a lot about requirements around selecting a > >> mandatory to > >> implement DHT. Its something we've discussed in the meeting and on > >> the > >> list. I think everyone agrees also that we need to allow for multiple > >> DHT and all of the recent protocol proposals support it. > >> > >> However, I do not think we should have a mandatory-to-implement > >> DHT at all. > >> > >> There are several reasons for this. First of all, its important to > >> understand the reason why IETF has mandatory-to-implement > >> functionality > >> in its protocols. The one and only reason is that it ensures > >> interoperability. It ensures that, independent of the optional > >> features > >> selected by a pair of entities, when you connect them together, > >> they can > >> still interoperate. > >> > >> This property will NOT be retained with a mandatory-to-implement DHT. > >> Once the ring forms, the DHT protocol is chosen and locked. Thus, > >> if any > >> DHT besides the 'mandatory-to-implement' one has been selected > >> for the > >> DHT, a new node not supporting that DHT will not be able to join the > >> ring even if it implements the mandatory-to-implement one. Thus, the > >> entire purpose of mandatory-to-implement is eliminated - we don't > >> actually get interoperability. > >> > >> Indeed, to get this kind of interoperability, we'd need to pick > >> one and > >> only one DHT that ever gets used with p2psip. I think that is a > >> mistake. > >> This is an evolving area and is one where agility is important. > >> > >> Instead, what I think happens is that a 'provider' that deploys a p2p > >> network will need to pick a DHT, and make sure that the clients all > >> support that DHT. This is something the market should drive, not us. > >> > >> Secondly, I think its important to realize that we are picking up > >> work > >> in an area that is well trod. There are lots and lots of papers and > >> protocols and software written around P2P networks. I don't think > >> anyone > >> looks at an IETF protocol and says, "IETF are the guys who know about > >> DHTs, lets go with their recommendation". What IETF is really good > >> at, > >> and what this group has expertise in, is SIP, and on designing good, > >> scalable protocols in general - things that have security, > >> extensibility, good performance, and so on. So I think the greatest > >> value we can bring to the table is to create a protocol that allows > >> others to take DHTs and easily turn them into a real wire protocol > >> that > >> you can actually deploy, on the Internet, to support SIP and ideally > >> other things too. Interestingly, this is exactly what all of the > >> protocol proposals do. That kind of focus goes hand-in-hand with > >> saying, > >> let someone else figure out which DHT to use. I think its perfectly > >> reasonable for us, and for others, to write documents on how to > >> use our > >> protocol with various DHTs. But I think we should be out of the > >> business > >> of picking one or recommending one (or ones) to be used. > >> > >> -Jonathan R. > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: (973) 952-5050 > >> http://www.jdrosen.net PHONE: (973) 952-5000 > >> http://www.cisco.com > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > > > > > > -- > > David A. Bryan > > dbryan@SIPeerior.com > > +1.757.565.0101 x101 > > +1.757.565.0088 (fax) > > www.SIPeerior.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Medhavi Bhatia CTO, 3CLogic www.3clogic.com ------=_Part_36994_27561682.1184372458221 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I don't think the DHT is something which gets negotiated between two nodes. So I don't think we need to look at the mandatory DHT in the same way as we look as at a mandatory codec. The requirement here is to prevent a situation where all vendors implement their own DHT to gain commercial advantage. If we don't pick a mandatory DHT, someone else outside this group will end up doing that anyway - maybe Skype ;)

On 7/13/07, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
Lack of a common DHT does not necessarily interfere with
interoperability. The client protocol, at least in our thinking, is
independent of the DHT, so a node that doesn't implement the DHT
algorithm of the overlay it wants to talk to can still reach others,
it just can't be a full peer. Since typically only a small fraction
of nodes need to act as peers at any given time, this may not be much
of a problem.

You could design a system that essentially replicated the key-data
mappings across two DHT algorithm, a baseline universal one and the
"fancy"/"better" one less universally spoken. This incurs
significantly more overhead and probably yields some strange partial
reachability cases particularly as new nodes are added, but it could
be done.

Henning

On Jul 13, 2007, at 6:16 PM, David A. Bryan wrote:

> I think this likely to be a source of serious discussion. At least for
> now (maybe Jonathan can convince me), I'm inclined to disagree.
>
> I think the problem is that if we don't specify a mandatory to
> implement, there may be many devices from different vendors that don't
> even implement a common DHT. Each will pick and choose which DHTs to
> implement, and in the end, there won't be a common DHT all can even
> run if they want to.
>
> I think looking at it from the perspective of "once the DHT chosen it
> is locked" is the wrong way to look at it. The idea isn't that any
> device can join any already established overlay, but that if I deploy
> a system of heterogeneous devices, there is at least one that I can
> select when I start and know that all "P2PSIP endpoints" (assuming
> that term means anything) will at least support that and I can form an
> overlay with them. Maybe not the ideal DHT for my overlay, but
> something I know all devices can support, and if I run it in that
> mode, it works.
>
> Personally, I think if we don't do that, many DHTs will be
> standardized for different environments (good) but each vendor will
> implement a (potentially disjoint) subset, and there may be no way to
> use two endpoints from different vendors together at all.
>
> I agree that if a user selects a non-mandatory DHT, they may risk not
> being fully interoperable, but I think if we don't pick one at all, we
> almost guarantee things won't be interoperable.
>
> And I (and I think nearly everyone) is 100% in the camp of "we should
> allow pluggable DHTs". I think it is safe to say that one is a done
> deal, but I would personally have thought a mandatory was as well. In
> any case, my vote is definitely for pluggable DHTs.
>
> David
>
> On 7/13/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
>> I've read draft-bryan-p2psip-requirements-00, and have a bunch of
>> comments. But a few items came to mind I wanted to discuss which
>> merit
>> their own threads.
>>
>> First, is the concept of mandatory-to-implement DHT. The requirements
>> document talks a lot about requirements around selecting a
>> mandatory to
>> implement DHT. Its something we've discussed in the meeting and on
>> the
>> list. I think everyone agrees also that we need to allow for multiple
>> DHT and all of the recent protocol proposals support it.
>>
>> However, I do not think we should have a mandatory-to-implement
>> DHT at all.
>>
>> There are several reasons for this. First of all, its important to
>> understand the reason why IETF has mandatory-to-implement
>> functionality
>> in its protocols. The one and only reason is that it ensures
>> interoperability. It ensures that, independent of the optional
>> features
>> selected by a pair of entities, when you connect them together,
>> they can
>> still interoperate.
>>
>> This property will NOT be retained with a mandatory-to-implement DHT.
>> Once the ring forms, the DHT protocol is chosen and locked. Thus,
>> if any
>>   DHT besides the 'mandatory-to-implement' one has been selected
>> for the
>> DHT, a new node not supporting that DHT will not be able to join the
>> ring even if it implements the mandatory-to-implement one. Thus, the
>> entire purpose of mandatory-to-implement is eliminated - we don't
>> actually get interoperability.
>>
>> Indeed, to get this kind of interoperability, we'd need to pick
>> one and
>> only one DHT that ever gets used with p2psip. I think that is a
>> mistake.
>> This is an evolving area and is one where agility is important.
>>
>> Instead, what I think happens is that a 'provider' that deploys a p2p
>> network will need to pick a DHT, and make sure that the clients all
>> support that DHT. This is something the market should drive, not us.
>>
>> Secondly, I think its important to realize that we are picking up
>> work
>> in an area that is well trod. There are lots and lots of papers and
>> protocols and software written around P2P networks. I don't think
>> anyone
>> looks at an IETF protocol and says, "IETF are the guys who know about
>> DHTs, lets go with their recommendation". What IETF is really good
>> at,
>> and what this group has expertise in, is SIP, and on designing good,
>> scalable protocols in general - things that have security,
>> extensibility, good performance, and so on. So I think the greatest
>> value we can bring to the table is to create a protocol that allows
>> others to take DHTs and easily turn them into a real wire protocol
>> that
>> you can actually deploy, on the Internet, to support SIP and ideally
>> other things too. Interestingly, this is exactly what all of the
>> protocol proposals do. That kind of focus goes hand-in-hand with
>> saying,
>> let someone else figure out which DHT to use. I think its perfectly
>> reasonable for us, and for others, to write documents on how to
>> use our
>> protocol with various DHTs. But I think we should be out of the
>> business
>> of picking one or recommending one (or ones) to be used.
>>
>> -Jonathan R.
>> --
>> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>> Cisco Fellow                                   Parsippany, NJ
>> 07054-2711
>> Cisco Systems
>> jdrosen@cisco.com                              FAX:   (973) 952-5050
>> http://www.jdrosen.net                         PHONE: (973) 952-5000
>> http://www.cisco.com
>>
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://www1.ietf.org/mailman/listinfo/p2psip
>>
>
>
> --
> David A. Bryan
> dbryan@SIPeerior.com
> +1.757.565.0101 x101
> +1.757.565.0088 (fax)
> www.SIPeerior.com
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip



--
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com ------=_Part_36994_27561682.1184372458221-- --===============0389135471== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0389135471==-- From p2psip-bounces@ietf.org Fri Jul 13 21:59:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Wuz-0005AC-Mz; Fri, 13 Jul 2007 21:59:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Wuy-0005A0-2Y for p2psip@ietf.org; Fri, 13 Jul 2007 21:59:32 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Wuu-0000aF-7Q for p2psip@ietf.org; Fri, 13 Jul 2007 21:59:32 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2007 18:59:27 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEvKl0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,538,1175497200"; d="scan'208"; a="181952749:sNHT35009145" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6E1xRmq008370; Fri, 13 Jul 2007 18:59:27 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6E1xNSb019997; Sat, 14 Jul 2007 01:59:23 GMT Received: from xmb-sjc-219.amer.cisco.com ([171.70.151.188]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 18:59:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Fri, 13 Jul 2007 18:57:54 -0700 Message-ID: <9FA16888AD1BF64ABCE6C2532CCEB98A02A6B555@xmb-sjc-219.amer.cisco.com> In-Reply-To: <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfFm4ca7O6YbFslStiYk2NlfDhslQAHDFiw From: "Krishna Sankar \(ksankar\)" To: "David A. Bryan" , "Jonathan Rosenberg \(jdrosen\)" X-OriginalArrivalTime: 14 Jul 2007 01:59:23.0060 (UTC) FILETIME=[9957B740:01C7C5BA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8190; t=1184378367; x=1185242367; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ksankar@cisco.com; z=From:=20=22Krishna=20Sankar=20\(ksankar\)=22=20 |Subject:=20RE=3A=20[P2PSIP]=20Mandatory-to-implement=20DHTs=20-=20a=20di ssenting=20opinion |Sender:=20; bh=FmvYhluCK40B7ojQqjGIFrjfPrYTjoLWWp1Jvl4Vru0=; b=FbjwS/+5Fj1W0AS0sROuAbKWaoTiJfus4fKrIk+XQunsk/7M5pYJaPsCZrTjlf+I1BHzIk7k NczaFerTY+KlG3unC5/CH4ZKWMaY6uI22ghhjwfuMfabbn2rHfljdNcnkPSvxftIZWhnZgmqYj ZKAUkxtIlluh0KEdLWhG2+nS0=; Authentication-Results: sj-dkim-1; header.From=ksankar@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David, I assume by "pluggable DHTs" you mean common interface and protocols.=20 Supporting your line of thought, as I understand them, basically if we have a model which says a DHT should do this thing, that thing and all those (well defined) things; plus a way of interacting with DHT instances (via well established and crisp protocols), do we care how the DHTs are implemented ? In fact, isn't this how routing works ? > to implement, there may be many devices from different=20 > vendors that don't even implement a common DHT. Each will=20 > pick and choose which DHTs to implement, and in the end,=20 > there won't be a common DHT all can even run if they want to. Wouldn't a device implement only the protocols and interfaces ? In fact, depending on the domain, we might need different types of DHTs anyway. I am not sure one size will fit all domains for various reasons - for example there might be a need for power saving; in which case that domain might choose a lightweight DHT implementation; Apple definitely will want to have an iDHT for no reason ;o),...=20 Also, I keep on seeing interoperability thrown around; interoperability has different forms in different domains - as Medhavi mentions, in the codec world what it means is different than in the routing world which is different than in the SAML world, for example. In short what exactly is interoperability in the world of P2PSIP ? I think if we have a clear & common understanding of the definition of interoperability, that would be a good start; we all have it in our heads, may be it is written down somewhere. =20 Cheers > -----Original Message----- > From: David A. Bryan [mailto:dbryan@sipeerior.com]=20 > Sent: Friday, July 13, 2007 3:16 PM > To: Jonathan Rosenberg (jdrosen) > Cc: P2PSIP WG > Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a=20 > dissenting opinion >=20 > I think this likely to be a source of serious discussion. At=20 > least for now (maybe Jonathan can convince me), I'm inclined=20 > to disagree. >=20 > I think the problem is that if we don't specify a mandatory=20 > to implement, there may be many devices from different=20 > vendors that don't even implement a common DHT. Each will=20 > pick and choose which DHTs to implement, and in the end,=20 > there won't be a common DHT all can even run if they want to. >=20 > I think looking at it from the perspective of "once the DHT=20 > chosen it is locked" is the wrong way to look at it. The idea=20 > isn't that any device can join any already established=20 > overlay, but that if I deploy a system of heterogeneous=20 > devices, there is at least one that I can select when I start=20 > and know that all "P2PSIP endpoints" (assuming that term=20 > means anything) will at least support that and I can form an=20 > overlay with them. Maybe not the ideal DHT for my overlay,=20 > but something I know all devices can support, and if I run it=20 > in that mode, it works. >=20 > Personally, I think if we don't do that, many DHTs will be=20 > standardized for different environments (good) but each=20 > vendor will implement a (potentially disjoint) subset, and=20 > there may be no way to use two endpoints from different=20 > vendors together at all. >=20 > I agree that if a user selects a non-mandatory DHT, they may=20 > risk not being fully interoperable, but I think if we don't=20 > pick one at all, we almost guarantee things won't be interoperable. >=20 > And I (and I think nearly everyone) is 100% in the camp of=20 > "we should allow pluggable DHTs". I think it is safe to say=20 > that one is a done deal, but I would personally have thought=20 > a mandatory was as well. In any case, my vote is definitely=20 > for pluggable DHTs. >=20 > David >=20 > On 7/13/07, Jonathan Rosenberg wrote: > > I've read draft-bryan-p2psip-requirements-00, and have a bunch of=20 > > comments. But a few items came to mind I wanted to discuss=20 > which merit=20 > > their own threads. > > > > First, is the concept of mandatory-to-implement DHT. The=20 > requirements=20 > > document talks a lot about requirements around selecting a=20 > mandatory=20 > > to implement DHT. Its something we've discussed in the=20 > meeting and on=20 > > the list. I think everyone agrees also that we need to allow for=20 > > multiple DHT and all of the recent protocol proposals support it. > > > > However, I do not think we should have a=20 > mandatory-to-implement DHT at all. > > > > There are several reasons for this. First of all, its important to=20 > > understand the reason why IETF has mandatory-to-implement=20 > > functionality in its protocols. The one and only reason is that it=20 > > ensures interoperability. It ensures that, independent of=20 > the optional=20 > > features selected by a pair of entities, when you connect them=20 > > together, they can still interoperate. > > > > This property will NOT be retained with a=20 > mandatory-to-implement DHT. > > Once the ring forms, the DHT protocol is chosen and locked.=20 > Thus, if any > > DHT besides the 'mandatory-to-implement' one has been=20 > selected for=20 > > the DHT, a new node not supporting that DHT will not be=20 > able to join=20 > > the ring even if it implements the mandatory-to-implement=20 > one. Thus,=20 > > the entire purpose of mandatory-to-implement is eliminated=20 > - we don't=20 > > actually get interoperability. > > > > Indeed, to get this kind of interoperability, we'd need to pick one=20 > > and only one DHT that ever gets used with p2psip. I think=20 > that is a mistake. > > This is an evolving area and is one where agility is important. > > > > Instead, what I think happens is that a 'provider' that=20 > deploys a p2p=20 > > network will need to pick a DHT, and make sure that the clients all=20 > > support that DHT. This is something the market should drive, not us. > > > > Secondly, I think its important to realize that we are=20 > picking up work=20 > > in an area that is well trod. There are lots and lots of papers and=20 > > protocols and software written around P2P networks. I don't think=20 > > anyone looks at an IETF protocol and says, "IETF are the=20 > guys who know=20 > > about DHTs, lets go with their recommendation". What IETF is really=20 > > good at, and what this group has expertise in, is SIP, and on=20 > > designing good, scalable protocols in general - things that have=20 > > security, extensibility, good performance, and so on. So I=20 > think the=20 > > greatest value we can bring to the table is to create a=20 > protocol that=20 > > allows others to take DHTs and easily turn them into a real wire=20 > > protocol that you can actually deploy, on the Internet, to=20 > support SIP=20 > > and ideally other things too. Interestingly, this is=20 > exactly what all=20 > > of the protocol proposals do. That kind of focus goes hand-in-hand=20 > > with saying, let someone else figure out which DHT to use.=20 > I think its=20 > > perfectly reasonable for us, and for others, to write=20 > documents on how=20 > > to use our protocol with various DHTs. But I think we=20 > should be out of=20 > > the business of picking one or recommending one (or ones)=20 > to be used. > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany,=20 > NJ 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > >=20 >=20 > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 10:32:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9ifR-0006lz-1k; Sat, 14 Jul 2007 10:32:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9ifP-0006lu-KR for p2psip@ietf.org; Sat, 14 Jul 2007 10:32:15 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9ifL-000212-2F for p2psip@ietf.org; Sat, 14 Jul 2007 10:32:15 -0400 Received: by py-out-1112.google.com with SMTP id f31so2401008pyh for ; Sat, 14 Jul 2007 07:32:10 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ogUMdQFjO4IvzW3eMvMeu1PcfWga7tAc7dT6kwHmh4nJOnT4Y0yViZHkbg7t0aNztpSf3va81SnIbop2ZaKjxnz3xznd68P8Qf9NA7Fn0TQ6TJHBqvXNpu9MZ+mkPv/EIql9DH+KliSSsMttKDl55UUGkfpuNP6yu9lbk7uZNKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=EHGn7QqRKOlQ+JCtsZpTma7rw86cfN7mSS/0TRjDET4UnOy6+uLd0C0YCnH7NMPGPhi2FKrTXS0B66y+6NVgWhj7/E0A2zX/dWM0EnmNhZOCTk3QZ5WVWP+Yplk3h4G2uVzI3gzcJR/TROR1OCvCotOH3rveUiOeF2Z08KS5bao= Received: by 10.64.53.20 with SMTP id b20mr4447628qba.1184423530454; Sat, 14 Jul 2007 07:32:10 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Sat, 14 Jul 2007 07:32:10 -0700 (PDT) Message-ID: <4d4304a00707140732y1f56d442t169c1b593ca7fc98@mail.gmail.com> Date: Sat, 14 Jul 2007 10:32:10 -0400 From: "David A. Bryan" To: "Henning Schulzrinne" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4697F02B.4030506@cisco.com> <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> X-Google-Sender-Auth: 8a237d557a4a540d X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think this is a bit short sighted. Skype works this way (only a small fraction act as peers at a given time), but many proposals beyond a replica for Skype have been proposed. The biggest gains in peer to peer come when there are many peers to distribute the work, so I can imagine that there will be cases where most entities will be peers. The replicate idea is interesting...seems somewhat analagous to the migration between DHTs mechanism in ASP. I agree this sounds like it could add significant overhead. David On 7/13/07, Henning Schulzrinne wrote: > Lack of a common DHT does not necessarily interfere with > interoperability. The client protocol, at least in our thinking, is > independent of the DHT, so a node that doesn't implement the DHT > algorithm of the overlay it wants to talk to can still reach others, > it just can't be a full peer. Since typically only a small fraction > of nodes need to act as peers at any given time, this may not be much > of a problem. > > You could design a system that essentially replicated the key-data > mappings across two DHT algorithm, a baseline universal one and the > "fancy"/"better" one less universally spoken. This incurs > significantly more overhead and probably yields some strange partial > reachability cases particularly as new nodes are added, but it could > be done. > > Henning > > On Jul 13, 2007, at 6:16 PM, David A. Bryan wrote: > > > I think this likely to be a source of serious discussion. At least for > > now (maybe Jonathan can convince me), I'm inclined to disagree. > > > > I think the problem is that if we don't specify a mandatory to > > implement, there may be many devices from different vendors that don't > > even implement a common DHT. Each will pick and choose which DHTs to > > implement, and in the end, there won't be a common DHT all can even > > run if they want to. > > > > I think looking at it from the perspective of "once the DHT chosen it > > is locked" is the wrong way to look at it. The idea isn't that any > > device can join any already established overlay, but that if I deploy > > a system of heterogeneous devices, there is at least one that I can > > select when I start and know that all "P2PSIP endpoints" (assuming > > that term means anything) will at least support that and I can form an > > overlay with them. Maybe not the ideal DHT for my overlay, but > > something I know all devices can support, and if I run it in that > > mode, it works. > > > > Personally, I think if we don't do that, many DHTs will be > > standardized for different environments (good) but each vendor will > > implement a (potentially disjoint) subset, and there may be no way to > > use two endpoints from different vendors together at all. > > > > I agree that if a user selects a non-mandatory DHT, they may risk not > > being fully interoperable, but I think if we don't pick one at all, we > > almost guarantee things won't be interoperable. > > > > And I (and I think nearly everyone) is 100% in the camp of "we should > > allow pluggable DHTs". I think it is safe to say that one is a done > > deal, but I would personally have thought a mandatory was as well. In > > any case, my vote is definitely for pluggable DHTs. > > > > David > > > > On 7/13/07, Jonathan Rosenberg wrote: > >> I've read draft-bryan-p2psip-requirements-00, and have a bunch of > >> comments. But a few items came to mind I wanted to discuss which > >> merit > >> their own threads. > >> > >> First, is the concept of mandatory-to-implement DHT. The requirements > >> document talks a lot about requirements around selecting a > >> mandatory to > >> implement DHT. Its something we've discussed in the meeting and on > >> the > >> list. I think everyone agrees also that we need to allow for multiple > >> DHT and all of the recent protocol proposals support it. > >> > >> However, I do not think we should have a mandatory-to-implement > >> DHT at all. > >> > >> There are several reasons for this. First of all, its important to > >> understand the reason why IETF has mandatory-to-implement > >> functionality > >> in its protocols. The one and only reason is that it ensures > >> interoperability. It ensures that, independent of the optional > >> features > >> selected by a pair of entities, when you connect them together, > >> they can > >> still interoperate. > >> > >> This property will NOT be retained with a mandatory-to-implement DHT. > >> Once the ring forms, the DHT protocol is chosen and locked. Thus, > >> if any > >> DHT besides the 'mandatory-to-implement' one has been selected > >> for the > >> DHT, a new node not supporting that DHT will not be able to join the > >> ring even if it implements the mandatory-to-implement one. Thus, the > >> entire purpose of mandatory-to-implement is eliminated - we don't > >> actually get interoperability. > >> > >> Indeed, to get this kind of interoperability, we'd need to pick > >> one and > >> only one DHT that ever gets used with p2psip. I think that is a > >> mistake. > >> This is an evolving area and is one where agility is important. > >> > >> Instead, what I think happens is that a 'provider' that deploys a p2p > >> network will need to pick a DHT, and make sure that the clients all > >> support that DHT. This is something the market should drive, not us. > >> > >> Secondly, I think its important to realize that we are picking up > >> work > >> in an area that is well trod. There are lots and lots of papers and > >> protocols and software written around P2P networks. I don't think > >> anyone > >> looks at an IETF protocol and says, "IETF are the guys who know about > >> DHTs, lets go with their recommendation". What IETF is really good > >> at, > >> and what this group has expertise in, is SIP, and on designing good, > >> scalable protocols in general - things that have security, > >> extensibility, good performance, and so on. So I think the greatest > >> value we can bring to the table is to create a protocol that allows > >> others to take DHTs and easily turn them into a real wire protocol > >> that > >> you can actually deploy, on the Internet, to support SIP and ideally > >> other things too. Interestingly, this is exactly what all of the > >> protocol proposals do. That kind of focus goes hand-in-hand with > >> saying, > >> let someone else figure out which DHT to use. I think its perfectly > >> reasonable for us, and for others, to write documents on how to > >> use our > >> protocol with various DHTs. But I think we should be out of the > >> business > >> of picking one or recommending one (or ones) to be used. > >> > >> -Jonathan R. > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: (973) 952-5050 > >> http://www.jdrosen.net PHONE: (973) 952-5000 > >> http://www.cisco.com > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > > > > > > -- > > David A. Bryan > > dbryan@SIPeerior.com > > +1.757.565.0101 x101 > > +1.757.565.0088 (fax) > > www.SIPeerior.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 11:03:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9j9d-0005DZ-Bd; Sat, 14 Jul 2007 11:03:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9j9c-0005DL-6N for p2psip@ietf.org; Sat, 14 Jul 2007 11:03:28 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9j9Y-00037M-Gd for p2psip@ietf.org; Sat, 14 Jul 2007 11:03:28 -0400 Received: by py-out-1112.google.com with SMTP id f31so2418879pyh for ; Sat, 14 Jul 2007 08:03:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=WvNh5uXNACZbO2ecND5MtbcYPrIrn7HGy8fhkcKlhvVzHDRJJgTUKyxCXWs89wpVYj7udG5bDSb2jXMZDU55tDI3h9fFExiwiViVlm+v4+PDNkdi8bttHIlouTrOmcQ8C8BqpBr4sGz30mwUkeLla+K7sX7BSz9DUrJrWBF8YHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=iGpQsv1ma+prgS3COsIGoRhsO3dyoReVX96zztSA29Eau4PXjBogVIfq5H1k7+wjXS196v6H0mo2+8BRN6Z9PHNxeaoeRHC1eXtPsg3ab+YKWkNN2Qv+meAGfVvVMWu6MuDWx7hFitbeqRJjcfWxJL4qt2LxiUEHy091lV04flI= Received: by 10.65.96.6 with SMTP id y6mr4445324qbl.1184425404041; Sat, 14 Jul 2007 08:03:24 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Sat, 14 Jul 2007 08:03:23 -0700 (PDT) Message-ID: <4d4304a00707140803r776f123av730e1bb280c322c0@mail.gmail.com> Date: Sat, 14 Jul 2007 11:03:23 -0400 From: "David A. Bryan" To: "Krishna Sankar (ksankar)" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <9FA16888AD1BF64ABCE6C2532CCEB98A02A6B555@xmb-sjc-219.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <9FA16888AD1BF64ABCE6C2532CCEB98A02A6B555@xmb-sjc-219.amer.cisco.com> X-Google-Sender-Auth: 221a6be97ed74022 X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think there is some confusion here. See inline. On 7/13/07, Krishna Sankar (ksankar) wrote: > David, > I assume by "pluggable DHTs" you mean common interface and > protocols. > > Supporting your line of thought, as I understand them, basically > if we have a model which says a DHT should do this thing, that thing and > all those (well defined) things; plus a way of interacting with DHT > instances (via well established and crisp protocols), do we care how the > DHTs are implemented ? In fact, isn't this how routing works ? You won't be able to have various different DHTs share the same overlay. I don't think anyone believes that will work. The protocol will define how messages are transported, and the syntax to get/put etc., but the particular DHT will decide specifics, such as where something is stored, which areas a particular peer is responsible for, and possibly some details of the routing. (For example the DHT EpiChord improves chord performance by routing on request forward around the ring and the other backward) This flexability is great -- and why I think we want pluggable DHTs. The field is still evolving, and new, better DHTs will be developed. Once someone who is deploying a system chooses the one to use, only those that can support it will be able to join, and I think that is fine for the reasons you mention below (they may have picked a good one for power saving, or optimized for an enterprise, or a global deployment with many NATs...), but if their goal is "I want to be able to use endpoints from any vendor", and we have no standard, it may not be possible. Say vendor A implements DHTs 1 and 2, Vendor B 2 and 3, and vendor C only 4. If I want to build an overlay and have devices from all vendors, my choices are: * Run a network on 2, A and B devices participate, but C devices run only in client mode, which less efficient (especially if I have about even numbers of A/B and C devices) It would be even worse if A, B and C had no common DHT and perhaps I only get to spread the work among 1/3 of the devices. * Run multiple overlays and connect via inter-overlay operations, but this is also ugly, and likely to be less efficient since multiple calls are made. To me the proposal that this is satisfactory would be akin to saying when the IETF was looking at SIP that we shouldn't bother, and that different vendors could just build VoIP systems with their own protocols and we can define how to use the PSTN to interconnect them. This seems destined to lead to a network where the large vendors get to define an industry standard of "their" DHT, patent it, license it, and control the market. I'd prefer another option, where all could run 0. It might not be the best DHT, but I can leverage the fact that all peers are sharing the load now, which is the whole point of P2P. In my experience with DHTs (and much of my Ph.D. thesis revolves around details of them, so I've studied them rather intently), The improvement between DHT A from the 90s and new super DHT Z are relatively minor in comparison the the performance gain of spreading the work among the various peers. That is really what P2P is trying to do -- spread the work over as many devices as possible to ensure each does little work, while collectively they get the work done. If we spread it over "just a few peers" and use client protocol between the rest, this looks kind of like a degenerate case of a proxy farm (or perhaps redirect farm) to me, where we aren't really spreading the load. Spreading work among 1000 peers with a fairly simply DHT seems preferable to having it spread across 400 marginally more efficient ones that must serve another 600. As Johnathan pointed out, there are a couple of models in the requirements document, because it is the result of many authors. The proxy model (which I personally don't like) and a true end to end where as many devices are in the overlay as possible (which I have always preferred and proposed) I want this to be as end to end as possible, and want to ensure that someone setting up a network of these can choose from any vendor. I'm also not sure there is a ton of value in each vendor sending messages that are the same format over the wire, but not being able to combine those devices together anyway except as islands interconnected by SIP or as dumb clients where only one vendor's device provide the smarts and stores the data. So far, at least, I'm not convinced we can do that without a mandatory DHT, although maybe in this discussion we'll figure it out. David > > > to implement, there may be many devices from different > > vendors that don't even implement a common DHT. Each will > > pick and choose which DHTs to implement, and in the end, > > there won't be a common DHT all can even run if they want to. > > Wouldn't a device implement only the protocols and interfaces ? > In fact, depending on the domain, we might need different types of DHTs > anyway. I am not sure one size will fit all domains for various reasons > - for example there might be a need for power saving; in which case that > domain might choose a lightweight DHT implementation; Apple definitely > will want to have an iDHT for no reason ;o),... > > > Also, I keep on seeing interoperability thrown around; interoperability > has different forms in different domains - as Medhavi mentions, in the > codec world what it means is different than in the routing world which > is different than in the SAML world, for example. In short what exactly > is interoperability in the world of P2PSIP ? I think if we have a clear > & common understanding of the definition of interoperability, that would > be a good start; we all have it in our heads, may be it is written down > somewhere. > > Cheers > > > -----Original Message----- > > From: David A. Bryan [mailto:dbryan@sipeerior.com] > > Sent: Friday, July 13, 2007 3:16 PM > > To: Jonathan Rosenberg (jdrosen) > > Cc: P2PSIP WG > > Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a > > dissenting opinion > > > > I think this likely to be a source of serious discussion. At > > least for now (maybe Jonathan can convince me), I'm inclined > > to disagree. > > > > I think the problem is that if we don't specify a mandatory > > to implement, there may be many devices from different > > vendors that don't even implement a common DHT. Each will > > pick and choose which DHTs to implement, and in the end, > > there won't be a common DHT all can even run if they want to. > > > > I think looking at it from the perspective of "once the DHT > > chosen it is locked" is the wrong way to look at it. The idea > > isn't that any device can join any already established > > overlay, but that if I deploy a system of heterogeneous > > devices, there is at least one that I can select when I start > > and know that all "P2PSIP endpoints" (assuming that term > > means anything) will at least support that and I can form an > > overlay with them. Maybe not the ideal DHT for my overlay, > > but something I know all devices can support, and if I run it > > in that mode, it works. > > > > Personally, I think if we don't do that, many DHTs will be > > standardized for different environments (good) but each > > vendor will implement a (potentially disjoint) subset, and > > there may be no way to use two endpoints from different > > vendors together at all. > > > > I agree that if a user selects a non-mandatory DHT, they may > > risk not being fully interoperable, but I think if we don't > > pick one at all, we almost guarantee things won't be interoperable. > > > > And I (and I think nearly everyone) is 100% in the camp of > > "we should allow pluggable DHTs". I think it is safe to say > > that one is a done deal, but I would personally have thought > > a mandatory was as well. In any case, my vote is definitely > > for pluggable DHTs. > > > > David > > > > On 7/13/07, Jonathan Rosenberg wrote: > > > I've read draft-bryan-p2psip-requirements-00, and have a bunch of > > > comments. But a few items came to mind I wanted to discuss > > which merit > > > their own threads. > > > > > > First, is the concept of mandatory-to-implement DHT. The > > requirements > > > document talks a lot about requirements around selecting a > > mandatory > > > to implement DHT. Its something we've discussed in the > > meeting and on > > > the list. I think everyone agrees also that we need to allow for > > > multiple DHT and all of the recent protocol proposals support it. > > > > > > However, I do not think we should have a > > mandatory-to-implement DHT at all. > > > > > > There are several reasons for this. First of all, its important to > > > understand the reason why IETF has mandatory-to-implement > > > functionality in its protocols. The one and only reason is that it > > > ensures interoperability. It ensures that, independent of > > the optional > > > features selected by a pair of entities, when you connect them > > > together, they can still interoperate. > > > > > > This property will NOT be retained with a > > mandatory-to-implement DHT. > > > Once the ring forms, the DHT protocol is chosen and locked. > > Thus, if any > > > DHT besides the 'mandatory-to-implement' one has been > > selected for > > > the DHT, a new node not supporting that DHT will not be > > able to join > > > the ring even if it implements the mandatory-to-implement > > one. Thus, > > > the entire purpose of mandatory-to-implement is eliminated > > - we don't > > > actually get interoperability. > > > > > > Indeed, to get this kind of interoperability, we'd need to pick one > > > and only one DHT that ever gets used with p2psip. I think > > that is a mistake. > > > This is an evolving area and is one where agility is important. > > > > > > Instead, what I think happens is that a 'provider' that > > deploys a p2p > > > network will need to pick a DHT, and make sure that the clients all > > > support that DHT. This is something the market should drive, not us. > > > > > > Secondly, I think its important to realize that we are > > picking up work > > > in an area that is well trod. There are lots and lots of papers and > > > protocols and software written around P2P networks. I don't think > > > anyone looks at an IETF protocol and says, "IETF are the > > guys who know > > > about DHTs, lets go with their recommendation". What IETF is really > > > good at, and what this group has expertise in, is SIP, and on > > > designing good, scalable protocols in general - things that have > > > security, extensibility, good performance, and so on. So I > > think the > > > greatest value we can bring to the table is to create a > > protocol that > > > allows others to take DHTs and easily turn them into a real wire > > > protocol that you can actually deploy, on the Internet, to > > support SIP > > > and ideally other things too. Interestingly, this is > > exactly what all > > > of the protocol proposals do. That kind of focus goes hand-in-hand > > > with saying, let someone else figure out which DHT to use. > > I think its > > > perfectly reasonable for us, and for others, to write > > documents on how > > > to use our protocol with various DHTs. But I think we > > should be out of > > > the business of picking one or recommending one (or ones) > > to be used. > > > > > > -Jonathan R. > > > -- > > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > > Cisco Fellow Parsippany, > > NJ 07054-2711 > > > Cisco Systems > > > jdrosen@cisco.com FAX: (973) 952-5050 > > > http://www.jdrosen.net PHONE: (973) 952-5000 > > > http://www.cisco.com > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > -- > > David A. Bryan > > dbryan@SIPeerior.com > > +1.757.565.0101 x101 > > +1.757.565.0088 (fax) > > www.SIPeerior.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 12:54:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9kse-0003zc-1U; Sat, 14 Jul 2007 12:54:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9ksa-0003u7-VF for p2psip@ietf.org; Sat, 14 Jul 2007 12:54:02 -0400 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9ksT-0006Is-Ni for p2psip@ietf.org; Sat, 14 Jul 2007 12:54:00 -0400 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id A032744A44E for ; Sun, 15 Jul 2007 00:53:50 +0800 (CST) Message-ID: <007a01c7c637$8d48d510$a507740a@DELLWEI> From: "Wei Gengyu" To: "P2PSIP WG" References: <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com><9FA16888AD1BF64ABCE6C2532CCEB98A02A6B555@xmb-sjc-219.amer.cisco.com> <4d4304a00707140803r776f123av730e1bb280c322c0@mail.gmail.com> Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sun, 15 Jul 2007 00:53:49 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.1 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1616814912==" Errors-To: p2psip-bounces@ietf.org --===============1616814912== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIA0KDQpJIGFncmVlIHRoYXQgdGhlcmUgaXMgYSBkZWZhdWx0IERIVCBhbGdvcml0aG0uIA0K QW5kIGZvciBmbGV4aWJpbGl0eSwgdGhlcmUgbWF5IGJlIGFuIG9wdGlvbiBmb3Igc2VsZWN0aW5n IG90aGVyIERIVHMgaW4gUGVlciBwcm90b2NvbHMuICANCg0KU29tZSBwcm9ibGVtIHdpbGwgb2Nj dXI6DQoxLiBIb3cgY2FuIGEgam9pbmluZyBwZWVyIGdldCB3aGF0IGlzIHRoZSBkZWZhdWx0IERI VD8NCixJdCBwcm9iYWJseSBjb3VsZCBnZXQgdGhlIGNvbmZpZ3VhdGlvbiBkYXRhIGJ5IGV4Y2hh bmdlIG1lc3NhZ2VzIGR1cmluZyBqb2luaW5nIHBoYXNlLg0KDQoyLiBBbmQgd2hldGhlciB0aGUg ZGVmYXVsdCBESFQgY2FuIGJlIGNoYW5nZWQgb3IgcmVjb25maWd1cmVkPw0KSWYgeWVzLCBpdCBu ZWVkcyB0byBkZWZpbmUgbWVjaGFuaXNtcyBpbiBQZWVyIFByb3RvY29sLg0KDQpJbiBwcmFjdGlj ZSwgdGhlIGRlZmF1bHQgaXMgcmVxdWlyZWQuIA0KRXZlbiB3ZSBoYXZlIHRoZSBmYXVsdCBjb25m aWd1cmF0aW9ucywgdGhlcmUgYXJlIG9mdGVuIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgZHVl IHRvIGRpZmZlcmVudCB1bmRlcnN0YW5kaW5nIG9yIGRldmVsb3BtZW50IGNob2ljZXMuDQpBbmQg SSBjYW4gbm90IGltYWdlIHRoZSByZXN1bHQgaWYgdGhlcmUgaXMgbm8gZGVmYXVsdCBESFQuDQoN ClJlZ2FyZHMsIA0KDQpHZW5neXUNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZy b206ICJEYXZpZCBBLiBCcnlhbiIgPGRicnlhbkBzaXBlZXJpb3IuY29tPg0KVG86ICJLcmlzaG5h IFNhbmthciAoa3NhbmthcikiIDxrc2Fua2FyQGNpc2NvLmNvbT4NCkNjOiAiUDJQU0lQIFdHIiA8 cDJwc2lwQGlldGYub3JnPg0KU2VudDogU2F0dXJkYXksIEp1bHkgMTQsIDIwMDcgMTE6MDMgUE0N ClN1YmplY3Q6IFJlOiBbUDJQU0lQXSBNYW5kYXRvcnktdG8taW1wbGVtZW50IERIVHMgLSBhIGRp c3NlbnRpbmcgb3Bpbmlvbg0KDQoNCj5JIHRoaW5rIHRoZXJlIGlzIHNvbWUgY29uZnVzaW9uIGhl cmUuIFNlZSBpbmxpbmUuDQo+IA0KPiBPbiA3LzEzLzA3LCBLcmlzaG5hIFNhbmthciAoa3Nhbmth cikgPGtzYW5rYXJAY2lzY28uY29tPiB3cm90ZToNCj4+IERhdmlkLA0KPj4gICAgICAgICBJIGFz c3VtZSBieSAicGx1Z2dhYmxlIERIVHMiIHlvdSBtZWFuIGNvbW1vbiBpbnRlcmZhY2UgYW5kDQo+ PiBwcm90b2NvbHMuDQo+Pg0KPj4gICAgICAgICBTdXBwb3J0aW5nIHlvdXIgbGluZSBvZiB0aG91 Z2h0LCBhcyBJIHVuZGVyc3RhbmQgdGhlbSwgYmFzaWNhbGx5DQo+PiBpZiB3ZSBoYXZlIGEgbW9k ZWwgd2hpY2ggc2F5cyBhIERIVCBzaG91bGQgZG8gdGhpcyB0aGluZywgdGhhdCB0aGluZyBhbmQN Cj4+IGFsbCB0aG9zZSAod2VsbCBkZWZpbmVkKSB0aGluZ3M7IHBsdXMgYSB3YXkgb2YgaW50ZXJh Y3Rpbmcgd2l0aCBESFQNCj4+IGluc3RhbmNlcyAodmlhIHdlbGwgZXN0YWJsaXNoZWQgYW5kIGNy aXNwIHByb3RvY29scyksIGRvIHdlIGNhcmUgaG93IHRoZQ0KPj4gREhUcyBhcmUgaW1wbGVtZW50 ZWQgPyBJbiBmYWN0LCBpc24ndCB0aGlzIGhvdyByb3V0aW5nIHdvcmtzID8NCj4gDQo+IFlvdSB3 b24ndCBiZSBhYmxlIHRvIGhhdmUgdmFyaW91cyBkaWZmZXJlbnQgREhUcyBzaGFyZSB0aGUgc2Ft ZQ0KPiBvdmVybGF5LiBJIGRvbid0IHRoaW5rIGFueW9uZSBiZWxpZXZlcyB0aGF0IHdpbGwgd29y ay4gVGhlIHByb3RvY29sDQo+IHdpbGwgZGVmaW5lIGhvdyBtZXNzYWdlcyBhcmUgdHJhbnNwb3J0 ZWQsIGFuZCB0aGUgc3ludGF4IHRvIGdldC9wdXQNCj4gZXRjLiwgYnV0IHRoZSBwYXJ0aWN1bGFy IERIVCB3aWxsIGRlY2lkZSBzcGVjaWZpY3MsIHN1Y2ggYXMgd2hlcmUNCj4gc29tZXRoaW5nIGlz IHN0b3JlZCwgd2hpY2ggYXJlYXMgYSBwYXJ0aWN1bGFyIHBlZXIgaXMgcmVzcG9uc2libGUgZm9y LA0KPiBhbmQgcG9zc2libHkgc29tZSBkZXRhaWxzIG9mIHRoZSByb3V0aW5nLiAoRm9yIGV4YW1w bGUgdGhlIERIVA0KPiBFcGlDaG9yZCBpbXByb3ZlcyBjaG9yZCBwZXJmb3JtYW5jZSBieSByb3V0 aW5nIG9uIHJlcXVlc3QgZm9yd2FyZA0KPiBhcm91bmQgdGhlIHJpbmcgYW5kIHRoZSBvdGhlciBi YWNrd2FyZCkNCj4gDQo+IFRoaXMgZmxleGFiaWxpdHkgaXMgZ3JlYXQgLS0gYW5kIHdoeSBJIHRo aW5rIHdlIHdhbnQgcGx1Z2dhYmxlIERIVHMuDQo+IFRoZSBmaWVsZCBpcyBzdGlsbCBldm9sdmlu ZywgYW5kIG5ldywgYmV0dGVyIERIVHMgd2lsbCBiZSBkZXZlbG9wZWQuDQo+IE9uY2Ugc29tZW9u ZSB3aG8gaXMgZGVwbG95aW5nIGEgc3lzdGVtIGNob29zZXMgdGhlIG9uZSB0byB1c2UsIG9ubHkN Cj4gdGhvc2UgdGhhdCBjYW4gc3VwcG9ydCBpdCB3aWxsIGJlIGFibGUgdG8gam9pbiwgYW5kIEkg dGhpbmsgdGhhdCBpcw0KPiBmaW5lIGZvciB0aGUgcmVhc29ucyB5b3UgbWVudGlvbiBiZWxvdyAo dGhleSBtYXkgaGF2ZSBwaWNrZWQgYSBnb29kDQo+IG9uZSBmb3IgcG93ZXIgc2F2aW5nLCBvciBv cHRpbWl6ZWQgZm9yIGFuIGVudGVycHJpc2UsIG9yIGEgZ2xvYmFsDQo+IGRlcGxveW1lbnQgd2l0 aCBtYW55IE5BVHMuLi4pLCBidXQgaWYgdGhlaXIgZ29hbCBpcyAiSSB3YW50IHRvIGJlIGFibGUN Cj4gdG8gdXNlIGVuZHBvaW50cyBmcm9tIGFueSB2ZW5kb3IiLCBhbmQgd2UgaGF2ZSBubyBzdGFu ZGFyZCwgaXQgbWF5IG5vdA0KPiBiZSBwb3NzaWJsZS4gU2F5IHZlbmRvciBBIGltcGxlbWVudHMg REhUcyAxIGFuZCAyLCBWZW5kb3IgQiAyIGFuZCAzLA0KPiBhbmQgdmVuZG9yIEMgb25seSA0LiBJ ZiBJIHdhbnQgdG8gYnVpbGQgYW4gb3ZlcmxheSBhbmQgaGF2ZSBkZXZpY2VzDQo+IGZyb20gYWxs IHZlbmRvcnMsIG15IGNob2ljZXMgYXJlOg0KPiANCj4gKiBSdW4gYSBuZXR3b3JrIG9uIDIsIEEg YW5kIEIgZGV2aWNlcyBwYXJ0aWNpcGF0ZSwgYnV0IEMgZGV2aWNlcyBydW4NCj4gb25seSBpbiBj bGllbnQgbW9kZSwgd2hpY2ggbGVzcyBlZmZpY2llbnQgKGVzcGVjaWFsbHkgaWYgSSBoYXZlIGFi b3V0DQo+IGV2ZW4gbnVtYmVycyBvZiBBL0IgYW5kIEMgZGV2aWNlcykgSXQgd291bGQgYmUgZXZl biB3b3JzZSBpZiBBLCBCIGFuZA0KPiBDIGhhZCBubyBjb21tb24gREhUIGFuZCBwZXJoYXBzIEkg b25seSBnZXQgdG8gc3ByZWFkIHRoZSB3b3JrIGFtb25nDQo+IDEvMyBvZiB0aGUgZGV2aWNlcy4N Cj4gDQo+ICogUnVuIG11bHRpcGxlIG92ZXJsYXlzIGFuZCBjb25uZWN0IHZpYSBpbnRlci1vdmVy bGF5IG9wZXJhdGlvbnMsIGJ1dA0KPiB0aGlzIGlzIGFsc28gdWdseSwgYW5kIGxpa2VseSB0byBi ZSBsZXNzIGVmZmljaWVudCBzaW5jZSBtdWx0aXBsZQ0KPiBjYWxscyBhcmUgbWFkZS4gVG8gbWUg dGhlIHByb3Bvc2FsIHRoYXQgdGhpcyBpcyBzYXRpc2ZhY3Rvcnkgd291bGQgYmUNCj4gYWtpbiB0 byBzYXlpbmcgd2hlbiB0aGUgSUVURiB3YXMgbG9va2luZyBhdCBTSVAgdGhhdCB3ZSBzaG91bGRu J3QNCj4gYm90aGVyLCBhbmQgdGhhdCBkaWZmZXJlbnQgdmVuZG9ycyBjb3VsZCBqdXN0IGJ1aWxk IFZvSVAgc3lzdGVtcyB3aXRoDQo+IHRoZWlyIG93biBwcm90b2NvbHMgYW5kIHdlIGNhbiBkZWZp bmUgaG93IHRvIHVzZSB0aGUgUFNUTiB0bw0KPiBpbnRlcmNvbm5lY3QgdGhlbS4gVGhpcyBzZWVt cyBkZXN0aW5lZCB0byBsZWFkIHRvIGEgbmV0d29yayB3aGVyZSB0aGUNCj4gbGFyZ2UgdmVuZG9y cyBnZXQgdG8gZGVmaW5lIGFuIGluZHVzdHJ5IHN0YW5kYXJkIG9mICJ0aGVpciIgREhULA0KPiBw YXRlbnQgaXQsIGxpY2Vuc2UgaXQsIGFuZCBjb250cm9sIHRoZSBtYXJrZXQuDQo+IA0KPiBJJ2Qg cHJlZmVyIGFub3RoZXIgb3B0aW9uLCB3aGVyZSBhbGwgY291bGQgcnVuIDAuIEl0IG1pZ2h0IG5v dCBiZSB0aGUNCj4gYmVzdCBESFQsIGJ1dCBJIGNhbiBsZXZlcmFnZSB0aGUgZmFjdCB0aGF0IGFs bCBwZWVycyBhcmUgc2hhcmluZyB0aGUNCj4gbG9hZCBub3csIHdoaWNoIGlzIHRoZSB3aG9sZSBw b2ludCBvZiBQMlAuIEluIG15IGV4cGVyaWVuY2Ugd2l0aCBESFRzDQo+IChhbmQgbXVjaCBvZiBt eSBQaC5ELiB0aGVzaXMgcmV2b2x2ZXMgYXJvdW5kIGRldGFpbHMgb2YgdGhlbSwgc28gSSd2ZQ0K PiBzdHVkaWVkIHRoZW0gcmF0aGVyIGludGVudGx5KSwgVGhlIGltcHJvdmVtZW50IGJldHdlZW4g REhUIEEgZnJvbSB0aGUNCj4gOTBzIGFuZCBuZXcgc3VwZXIgREhUIFogYXJlIHJlbGF0aXZlbHkg bWlub3IgaW4gY29tcGFyaXNvbiB0aGUgdGhlDQo+IHBlcmZvcm1hbmNlIGdhaW4gb2Ygc3ByZWFk aW5nIHRoZSB3b3JrIGFtb25nIHRoZSB2YXJpb3VzIHBlZXJzLiBUaGF0DQo+IGlzIHJlYWxseSB3 aGF0IFAyUCBpcyB0cnlpbmcgdG8gZG8gLS0gc3ByZWFkIHRoZSB3b3JrIG92ZXIgYXMgbWFueQ0K PiBkZXZpY2VzIGFzIHBvc3NpYmxlIHRvIGVuc3VyZSBlYWNoIGRvZXMgbGl0dGxlIHdvcmssIHdo aWxlDQo+IGNvbGxlY3RpdmVseSB0aGV5IGdldCB0aGUgd29yayBkb25lLg0KPiANCj4gSWYgd2Ug c3ByZWFkIGl0IG92ZXIgImp1c3QgYSBmZXcgcGVlcnMiIGFuZCB1c2UgY2xpZW50IHByb3RvY29s DQo+IGJldHdlZW4gdGhlIHJlc3QsIHRoaXMgbG9va3Mga2luZCBvZiBsaWtlIGEgZGVnZW5lcmF0 ZSBjYXNlIG9mIGEgcHJveHkNCj4gZmFybSAob3IgcGVyaGFwcyByZWRpcmVjdCBmYXJtKSB0byBt ZSwgd2hlcmUgd2UgYXJlbid0IHJlYWxseQ0KPiBzcHJlYWRpbmcgdGhlIGxvYWQuIFNwcmVhZGlu ZyB3b3JrIGFtb25nIDEwMDAgcGVlcnMgd2l0aCBhIGZhaXJseQ0KPiBzaW1wbHkgREhUIHNlZW1z IHByZWZlcmFibGUgdG8gaGF2aW5nIGl0IHNwcmVhZCBhY3Jvc3MgNDAwIG1hcmdpbmFsbHkNCj4g bW9yZSBlZmZpY2llbnQgb25lcyB0aGF0IG11c3Qgc2VydmUgYW5vdGhlciA2MDAuDQo+IA0KPiBB cyBKb2huYXRoYW4gcG9pbnRlZCBvdXQsIHRoZXJlIGFyZSBhIGNvdXBsZSBvZiBtb2RlbHMgaW4g dGhlDQo+IHJlcXVpcmVtZW50cyBkb2N1bWVudCwgYmVjYXVzZSBpdCBpcyB0aGUgcmVzdWx0IG9m IG1hbnkgYXV0aG9ycy4gVGhlDQo+IHByb3h5IG1vZGVsICh3aGljaCBJIHBlcnNvbmFsbHkgZG9u J3QgbGlrZSkgYW5kIGEgdHJ1ZSBlbmQgdG8gZW5kDQo+IHdoZXJlIGFzIG1hbnkgZGV2aWNlcyBh cmUgaW4gdGhlIG92ZXJsYXkgYXMgcG9zc2libGUgKHdoaWNoIEkgaGF2ZQ0KPiBhbHdheXMgcHJl ZmVycmVkIGFuZCBwcm9wb3NlZCkgSSB3YW50IHRoaXMgdG8gYmUgYXMgZW5kIHRvIGVuZCBhcw0K PiBwb3NzaWJsZSwgYW5kIHdhbnQgdG8gZW5zdXJlIHRoYXQgc29tZW9uZSBzZXR0aW5nIHVwIGEg bmV0d29yayBvZg0KPiB0aGVzZSBjYW4gY2hvb3NlIGZyb20gYW55IHZlbmRvci4gSSdtIGFsc28g bm90IHN1cmUgdGhlcmUgaXMgYSB0b24gb2YNCj4gdmFsdWUgaW4gZWFjaCB2ZW5kb3Igc2VuZGlu ZyBtZXNzYWdlcyB0aGF0IGFyZSB0aGUgc2FtZSBmb3JtYXQgb3Zlcg0KPiB0aGUgd2lyZSwgYnV0 IG5vdCBiZWluZyBhYmxlIHRvIGNvbWJpbmUgdGhvc2UgZGV2aWNlcyB0b2dldGhlciBhbnl3YXkN Cj4gZXhjZXB0IGFzIGlzbGFuZHMgaW50ZXJjb25uZWN0ZWQgYnkgU0lQIG9yIGFzIGR1bWIgY2xp ZW50cyB3aGVyZSBvbmx5DQo+IG9uZSB2ZW5kb3IncyBkZXZpY2UgcHJvdmlkZSB0aGUgc21hcnRz IGFuZCBzdG9yZXMgdGhlIGRhdGEuDQo+IA0KPiBTbyBmYXIsIGF0IGxlYXN0LCBJJ20gbm90IGNv bnZpbmNlZCB3ZSBjYW4gZG8gdGhhdCB3aXRob3V0IGEgbWFuZGF0b3J5DQo+IERIVCwgYWx0aG91 Z2ggbWF5YmUgaW4gdGhpcyBkaXNjdXNzaW9uIHdlJ2xsIGZpZ3VyZSBpdCBvdXQuDQo+IA0KPiBE YXZpZA0KPiANCj4+DQo+PiA+IHRvIGltcGxlbWVudCwgdGhlcmUgbWF5IGJlIG1hbnkgZGV2aWNl cyBmcm9tIGRpZmZlcmVudA0KPj4gPiB2ZW5kb3JzIHRoYXQgZG9uJ3QgZXZlbiBpbXBsZW1lbnQg YSBjb21tb24gREhULiBFYWNoIHdpbGwNCj4+ID4gcGljayBhbmQgY2hvb3NlIHdoaWNoIERIVHMg dG8gaW1wbGVtZW50LCBhbmQgaW4gdGhlIGVuZCwNCj4+ID4gdGhlcmUgd29uJ3QgYmUgYSBjb21t b24gREhUIGFsbCBjYW4gZXZlbiBydW4gaWYgdGhleSB3YW50IHRvLg0KPj4gPEtTPg0KPj4gICAg ICAgICBXb3VsZG4ndCBhIGRldmljZSBpbXBsZW1lbnQgb25seSB0aGUgcHJvdG9jb2xzIGFuZCBp bnRlcmZhY2VzID8NCj4+IEluIGZhY3QsIGRlcGVuZGluZyBvbiB0aGUgZG9tYWluLCB3ZSBtaWdo dCBuZWVkIGRpZmZlcmVudCB0eXBlcyBvZiBESFRzDQo+PiBhbnl3YXkuIEkgYW0gbm90IHN1cmUg b25lIHNpemUgd2lsbCBmaXQgYWxsIGRvbWFpbnMgZm9yIHZhcmlvdXMgcmVhc29ucw0KPj4gLSBm b3IgZXhhbXBsZSB0aGVyZSBtaWdodCBiZSBhIG5lZWQgZm9yIHBvd2VyIHNhdmluZzsgaW4gd2hp Y2ggY2FzZSB0aGF0DQo+PiBkb21haW4gbWlnaHQgY2hvb3NlIGEgbGlnaHR3ZWlnaHQgREhUIGlt cGxlbWVudGF0aW9uOyBBcHBsZSBkZWZpbml0ZWx5DQo+PiB3aWxsIHdhbnQgdG8gaGF2ZSBhbiBp REhUIGZvciBubyByZWFzb24gO28pLC4uLg0KPj4gPC9LUz4NCj4+DQo+PiBBbHNvLCBJIGtlZXAg b24gc2VlaW5nIGludGVyb3BlcmFiaWxpdHkgdGhyb3duIGFyb3VuZDsgaW50ZXJvcGVyYWJpbGl0 eQ0KPj4gaGFzIGRpZmZlcmVudCBmb3JtcyBpbiBkaWZmZXJlbnQgZG9tYWlucyAtIGFzIE1lZGhh dmkgbWVudGlvbnMsIGluIHRoZQ0KPj4gY29kZWMgd29ybGQgd2hhdCBpdCBtZWFucyBpcyBkaWZm ZXJlbnQgdGhhbiBpbiB0aGUgcm91dGluZyB3b3JsZCB3aGljaA0KPj4gaXMgZGlmZmVyZW50IHRo YW4gaW4gdGhlIFNBTUwgd29ybGQsIGZvciBleGFtcGxlLiBJbiBzaG9ydCB3aGF0IGV4YWN0bHkN Cj4+IGlzIGludGVyb3BlcmFiaWxpdHkgaW4gdGhlIHdvcmxkIG9mIFAyUFNJUCA/IEkgdGhpbmsg aWYgd2UgaGF2ZSBhIGNsZWFyDQo+PiAmIGNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIHRoZSBkZWZp bml0aW9uIG9mIGludGVyb3BlcmFiaWxpdHksIHRoYXQgd291bGQNCj4+IGJlIGEgZ29vZCBzdGFy dDsgd2UgYWxsIGhhdmUgaXQgaW4gb3VyIGhlYWRzLCBtYXkgYmUgaXQgaXMgd3JpdHRlbiBkb3du DQo+PiBzb21ld2hlcmUuDQo+Pg0KPj4gQ2hlZXJzDQo+PiA8ay8+DQo+PiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiA+IEZyb206IERhdmlkIEEuIEJyeWFuIFttYWlsdG86ZGJyeWFu QHNpcGVlcmlvci5jb21dDQo+PiA+IFNlbnQ6IEZyaWRheSwgSnVseSAxMywgMjAwNyAzOjE2IFBN DQo+PiA+IFRvOiBKb25hdGhhbiBSb3NlbmJlcmcgKGpkcm9zZW4pDQo+PiA+IENjOiBQMlBTSVAg V0cNCj4+ID4gU3ViamVjdDogUmU6IFtQMlBTSVBdIE1hbmRhdG9yeS10by1pbXBsZW1lbnQgREhU cyAtIGENCj4+ID4gZGlzc2VudGluZyBvcGluaW9uDQo+PiA+DQo+PiA+IEkgdGhpbmsgdGhpcyBs aWtlbHkgdG8gYmUgYSBzb3VyY2Ugb2Ygc2VyaW91cyBkaXNjdXNzaW9uLiBBdA0KPj4gPiBsZWFz dCBmb3Igbm93IChtYXliZSBKb25hdGhhbiBjYW4gY29udmluY2UgbWUpLCBJJ20gaW5jbGluZWQN Cj4+ID4gdG8gZGlzYWdyZWUuDQo+PiA+DQo+PiA+IEkgdGhpbmsgdGhlIHByb2JsZW0gaXMgdGhh dCBpZiB3ZSBkb24ndCBzcGVjaWZ5IGEgbWFuZGF0b3J5DQo+PiA+IHRvIGltcGxlbWVudCwgdGhl cmUgbWF5IGJlIG1hbnkgZGV2aWNlcyBmcm9tIGRpZmZlcmVudA0KPj4gPiB2ZW5kb3JzIHRoYXQg ZG9uJ3QgZXZlbiBpbXBsZW1lbnQgYSBjb21tb24gREhULiBFYWNoIHdpbGwNCj4+ID4gcGljayBh bmQgY2hvb3NlIHdoaWNoIERIVHMgdG8gaW1wbGVtZW50LCBhbmQgaW4gdGhlIGVuZCwNCj4+ID4g dGhlcmUgd29uJ3QgYmUgYSBjb21tb24gREhUIGFsbCBjYW4gZXZlbiBydW4gaWYgdGhleSB3YW50 IHRvLg0KPj4gPg0KPj4gPiBJIHRoaW5rIGxvb2tpbmcgYXQgaXQgZnJvbSB0aGUgcGVyc3BlY3Rp dmUgb2YgIm9uY2UgdGhlIERIVA0KPj4gPiBjaG9zZW4gaXQgaXMgbG9ja2VkIiBpcyB0aGUgd3Jv bmcgd2F5IHRvIGxvb2sgYXQgaXQuIFRoZSBpZGVhDQo+PiA+IGlzbid0IHRoYXQgYW55IGRldmlj ZSBjYW4gam9pbiBhbnkgYWxyZWFkeSBlc3RhYmxpc2hlZA0KPj4gPiBvdmVybGF5LCBidXQgdGhh dCBpZiBJIGRlcGxveSBhIHN5c3RlbSBvZiBoZXRlcm9nZW5lb3VzDQo+PiA+IGRldmljZXMsIHRo ZXJlIGlzIGF0IGxlYXN0IG9uZSB0aGF0IEkgY2FuIHNlbGVjdCB3aGVuIEkgc3RhcnQNCj4+ID4g YW5kIGtub3cgdGhhdCBhbGwgIlAyUFNJUCBlbmRwb2ludHMiIChhc3N1bWluZyB0aGF0IHRlcm0N Cj4+ID4gbWVhbnMgYW55dGhpbmcpIHdpbGwgYXQgbGVhc3Qgc3VwcG9ydCB0aGF0IGFuZCBJIGNh biBmb3JtIGFuDQo+PiA+IG92ZXJsYXkgd2l0aCB0aGVtLiBNYXliZSBub3QgdGhlIGlkZWFsIERI VCBmb3IgbXkgb3ZlcmxheSwNCj4+ID4gYnV0IHNvbWV0aGluZyBJIGtub3cgYWxsIGRldmljZXMg Y2FuIHN1cHBvcnQsIGFuZCBpZiBJIHJ1biBpdA0KPj4gPiBpbiB0aGF0IG1vZGUsIGl0IHdvcmtz Lg0KPj4gPg0KPj4gPiBQZXJzb25hbGx5LCBJIHRoaW5rIGlmIHdlIGRvbid0IGRvIHRoYXQsIG1h bnkgREhUcyB3aWxsIGJlDQo+PiA+IHN0YW5kYXJkaXplZCBmb3IgZGlmZmVyZW50IGVudmlyb25t ZW50cyAoZ29vZCkgYnV0IGVhY2gNCj4+ID4gdmVuZG9yIHdpbGwgaW1wbGVtZW50IGEgKHBvdGVu dGlhbGx5IGRpc2pvaW50KSBzdWJzZXQsIGFuZA0KPj4gPiB0aGVyZSBtYXkgYmUgbm8gd2F5IHRv IHVzZSB0d28gZW5kcG9pbnRzIGZyb20gZGlmZmVyZW50DQo+PiA+IHZlbmRvcnMgdG9nZXRoZXIg YXQgYWxsLg0KPj4gPg0KPj4gPiBJIGFncmVlIHRoYXQgaWYgYSB1c2VyIHNlbGVjdHMgYSBub24t bWFuZGF0b3J5IERIVCwgdGhleSBtYXkNCj4+ID4gcmlzayBub3QgYmVpbmcgZnVsbHkgaW50ZXJv cGVyYWJsZSwgYnV0IEkgdGhpbmsgaWYgd2UgZG9uJ3QNCj4+ID4gcGljayBvbmUgYXQgYWxsLCB3 ZSBhbG1vc3QgZ3VhcmFudGVlIHRoaW5ncyB3b24ndCBiZSBpbnRlcm9wZXJhYmxlLg0KPj4gPg0K Pj4gPiBBbmQgSSAoYW5kIEkgdGhpbmsgbmVhcmx5IGV2ZXJ5b25lKSBpcyAxMDAlIGluIHRoZSBj YW1wIG9mDQo+PiA+ICJ3ZSBzaG91bGQgYWxsb3cgcGx1Z2dhYmxlIERIVHMiLiBJIHRoaW5rIGl0 IGlzIHNhZmUgdG8gc2F5DQo+PiA+IHRoYXQgb25lIGlzIGEgZG9uZSBkZWFsLCBidXQgSSB3b3Vs ZCBwZXJzb25hbGx5IGhhdmUgdGhvdWdodA0KPj4gPiBhIG1hbmRhdG9yeSB3YXMgYXMgd2VsbC4g SW4gYW55IGNhc2UsIG15IHZvdGUgaXMgZGVmaW5pdGVseQ0KPj4gPiBmb3IgcGx1Z2dhYmxlIERI VHMuDQo+PiA+DQo+PiA+IERhdmlkDQo+PiA+DQo+PiA+IE9uIDcvMTMvMDcsIEpvbmF0aGFuIFJv c2VuYmVyZyA8amRyb3NlbkBjaXNjby5jb20+IHdyb3RlOg0KPj4gPiA+IEkndmUgcmVhZCBkcmFm dC1icnlhbi1wMnBzaXAtcmVxdWlyZW1lbnRzLTAwLCBhbmQgaGF2ZSBhIGJ1bmNoIG9mDQo+PiA+ ID4gY29tbWVudHMuIEJ1dCBhIGZldyBpdGVtcyBjYW1lIHRvIG1pbmQgSSB3YW50ZWQgdG8gZGlz Y3Vzcw0KPj4gPiB3aGljaCBtZXJpdA0KPj4gPiA+IHRoZWlyIG93biB0aHJlYWRzLg0KPj4gPiA+ DQo+PiA+ID4gRmlyc3QsIGlzIHRoZSBjb25jZXB0IG9mIG1hbmRhdG9yeS10by1pbXBsZW1lbnQg REhULiBUaGUNCj4+ID4gcmVxdWlyZW1lbnRzDQo+PiA+ID4gZG9jdW1lbnQgdGFsa3MgYSBsb3Qg YWJvdXQgcmVxdWlyZW1lbnRzIGFyb3VuZCBzZWxlY3RpbmcgYQ0KPj4gPiBtYW5kYXRvcnkNCj4+ ID4gPiB0byBpbXBsZW1lbnQgREhULiBJdHMgc29tZXRoaW5nIHdlJ3ZlIGRpc2N1c3NlZCBpbiB0 aGUNCj4+ID4gbWVldGluZyBhbmQgb24NCj4+ID4gPiB0aGUgbGlzdC4gSSB0aGluayBldmVyeW9u ZSBhZ3JlZXMgYWxzbyB0aGF0IHdlIG5lZWQgdG8gYWxsb3cgZm9yDQo+PiA+ID4gbXVsdGlwbGUg REhUIGFuZCBhbGwgb2YgdGhlIHJlY2VudCBwcm90b2NvbCBwcm9wb3NhbHMgc3VwcG9ydCBpdC4N Cj4+ID4gPg0KPj4gPiA+IEhvd2V2ZXIsIEkgZG8gbm90IHRoaW5rIHdlIHNob3VsZCBoYXZlIGEN Cj4+ID4gbWFuZGF0b3J5LXRvLWltcGxlbWVudCBESFQgYXQgYWxsLg0KPj4gPiA+DQo+PiA+ID4g VGhlcmUgYXJlIHNldmVyYWwgcmVhc29ucyBmb3IgdGhpcy4gRmlyc3Qgb2YgYWxsLCBpdHMgaW1w b3J0YW50IHRvDQo+PiA+ID4gdW5kZXJzdGFuZCB0aGUgcmVhc29uIHdoeSBJRVRGIGhhcyBtYW5k YXRvcnktdG8taW1wbGVtZW50DQo+PiA+ID4gZnVuY3Rpb25hbGl0eSBpbiBpdHMgcHJvdG9jb2xz LiBUaGUgb25lIGFuZCBvbmx5IHJlYXNvbiBpcyB0aGF0IGl0DQo+PiA+ID4gZW5zdXJlcyBpbnRl cm9wZXJhYmlsaXR5LiBJdCBlbnN1cmVzIHRoYXQsIGluZGVwZW5kZW50IG9mDQo+PiA+IHRoZSBv cHRpb25hbA0KPj4gPiA+IGZlYXR1cmVzIHNlbGVjdGVkIGJ5IGEgcGFpciBvZiBlbnRpdGllcywg d2hlbiB5b3UgY29ubmVjdCB0aGVtDQo+PiA+ID4gdG9nZXRoZXIsIHRoZXkgY2FuIHN0aWxsIGlu dGVyb3BlcmF0ZS4NCj4+ID4gPg0KPj4gPiA+IFRoaXMgcHJvcGVydHkgd2lsbCBOT1QgYmUgcmV0 YWluZWQgd2l0aCBhDQo+PiA+IG1hbmRhdG9yeS10by1pbXBsZW1lbnQgREhULg0KPj4gPiA+IE9u Y2UgdGhlIHJpbmcgZm9ybXMsIHRoZSBESFQgcHJvdG9jb2wgaXMgY2hvc2VuIGFuZCBsb2NrZWQu DQo+PiA+IFRodXMsIGlmIGFueQ0KPj4gPiA+ICAgREhUIGJlc2lkZXMgdGhlICdtYW5kYXRvcnkt dG8taW1wbGVtZW50JyBvbmUgaGFzIGJlZW4NCj4+ID4gc2VsZWN0ZWQgZm9yDQo+PiA+ID4gdGhl IERIVCwgYSBuZXcgbm9kZSBub3Qgc3VwcG9ydGluZyB0aGF0IERIVCB3aWxsIG5vdCBiZQ0KPj4g PiBhYmxlIHRvIGpvaW4NCj4+ID4gPiB0aGUgcmluZyBldmVuIGlmIGl0IGltcGxlbWVudHMgdGhl IG1hbmRhdG9yeS10by1pbXBsZW1lbnQNCj4+ID4gb25lLiBUaHVzLA0KPj4gPiA+IHRoZSBlbnRp cmUgcHVycG9zZSBvZiBtYW5kYXRvcnktdG8taW1wbGVtZW50IGlzIGVsaW1pbmF0ZWQNCj4+ID4g LSB3ZSBkb24ndA0KPj4gPiA+IGFjdHVhbGx5IGdldCBpbnRlcm9wZXJhYmlsaXR5Lg0KPj4gPiA+ DQo+PiA+ID4gSW5kZWVkLCB0byBnZXQgdGhpcyBraW5kIG9mIGludGVyb3BlcmFiaWxpdHksIHdl J2QgbmVlZCB0byBwaWNrIG9uZQ0KPj4gPiA+IGFuZCBvbmx5IG9uZSBESFQgdGhhdCBldmVyIGdl dHMgdXNlZCB3aXRoIHAycHNpcC4gSSB0aGluaw0KPj4gPiB0aGF0IGlzIGEgbWlzdGFrZS4NCj4+ ID4gPiBUaGlzIGlzIGFuIGV2b2x2aW5nIGFyZWEgYW5kIGlzIG9uZSB3aGVyZSBhZ2lsaXR5IGlz IGltcG9ydGFudC4NCj4+ID4gPg0KPj4gPiA+IEluc3RlYWQsIHdoYXQgSSB0aGluayBoYXBwZW5z IGlzIHRoYXQgYSAncHJvdmlkZXInIHRoYXQNCj4+ID4gZGVwbG95cyBhIHAycA0KPj4gPiA+IG5l dHdvcmsgd2lsbCBuZWVkIHRvIHBpY2sgYSBESFQsIGFuZCBtYWtlIHN1cmUgdGhhdCB0aGUgY2xp ZW50cyBhbGwNCj4+ID4gPiBzdXBwb3J0IHRoYXQgREhULiBUaGlzIGlzIHNvbWV0aGluZyB0aGUg bWFya2V0IHNob3VsZCBkcml2ZSwgbm90IHVzLg0KPj4gPiA+DQo+PiA+ID4gU2Vjb25kbHksIEkg dGhpbmsgaXRzIGltcG9ydGFudCB0byByZWFsaXplIHRoYXQgd2UgYXJlDQo+PiA+IHBpY2tpbmcg dXAgd29yaw0KPj4gPiA+IGluIGFuIGFyZWEgdGhhdCBpcyB3ZWxsIHRyb2QuIFRoZXJlIGFyZSBs b3RzIGFuZCBsb3RzIG9mIHBhcGVycyBhbmQNCj4+ID4gPiBwcm90b2NvbHMgYW5kIHNvZnR3YXJl IHdyaXR0ZW4gYXJvdW5kIFAyUCBuZXR3b3Jrcy4gSSBkb24ndCB0aGluaw0KPj4gPiA+IGFueW9u ZSBsb29rcyBhdCBhbiBJRVRGIHByb3RvY29sIGFuZCBzYXlzLCAiSUVURiBhcmUgdGhlDQo+PiA+ IGd1eXMgd2hvIGtub3cNCj4+ID4gPiBhYm91dCBESFRzLCBsZXRzIGdvIHdpdGggdGhlaXIgcmVj b21tZW5kYXRpb24iLiBXaGF0IElFVEYgaXMgcmVhbGx5DQo+PiA+ID4gZ29vZCBhdCwgYW5kIHdo YXQgdGhpcyBncm91cCBoYXMgZXhwZXJ0aXNlIGluLCBpcyBTSVAsIGFuZCBvbg0KPj4gPiA+IGRl c2lnbmluZyBnb29kLCBzY2FsYWJsZSBwcm90b2NvbHMgaW4gZ2VuZXJhbCAtIHRoaW5ncyB0aGF0 IGhhdmUNCj4+ID4gPiBzZWN1cml0eSwgZXh0ZW5zaWJpbGl0eSwgZ29vZCBwZXJmb3JtYW5jZSwg YW5kIHNvIG9uLiBTbyBJDQo+PiA+IHRoaW5rIHRoZQ0KPj4gPiA+IGdyZWF0ZXN0IHZhbHVlIHdl IGNhbiBicmluZyB0byB0aGUgdGFibGUgaXMgdG8gY3JlYXRlIGENCj4+ID4gcHJvdG9jb2wgdGhh dA0KPj4gPiA+IGFsbG93cyBvdGhlcnMgdG8gdGFrZSBESFRzIGFuZCBlYXNpbHkgdHVybiB0aGVt IGludG8gYSByZWFsIHdpcmUNCj4+ID4gPiBwcm90b2NvbCB0aGF0IHlvdSBjYW4gYWN0dWFsbHkg ZGVwbG95LCBvbiB0aGUgSW50ZXJuZXQsIHRvDQo+PiA+IHN1cHBvcnQgU0lQDQo+PiA+ID4gYW5k IGlkZWFsbHkgb3RoZXIgdGhpbmdzIHRvby4gSW50ZXJlc3RpbmdseSwgdGhpcyBpcw0KPj4gPiBl eGFjdGx5IHdoYXQgYWxsDQo+PiA+ID4gb2YgdGhlIHByb3RvY29sIHByb3Bvc2FscyBkby4gVGhh dCBraW5kIG9mIGZvY3VzIGdvZXMgaGFuZC1pbi1oYW5kDQo+PiA+ID4gd2l0aCBzYXlpbmcsIGxl dCBzb21lb25lIGVsc2UgZmlndXJlIG91dCB3aGljaCBESFQgdG8gdXNlLg0KPj4gPiBJIHRoaW5r IGl0cw0KPj4gPiA+IHBlcmZlY3RseSByZWFzb25hYmxlIGZvciB1cywgYW5kIGZvciBvdGhlcnMs IHRvIHdyaXRlDQo+PiA+IGRvY3VtZW50cyBvbiBob3cNCj4+ID4gPiB0byB1c2Ugb3VyIHByb3Rv Y29sIHdpdGggdmFyaW91cyBESFRzLiBCdXQgSSB0aGluayB3ZQ0KPj4gPiBzaG91bGQgYmUgb3V0 IG9mDQo+PiA+ID4gdGhlIGJ1c2luZXNzIG9mIHBpY2tpbmcgb25lIG9yIHJlY29tbWVuZGluZyBv bmUgKG9yIG9uZXMpDQo+PiA+IHRvIGJlIHVzZWQuDQo+PiA+ID4NCj4+ID4gPiAtSm9uYXRoYW4g Ui4NCj4+ID4gPiAtLQ0KPj4gPiA+IEpvbmF0aGFuIEQuIFJvc2VuYmVyZywgUGguRC4gICAgICAg ICAgICAgICAgICAgNjAwIExhbmlkZXggUGxhemENCj4+ID4gPiBDaXNjbyBGZWxsb3cgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBhcnNpcHBhbnksDQo+PiA+IE5KIDA3MDU0LTI3 MTENCj4+ID4gPiBDaXNjbyBTeXN0ZW1zDQo+PiA+ID4gamRyb3NlbkBjaXNjby5jb20gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBGQVg6ICAgKDk3MykgOTUyLTUwNTANCj4+ID4gPiBodHRw Oi8vd3d3Lmpkcm9zZW4ubmV0ICAgICAgICAgICAgICAgICAgICAgICAgIFBIT05FOiAoOTczKSA5 NTItNTAwMA0KPj4gPiA+IGh0dHA6Ly93d3cuY2lzY28uY29tDQo+PiA+ID4NCj4+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPiA+IFAyUFNJ UCBtYWlsaW5nIGxpc3QNCj4+ID4gPiBQMlBTSVBAaWV0Zi5vcmcNCj4+ID4gPiBodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCj4+ID4gPg0KPj4gPg0KPj4gPg0K Pj4gPiAtLQ0KPj4gPiBEYXZpZCBBLiBCcnlhbg0KPj4gPiBkYnJ5YW5AU0lQZWVyaW9yLmNvbQ0K Pj4gPiArMS43NTcuNTY1LjAxMDEgeDEwMQ0KPj4gPiArMS43NTcuNTY1LjAwODggKGZheCkNCj4+ ID4gd3d3LlNJUGVlcmlvci5jb20NCj4+ID4NCj4+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4gUDJQU0lQIG1haWxpbmcgbGlzdA0KPj4gPiBQ MlBTSVBAaWV0Zi5vcmcNCj4+ID4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcDJwc2lwDQo+PiA+DQo+Pg0KPiANCj4gDQo+IC0tIA0KPiBEYXZpZCBBLiBCcnlhbg0KPiBk YnJ5YW5AU0lQZWVyaW9yLmNvbQ0KPiArMS43NTcuNTY1LjAxMDEgeDEwMQ0KPiArMS43NTcuNTY1 LjAwODggKGZheCkNCj4gd3d3LlNJUGVlcmlvci5jb20NCj4gDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4g UDJQU0lQQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3AycHNpcA0KPg== --===============1616814912== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1616814912==-- From p2psip-bounces@ietf.org Sat Jul 14 15:04:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9muX-00058G-DM; Sat, 14 Jul 2007 15:04:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9muV-0004zv-DE for p2psip@ietf.org; Sat, 14 Jul 2007 15:04:07 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9muR-0001D5-2u for p2psip@ietf.org; Sat, 14 Jul 2007 15:04:07 -0400 Received: from cpe-76-185-142-113.tx.res.rr.com ([76.185.142.113] helo=[192.168.2.103]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1I9muQ-0006ch-N1; Sat, 14 Jul 2007 14:04:02 -0500 In-Reply-To: <4697F367.6000809@cisco.com> References: <4697F367.6000809@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] HBH vs. E2E SIP in P2PSIP Date: Sat, 14 Jul 2007 14:03:50 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jul 13, 2007, at 4:49 PM, Jonathan Rosenberg wrote: > draft-bryan-p2psip-requirements-00 talks about how SIP relates to > the P2P protocol. It says: > >> The above discussion suggests at least two paradigms for SIP >> operation in a p2p setting: the end-to-end paradigm where a SIP >> user agent uses the p2p location service to discover the >> location of callee, and then send the SIP message directly to >> the callee, or a hop-by-hop paradigm where each peer forwards >> the SIP request to a peer which is more 'closer' to the callee. >> The former can be thought of as a RPC whereas the later can be >> thought of as a local procedure call to determine the next hop. > > I'd like to propose that, any model which views the peers in the > p2p network as proxies (things that add Via headers, follow proxy > rules as defined in RFC 3261, and so on), is basically fatally > flawed from a security perspective. Unless the system uses the SIPSEC model, where following an initial SIP request the proxies form a cryptotransparent tunnel between UAs. That's the real reason I've been pushing the SIPSEC draft. If we have a SIP-based P2P layer where peers act as SIP proxies (as in dSIP), then we must have something like SIPSEC to provide for secure transport. If we use something other than SIP, then that "something" must have equivalent functionality. We just can't go around handing cleartext to peers (even if the peer is a STUN relay instead of a SIP proxy) and hoping they don't abuse it. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 15:42:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9nVE-0004Ud-8C; Sat, 14 Jul 2007 15:42:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9nVC-0004OB-5y for p2psip@ietf.org; Sat, 14 Jul 2007 15:42:02 -0400 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9nUq-00018F-Bp for p2psip@ietf.org; Sat, 14 Jul 2007 15:42:01 -0400 Received: from source ([192.150.11.134]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Sat, 14 Jul 2007 12:40:30 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6EJdHot029905 for ; Sat, 14 Jul 2007 12:39:17 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6EJeR0c028580 for ; Sat, 14 Jul 2007 12:40:28 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 12:40:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sat, 14 Jul 2007 12:40:26 -0700 Message-ID: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> In-Reply-To: <007a01c7c637$8d48d510$a507740a@DELLWEI> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfGN6OPpcrVe3O1SBOtTL3Hc9smjgAEIOSg References: <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com><9FA16888AD1BF64ABCE6C2532CCEB98A02A6B555@xmb-sjc-219.amer.cisco.com><4d4304a00707140803r776f123av730e1bb280c322c0@mail.gmail.com> <007a01c7c637$8d48d510$a507740a@DELLWEI> From: "Kundan Singh" To: "P2PSIP WG" X-OriginalArrivalTime: 14 Jul 2007 19:40:28.0103 (UTC) FILETIME=[D4AA5570:01C7C64E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 Suppose we define a mandatory-to-implement DHT, say D0. Now node N1 implements DHTs D0 and D1, and node N2 implements D0 and D2. When N1 started, it decided to use DHT D1 and joined the existing DHT with D1 (hence locked to D1). When N2 started, it decided on D2 (hence locked to D2). I suppose in this case we all agree that N1 and N2 can talk only via client protocol. --- (A) Essentially N1 and N2 are not interoperating using the peer protocol of mandatory-to-implement D0. Now in the example, to effectively utilize mandatory-to-implement DHT, both N1 and N2 _MUST_ also join D0 using the peer protocol --- (B) (Does anyone disagree with statement (B)?) This means, for N1, the DHT maintenance operations must be done in D0 as well as in D1, and any lookup operation must fallback to D0 if failed in D1. Essentially, the performance gain of D1 is nullified and the performance is limited to that of the algorithm in D0. This defeats the purpose of let-the-best-DHT-win motto, and in practice *discourages* implementing other DHTs besides default D0 since you don't gain performance. (Which encourages implementations to become non-standard in favor of better performance.) I agree with Jonathan. I don't think we should limit innovation by specifying a mandatory-to-implement DHT when we clearly don't know which is the best DHT. Like Henning said, the client protocol can be used for interconnecting. (Talking about 'the best DHT', I think depending on the deployment scenario different DHTs will perform differently. So one-size-fits-all model may not be best for all the use cases we have. For example Bamboo is proven to be good for DHT service hence probably good for low-churn high-storage P2PSIP-proxies use case, but too many connections and low keep-alives and data sync timers of Bamboo may not be good for high-churn behind-the-NAT residential peers running on user laptops.) _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 16:28:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9oDc-0007Kv-NN; Sat, 14 Jul 2007 16:27:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9oDb-0007KS-8n for p2psip@ietf.org; Sat, 14 Jul 2007 16:27:55 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9oDW-0003EU-QX for p2psip@ietf.org; Sat, 14 Jul 2007 16:27:55 -0400 Received: from lappy ([67.161.59.204]) by quinthar.com for ; Sat, 14 Jul 2007 13:27:46 -0700 From: "David Barrett" To: "'Kundan Singh'" , "'P2PSIP WG'" Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sat, 14 Jul 2007 13:27:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfGN6OPpcrVe3O1SBOtTL3Hc9smjgAEIOSgAAKVN8A= In-Reply-To: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Kundan Singh [mailto:kundan@adobe.com] > Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > > I agree with Jonathan. I don't think we should limit innovation by > specifying a mandatory-to-implement DHT when we clearly don't know which > is the best DHT. Like Henning said, the client protocol can be used for > interconnecting. If we can't standardize on a set of DHT messages, what *can* we standardize on? For something like TCP, so long as the packets over the wire are standardized, the internal state machines and congestion-control algorithms can vary on a per-endpoint basis (to some degree). Ideally we could find a similar approach: standardize the packet format such that any two endpoints can talk in some form, but leave the algorithm flexible such that even if each side uses a different DHT algorithm it still somehow works (just like with TCP, we might be using different congestion control algorithms, but we can still talk fine). However, I don't know if such a thing is realistically possible because DHTs require much greater cooperation: not only at the protocol level, but between endpoints, and across the overlay as a whole. Given this, I don't know if it's realistically possible to *not* standardize on a given DHT implementation. And as Kundan points out, merely saying "you need to support at least X and optionally Y or Z" doesn't work unless everybody always connects with at least X -- if you and I support X but only connect with Y or Z, then the X DHT suffers. (And if everybody connects with at least X, then we've effectively standardized on that and why bother with Y and Z?) So I say we pick one and be done with it. Yes, a better one will come along, that's a certainty. But let's cross that bridge when we get there, and cross the bridge before us now. -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 17:28:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pAg-0007Ms-0D; Sat, 14 Jul 2007 17:28:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pAe-0007MG-5d for p2psip@ietf.org; Sat, 14 Jul 2007 17:28:56 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9pAa-00055o-Pj for p2psip@ietf.org; Sat, 14 Jul 2007 17:28:56 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Sat, 14 Jul 2007 14:28:51 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6ELSnWs011042 for ; Sat, 14 Jul 2007 14:28:50 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6ELSm0c000438 for ; Sat, 14 Jul 2007 14:28:49 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 14:28:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sat, 14 Jul 2007 14:28:47 -0700 Message-ID: <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> In-Reply-To: <200707142027.l6EKRvoX002283@inbound-smtp-1.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfGN6OPpcrVe3O1SBOtTL3Hc9smjgAEIOSgAAKVN8AAAQSZgA== References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <200707142027.l6EKRvoX002283@inbound-smtp-1.corp.adobe.com> From: "Kundan Singh" To: "P2PSIP WG" X-OriginalArrivalTime: 14 Jul 2007 21:28:49.0238 (UTC) FILETIME=[F7A4CF60:01C7C65D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 > If we can't standardize on a set of DHT messages, what *can*=20 > we standardize on? Agreed. That's why the pluggable DHT approach is good. In particular, the specification can define the common framework (similar to ASP including on-the-wire message) but does not require that a particular DHT algorithm must be implemented. Let the individual DHT algorithms that confirm to the framework be defined separately. The implementators can say 'this is a P2P SIP implementation that uses so-and-so DHT algorithm'. Now one can argue that if the DHT algorithms are different what is the point of having a common peer protocol's message format because in practice peers with different DHT algorithms may not be communicating with each other using the peer protocol. One reason is that most of these DHT protocols share common parts and the framework unifies the common parts. Hence a new DHT algorithm specification does not have to re-specify the common parts, if the common parts are abstracted in the framework. Also, it allows migrating from one algorithm to another. > So I say we pick one and be done with it. Yes, a better one=20 > will come along, that's a certainty. But let's cross that=20 > bridge when we get there, and cross the bridge before us now. Yes.=20 But this doesn't require a mandatory DHT in the specification. The roadmap could be (1) a P2P-SIP framework specification for common parts (2) individual DHT algorithms that confirm to the interface in (1). Let the implementors decide which DHT algorithm(s) they want to confirm to. If two products implement different DHT algorithm, they are in entirely different P2P overlay. Thus, an implementation claiming to be P2P-SIP compliant must also specify the DHT algorithm(s) it implements. The ASP draft also describes the migration strategy when a vendor wants to change its DHT algorithm.=20 I think it would be nice if P2P-SIP can handle DHT evolution without enforcing backward compatibility with that one mandatory-to-implement DHT. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 17:57:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pcH-0008Gr-Fr; Sat, 14 Jul 2007 17:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pcG-0008Ge-ES for p2psip@ietf.org; Sat, 14 Jul 2007 17:57:28 -0400 Received: from an-out-0708.google.com ([209.85.132.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9pcC-0005sX-68 for p2psip@ietf.org; Sat, 14 Jul 2007 17:57:28 -0400 Received: by an-out-0708.google.com with SMTP id c17so170330anc for ; Sat, 14 Jul 2007 14:57:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Pfb5G1CznhD1j9Xe9gtbVHVQNpoWBSQaxMGjex1HdEFZ2Gf5mOg8p/3rg/G/K0OjiQV1BdGotLLg3olAeskjHm5Dn/miw7bZyPzvXfZqwH2Gv++VQKJjLs7DlvijTPZWeVpcUlTHjfgmOKNe4BZkGKGCgjpuVzU+lt9HTMyJxGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=rWkKdXmU5cnc21XwxO30ax2/nJnUMtXTTOTxPu9Iv5c6rv79nN+fbWYPwcK5G0O3nj2CHdUtsMPxm7p1aqxj+Rt9Nmq5ojkF1CCWw3RjQ/tbZdCngPPcwNgqoqVBukEno+OQAWsYX1OQ/CsbIgy1TvZGAEgjmeR3VMtacJyE8Fw= Received: by 10.100.122.8 with SMTP id u8mr1574976anc.1184450243758; Sat, 14 Jul 2007 14:57:23 -0700 (PDT) Received: by 10.100.112.12 with HTTP; Sat, 14 Jul 2007 14:57:23 -0700 (PDT) Message-ID: <20d2bdfb0707141457w4ff29785r93c1021d7803d210@mail.gmail.com> Date: Sat, 14 Jul 2007 17:57:23 -0400 From: "Bruce Lowekamp" To: "Jonathan Rosenberg" Subject: Re: [P2PSIP] HBH vs. E2E SIP in P2PSIP In-Reply-To: <4697F367.6000809@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4697F367.6000809@cisco.com> X-Google-Sender-Auth: 99416f8bc29cc0f4 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 7/13/07, Jonathan Rosenberg wrote: > I'd like to propose that, any model which views the peers in the p2p > network as proxies (things that add Via headers, follow proxy rules as > defined in RFC 3261, and so on), is basically fatally flawed from a > security perspective. I think this is a fair statement, not only for the security reasons, but also because the routing requirements of SIP proxies don't mesh very well with the routing (and route stability) characteristics of P2P overlay networks. > The way you limit what peers can do is by using a protocol to > communicate with peers whose very design limits what can be done. A > protocol built from the ground up to do nothing but give an intermediary > the ability to move a message around based on DHT topology. You wouldn't > need to worry about things modifying media destinations since there is > no SDP. You needn't worry about spoofing caller ID since there is no > caller ID in the protocol. All you do is use this protocol to allow you > to set up a secure, e2e, TLS connection between you and the UA you want > to talk to, and then run SIP over that. > > The great benefit is that SIP already allows UA to UA communications. It > always has. P2PSIP then slides in as a pure, clean replacement for > RFC3263, allowing you to identify the target UA that you want to connect > to, and provide a means for connecting to them through firewalls and NATs. One of the current shortcomings of this requirements drafts is that section 9.2, SIP Security, is still work-in-progress. It seems like one security requirement here is: - If the peer protocol allows for the routing of SIP messages across the overlay, then it MUST provide an integrity mechanism to ensure that the message is not modified by the routing peers. I'm unsure whether I believe that message secrecy should be the responsibility of the Peer protocol or the E2E (SIP) protocol. It's certainly not hard to provide such a mechanism in the Peer protocol, so I think we should also list that capability as a requirement for the protocol. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 18:07:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pm2-0000ox-4x; Sat, 14 Jul 2007 18:07:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pm0-0000oq-L8 for p2psip@ietf.org; Sat, 14 Jul 2007 18:07:32 -0400 Received: from mta2.prod1.dngr.net ([216.220.209.221]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9pm0-00051a-Ah for p2psip@ietf.org; Sat, 14 Jul 2007 18:07:32 -0400 Received: from mfe1.prod.danger.com (unknown [10.253.33.100]) by px03.prod1.dngr.org (Postfix) with ESMTP id 81C0D10F1C1C; Sat, 14 Jul 2007 15:06:39 -0700 (PDT) Received: from [10.253.33.100] (HELO localhost.localdomain) by mfe1.prod.danger.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1707834647; Sat, 14 Jul 2007 15:06:38 -0700 Date: Sat, 14 Jul 2007 15:06:33 -0700 Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion X-Mailer: Danger Service X-Danger-Send-Id: AAAwk0aZSO4AAYap Content-Transfer-Encoding: 7bit In-Reply-To: <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Kundan Singh , P2PSIP WG Mime-Version: 1.0 References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> From: David Barrett Message-Id: <1184450797.2D359846@fc9.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Barrett List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Ah, I agree with you here. I like the goal of separating DHT-specific code from general shared code. The one change I'd make to your proposal (as I understand it) is to first just pick a single DHT as if it were the only choice, build everything exactly around that DHT, and call that P2PSIP 1.0. Then, after we've done it once, we'll have a very detailed understanding of its real-word issues and can thus figure out the right abstraction layer to enable pluggable DHTs. But my fear is before doing the specific case once from top to bottom, it's premature to try to generalize for other types of DHTs. -david On Sat, 14 Jul 2007 2:53 pm, Kundan Singh wrote: > > >> If we can't standardize on a set of DHT messages, what *can* >> we standardize on? > > Agreed. That's why the pluggable DHT approach is good. In particular, > the specification can define the common framework (similar to ASP > including on-the-wire message) but does not require that a particular > DHT algorithm must be implemented. Let the individual DHT algorithms > that confirm to the framework be defined separately. The implementators > can say 'this is a P2P SIP implementation that uses so-and-so DHT > algorithm'. > > Now one can argue that if the DHT algorithms are different what is the > point of having a common peer protocol's message format because in > practice peers with different DHT algorithms may not be communicating > with each other using the peer protocol. One reason is that most of > these DHT protocols share common parts and the framework unifies the > common parts. Hence a new DHT algorithm specification does not have to > re-specify the common parts, if the common parts are abstracted in the > framework. Also, it allows migrating from one algorithm to another. > >> So I say we pick one and be done with it. Yes, a better one >> will come along, that's a certainty. But let's cross that >> bridge when we get there, and cross the bridge before us now. > > Yes. > But this doesn't require a mandatory DHT in the specification. The > roadmap could be > (1) a P2P-SIP framework specification for common parts > (2) individual DHT algorithms that confirm to the interface in (1). > > Let the implementors decide which DHT algorithm(s) they want to confirm > to. If two products implement different DHT algorithm, they are in > entirely different P2P overlay. Thus, an implementation claiming to be > P2P-SIP compliant must also specify the DHT algorithm(s) it implements. > The ASP draft also describes the migration strategy when a vendor wants > to change its DHT algorithm. > > I think it would be nice if P2P-SIP can handle DHT evolution without > enforcing backward compatibility with that one mandatory-to-implement > DHT. > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 18:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9puF-0003jF-85; Sat, 14 Jul 2007 18:16:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9puE-0003jA-A8 for p2psip@ietf.org; Sat, 14 Jul 2007 18:16:02 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9puA-0006Hc-1v for p2psip@ietf.org; Sat, 14 Jul 2007 18:16:02 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6EMFp1P017115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Jul 2007 18:15:52 -0400 (EDT) In-Reply-To: <1184450797.2D359846@fc9.dngr.org> References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> <1184450797.2D359846@fc9.dngr.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91783A02-1B95-4CBC-A81D-EBFE9EA573A4@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sat, 14 Jul 2007 18:15:49 -0400 To: David Barrett X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org A number of proposals have moved beyond this stage and demonstrated, in running code or plausible description, that using a single maintenance and look-up protocol is quite feasible across multiple different DHTs. Naturally, there is no way to prove that every conceivable DHT that somebody may invent in the future can be handled by these protocols, but I see no reason to regress below working code and good reason to suspect that at least structured overlays can be maintained by these protocols if they are designed correctly, i.e., without making unwarranted assumptions. DHTs aren't magic. If we ignore the 'distributed' part, DHTs are essentially graphs, where vertices are network nodes. Just like a 'graph maintenance protocol' within a host can build new data structures beyond, say, trees, it is very likely that the protocol proposals can maintain new distributed structures, as long as they follow that basic model. The protocol is really not much more than a pointer establishment mechanism, with lots of machinery to take into account that network 'pointers' aren't as nicely behaved as pointers in C/C++. Henning On Jul 14, 2007, at 6:06 PM, David Barrett wrote: > Ah, I agree with you here. I like the goal of separating DHT- > specific code from general shared code. > > The one change I'd make to your proposal (as I understand it) is to > first just pick a single DHT as if it were the only choice, build > everything exactly around that DHT, and call that P2PSIP 1.0. > Then, after we've done it once, we'll have a very detailed > understanding of its real-word issues and can thus figure out the > right abstraction layer to enable pluggable DHTs. > > But my fear is before doing the specific case once from top to > bottom, it's premature to try to generalize for other types of DHTs. > > -david > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 18:24:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9q1v-0005Ji-6k; Sat, 14 Jul 2007 18:23:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9q1t-0005JO-91 for p2psip@ietf.org; Sat, 14 Jul 2007 18:23:57 -0400 Received: from an-out-0708.google.com ([209.85.132.242]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9q1d-0005Kj-VZ for p2psip@ietf.org; Sat, 14 Jul 2007 18:23:57 -0400 Received: by an-out-0708.google.com with SMTP id c17so170925anc for ; Sat, 14 Jul 2007 15:22:29 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=uSgSCP7J3ZRHHS9Ik8kLoNDwPnCRM9Dyo4dyDMRtbi0lq8IljyH3dSQdYvCZuMb84GmLrYAtgwsRT2yVDrcZMqtgpx4HnDPB81qj16YWk003EeDbi1f3EvvHi2Abmz5KTBDrC+D+nagdj1cZvzEVx9UZnhco//cXu3TWo7CTxDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=NxIvgrYb40bszai4gbKBgX8Q4qTH0cwp0Hut1gQDNWIo84bzvZN9bDQRWCbPpzPHQltGZPMU+85EDt9PU0Hy4TCRv/iAw31jLbQLWGwb0ZFFmqY9Ryswru7lnpL/Ax5okkrjXP/VBkeMbLAxtJcIHJX8Avmhf9gA0I6pi8338oE= Received: by 10.100.92.17 with SMTP id p17mr1591700anb.1184451749376; Sat, 14 Jul 2007 15:22:29 -0700 (PDT) Received: by 10.100.112.12 with HTTP; Sat, 14 Jul 2007 15:22:29 -0700 (PDT) Message-ID: <20d2bdfb0707141522n14a061cfte71e310a545c88ea@mail.gmail.com> Date: Sat, 14 Jul 2007 18:22:29 -0400 From: "Bruce Lowekamp" To: "Jonathan Rosenberg" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <4697F02B.4030506@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4697F02B.4030506@cisco.com> X-Google-Sender-Auth: 811eb6e8074f4716 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 7/13/07, Jonathan Rosenberg wrote: > This property will NOT be retained with a mandatory-to-implement DHT. > Once the ring forms, the DHT protocol is chosen and locked. Thus, if any > DHT besides the 'mandatory-to-implement' one has been selected for the > DHT, a new node not supporting that DHT will not be able to join the > ring even if it implements the mandatory-to-implement one. Thus, the > entire purpose of mandatory-to-implement is eliminated - we don't > actually get interoperability. > > Indeed, to get this kind of interoperability, we'd need to pick one and > only one DHT that ever gets used with p2psip. I think that is a mistake. > This is an evolving area and is one where agility is important. > > Instead, what I think happens is that a 'provider' that deploys a p2p > network will need to pick a DHT, and make sure that the clients all > support that DHT. This is something the market should drive, not us. I think it's important that we carefully consider what use-cases we care about and evaluate our decisions in those terms. While I understand your point, the "provider" use case is only one of many (and we really need more work on use-cases). The problem, as you point out, is that a default only helps if all of the relevant peers are present at the time the overlay is formed (and I haven't seen any proposals for a distributed consensus algorithm in this group). While I disagree with Henning's position that there will be relatively few peers in the overlay (for many use cases), the general concept that those nodes that don't speak the chosen DHT can become clients is probably the right approach. If we don't specify a mandatory DHT, then we run the risk that a large percentage of the use-cases we have will only work with devices from the same vendor. I do hope that the market will drive solutions (and that a larger percentage of these dht algorithm papers will move beyond the paper stage) that lead to better DHTs being commonly available, but I would hate for the first generation of devices to fail to provide any level of interoperability. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 18:52:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9qTd-00027N-OX; Sat, 14 Jul 2007 18:52:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9qTc-00027H-NA for p2psip@ietf.org; Sat, 14 Jul 2007 18:52:36 -0400 Received: from mta1.prod1.dngr.net ([216.220.209.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9qTY-00079n-9C for p2psip@ietf.org; Sat, 14 Jul 2007 18:52:36 -0400 Received: from mfe1.prod.danger.com (unknown [10.253.33.100]) by px01.prod1.dngr.org (Postfix) with ESMTP id A29B010F1DB1; Sat, 14 Jul 2007 15:52:29 -0700 (PDT) Received: from [10.253.33.100] (HELO localhost.localdomain) by mfe1.prod.danger.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1707986871; Sat, 14 Jul 2007 15:52:29 -0700 Date: Sat, 14 Jul 2007 15:52:24 -0700 Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion X-Mailer: Danger Service X-Danger-Send-Id: AABHnkaZU60AAYa5 Content-Transfer-Encoding: 7bit In-Reply-To: <20d2bdfb0707141522n14a061cfte71e310a545c88ea@mail.gmail.com> Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Bruce Lowekamp , Jonathan Rosenberg Mime-Version: 1.0 References: <4697F02B.4030506@cisco.com> <20d2bdfb0707141522n14a061cfte71e310a545c88ea@mail.gmail.com> From: David Barrett Message-Id: <1184453549.29E9C06C@fb4.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Barrett List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with Bruce: a top priority for P2PSIP 1.0 is to be highly compatible between multple vendor's implementations. As such, choosing a single DHT seems like a sensible risk reduction -- even if later we decide to change it. And I agree with Henning -- I'm sure there are ways to create an uber-DHT that is algorithm independent. But it's harder and riskier, and I think that problem needn't be solved today. I agree it's not magic, but there is a surprising amount of voodoo to get any of this working outside the lab. Overall, I still think this quest for eternal agility and fear of commitment is keeping us from moving forward at all. I'd happily give up some short-term flexibility if it meant improving the odds of getting *anything* working. Problems are so much easier to solve when you actually have them, versus when we merely theorize them. -david On Sat, 14 Jul 2007 3:28 pm, Bruce Lowekamp wrote: > On 7/13/07, Jonathan Rosenberg wrote: >> This property will NOT be retained with a mandatory-to-implement DHT. >> Once the ring forms, the DHT protocol is chosen and locked. Thus, if >> any >> DHT besides the 'mandatory-to-implement' one has been selected for >> the >> DHT, a new node not supporting that DHT will not be able to join the >> ring even if it implements the mandatory-to-implement one. Thus, the >> entire purpose of mandatory-to-implement is eliminated - we don't >> actually get interoperability. >> >> Indeed, to get this kind of interoperability, we'd need to pick one and >> only one DHT that ever gets used with p2psip. I think that is a >> mistake. >> This is an evolving area and is one where agility is important. >> >> Instead, what I think happens is that a 'provider' that deploys a p2p >> network will need to pick a DHT, and make sure that the clients all >> support that DHT. This is something the market should drive, not us. > > I think it's important that we carefully consider what use-cases we > care about and evaluate our decisions in those terms. While I > understand your point, the "provider" use case is only one of many > (and we really need more work on use-cases). > > The problem, as you point out, is that a default only helps if all of > the relevant peers are present at the time the overlay is formed (and > I haven't seen any proposals for a distributed consensus algorithm in > this group). While I disagree with Henning's position that there will > be relatively few peers in the overlay (for many use cases), the > general concept that those nodes that don't speak the chosen DHT can > become clients is probably the right approach. > > If we don't specify a mandatory DHT, then we run the risk that a large > percentage of the use-cases we have will only work with devices from > the same vendor. I do hope that the market will drive solutions (and > that a larger percentage of these dht algorithm papers will move > beyond the paper stage) that lead to better DHTs being commonly > available, but I would hate for the first generation of devices to > fail to provide any level of interoperability. > > Bruce > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 19:00:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9qbR-0003Xy-3f; Sat, 14 Jul 2007 19:00:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9qbP-0003Xi-Av for p2psip@ietf.org; Sat, 14 Jul 2007 19:00:39 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9qbL-0007I4-1X for p2psip@ietf.org; Sat, 14 Jul 2007 19:00:39 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6EN0Tge020998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Jul 2007 19:00:34 -0400 (EDT) In-Reply-To: <1184453549.29E9C06C@fb4.dngr.org> References: <4697F02B.4030506@cisco.com> <20d2bdfb0707141522n14a061cfte71e310a545c88ea@mail.gmail.com> <1184453549.29E9C06C@fb4.dngr.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EFFB547-4032-407E-BC20-F593BA25F073@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sat, 14 Jul 2007 19:00:27 -0400 To: David Barrett X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I don't know what beyond actual proposals and running code you'd like. Fear-mongering and mentioning demons in the closet isn't going to help us. If you have concrete concerns about any of the proposals, please describe them. Otherwise, I don't find these generic "it's really, really difficult" statements all that helpful in making progress. Henning On Jul 14, 2007, at 6:52 PM, David Barrett wrote: > I agree with Bruce: a top priority for P2PSIP 1.0 is to be highly > compatible between multple vendor's implementations. As such, > choosing a single DHT seems like a sensible risk reduction -- even > if later we decide to change it. > > And I agree with Henning -- I'm sure there are ways to create an > uber-DHT that is algorithm independent. But it's harder and > riskier, and I think that problem needn't be solved today. I agree > it's not magic, but there is a surprising amount of voodoo to get > any of this working outside the lab. > > Overall, I still think this quest for eternal agility and fear of > commitment is keeping us from moving forward at all. I'd happily > give up some short-term flexibility if it meant improving the odds > of getting *anything* working. Problems are so much easier to > solve when you actually have them, versus when we merely theorize > them. > > -david > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 19:41:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9rEp-00072i-Ps; Sat, 14 Jul 2007 19:41:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9rEo-00072d-OC for p2psip@ietf.org; Sat, 14 Jul 2007 19:41:22 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9rEi-000882-2c for p2psip@ietf.org; Sat, 14 Jul 2007 19:41:22 -0400 Received: from lappy ([68.26.224.1]) by quinthar.com for ; Sat, 14 Jul 2007 16:41:13 -0700 From: "David Barrett" To: "'Henning Schulzrinne'" Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sat, 14 Jul 2007 16:41:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfGaszo0HSaR5JKSKCUvP5wM/VD5AAAW1mA In-Reply-To: <2EFFB547-4032-407E-BC20-F593BA25F073@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: I want running code on a large scale, in the real world, outside the lab. It doesn't matter what algorithm it uses, how the packets are laid out, etc. I just want something that solves a real problem for some relevant set of users, and then I want to iterate. Thus I have "concrete concerns" with any proposal that deviates from this goal. Adding more flexibility to a nonexistent system isn't useful. Paving the way for experimental algorithms that might exist on paper or on a few buddies' computers isn't useful. Planning for esoteric networking environments with exceedingly difficult constraints isn't useful. The only thing that's useful is running code at a meaningful scale, instrumented in such a fashion to learn if it works and what needs fixing. I understand that it might not be exciting to hear my proposals. "Blah blah, reality, blah blah, actual users." It's always more fun to add more features and more flexibility, but it's not useful (for any meaningful definition of "useful" that is somehow tied to actual users communicating). I respect we all come to this forum with our own experiences. And I'll grant that others might have experienced success with alternate strategies. But in my experience developing commercial P2P applications deployed on hundreds of thousands of active computers around the world, until you have something that actually does what you want to do -- even if it doesn't do it great -- any distraction from this goal isn't useful. So again, I say we pick the best DHT available today, build around that to the exclusion of all others, and actually ship a product that people can use. Then, once people are using it, we'll know what works and what doesn't, and then we can focus our attention accordingly. I understand and respect there are other proposals, but this is mine. -david > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, July 14, 2007 4:00 PM > To: David Barrett > Cc: P2PSIP WG > Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > > I don't know what beyond actual proposals and running code you'd > like. Fear-mongering and mentioning demons in the closet isn't going > to help us. If you have concrete concerns about any of the proposals, > please describe them. Otherwise, I don't find these generic "it's > really, really difficult" statements all that helpful in making > progress. > > Henning > > On Jul 14, 2007, at 6:52 PM, David Barrett wrote: > > > I agree with Bruce: a top priority for P2PSIP 1.0 is to be highly > > compatible between multple vendor's implementations. As such, > > choosing a single DHT seems like a sensible risk reduction -- even > > if later we decide to change it. > > > > And I agree with Henning -- I'm sure there are ways to create an > > uber-DHT that is algorithm independent. But it's harder and > > riskier, and I think that problem needn't be solved today. I agree > > it's not magic, but there is a surprising amount of voodoo to get > > any of this working outside the lab. > > > > Overall, I still think this quest for eternal agility and fear of > > commitment is keeping us from moving forward at all. I'd happily > > give up some short-term flexibility if it meant improving the odds > > of getting *anything* working. Problems are so much easier to > > solve when you actually have them, versus when we merely theorize > > them. > > > > -david > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Jul 14 23:01:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9uMQ-0000wk-AQ; Sat, 14 Jul 2007 23:01:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9uMO-0000rb-DN for p2psip@ietf.org; Sat, 14 Jul 2007 23:01:24 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9uMJ-0003Fn-K6 for p2psip@ietf.org; Sat, 14 Jul 2007 23:01:24 -0400 Received: by nf-out-0910.google.com with SMTP id c10so60736nfd for ; Sat, 14 Jul 2007 20:01:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=cM17TWlVCnetkyFtxzg/1ffcqm26dVmSC8gEcFJLZTgpPgEqYiFw9/KLTie3OL5KvVXbyqxDj5qsyuKcFagUnYasD59BC8qvoXI3gnASmLVho23eWIsVWX3FOA/VNk2vvsb09iygvV53Qdcaz4uHZlXEsbFr17Ga139lRhQao6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=h934x2/e6T67Gif0PnOeJuvK8sR79oAcsON4olmIFAg287QB9bKbqhDH8N4huzJloCMwAFYTz8zmojRdRrdDBtmhNHbD2hBAUuXR4u95OG2vb9XA65ZKNmgilHNkH1+3Hl5rBNHB+4obHVPwH01xshuICxUTPK+VgjhK9KhFoPk= Received: by 10.78.185.15 with SMTP id i15mr839049huf.1184468478726; Sat, 14 Jul 2007 20:01:18 -0700 (PDT) Received: by 10.78.53.20 with HTTP; Sat, 14 Jul 2007 20:01:18 -0700 (PDT) Message-ID: <7b683f3f0707142001o8df5ecdhf4bd3c9e07b995d7@mail.gmail.com> Date: Sat, 14 Jul 2007 23:01:18 -0400 From: "Eunsoo Shim" To: "Jonathan Rosenberg" Subject: Re: [P2PSIP] HBH vs. E2E SIP in P2PSIP In-Reply-To: <4697F367.6000809@cisco.com> MIME-Version: 1.0 References: <4697F367.6000809@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1522525304==" Errors-To: p2psip-bounces@ietf.org --===============1522525304== Content-Type: multipart/alternative; boundary="----=_Part_42256_5871761.1184468478679" ------=_Part_42256_5871761.1184468478679 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Jonathan's suggestion. That's what I have been proposing for almost two years. And that's why a client protocol different from SIP brings a clean separation between the protocols for the overlay and SIP. Thanks. Eunsoo On 7/13/07, Jonathan Rosenberg wrote: > > draft-bryan-p2psip-requirements-00 talks about how SIP relates to the > P2P protocol. It says: > > > The above discussion suggests at least two paradigms for SIP > > operation in a p2p setting: the end-to-end paradigm where a SIP user > > agent uses the p2p location service to discover the location of > > callee, and then send the SIP message directly to the callee, or a > > hop-by-hop paradigm where each peer forwards the SIP request to a > > peer which is more 'closer' to the callee. The former can be thought > > of as a RPC whereas the later can be thought of as a local procedure > > call to determine the next hop. > > I'd like to propose that, any model which views the peers in the p2p > network as proxies (things that add Via headers, follow proxy rules as > defined in RFC 3261, and so on), is basically fatally flawed from a > security perspective. > > SIP was not designed on a model of untrusted proxies. I know this keeps > coming up time and time again in the core SIP mailing list. The problem > is, the design of SIP quite purposefully gives SIP proxies pretty wide > latitude in manipulating message contents and doing things. We have some > limited protection, if you believe in things like S/MIME, but by its > very definition, SIP allows proxies to do lots of stuff. They can send > requests to different places, they can fork, they can send responses, > they can add and remove headers, they can change the destination of a > request. All of it is legal and makes sense in a proxy-routed model. > > However, in P2PSIP, if you think of the peers as proxies, you enter a > use case where you trust none of the proxies, and in fact every call has > a whole lot of them on the signaling path (O(logN)). I guarantee you > that these untrusted proxies will launch attacks that are hard to fix > without basically completely changing the way the SIP protocol works. > > So, don't do it. > > The way you limit what peers can do is by using a protocol to > communicate with peers whose very design limits what can be done. A > protocol built from the ground up to do nothing but give an intermediary > the ability to move a message around based on DHT topology. You wouldn't > need to worry about things modifying media destinations since there is > no SDP. You needn't worry about spoofing caller ID since there is no > caller ID in the protocol. All you do is use this protocol to allow you > to set up a secure, e2e, TLS connection between you and the UA you want > to talk to, and then run SIP over that. > > The great benefit is that SIP already allows UA to UA communications. It > always has. P2PSIP then slides in as a pure, clean replacement for > RFC3263, allowing you to identify the target UA that you want to connect > to, and provide a means for connecting to them through firewalls and NATs. > > Thus I'd like to suggest that the E2E SIP model described in the > requirements document be the one we are shooting for. > > Thanks, > Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_42256_5871761.1184468478679 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Jonathan's suggestion.
That's what I have been proposing for almost two years.
And that's why a client protocol different from SIP brings a clean separation between the protocols for the overlay and SIP.

Thanks.

Eunsoo

On 7/13/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
draft-bryan-p2psip-requirements-00 talks about how SIP relates to the
P2P protocol. It says:

> The above discussion suggests at least two paradigms for SIP
>    operation in a p2p setting: the end-to-end paradigm where a SIP user
>    agent uses the p2p location service to discover the location of
>    callee, and then send the SIP message directly to the callee, or a
>    hop-by-hop paradigm where each peer forwards the SIP request to a
>    peer which is more 'closer' to the callee. The former can be thought
>    of as a RPC whereas the later can be thought of as a local procedure
>    call to determine the next hop.

I'd like to propose that, any model which views the peers in the p2p
network as proxies (things that add Via headers, follow proxy rules as
defined in RFC 3261, and so on), is basically fatally flawed from a
security perspective.

SIP was not designed on a model of untrusted proxies. I know this keeps
coming up time and time again in the core SIP mailing list. The problem
is, the design of SIP quite purposefully gives SIP proxies pretty wide
latitude in manipulating message contents and doing things. We have some
limited protection, if you believe in things like S/MIME, but by its
very definition, SIP allows proxies to do lots of stuff. They can send
requests to different places, they can fork, they can send responses,
they can add and remove headers, they can change the destination of a
request. All of it is legal and makes sense in a proxy-routed model.

However, in P2PSIP, if you think of the peers as proxies, you enter a
use case where you trust none of the proxies, and in fact every call has
a whole lot of them on the signaling path (O(logN)). I guarantee you
that these untrusted proxies will launch attacks that are hard to fix
without basically completely changing the way the SIP protocol works.

So, don't do it.

The way you limit what peers can do is by using a protocol to
communicate with peers whose very design limits what can be done. A
protocol built from the ground up to do nothing but give an intermediary
the ability to move a message around based on DHT topology. You wouldn't
need to worry about things modifying media destinations since there is
no SDP. You needn't worry about spoofing caller ID since there is no
caller ID in the protocol. All you do is use this protocol to allow you
to set up a secure, e2e, TLS connection between you and the UA you want
to talk to, and then run SIP over that.

The great benefit is that SIP already allows UA to UA communications. It
always has. P2PSIP then slides in as a pure, clean replacement for
RFC3263, allowing you to identify the target UA that you want to connect
to, and provide a means for connecting to them through firewalls and NATs.

Thus I'd like to suggest that the E2E SIP model described in the
requirements document be the one we are shooting for.

Thanks,
Jonathan R.


--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_42256_5871761.1184468478679-- --===============1522525304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1522525304==-- From p2psip-bounces@ietf.org Sat Jul 14 23:41:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9uzc-0006bI-GW; Sat, 14 Jul 2007 23:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9uzb-0006b4-50 for p2psip@ietf.org; Sat, 14 Jul 2007 23:41:55 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9uzX-0003px-Kc for p2psip@ietf.org; Sat, 14 Jul 2007 23:41:55 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com id BT-MMP-1992742; Sat, 14 Jul 2007 23:41:45 -0400 Received: from 0015-ITS-EXBH01.us.saic.com ([10.43.229.18]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2007071423414513661 ; Sat, 14 Jul 2007 23:41:45 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-ITS-EXBH01.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 Jul 2007 23:41:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sat, 14 Jul 2007 23:41:45 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1D19B@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfGaszo0HSaR5JKSKCUvP5wM/VD5AAAW1mAAAjXuTA= References: From: "Roy, Radhika R." To: "David Barrett" , "Henning Schulzrinne" X-OriginalArrivalTime: 15 Jul 2007 03:41:45.0666 (UTC) FILETIME=[1108C220:01C7C692] X-Spam-Score: 0.5 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0526828464==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0526828464== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C692.10C6E936" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C692.10C6E936 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I guess that David has made some excellent technical points: = Implementation in Large-scale commercial networks vs. implementations in = small lab networks. =20 For example, SIP is yet to provide any meaningful inter-operable = standard-based large-scale commercial implementations for multipoint, = multimedia conferencing. Had it been the case that we had been in a = hurry to standardize SIP based on lab's point-to-point communications = only (as multi-point multimedia conferencing using SIP had been = difficult to implement in labs environments)? =20 We like to see more solid technical arguments against David's real-world = large-scale commericial implementation experiences for using of one = standardized DHT to start with. =20 Is it not that we want the economies-of-large-scale using = "standarization?" =20 Best regards, Radhika ________________________________ From: p2psip-bounces@ietf.org on behalf of David Barrett Sent: Sat 7/14/2007 7:41 PM To: 'Henning Schulzrinne' Cc: 'P2PSIP WG' Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion I want running code on a large scale, in the real world, outside the = lab. It doesn't matter what algorithm it uses, how the packets are laid out, = etc. I just want something that solves a real problem for some relevant set = of users, and then I want to iterate. Thus I have "concrete concerns" with any proposal that deviates from = this goal. Adding more flexibility to a nonexistent system isn't useful. = Paving the way for experimental algorithms that might exist on paper or on a = few buddies' computers isn't useful. Planning for esoteric networking environments with exceedingly difficult constraints isn't useful. The = only thing that's useful is running code at a meaningful scale, instrumented = in such a fashion to learn if it works and what needs fixing. I understand that it might not be exciting to hear my proposals. "Blah blah, reality, blah blah, actual users." It's always more fun to add = more features and more flexibility, but it's not useful (for any meaningful definition of "useful" that is somehow tied to actual users = communicating). I respect we all come to this forum with our own experiences. And I'll grant that others might have experienced success with alternate = strategies. But in my experience developing commercial P2P applications deployed on hundreds of thousands of active computers around the world, until you = have something that actually does what you want to do -- even if it doesn't = do it great -- any distraction from this goal isn't useful. So again, I say we pick the best DHT available today, build around that = to the exclusion of all others, and actually ship a product that people can use. Then, once people are using it, we'll know what works and what doesn't, and then we can focus our attention accordingly. I understand and respect there are other proposals, but this is mine. -david > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, July 14, 2007 4:00 PM > To: David Barrett > Cc: P2PSIP WG > Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting = opinion > > I don't know what beyond actual proposals and running code you'd > like. Fear-mongering and mentioning demons in the closet isn't going > to help us. If you have concrete concerns about any of the proposals, > please describe them. Otherwise, I don't find these generic "it's > really, really difficult" statements all that helpful in making > progress. > > Henning > > On Jul 14, 2007, at 6:52 PM, David Barrett wrote: > > > I agree with Bruce: a top priority for P2PSIP 1.0 is to be highly > > compatible between multple vendor's implementations. As such, > > choosing a single DHT seems like a sensible risk reduction -- even > > if later we decide to change it. > > > > And I agree with Henning -- I'm sure there are ways to create an > > uber-DHT that is algorithm independent. But it's harder and > > riskier, and I think that problem needn't be solved today. I agree > > it's not magic, but there is a surprising amount of voodoo to get > > any of this working outside the lab. > > > > Overall, I still think this quest for eternal agility and fear of > > commitment is keeping us from moving forward at all. I'd happily > > give up some short-term flexibility if it meant improving the odds > > of getting *anything* working. Problems are so much easier to > > solve when you actually have them, versus when we merely theorize > > them. > > > > -david > > ------_=_NextPart_001_01C7C692.10C6E936 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [P2PSIP] Mandatory-to-implement DHTs - = a dissenting opinion=0A= =0A= =0A= =0A=
=0A=
I guess that = David has made some excellent technical points: Implementation in = Large-scale commercial networks vs. implementations in small lab = networks.
=0A=
 
=0A=
For example, SIP is yet to = provide any meaningful inter-operable standard-based large-scale = commercial implementations for multipoint, multimedia conferencing. Had = it been the case that we had been in a hurry to standardize SIP based on = lab's point-to-point communications only (as multi-point multimedia = conferencing using SIP had been difficult to implement in labs = environments)?
=0A=
 
=0A=
We like to see more solid = technical arguments against David's real-world large-scale commericial = implementation experiences for using of one standardized DHT to start = with.
=0A=
 
=0A=
Is it not that we want the = economies-of-large-scale using "standarization?"
=0A=
 
=0A=
Best regards,
=0A=
Radhika
=0A=

=0A=
=0A=
=0A=
=0A=
From: = p2psip-bounces@ietf.org on behalf of David Barrett
Sent: Sat = 7/14/2007 7:41 PM
To: 'Henning Schulzrinne'
Cc: = 'P2PSIP WG'
Subject: RE: [P2PSIP] Mandatory-to-implement DHTs = - a dissenting opinion

=0A=
=0A=

I want running code on a large scale, in the real = world, outside the lab.
It doesn't matter what algorithm it uses, how = the packets are laid out, etc.
I just want something that solves a = real problem for some relevant set of
users, and then I want to = iterate.

Thus I have "concrete concerns" with any proposal that = deviates from this
goal.  Adding more flexibility to a = nonexistent system isn't useful.  Paving
the way for = experimental algorithms that might exist on paper or on a = few
buddies' computers isn't useful.  Planning for esoteric = networking
environments with exceedingly difficult constraints isn't = useful.  The only
thing that's useful is running code at a = meaningful scale, instrumented in
such a fashion to learn if it works = and what needs fixing.

I understand that it might not be exciting = to hear my proposals.  "Blah
blah, reality, blah blah, actual = users."  It's always more fun to add more
features and more = flexibility, but it's not useful (for any meaningful
definition of = "useful" that is somehow tied to actual users communicating).

I = respect we all come to this forum with our own experiences.  And = I'll
grant that others might have experienced success with alternate = strategies.
But in my experience developing commercial P2P = applications deployed on
hundreds of thousands of active computers = around the world, until you have
something that actually does what = you want to do -- even if it doesn't do it
great -- any distraction = from this goal isn't useful.


So again, I say we pick the best = DHT available today, build around that to
the exclusion of all = others, and actually ship a product that people can
use.  Then, = once people are using it, we'll know what works and what
doesn't, and = then we can focus our attention accordingly.

I understand and = respect there are other proposals, but this is = mine.

-david

> -----Original Message-----
> From: = Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
&g= t; Sent: Saturday, July 14, 2007 4:00 PM
> To: David = Barrett
> Cc: P2PSIP WG
> Subject: Re: [P2PSIP] = Mandatory-to-implement DHTs - a dissenting opinion
>
> I = don't know what beyond actual proposals and running code you'd
> = like. Fear-mongering and mentioning demons in the closet isn't = going
> to help us. If you have concrete concerns about any of the = proposals,
> please describe them. Otherwise, I don't find these = generic "it's
> really, really difficult" statements all that = helpful in making
> progress.
>
> = Henning
>
> On Jul 14, 2007, at 6:52 PM, David Barrett = wrote:
>
> > I agree with Bruce: a top priority for = P2PSIP 1.0 is to be highly
> > compatible between multple = vendor's implementations.  As such,
> > choosing a single = DHT seems like a sensible risk reduction -- even
> > if later = we decide to change it.
> >
> > And I agree with = Henning -- I'm sure there are ways to create an
> > uber-DHT = that is algorithm independent.  But it's harder and
> > = riskier, and I think that problem needn't be solved today.  I = agree
> > it's not magic, but there is a surprising amount of = voodoo to get
> > any of this working outside the lab.
> = >
> > Overall, I still think this quest for eternal agility = and fear of
> > commitment is keeping us from moving forward at = all.  I'd happily
> > give up some short-term flexibility = if it meant improving the odds
> > of getting *anything* = working.  Problems are so much easier to
> > solve when = you actually have them, versus when we merely theorize
> > = them.
> >
> > -david
> = >


------_=_NextPart_001_01C7C692.10C6E936-- --===============0526828464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0526828464==-- From p2psip-bounces@ietf.org Sat Jul 14 23:43:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9v0x-0000cl-Ly; Sat, 14 Jul 2007 23:43:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9v0w-0000X0-Bp for p2psip@ietf.org; Sat, 14 Jul 2007 23:43:18 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9v0s-0003rr-H5 for p2psip@ietf.org; Sat, 14 Jul 2007 23:43:18 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2256490uge for ; Sat, 14 Jul 2007 20:43:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=DqBeIZrNGf5S184kuDMAflRQk061j0GpoHx0DKlt/wAfzdWm5ZWnW9E0tmv2yhiMy0BeProX0F+sfpd0AeMuSJInPfSz6JIl7g/DoQIlu4C8cSH7TVuyUP7VbS5EIO2syf4jjGVxhOaM1eHSrWYKvvDgwx4zTDbDo3nap6jyDC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=pvG7LOxSat2QBMRGhkz6A8Sxjju4oLmfrGfUrqFj8sSwRV+O+Qn5xYqdFdsaaEwnklLqmysrtYd4Q/ua/ddfL2pTJeveiA41XD+0P6L6z+KOqzNRV5Q0LbLOkbZ21OAq59X08l7ShxU/2IIQfwJwQLnPZ6mL0uL0w5S/Hz21QuY= Received: by 10.78.156.6 with SMTP id d6mr847001hue.1184470993527; Sat, 14 Jul 2007 20:43:13 -0700 (PDT) Received: by 10.78.53.20 with HTTP; Sat, 14 Jul 2007 20:43:13 -0700 (PDT) Message-ID: <7b683f3f0707142043n38e4f51fg4126ecd02e160da3@mail.gmail.com> Date: Sat, 14 Jul 2007 23:43:13 -0400 From: "Eunsoo Shim" To: "Jonathan Rosenberg" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <4697F02B.4030506@cisco.com> MIME-Version: 1.0 References: <4697F02B.4030506@cisco.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1056892569==" Errors-To: p2psip-bounces@ietf.org --===============1056892569== Content-Type: multipart/alternative; boundary="----=_Part_42456_24799276.1184470993432" ------=_Part_42456_24799276.1184470993432 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree that it should be the market that drives the choice of the DHT algorithm eventually. On the other hand, currently no specific DHT algorithm has been established as a widely accepted one for P2PSIP overlays. So I am wondering what DHT algorithms a manufacturer would implement if they implement P2PSIP nodes. And if manufacturers choose all kinds of variations of various DHT algorithms, it will give significant headache and limited choices of devices to even large service providers, not to mention smaller ones and enterprises who like to use multi-vendor solutions. The SIP community did not have to recommend or choose any voice codec. Other organizations developed various voice codec standards and there were widely accepted voice codecs such as G.711. So it was not much of an issue what voice codec should be implemented or selected for SIP devices. The situation with DHT is different in my understanding. There are too many options and one can easily try to tweak a known DHT algorithm. I am not aware of any standardization body or industry organization that is working to define any standard DHT. I believe at least some kind of recommendation on DHT algorithms, if not a mandatory implementation requirement, would help a lot. If the P2PSIP community does not produce it for P2PSIP overlays, who would do it? Thanks. Eunsoo On 7/13/07, Jonathan Rosenberg wrote: > > I've read draft-bryan-p2psip-requirements-00, and have a bunch of > comments. But a few items came to mind I wanted to discuss which merit > their own threads. > > First, is the concept of mandatory-to-implement DHT. The requirements > document talks a lot about requirements around selecting a mandatory to > implement DHT. Its something we've discussed in the meeting and on the > list. I think everyone agrees also that we need to allow for multiple > DHT and all of the recent protocol proposals support it. > > However, I do not think we should have a mandatory-to-implement DHT at > all. > > There are several reasons for this. First of all, its important to > understand the reason why IETF has mandatory-to-implement functionality > in its protocols. The one and only reason is that it ensures > interoperability. It ensures that, independent of the optional features > selected by a pair of entities, when you connect them together, they can > still interoperate. > > This property will NOT be retained with a mandatory-to-implement DHT. > Once the ring forms, the DHT protocol is chosen and locked. Thus, if any > DHT besides the 'mandatory-to-implement' one has been selected for the > DHT, a new node not supporting that DHT will not be able to join the > ring even if it implements the mandatory-to-implement one. Thus, the > entire purpose of mandatory-to-implement is eliminated - we don't > actually get interoperability. > > Indeed, to get this kind of interoperability, we'd need to pick one and > only one DHT that ever gets used with p2psip. I think that is a mistake. > This is an evolving area and is one where agility is important. > > Instead, what I think happens is that a 'provider' that deploys a p2p > network will need to pick a DHT, and make sure that the clients all > support that DHT. This is something the market should drive, not us. > > Secondly, I think its important to realize that we are picking up work > in an area that is well trod. There are lots and lots of papers and > protocols and software written around P2P networks. I don't think anyone > looks at an IETF protocol and says, "IETF are the guys who know about > DHTs, lets go with their recommendation". What IETF is really good at, > and what this group has expertise in, is SIP, and on designing good, > scalable protocols in general - things that have security, > extensibility, good performance, and so on. So I think the greatest > value we can bring to the table is to create a protocol that allows > others to take DHTs and easily turn them into a real wire protocol that > you can actually deploy, on the Internet, to support SIP and ideally > other things too. Interestingly, this is exactly what all of the > protocol proposals do. That kind of focus goes hand-in-hand with saying, > let someone else figure out which DHT to use. I think its perfectly > reasonable for us, and for others, to write documents on how to use our > protocol with various DHTs. But I think we should be out of the business > of picking one or recommending one (or ones) to be used. > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_42456_24799276.1184470993432 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree that it should be the market that drives the choice of the DHT algorithm eventually.

On the other hand, currently no specific DHT algorithm has been established as a widely accepted one for P2PSIP overlays. So I am wondering what DHT algorithms a manufacturer would implement if they implement P2PSIP nodes. And if manufacturers choose all kinds of variations of various DHT algorithms, it will give significant headache and limited choices of devices to even large service providers, not to mention smaller ones and enterprises who like to use multi-vendor solutions.

The SIP community did not have to recommend or choose any voice codec. Other organizations developed various voice codec standards and there were widely accepted voice codecs such as G.711. So it was not much of an issue what voice codec should be implemented or selected for SIP devices. The situation with DHT is different in my understanding. There are too many options and one can easily try to tweak a known DHT algorithm.

I am not aware of any standardization body or industry organization that is working to define any standard DHT.

I believe at least some kind of recommendation on DHT algorithms, if not a mandatory implementation requirement, would help a lot.

If the P2PSIP community does not produce it for P2PSIP overlays, who would do it?

Thanks.

Eunsoo



On 7/13/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
I've read draft-bryan-p2psip-requirements-00, and have a bunch of
comments. But a few items came to mind I wanted to discuss which merit
their own threads.

First, is the concept of mandatory-to-implement DHT. The requirements
document talks a lot about requirements around selecting a mandatory to
implement DHT. Its something we've discussed in the meeting and on the
list. I think everyone agrees also that we need to allow for multiple
DHT and all of the recent protocol proposals support it.

However, I do not think we should have a mandatory-to-implement DHT at all.

There are several reasons for this. First of all, its important to
understand the reason why IETF has mandatory-to-implement functionality
in its protocols. The one and only reason is that it ensures
interoperability. It ensures that, independent of the optional features
selected by a pair of entities, when you connect them together, they can
still interoperate.

This property will NOT be retained with a mandatory-to-implement DHT.
Once the ring forms, the DHT protocol is chosen and locked. Thus, if any
  DHT besides the 'mandatory-to-implement' one has been selected for the
DHT, a new node not supporting that DHT will not be able to join the
ring even if it implements the mandatory-to-implement one. Thus, the
entire purpose of mandatory-to-implement is eliminated - we don't
actually get interoperability.

Indeed, to get this kind of interoperability, we'd need to pick one and
only one DHT that ever gets used with p2psip. I think that is a mistake.
This is an evolving area and is one where agility is important.

Instead, what I think happens is that a 'provider' that deploys a p2p
network will need to pick a DHT, and make sure that the clients all
support that DHT. This is something the market should drive, not us.

Secondly, I think its important to realize that we are picking up work
in an area that is well trod. There are lots and lots of papers and
protocols and software written around P2P networks. I don't think anyone
looks at an IETF protocol and says, "IETF are the guys who know about
DHTs, lets go with their recommendation". What IETF is really good at,
and what this group has expertise in, is SIP, and on designing good,
scalable protocols in general - things that have security,
extensibility, good performance, and so on. So I think the greatest
value we can bring to the table is to create a protocol that allows
others to take DHTs and easily turn them into a real wire protocol that
you can actually deploy, on the Internet, to support SIP and ideally
other things too. Interestingly, this is exactly what all of the
protocol proposals do. That kind of focus goes hand-in-hand with saying,
let someone else figure out which DHT to use. I think its perfectly
reasonable for us, and for others, to write documents on how to use our
protocol with various DHTs. But I think we should be out of the business
of picking one or recommending one (or ones) to be used.

-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_42456_24799276.1184470993432-- --===============1056892569== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1056892569==-- From p2psip-bounces@ietf.org Sat Jul 14 23:54:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9vC9-000705-Gs; Sat, 14 Jul 2007 23:54:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9vC8-0006xZ-A1 for p2psip@ietf.org; Sat, 14 Jul 2007 23:54:52 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9vC4-00041v-7E for p2psip@ietf.org; Sat, 14 Jul 2007 23:54:52 -0400 Received: by nf-out-0910.google.com with SMTP id c10so61306nfd for ; Sat, 14 Jul 2007 20:54:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=mqfqNLrTntBhWCcpzflEiUWvTSkkwnhlountlj+wI+P26gyA8oOeLAlWYn4k6iEbUTqL8Sm64CPzBrEKE0sclHeXVidbKjUMWL0BEdLXDrbEnkJhXgFFOYgCkiXQPBEwd79Z5LNObRlF31I6VsX9l+mUOxVQF7Np7tWvSGfPAjo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=UXCfJ2wQlWtOeeG0FhFbYdaDGRR4zcZXNXQv1woxTmolIM9JbhWzhAepDwSGBzarB0cwep6mXAUtVBHu/X842OT8a57XAMDhaAtjLuge53vLZGqDP61fYz1s1xlwh6sHvTs4oOre/wZ4lyJiV60n55WEshMNLfHwUn6yKVQwQjc= Received: by 10.78.165.16 with SMTP id n16mr847972hue.1184471686836; Sat, 14 Jul 2007 20:54:46 -0700 (PDT) Received: by 10.78.53.20 with HTTP; Sat, 14 Jul 2007 20:54:46 -0700 (PDT) Message-ID: <7b683f3f0707142054y66138c82hf5a39c30f9dd5fa9@mail.gmail.com> Date: Sat, 14 Jul 2007 23:54:46 -0400 From: "Eunsoo Shim" To: "Henning Schulzrinne" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> MIME-Version: 1.0 References: <4697F02B.4030506@cisco.com> <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0614086879==" Errors-To: p2psip-bounces@ietf.org --===============0614086879== Content-Type: multipart/alternative; boundary="----=_Part_42492_9544413.1184471686750" ------=_Part_42492_9544413.1184471686750 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/13/07, Henning Schulzrinne wrote: > > Lack of a common DHT does not necessarily interfere with > interoperability. The client protocol, at least in our thinking, is > independent of the DHT, so a node that doesn't implement the DHT > algorithm of the overlay it wants to talk to can still reach others, > it just can't be a full peer. Since typically only a small fraction > of nodes need to act as peers at any given time, this may not be much > of a problem. I am not sure whether this is a desirable approach. Having a commond DHT and thus being able to use more devices as full peers seems to be more desirable to me. You could design a system that essentially replicated the key-data > mappings across two DHT algorithm, a baseline universal one and the > "fancy"/"better" one less universally spoken. I am not sure whether it is always the case that, given two DHT algorithms, one can be considered as a baseline universal one and the other a fancier/better one. This incurs > significantly more overhead and probably yields some strange partial > reachability cases particularly as new nodes are added, but it could > be done. I am not convinced why we would want to pursue this complex approach instead of choosing/recommending one common DHT. We can change the common DHT or add one more later. Thanks. Eunsoo Henning > > On Jul 13, 2007, at 6:16 PM, David A. Bryan wrote: > > > I think this likely to be a source of serious discussion. At least for > > now (maybe Jonathan can convince me), I'm inclined to disagree. > > > > I think the problem is that if we don't specify a mandatory to > > implement, there may be many devices from different vendors that don't > > even implement a common DHT. Each will pick and choose which DHTs to > > implement, and in the end, there won't be a common DHT all can even > > run if they want to. > > > > I think looking at it from the perspective of "once the DHT chosen it > > is locked" is the wrong way to look at it. The idea isn't that any > > device can join any already established overlay, but that if I deploy > > a system of heterogeneous devices, there is at least one that I can > > select when I start and know that all "P2PSIP endpoints" (assuming > > that term means anything) will at least support that and I can form an > > overlay with them. Maybe not the ideal DHT for my overlay, but > > something I know all devices can support, and if I run it in that > > mode, it works. > > > > Personally, I think if we don't do that, many DHTs will be > > standardized for different environments (good) but each vendor will > > implement a (potentially disjoint) subset, and there may be no way to > > use two endpoints from different vendors together at all. > > > > I agree that if a user selects a non-mandatory DHT, they may risk not > > being fully interoperable, but I think if we don't pick one at all, we > > almost guarantee things won't be interoperable. > > > > And I (and I think nearly everyone) is 100% in the camp of "we should > > allow pluggable DHTs". I think it is safe to say that one is a done > > deal, but I would personally have thought a mandatory was as well. In > > any case, my vote is definitely for pluggable DHTs. > > > > David > > > > On 7/13/07, Jonathan Rosenberg wrote: > >> I've read draft-bryan-p2psip-requirements-00, and have a bunch of > >> comments. But a few items came to mind I wanted to discuss which > >> merit > >> their own threads. > >> > >> First, is the concept of mandatory-to-implement DHT. The requirements > >> document talks a lot about requirements around selecting a > >> mandatory to > >> implement DHT. Its something we've discussed in the meeting and on > >> the > >> list. I think everyone agrees also that we need to allow for multiple > >> DHT and all of the recent protocol proposals support it. > >> > >> However, I do not think we should have a mandatory-to-implement > >> DHT at all. > >> > >> There are several reasons for this. First of all, its important to > >> understand the reason why IETF has mandatory-to-implement > >> functionality > >> in its protocols. The one and only reason is that it ensures > >> interoperability. It ensures that, independent of the optional > >> features > >> selected by a pair of entities, when you connect them together, > >> they can > >> still interoperate. > >> > >> This property will NOT be retained with a mandatory-to-implement DHT. > >> Once the ring forms, the DHT protocol is chosen and locked. Thus, > >> if any > >> DHT besides the 'mandatory-to-implement' one has been selected > >> for the > >> DHT, a new node not supporting that DHT will not be able to join the > >> ring even if it implements the mandatory-to-implement one. Thus, the > >> entire purpose of mandatory-to-implement is eliminated - we don't > >> actually get interoperability. > >> > >> Indeed, to get this kind of interoperability, we'd need to pick > >> one and > >> only one DHT that ever gets used with p2psip. I think that is a > >> mistake. > >> This is an evolving area and is one where agility is important. > >> > >> Instead, what I think happens is that a 'provider' that deploys a p2p > >> network will need to pick a DHT, and make sure that the clients all > >> support that DHT. This is something the market should drive, not us. > >> > >> Secondly, I think its important to realize that we are picking up > >> work > >> in an area that is well trod. There are lots and lots of papers and > >> protocols and software written around P2P networks. I don't think > >> anyone > >> looks at an IETF protocol and says, "IETF are the guys who know about > >> DHTs, lets go with their recommendation". What IETF is really good > >> at, > >> and what this group has expertise in, is SIP, and on designing good, > >> scalable protocols in general - things that have security, > >> extensibility, good performance, and so on. So I think the greatest > >> value we can bring to the table is to create a protocol that allows > >> others to take DHTs and easily turn them into a real wire protocol > >> that > >> you can actually deploy, on the Internet, to support SIP and ideally > >> other things too. Interestingly, this is exactly what all of the > >> protocol proposals do. That kind of focus goes hand-in-hand with > >> saying, > >> let someone else figure out which DHT to use. I think its perfectly > >> reasonable for us, and for others, to write documents on how to > >> use our > >> protocol with various DHTs. But I think we should be out of the > >> business > >> of picking one or recommending one (or ones) to be used. > >> > >> -Jonathan R. > >> -- > >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > >> Cisco Fellow Parsippany, NJ > >> 07054-2711 > >> Cisco Systems > >> jdrosen@cisco.com FAX: (973) 952-5050 > >> http://www.jdrosen.net PHONE: (973) 952-5000 > >> http://www.cisco.com > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > > > > > > -- > > David A. Bryan > > dbryan@SIPeerior.com > > +1.757.565.0101 x101 > > +1.757.565.0088 (fax) > > www.SIPeerior.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_42492_9544413.1184471686750 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 7/13/07, Henning Schulzrinne <hgs@cs.columbia.edu> wrote:
Lack of a common DHT does not necessarily interfere with
interoperability. The client protocol, at least in our thinking, is
independent of the DHT, so a node that doesn't implement the DHT
algorithm of the overlay it wants to talk to can still reach others,
it just can't be a full peer. Since typically only a small fraction
of nodes need to act as peers at any given time, this may not be much
of a problem.

I am not sure whether this is a desirable approach.
Having a commond DHT and thus being able to use more devices as full peers seems to be more desirable to me.

You could design a system that essentially replicated the key-data
mappings across two DHT algorithm, a baseline universal one and the
"fancy"/"better" one less universally spoken.

I am not sure whether it is always the case that, given two DHT algorithms, one can be considered as a baseline universal one and the other a fancier/better one.

This incurs
significantly more overhead and probably yields some strange partial
reachability cases particularly as new nodes are added, but it could
be done.

I am not convinced why we would want to pursue this complex approach instead of choosing/recommending one common DHT.
We can change the common DHT or add one more later.

Thanks.

Eunsoo
 

Henning

On Jul 13, 2007, at 6:16 PM, David A. Bryan wrote:

> I think this likely to be a source of serious discussion. At least for
> now (maybe Jonathan can convince me), I'm inclined to disagree.
>
> I think the problem is that if we don't specify a mandatory to
> implement, there may be many devices from different vendors that don't
> even implement a common DHT. Each will pick and choose which DHTs to
> implement, and in the end, there won't be a common DHT all can even
> run if they want to.
>
> I think looking at it from the perspective of "once the DHT chosen it
> is locked" is the wrong way to look at it. The idea isn't that any
> device can join any already established overlay, but that if I deploy
> a system of heterogeneous devices, there is at least one that I can
> select when I start and know that all "P2PSIP endpoints" (assuming
> that term means anything) will at least support that and I can form an
> overlay with them. Maybe not the ideal DHT for my overlay, but
> something I know all devices can support, and if I run it in that
> mode, it works.
>
> Personally, I think if we don't do that, many DHTs will be
> standardized for different environments (good) but each vendor will
> implement a (potentially disjoint) subset, and there may be no way to
> use two endpoints from different vendors together at all.
>
> I agree that if a user selects a non-mandatory DHT, they may risk not
> being fully interoperable, but I think if we don't pick one at all, we
> almost guarantee things won't be interoperable.
>
> And I (and I think nearly everyone) is 100% in the camp of "we should
> allow pluggable DHTs". I think it is safe to say that one is a done
> deal, but I would personally have thought a mandatory was as well. In
> any case, my vote is definitely for pluggable DHTs.
>
> David
>
> On 7/13/07, Jonathan Rosenberg < jdrosen@cisco.com> wrote:
>> I've read draft-bryan-p2psip-requirements-00, and have a bunch of
>> comments. But a few items came to mind I wanted to discuss which
>> merit
>> their own threads.
>>
>> First, is the concept of mandatory-to-implement DHT. The requirements
>> document talks a lot about requirements around selecting a
>> mandatory to
>> implement DHT. Its something we've discussed in the meeting and on
>> the
>> list. I think everyone agrees also that we need to allow for multiple
>> DHT and all of the recent protocol proposals support it.
>>
>> However, I do not think we should have a mandatory-to-implement
>> DHT at all.
>>
>> There are several reasons for this. First of all, its important to
>> understand the reason why IETF has mandatory-to-implement
>> functionality
>> in its protocols. The one and only reason is that it ensures
>> interoperability. It ensures that, independent of the optional
>> features
>> selected by a pair of entities, when you connect them together,
>> they can
>> still interoperate.
>>
>> This property will NOT be retained with a mandatory-to-implement DHT.
>> Once the ring forms, the DHT protocol is chosen and locked. Thus,
>> if any
>>   DHT besides the 'mandatory-to-implement' one has been selected
>> for the
>> DHT, a new node not supporting that DHT will not be able to join the
>> ring even if it implements the mandatory-to-implement one. Thus, the
>> entire purpose of mandatory-to-implement is eliminated - we don't
>> actually get interoperability.
>>
>> Indeed, to get this kind of interoperability, we'd need to pick
>> one and
>> only one DHT that ever gets used with p2psip. I think that is a
>> mistake.
>> This is an evolving area and is one where agility is important.
>>
>> Instead, what I think happens is that a 'provider' that deploys a p2p
>> network will need to pick a DHT, and make sure that the clients all
>> support that DHT. This is something the market should drive, not us.
>>
>> Secondly, I think its important to realize that we are picking up
>> work
>> in an area that is well trod. There are lots and lots of papers and
>> protocols and software written around P2P networks. I don't think
>> anyone
>> looks at an IETF protocol and says, "IETF are the guys who know about
>> DHTs, lets go with their recommendation". What IETF is really good
>> at,
>> and what this group has expertise in, is SIP, and on designing good,
>> scalable protocols in general - things that have security,
>> extensibility, good performance, and so on. So I think the greatest
>> value we can bring to the table is to create a protocol that allows
>> others to take DHTs and easily turn them into a real wire protocol
>> that
>> you can actually deploy, on the Internet, to support SIP and ideally
>> other things too. Interestingly, this is exactly what all of the
>> protocol proposals do. That kind of focus goes hand-in-hand with
>> saying,
>> let someone else figure out which DHT to use. I think its perfectly
>> reasonable for us, and for others, to write documents on how to
>> use our
>> protocol with various DHTs. But I think we should be out of the
>> business
>> of picking one or recommending one (or ones) to be used.
>>
>> -Jonathan R.
>> --
>> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
>> Cisco Fellow                                   Parsippany, NJ
>> 07054-2711
>> Cisco Systems
>> jdrosen@cisco.com                              FAX:   (973) 952-5050
>> http://www.jdrosen.net                         PHONE: (973) 952-5000
>> http://www.cisco.com
>>
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://www1.ietf.org/mailman/listinfo/p2psip
>>
>
>
> --
> David A. Bryan
> dbryan@SIPeerior.com
> +1.757.565.0101 x101
> +1.757.565.0088 (fax)
> www.SIPeerior.com
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_42492_9544413.1184471686750-- --===============0614086879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0614086879==-- From p2psip-bounces@ietf.org Sat Jul 14 23:59:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9vGj-0004M4-AB; Sat, 14 Jul 2007 23:59:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9vGh-0004Ly-Sy for p2psip@ietf.org; Sat, 14 Jul 2007 23:59:35 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9vGh-0002Sg-A6 for p2psip@ietf.org; Sat, 14 Jul 2007 23:59:35 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2257698uge for ; Sat, 14 Jul 2007 20:58:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lt6YuSVLG1MNEvRz26rUaqmZovUiWKdKbXNfS6d0Cn6CeXnvTFoikRMoG0FxTYr/v9MhKAKql7YbLBMwLBU2WT9DK2eSfs7qun5KA05qSaIAcE++/1gp5TOSAYsyK0h941dX3tNtUvpmUd+flsMzNJTVHHJaCCKct7lwW0u32l0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=siLNkUTswsTE/s2OkP7vC8juS5opU1kDZrnNlBus1sWKHFBM1T5FBV4T3K9QRzJPu4LCXCyUsEKjoih3thHBeTkqgtK8jSfIM2i6Q/NjaqmJvq4hSq7iRewQztdPrhv1u0V1H6RokMGTtn0G/hrJ2H74lurkXm/R2FOCfeCxEWg= Received: by 10.78.201.15 with SMTP id y15mr854043huf.1184471902083; Sat, 14 Jul 2007 20:58:22 -0700 (PDT) Received: by 10.78.53.20 with HTTP; Sat, 14 Jul 2007 20:58:21 -0700 (PDT) Message-ID: <7b683f3f0707142058g327383fdmffd4d1f818e4dba6@mail.gmail.com> Date: Sat, 14 Jul 2007 23:58:21 -0400 From: "Eunsoo Shim" To: "Kundan Singh" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> MIME-Version: 1.0 References: <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <9FA16888AD1BF64ABCE6C2532CCEB98A02A6B555@xmb-sjc-219.amer.cisco.com> <4d4304a00707140803r776f123av730e1bb280c322c0@mail.gmail.com> <007a01c7c637$8d48d510$a507740a@DELLWEI> <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0451361347==" Errors-To: p2psip-bounces@ietf.org --===============0451361347== Content-Type: multipart/alternative; boundary="----=_Part_42524_16850802.1184471901991" ------=_Part_42524_16850802.1184471901991 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline You made a good point that choosing a common DHT algorithm does not guarantee automatic interoperation among various devices. However, it still provides a much better situation than where developers/manufacturers implement arbitrary sets of arbitrary DHT algorithms. In the former situation, at least one can configure devices to use the common algorithm. In the latter situation, interoperation may not be able to be achieved at all. Thanks. Eunsoo On 7/14/07, Kundan Singh wrote: > > > > Suppose we define a mandatory-to-implement DHT, say D0. > > Now node N1 implements DHTs D0 and D1, and node N2 implements D0 and D2. > When N1 started, it decided to use DHT D1 and joined the existing DHT > with D1 (hence locked to D1). > When N2 started, it decided on D2 (hence locked to D2). > > I suppose in this case we all agree that N1 and N2 can talk only via > client protocol. --- (A) > > Essentially N1 and N2 are not interoperating using the peer protocol of > mandatory-to-implement D0. > > Now in the example, to effectively utilize mandatory-to-implement DHT, > both N1 and N2 _MUST_ also join D0 using the peer protocol --- (B) > > (Does anyone disagree with statement (B)?) > > This means, for N1, the DHT maintenance operations must be done in D0 as > well as in D1, and any lookup operation must fallback to D0 if failed in > D1. Essentially, the performance gain of D1 is nullified and the > performance is limited to that of the algorithm in D0. This defeats the > purpose of let-the-best-DHT-win motto, and in practice *discourages* > implementing other DHTs besides default D0 since you don't gain > performance. (Which encourages implementations to become non-standard in > favor of better performance.) > > I agree with Jonathan. I don't think we should limit innovation by > specifying a mandatory-to-implement DHT when we clearly don't know which > is the best DHT. Like Henning said, the client protocol can be used for > interconnecting. > > (Talking about 'the best DHT', I think depending on the deployment > scenario different DHTs will perform differently. So one-size-fits-all > model may not be best for all the use cases we have. For example Bamboo > is proven to be good for DHT service hence probably good for low-churn > high-storage P2PSIP-proxies use case, but too many connections and low > keep-alives and data sync timers of Bamboo may not be good for > high-churn behind-the-NAT residential peers running on user laptops.) > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_42524_16850802.1184471901991 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline You made a good point that choosing a common DHT algorithm does not guarantee automatic interoperation among various devices.
However, it still provides a much better situation than where developers/manufacturers implement arbitrary sets of arbitrary DHT algorithms. In the former situation, at least one can configure devices to use the common algorithm. In the latter situation, interoperation may not be able to be achieved at all.
Thanks.

Eunsoo

On 7/14/07, Kundan Singh <kundan@adobe.com> wrote:


Suppose we define a mandatory-to-implement DHT, say D0.

Now node N1 implements DHTs D0 and D1, and node N2 implements D0 and D2.
When N1 started, it decided to use DHT D1 and joined the existing DHT
with D1 (hence locked to D1).
When N2 started, it decided on D2 (hence locked to D2).

I suppose in this case we all agree that N1 and N2 can talk only via
client protocol. --- (A)

Essentially N1 and N2 are not interoperating using the peer protocol of
mandatory-to-implement D0.

Now in the example, to effectively utilize mandatory-to-implement DHT,
both N1 and N2 _MUST_ also join D0 using the peer protocol --- (B)

(Does anyone disagree with statement (B)?)

This means, for N1, the DHT maintenance operations must be done in D0 as
well as in D1, and any lookup operation must fallback to D0 if failed in
D1. Essentially, the performance gain of D1 is nullified and the
performance is limited to that of the algorithm in D0. This defeats the
purpose of let-the-best-DHT-win motto, and in practice *discourages*
implementing other DHTs besides default D0 since you don't gain
performance. (Which encourages implementations to become non-standard in
favor of better performance.)

I agree with Jonathan. I don't think we should limit innovation by
specifying a mandatory-to-implement DHT when we clearly don't know which
is the best DHT. Like Henning said, the client protocol can be used for
interconnecting.

(Talking about 'the best DHT', I think depending on the deployment
scenario different DHTs will perform differently. So one-size-fits-all
model may not be best for all the use cases we have. For example Bamboo
is proven to be good for DHT service hence probably good for low-churn
high-storage P2PSIP-proxies use case, but too many connections and low
keep-alives and data sync timers of Bamboo may not be good for
high-churn behind-the-NAT residential peers running on user laptops.)


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_42524_16850802.1184471901991-- --===============0451361347== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0451361347==-- From p2psip-bounces@ietf.org Sun Jul 15 00:01:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9vIx-0007Yk-VC; Sun, 15 Jul 2007 00:01:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9vIx-0007XK-Eo for p2psip@ietf.org; Sun, 15 Jul 2007 00:01:55 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9vIt-00046J-Oq for p2psip@ietf.org; Sun, 15 Jul 2007 00:01:55 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com id BT-MMP-2118296; Sun, 15 Jul 2007 00:01:48 -0400 Received: from 0015-its-exbh02.us.saic.com ([10.43.229.22]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2007071500014814434 ; Sun, 15 Jul 2007 00:01:48 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-its-exbh02.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 00:01:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sun, 15 Jul 2007 00:01:48 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1D19C@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfGklUEnYRNFoU5R1OPE72WpYJ0CQAAHylT References: <4697F02B.4030506@cisco.com> <7b683f3f0707142043n38e4f51fg4126ecd02e160da3@mail.gmail.com> From: "Roy, Radhika R." To: "Eunsoo Shim" , "Jonathan Rosenberg" X-OriginalArrivalTime: 15 Jul 2007 04:01:48.0230 (UTC) FILETIME=[DDD17660:01C7C694] X-Spam-Score: 0.5 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2037471209==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============2037471209== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C694.DDD0DD59" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C694.DDD0DD59 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The example of G.711 codec is NOT exactly right here although some = aspects of this are applicable in the DHT argument. A couple of things = are as follows: 1.=09 All codecs including G.711 use the same SIP signaling protocol 2.=09 G.711 codec has been used as a reference for all other codecs for = interoperability purpose. For example, if audio bridging with multiple = different codecs are done, then all of them need to be converted into a = single common format, and G.711 is used as a reference common format. So, if we analyze items 1 and 2 very carefully, it again proves the = fact, as David pointed out, we need one standard thing as a reference to = start with as follows: * Only "one" reference standard for the signaling protocol (in this case = it is SIP) to provide interoperability * Only "one" reference standard codec that will offer a reference = standard format that will be used for inter-operability among different = codecs As such, what is the lesson from the above from standardization point of = view when we apply those experiences in DHT standardization? Is it not what David has pointed out? Best regards, Radhika ________________________________ From: p2psip-bounces@ietf.org on behalf of Eunsoo Shim Sent: Sat 7/14/2007 11:43 PM To: Jonathan Rosenberg Cc: P2PSIP WG Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion I agree that it should be the market that drives the choice of the DHT = algorithm eventually. On the other hand, currently no specific DHT algorithm has been = established as a widely accepted one for P2PSIP overlays. So I am = wondering what DHT algorithms a manufacturer would implement if they = implement P2PSIP nodes. And if manufacturers choose all kinds of = variations of various DHT algorithms, it will give significant headache = and limited choices of devices to even large service providers, not to = mention smaller ones and enterprises who like to use multi-vendor = solutions.=20 The SIP community did not have to recommend or choose any voice codec. = Other organizations developed various voice codec standards and there = were widely accepted voice codecs such as G.711. So it was not much of = an issue what voice codec should be implemented or selected for SIP = devices. The situation with DHT is different in my understanding. There = are too many options and one can easily try to tweak a known DHT = algorithm.=20 I am not aware of any standardization body or industry organization that = is working to define any standard DHT.=20 I believe at least some kind of recommendation on DHT algorithms, if not = a mandatory implementation requirement, would help a lot.=20 If the P2PSIP community does not produce it for P2PSIP overlays, who = would do it? Thanks. Eunsoo On 7/13/07, Jonathan Rosenberg wrote:=20 I've read draft-bryan-p2psip-requirements-00, and have a bunch of=20 comments. But a few items came to mind I wanted to discuss which merit their own threads. =09 First, is the concept of mandatory-to-implement DHT. The requirements document talks a lot about requirements around selecting a mandatory to = implement DHT. Its something we've discussed in the meeting and on the list. I think everyone agrees also that we need to allow for multiple DHT and all of the recent protocol proposals support it. =09 However, I do not think we should have a mandatory-to-implement DHT at = all.=20 =09 There are several reasons for this. First of all, its important to understand the reason why IETF has mandatory-to-implement functionality in its protocols. The one and only reason is that it ensures interoperability. It ensures that, independent of the optional features = selected by a pair of entities, when you connect them together, they = can still interoperate. =09 This property will NOT be retained with a mandatory-to-implement DHT. Once the ring forms, the DHT protocol is chosen and locked. Thus, if = any=20 DHT besides the 'mandatory-to-implement' one has been selected for = the DHT, a new node not supporting that DHT will not be able to join the ring even if it implements the mandatory-to-implement one. Thus, the=20 entire purpose of mandatory-to-implement is eliminated - we don't actually get interoperability. =09 Indeed, to get this kind of interoperability, we'd need to pick one and only one DHT that ever gets used with p2psip. I think that is a = mistake.=20 This is an evolving area and is one where agility is important. =09 Instead, what I think happens is that a 'provider' that deploys a p2p network will need to pick a DHT, and make sure that the clients all=20 support that DHT. This is something the market should drive, not us. =09 Secondly, I think its important to realize that we are picking up work in an area that is well trod. There are lots and lots of papers and=20 protocols and software written around P2P networks. I don't think = anyone looks at an IETF protocol and says, "IETF are the guys who know about DHTs, lets go with their recommendation". What IETF is really good at,=20 and what this group has expertise in, is SIP, and on designing good, scalable protocols in general - things that have security, extensibility, good performance, and so on. So I think the greatest value we can bring to the table is to create a protocol that allows=20 others to take DHTs and easily turn them into a real wire protocol that you can actually deploy, on the Internet, to support SIP and ideally other things too. Interestingly, this is exactly what all of the protocol proposals do. That kind of focus goes hand-in-hand with = saying,=20 let someone else figure out which DHT to use. I think its perfectly reasonable for us, and for others, to write documents on how to use our protocol with various DHTs. But I think we should be out of the = business=20 of picking one or recommending one (or ones) to be used. =09 -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ = 07054-2711=20 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net = PHONE: (973) 952-5000=20 http://www.cisco.com =20 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =09 ------_=_NextPart_001_01C7C694.DDD0DD59 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
The example = of G.711 codec is NOT exactly right here although some aspects of this = are applicable in the DHT argument. A couple of things are as = follows:
=0A=
=0A=
    =0A=
  1. =0A=
    All codecs including G.711 use the same = SIP signaling protocol
    2. =0A=
  2. =0A=
    G.711 codec has been used as a = reference for all other codecs for interoperability purpose. For = example, if audio bridging with multiple different codecs are done, then = all of them need to be converted into a single common format, and G.711 = is used as a reference common format.
=0A=

So, if we analyze items 1 and 2 very = carefully, it again proves the fact, as David pointed out, we need one = standard thing as a reference to start with as follows:

=0A=
    =0A=
  • Only "one" reference standard for = the signaling protocol (in this case it is SIP) to provide = interoperability
    • =0A=
  • Only "one" reference standard codec that = will offer a reference standard format that will be used for = inter-operability among different codecs
=0A=

As such, what is the lesson from the = above from standardization point of view when we apply those experiences = in DHT standardization?

=0A=

Is it not what David has pointed = out?

=0A=

Best regards,

=0A=

Radhika

=0A=

=0A=
=0A=
=0A=
=0A=
From: = p2psip-bounces@ietf.org on behalf of Eunsoo Shim
Sent: Sat = 7/14/2007 11:43 PM
To: Jonathan Rosenberg
Cc: P2PSIP = WG
Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a = dissenting opinion

=0A=
I agree that it should be the market that drives the choice of the = DHT algorithm eventually.

On the other hand, currently no = specific DHT algorithm has been established as a widely accepted one for = P2PSIP overlays. So I am wondering what DHT algorithms a manufacturer = would implement if they implement P2PSIP nodes. And if manufacturers = choose all kinds of variations of various DHT algorithms, it will give = significant headache and limited choices of devices to even large = service providers, not to mention smaller ones and enterprises who like = to use multi-vendor solutions.

The SIP community did not have to = recommend or choose any voice codec. Other organizations developed = various voice codec standards and there were widely accepted voice = codecs such as G.711. So it was not much of an issue what voice codec = should be implemented or selected for SIP devices. The situation with = DHT is different in my understanding. There are too many options and one = can easily try to tweak a known DHT algorithm.

I am not aware of = any standardization body or industry organization that is working to = define any standard DHT.

I believe at least some kind of = recommendation on DHT algorithms, if not a mandatory implementation = requirement, would help a lot.

If the P2PSIP community does not = produce it for P2PSIP overlays, who would do = it?

Thanks.

Eunsoo



=0A=
On 7/13/07, Jonathan Rosenberg <jdrosen@cisco.com> = wrote: =0A=
I've read = draft-bryan-p2psip-requirements-00, and have a bunch of
comments. = But a few items came to mind I wanted to discuss which merit
their = own threads.

First, is the concept of mandatory-to-implement DHT. = The requirements
document talks a lot about requirements around = selecting a mandatory to
implement DHT. Its something we've = discussed in the meeting and on the
list. I think everyone agrees = also that we need to allow for multiple
DHT and all of the recent = protocol proposals support it.

However, I do not think we should = have a mandatory-to-implement DHT at all.

There are several = reasons for this. First of all, its important to
understand the = reason why IETF has mandatory-to-implement functionality
in its = protocols. The one and only reason is that it = ensures
interoperability. It ensures that, independent of the = optional features
selected by a pair of entities, when you connect = them together, they can
still interoperate.

This property will = NOT be retained with a mandatory-to-implement DHT.
Once the ring = forms, the DHT protocol is chosen and locked. Thus, if any =
  DHT besides the 'mandatory-to-implement' one has been = selected for the
DHT, a new node not supporting that DHT will not be = able to join the
ring even if it implements the = mandatory-to-implement one. Thus, the
entire purpose of = mandatory-to-implement is eliminated - we don't
actually get = interoperability.

Indeed, to get this kind of interoperability, = we'd need to pick one and
only one DHT that ever gets used with = p2psip. I think that is a mistake.
This is an evolving area and is = one where agility is important.

Instead, what I think happens is = that a 'provider' that deploys a p2p
network will need to pick a DHT, = and make sure that the clients all
support that DHT. This is = something the market should drive, not us.

Secondly, I think its = important to realize that we are picking up work
in an area that is = well trod. There are lots and lots of papers and
protocols and = software written around P2P networks. I don't think anyone
looks at = an IETF protocol and says, "IETF are the guys who know about
DHTs, = lets go with their recommendation". What IETF is really good at,
and = what this group has expertise in, is SIP, and on designing = good,
scalable protocols in general - things that have = security,
extensibility, good performance, and so on. So I think the = greatest
value we can bring to the table is to create a protocol that = allows
others to take DHTs and easily turn them into a real wire = protocol that
you can actually deploy, on the Internet, to support = SIP and ideally
other things too. Interestingly, this is exactly what = all of the
protocol proposals do. That kind of focus goes = hand-in-hand with saying,
let someone else figure out which DHT to = use. I think its perfectly
reasonable for us, and for others, to = write documents on how to use our
protocol with various DHTs. But I = think we should be out of the business
of picking one or = recommending one (or ones) to be used.

-Jonathan = R.
--
Jonathan D. Rosenberg, = Ph.D.           &n= bsp;       600 Lanidex Plaza
Cisco = Fellow           &= nbsp;           &n= bsp;           = Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com   =             &= nbsp;           &n= bsp;  FAX:   (973) 952-5050
http://www.jdrosen.net  &n= bsp;           &nb= sp;          PHONE: (973) = 952-5000
http://www.cisco.com

__________= _____________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

------_=_NextPart_001_01C7C694.DDD0DD59-- --===============2037471209== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2037471209==-- From p2psip-bounces@ietf.org Sun Jul 15 00:04:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9vLq-0001ui-QG; Sun, 15 Jul 2007 00:04:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9vLp-0001ud-DU for p2psip@ietf.org; Sun, 15 Jul 2007 00:04:53 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9vLa-0002ZH-5C for p2psip@ietf.org; Sun, 15 Jul 2007 00:04:53 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com id BT-MMP-2118442; Sun, 15 Jul 2007 00:04:18 -0400 Received: from 0015-its-exbh02.us.saic.com ([10.43.229.22]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2007071500041814550 ; Sun, 15 Jul 2007 00:04:18 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-its-exbh02.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 00:04:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sun, 15 Jul 2007 00:02:22 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1D19D@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfGlJ/fM+fT8sTdSHWV9maGi50r/AAAFKWE References: <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com><9FA16888AD1BF64ABCE6C2532CCEB98A02A6B555@xmb-sjc-219.amer.cisco.com><4d4304a00707140803r776f123av730e1bb280c322c0@mail.gmail.com><007a01c7c637$8d48d510$a507740a@DELLWEI><625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <7b683f3f0707142058g327383fdmffd4d1f818e4dba6@mail.gmail.com> From: "Roy, Radhika R." To: "Eunsoo Shim" , "Kundan Singh" X-OriginalArrivalTime: 15 Jul 2007 04:04:18.0413 (UTC) FILETIME=[375591D0:01C7C695] X-Spam-Score: 1.8 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1371831481==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1371831481== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C695.37303E5D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C695.37303E5D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You are right Eunsoo as David also has made the same point. - Radhika ________________________________ From: p2psip-bounces@ietf.org on behalf of Eunsoo Shim Sent: Sat 7/14/2007 11:58 PM To: Kundan Singh Cc: P2PSIP WG Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion You made a good point that choosing a common DHT algorithm does not = guarantee automatic interoperation among various devices. However, it still provides a much better situation than where = developers/manufacturers implement arbitrary sets of arbitrary DHT = algorithms. In the former situation, at least one can configure devices = to use the common algorithm. In the latter situation, interoperation may = not be able to be achieved at all.=20 Thanks. Eunsoo ------_=_NextPart_001_01C7C695.37303E5D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
You are right = Eunsoo as David also has made the same point. - = Radhika
=0A=

=0A=
=0A= From: p2psip-bounces@ietf.org on = behalf of Eunsoo Shim
Sent: Sat 7/14/2007 11:58 = PM
To: Kundan Singh
Cc: P2PSIP WG
Subject: = Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting = opinion

=0A=
You made a good point that choosing a common DHT algorithm does not = guarantee automatic interoperation among various devices.
However, it = still provides a much better situation than where = developers/manufacturers implement arbitrary sets of arbitrary DHT = algorithms. In the former situation, at least one can configure devices = to use the common algorithm. In the latter situation, interoperation may = not be able to be achieved at all. =
Thanks.

Eunsoo

------_=_NextPart_001_01C7C695.37303E5D-- --===============1371831481== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1371831481==-- From p2psip-bounces@ietf.org Sun Jul 15 18:54:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IACyD-0001ip-32; Sun, 15 Jul 2007 18:53:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IACyC-0001dR-39 for p2psip@ietf.org; Sun, 15 Jul 2007 18:53:40 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IACyB-0004Pv-Eo for p2psip@ietf.org; Sun, 15 Jul 2007 18:53:40 -0400 Received: from source ([192.150.11.134]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Sun, 15 Jul 2007 15:52:22 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6FMp4ot010022; Sun, 15 Jul 2007 15:51:09 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6FMqE0c025915; Sun, 15 Jul 2007 15:52:15 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Jul 2007 15:52:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sun, 15 Jul 2007 15:52:13 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AA9D47@namail5.corp.adobe.com> In-Reply-To: <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfFqmGbnX4TyUg6SQ+JbBVOMYFPwABhw/8g References: <4697F02B.4030506@cisco.com><4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> From: "Henry Sinnreich" To: "Henning Schulzrinne" , "David A. Bryan" X-OriginalArrivalTime: 15 Jul 2007 22:52:14.0425 (UTC) FILETIME=[C9617C90:01C7C732] X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henning Schulzrinne wrote: >Lack of a common DHT does not necessarily interfere with =20 >interoperability. The client protocol, at least in our thinking, is =20 >independent of the DHT, so a node that doesn't implement the DHT =20 >algorithm of the overlay it wants to talk to can still reach others, =20 >it just can't be a full peer. Can we interpret this as an endorsement of the client protocol and/or another argument in its favor? Thanks, Henry -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Friday, July 13, 2007 5:02 PM To: David A. Bryan Cc: P2PSIP WG Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Lack of a common DHT does not necessarily interfere with =20 interoperability. The client protocol, at least in our thinking, is =20 independent of the DHT, so a node that doesn't implement the DHT =20 algorithm of the overlay it wants to talk to can still reach others, =20 it just can't be a full peer. Since typically only a small fraction =20 of nodes need to act as peers at any given time, this may not be much =20 of a problem. You could design a system that essentially replicated the key-data =20 mappings across two DHT algorithm, a baseline universal one and the =20 "fancy"/"better" one less universally spoken. This incurs =20 significantly more overhead and probably yields some strange partial =20 reachability cases particularly as new nodes are added, but it could =20 be done. Henning On Jul 13, 2007, at 6:16 PM, David A. Bryan wrote: > I think this likely to be a source of serious discussion. At least for > now (maybe Jonathan can convince me), I'm inclined to disagree. > > I think the problem is that if we don't specify a mandatory to > implement, there may be many devices from different vendors that don't > even implement a common DHT. Each will pick and choose which DHTs to > implement, and in the end, there won't be a common DHT all can even > run if they want to. > > I think looking at it from the perspective of "once the DHT chosen it > is locked" is the wrong way to look at it. The idea isn't that any > device can join any already established overlay, but that if I deploy > a system of heterogeneous devices, there is at least one that I can > select when I start and know that all "P2PSIP endpoints" (assuming > that term means anything) will at least support that and I can form an > overlay with them. Maybe not the ideal DHT for my overlay, but > something I know all devices can support, and if I run it in that > mode, it works. > > Personally, I think if we don't do that, many DHTs will be > standardized for different environments (good) but each vendor will > implement a (potentially disjoint) subset, and there may be no way to > use two endpoints from different vendors together at all. > > I agree that if a user selects a non-mandatory DHT, they may risk not > being fully interoperable, but I think if we don't pick one at all, we > almost guarantee things won't be interoperable. > > And I (and I think nearly everyone) is 100% in the camp of "we should > allow pluggable DHTs". I think it is safe to say that one is a done > deal, but I would personally have thought a mandatory was as well. In > any case, my vote is definitely for pluggable DHTs. > > David > > On 7/13/07, Jonathan Rosenberg wrote: >> I've read draft-bryan-p2psip-requirements-00, and have a bunch of >> comments. But a few items came to mind I wanted to discuss which =20 >> merit >> their own threads. >> >> First, is the concept of mandatory-to-implement DHT. The requirements >> document talks a lot about requirements around selecting a =20 >> mandatory to >> implement DHT. Its something we've discussed in the meeting and on =20 >> the >> list. I think everyone agrees also that we need to allow for multiple >> DHT and all of the recent protocol proposals support it. >> >> However, I do not think we should have a mandatory-to-implement =20 >> DHT at all. >> >> There are several reasons for this. First of all, its important to >> understand the reason why IETF has mandatory-to-implement =20 >> functionality >> in its protocols. The one and only reason is that it ensures >> interoperability. It ensures that, independent of the optional =20 >> features >> selected by a pair of entities, when you connect them together, =20 >> they can >> still interoperate. >> >> This property will NOT be retained with a mandatory-to-implement DHT. >> Once the ring forms, the DHT protocol is chosen and locked. Thus, =20 >> if any >> DHT besides the 'mandatory-to-implement' one has been selected =20 >> for the >> DHT, a new node not supporting that DHT will not be able to join the >> ring even if it implements the mandatory-to-implement one. Thus, the >> entire purpose of mandatory-to-implement is eliminated - we don't >> actually get interoperability. >> >> Indeed, to get this kind of interoperability, we'd need to pick =20 >> one and >> only one DHT that ever gets used with p2psip. I think that is a =20 >> mistake. >> This is an evolving area and is one where agility is important. >> >> Instead, what I think happens is that a 'provider' that deploys a p2p >> network will need to pick a DHT, and make sure that the clients all >> support that DHT. This is something the market should drive, not us. >> >> Secondly, I think its important to realize that we are picking up =20 >> work >> in an area that is well trod. There are lots and lots of papers and >> protocols and software written around P2P networks. I don't think =20 >> anyone >> looks at an IETF protocol and says, "IETF are the guys who know about >> DHTs, lets go with their recommendation". What IETF is really good =20 >> at, >> and what this group has expertise in, is SIP, and on designing good, >> scalable protocols in general - things that have security, >> extensibility, good performance, and so on. So I think the greatest >> value we can bring to the table is to create a protocol that allows >> others to take DHTs and easily turn them into a real wire protocol =20 >> that >> you can actually deploy, on the Internet, to support SIP and ideally >> other things too. Interestingly, this is exactly what all of the >> protocol proposals do. That kind of focus goes hand-in-hand with =20 >> saying, >> let someone else figure out which DHT to use. I think its perfectly >> reasonable for us, and for others, to write documents on how to =20 >> use our >> protocol with various DHTs. But I think we should be out of the =20 >> business >> of picking one or recommending one (or ones) to be used. >> >> -Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Cisco Fellow Parsippany, NJ =20 >> 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > --=20 > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 15 19:20:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IADNu-00064k-3Z; Sun, 15 Jul 2007 19:20:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IADNr-0005sH-RE for p2psip@ietf.org; Sun, 15 Jul 2007 19:20:12 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IADNc-0004ux-KE for p2psip@ietf.org; Sun, 15 Jul 2007 19:20:11 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6FNJIoJ029643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Jul 2007 19:19:21 -0400 (EDT) In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AA9D47@namail5.corp.adobe.com> References: <4697F02B.4030506@cisco.com><4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> <24CCCC428EFEA2469BF046DB3C7A8D22AA9D47@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <642EF0D3-3597-498F-9BCB-AB5A745F0024@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sun, 15 Jul 2007 19:19:16 -0400 To: "Henry Sinnreich" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jul 15, 2007, at 6:52 PM, Henry Sinnreich wrote: > Henning Schulzrinne wrote: > >> Lack of a common DHT does not necessarily interfere with >> interoperability. The client protocol, at least in our thinking, is >> independent of the DHT, so a node that doesn't implement the DHT >> algorithm of the overlay it wants to talk to can still reach others, >> it just can't be a full peer. > > Can we interpret this as an endorsement of the client protocol and/or > another argument in its favor? > I admit not having followed the discussion in detail, so I'm hesitant to answer, but I suspect, yes. My feeling is that the client protocol can probably be structured as a proper subset of the peer maintenance protocol. I'll also note in passing that, so far, I have not found it helpful to restrict the DHT in designing P2PP. In other words, if the WG charter said "Thou shalt use foobar DHT only", I don't think the protocol would have been much simpler or different, except maybe for a small part of the discovery/introspection features. I'd be curious if designers of other protocol proposals have had different experiences. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 15 20:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAE0b-0002zU-6F; Sun, 15 Jul 2007 20:00:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAE0a-0002zO-Ad for p2psip@ietf.org; Sun, 15 Jul 2007 20:00:12 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAE0Z-0005c4-VU for p2psip@ietf.org; Sun, 15 Jul 2007 20:00:12 -0400 Received: from [72.87.190.18] (helo=[192.9.200.1]) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IADzb-00030i-0i; Sun, 15 Jul 2007 19:59:11 -0400 Message-ID: <469AC39B.1010808@idssoftware.com> Date: Sun, 15 Jul 2007 17:02:19 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Bruce Lowekamp , P2PSIP Mailing List Subject: Re: [P2PSIP] new RELOAD drafts References: <20d2bdfb0707090720o4afb663ewa3f1f3e64c4ac102@mail.gmail.com> In-Reply-To: <20d2bdfb0707090720o4afb663ewa3f1f3e64c4ac102@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940fbef1d000903ea0827cf9f08aa3d82c5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 72.87.190.18 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Bruce, Just want to point out that in this new draft, the description for the Method field of the protocol is one bit short. In section 5.1, the paragraph on the method field begins as: "Method is a 7 bit field that indicates the message method. ... The class of methods are specified by the first two bits:" ... "The remaining four bits are used to specify the peer, resource, and transport methods. The following list of methods MUST be understood and are shown with their full 6 bit representations (first two bits are method type, last four specify method):" Only 6 out of 7 bits for the method field are defined. Thanks Michael Chen IDS Software Bruce Lowekamp wrote: > We have submitted an update to the base RELOAD draft, > draft-bryan-p2psip-reload-01 > and on security extensions for RELOAD > draft-lowekamp-p2psip-reload-security-01 > > Until they are available in the repository, they are available from > p2psip.org > > The major change to reload-01 is the addition of sections describing > the TRANSPORT-OPEN and TRANSPORT-TUNNEL methods for NAT traversal. > > Bruce > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 15 21:11:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAF7z-0000j8-3y; Sun, 15 Jul 2007 21:11:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAF7y-0000j3-6Z for p2psip@ietf.org; Sun, 15 Jul 2007 21:11:54 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAF7t-00026e-U4 for p2psip@ietf.org; Sun, 15 Jul 2007 21:11:54 -0400 Received: by py-out-1112.google.com with SMTP id f31so3428313pyh for ; Sun, 15 Jul 2007 18:11:49 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=IYvefuOe3D27WyrRWtC15Bju0Y34aeXK6Vd/fEdo3XeL9EAOebCgwqE9hcEdmCgmgwC9tBZ19wLls5pLaELdu6OP81BzVuKYC/Hv9ZpYucYot3cqmKeMeqqBeBnUJPd1n/6TmxGuMkrM2Sb61bQa8/5GspHfvUVLE2J6/eBXu8U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=quehIrLbdeudS/QZR3C054utoe8cV6jPL+L/PhvYQmD8LGoPDmFnLi0mhMnXEjaGfVxDsCm0N1ZTgmd29ldurrHXIMHDnnno+tXqcYWZPUQexX/xtLrM+Sap5CGUMFomYFCdHTu++sSVFsPOfvJEYtGMcfmAH2abG23dVwpx/1I= Received: by 10.65.119.14 with SMTP id w14mr5882757qbm.1184548309276; Sun, 15 Jul 2007 18:11:49 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Sun, 15 Jul 2007 18:11:49 -0700 (PDT) Message-ID: <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com> Date: Sun, 15 Jul 2007 21:11:49 -0400 From: "David A. Bryan" To: "Henning Schulzrinne" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <642EF0D3-3597-498F-9BCB-AB5A745F0024@cs.columbia.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4697F02B.4030506@cisco.com> <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> <24CCCC428EFEA2469BF046DB3C7A8D22AA9D47@namail5.corp.adobe.com> <642EF0D3-3597-498F-9BCB-AB5A745F0024@cs.columbia.edu> X-Google-Sender-Auth: cf8306b5d42b498b X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 7/15/07, Henning Schulzrinne wrote: > I'll also note in passing that, so far, I have not found it helpful > to restrict the DHT in designing P2PP. In other words, if the WG > charter said "Thou shalt use foobar DHT only", I don't think the > protocol would have been much simpler or different, except maybe for > a small part of the discovery/introspection features. I'd be curious > if designers of other protocol proposals have had different experiences. Agree that restricting to one DHT will not make the protocol substantially simpler (in both dSIP and RELOAD we had multiple DHTs, and other than using somewhat more generic labels for fields, I don't think picking a particular DHT would make that easier. In some ways, that is my worry about not defining a must implement DHT...it is pretty easy to use the protocols to encode any DHT one likes, so if we don't define one, expect each and every vendor to use a different, non-interoperable one (at least until market strength and a patent from one of the big players forces a default implement anyway, encumbered by a license fee at that point...) David -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 15 21:20:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAFG8-0008IU-C7; Sun, 15 Jul 2007 21:20:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAFG7-0008GE-NM for p2psip@ietf.org; Sun, 15 Jul 2007 21:20:19 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAFG3-0002Gq-9o for p2psip@ietf.org; Sun, 15 Jul 2007 21:20:19 -0400 Received: from lappy ([75.7.13.129]) by quinthar.com for ; Sun, 15 Jul 2007 18:20:05 -0700 From: "David Barrett" To: "'David A. Bryan'" , "'Henning Schulzrinne'" Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sun, 15 Jul 2007 18:20:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfHRlWIyCO6RY2qRpOoI/fK0Jk7wAAANmuQ In-Reply-To: <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'Henry Sinnreich' , 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: David A. Bryan [mailto:dbryan@sipeerior.com] > > Agree that restricting to one DHT will not make the protocol > substantially simpler (in both dSIP and RELOAD we had multiple DHTs, > and other than using somewhat more generic labels for fields, I don't > think picking a particular DHT would make that easier. I agree the messages on the wire are probably about the same irrespective of the DHT algorithm. But would you agree that standardizing on a particular algorithm would make things easier? For example, if I'm using Kademlia and you're using Chord -- even we're using compatible packet formats -- won't that create a dysfunctional overlay network? -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 15 21:31:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAFQt-0000Lu-Hx; Sun, 15 Jul 2007 21:31:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAFQr-0000Dw-Qx for p2psip@ietf.org; Sun, 15 Jul 2007 21:31:25 -0400 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAFQn-0002Tm-EC for p2psip@ietf.org; Sun, 15 Jul 2007 21:31:25 -0400 Received: by py-out-1112.google.com with SMTP id f31so3439128pyh for ; Sun, 15 Jul 2007 18:31:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=JuyrvdpycYZQ6YoL06EMvUEjQQxQ3PPz1aRLlpk3gjBqMOJBb4uwF4bJS9PZSJ2yAe5mFqGE9rcWcONUAFyJLL5kcPjm7vY9joYXYUdZ9fGMKKN+sjnnqISDJCHFlusezIerNS0BjQkqPQ6ILVckDPwu2dp2dZTwB81ohvSrhXA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=U2QSBSVIqolQ4tkA45blV54QjexGt9vaDKz20UlP7dK3tnM0FbQRNyEHssmdVCHalW4K/6sKqv5K68VCmmuJT6uFuJHQK0vmlSIfk0Rkb+ZjOMfKqsVhnCsMJpuszxp9j9PGf+lkw1Ka9cY2zP7ZDsG8ecYSudkXzmNqMXi86zM= Received: by 10.64.21.6 with SMTP id 6mr5868101qbu.1184549480833; Sun, 15 Jul 2007 18:31:20 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Sun, 15 Jul 2007 18:31:20 -0700 (PDT) Message-ID: <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> Date: Sun, 15 Jul 2007 21:31:20 -0400 From: "David A. Bryan" To: "David Barrett" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <20070716012015.99E246F82AB@mail.sipeerior.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com> <20070716012015.99E246F82AB@mail.sipeerior.com> X-Google-Sender-Auth: d97f572f12a004b4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Um, I guess I wasn't clear. Sorry. That was precisely the point I was making, particularly in my second paragraph below (and did in the email response to Johnathan that started this thread) I was trying to say that while valid, Henning's point that the protocol won't be different if we pick a DHT is irrelevant to the argument about whether to choose a must implement or not. If we don't have at least one mandatory to implement, we will have islands of each vendor's device not working together, and worse, may be forced into using one specified by a player with large market share that might have nasty strings attached. So to again make my position clear: We should allow modular DHTs. We should specify one or a small number of must implement for compatibility. That said, I do agree with the point Henning made that if we picked only one DHT and didn't allow modularity (which I don't think anyone is really suggesting, anyway), it wouldn't really significantly simplify the protocol. I think Henning's argument had more to do with why we should allow modular DHTs than anything about if a mandatory is a good idea or not. David On 7/15/07, David Barrett wrote: > > -----Original Message----- > > From: David A. Bryan [mailto:dbryan@sipeerior.com] > > > > Agree that restricting to one DHT will not make the protocol > > substantially simpler (in both dSIP and RELOAD we had multiple DHTs, > > and other than using somewhat more generic labels for fields, I don't > > think picking a particular DHT would make that easier. > > I agree the messages on the wire are probably about the same irrespective of > the DHT algorithm. But would you agree that standardizing on a particular > algorithm would make things easier? > > For example, if I'm using Kademlia and you're using Chord -- even we're > using compatible packet formats -- won't that create a dysfunctional overlay > network? > > -david > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 15 21:38:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAFXg-0007K9-Uy; Sun, 15 Jul 2007 21:38:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAFXg-0007K4-92 for p2psip@ietf.org; Sun, 15 Jul 2007 21:38:28 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAFXR-0007DT-0u for p2psip@ietf.org; Sun, 15 Jul 2007 21:38:28 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6G1bQMh009120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Jul 2007 21:37:26 -0400 (EDT) In-Reply-To: <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com> References: <4697F02B.4030506@cisco.com> <4d4304a00707131516p12fedab1pc22124ce7879e20f@mail.gmail.com> <563F8B51-9F14-400C-9274-220672F8AD40@cs.columbia.edu> <24CCCC428EFEA2469BF046DB3C7A8D22AA9D47@namail5.corp.adobe.com> <642EF0D3-3597-498F-9BCB-AB5A745F0024@cs.columbia.edu> <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sun, 15 Jul 2007 21:37:23 -0400 To: "David A. Bryan" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > One way to deal with this is to have a separate document that defines "how to use P2PSIP protocol X for DHT Y". This will likely bias the implementor choice. I have to admit that I'm torn between several arguments on this. For once, my perception is that the difference in performance, once you subtract out the DHT-independent optimizations, isn't all that large, at least among the core set of DHTs discussed here (Chord, CAN, Kademlia and kin). I also suspect that implementing several of them isn't all that hard. Just like today's voice clients typically implement a handful of codecs, at least the non-encumbered ones, I'm guessing that almost all P2P clients will implement several of the well-known, non-encumbered DHTs, making the problem of interoperability far less significant. This doesn't guarantee interoperability, but anything short of prohibiting building clients that support other than the default set won't. As Jonathan pointed out, just defining a must-implement DHT doesn't help a whole lot as long as a group of clients can choose something else and thus lock out the plebes. > In some ways, that is my worry about not defining a must implement > DHT...it is pretty easy to use the protocols to encode any DHT one > likes, so if we don't define one, expect each and every vendor to use > a different, non-interoperable one (at least until market strength and > a patent from one of the big players forces a default implement > anyway, encumbered by a license fee at that point...) > > David > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 15 21:43:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAFcp-0003eq-N2; Sun, 15 Jul 2007 21:43:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAFco-0003eh-BI for p2psip@ietf.org; Sun, 15 Jul 2007 21:43:46 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAFcZ-0007IM-02 for p2psip@ietf.org; Sun, 15 Jul 2007 21:43:46 -0400 Received: from lappy ([75.7.13.129]) by quinthar.com for ; Sun, 15 Jul 2007 18:42:34 -0700 From: "David Barrett" To: "'David A. Bryan'" Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Sun, 15 Jul 2007 18:42:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfHSQTGefguwqKES1yk/ccGW/9bwgAAYeNA In-Reply-To: <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'Henry Sinnreich' , 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: David A. Bryan > Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > > Um, I guess I wasn't clear. Sorry. That was precisely the point I was > making, particularly in my second paragraph below (and did in the > email response to Johnathan that started this thread) Got it. > That said, I do agree with the point Henning made that if we picked > only one DHT and didn't allow modularity (which I don't think anyone > is really suggesting, anyway), it wouldn't really significantly > simplify the protocol. Well, I'd suggest that before we've done it once for real, we probably don't know enough to make smart modularity decisions. If we just picked one DHT and focused on nothing but that, we stand the highest chance of getting *something* working in short order for P2PSIP 1.0. Then I expect we'd be in a good position to make modularization decisions for P2PSIP 2.0. But regardless, I'm with you on the need for picking a baseline DHT and focusing in that -- I'm just a bit more aggressive on scope reductions. :) -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 15 22:16:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAG8N-0008Vj-Ky; Sun, 15 Jul 2007 22:16:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAG8M-0008Ve-Dk for p2psip@ietf.org; Sun, 15 Jul 2007 22:16:22 -0400 Received: from an-out-0708.google.com ([209.85.132.240]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAG8I-0003RD-61 for p2psip@ietf.org; Sun, 15 Jul 2007 22:16:22 -0400 Received: by an-out-0708.google.com with SMTP id c17so210027anc for ; Sun, 15 Jul 2007 19:16:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=VvqOJmEZi6mESbVEZlO3kIboNJw9m8sowbNlbxEdkntbStfrLRNz8xAIIHOMjbvDV93jihd+cMIpIS7p4I85bjfy9vJaMhSfI+x+gn1BPaYyUHydte2YfBc6ICu7j/G4aZMZzbBAYagwX0q7TxTc7bjKBFcDi1q4GQtamu4L8eA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=XOWQDmvr5e8Bq6zQdpMoKsJK/6ZO7f/fMoHOjL5DbW+yXN4SpTfLoQ4qvZLDwbRG1yHoKmfa54uePj7h1nG+rjkrxwJd4wl51XYq49NPRZWke1OZV/fIrZ3CLMKXgwa9fRZ8ThqVaOYFTahbCgOTZ/dhBU3S1Rr6cQkMRHz0P/0= Received: by 10.100.106.5 with SMTP id e5mr2066772anc.1184552177894; Sun, 15 Jul 2007 19:16:17 -0700 (PDT) Received: by 10.100.112.12 with HTTP; Sun, 15 Jul 2007 19:16:17 -0700 (PDT) Message-ID: <20d2bdfb0707151916p6e83bd31y8f34e2020fc564d6@mail.gmail.com> Date: Sun, 15 Jul 2007 22:16:17 -0400 From: "Bruce Lowekamp" To: "David Barrett" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> X-Google-Sender-Auth: bdbb31d8f3b366b0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 7/15/07, David Barrett wrote: > Well, I'd suggest that before we've done it once for real, we probably don't > know enough to make smart modularity decisions. If we just picked one DHT > and focused on nothing but that, we stand the highest chance of getting > *something* working in short order for P2PSIP 1.0. Then I expect we'd be in > a good position to make modularization decisions for P2PSIP 2.0. Nearly all of the current peer protocol proposals support pluggable DHTs. dSIP actually had two separate drafts to demonstrate how it could work. Marcia didn't have time to rewrite them for RELOAD, but essentially it's just a matter of providing attribute numbers for what were headers in dSIP. P2PP supports different DHTs and actually has tried to even support unstructured overlays. Given that there are specific, concrete proposals out already, do you have specific criticisms or concerns after reading the drafts? Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Jul 15 22:52:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAGhe-0007nC-I7; Sun, 15 Jul 2007 22:52:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAGhd-0007n7-5K for p2psip@ietf.org; Sun, 15 Jul 2007 22:52:49 -0400 Received: from nat1.alcatel-sbell.com.cn ([202.96.203.177] helo=mail.alcatel-sbell.com.cn) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAGhZ-0008UN-Su for p2psip@ietf.org; Sun, 15 Jul 2007 22:52:49 -0400 Received: from cnshgsbhs01.ad4.ad.alcatel.com (localhost [127.0.0.1]) by mail.alcatel-sbell.com.cn (8.13.8/8.13.8/Alcanet1.0) with ESMTP id l6G1jLel007403; Mon, 16 Jul 2007 09:45:21 +0800 Received: from CNSHGSMBS03.ad4.ad.alcatel.com ([172.24.146.173]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Jul 2007 09:48:24 +0800 Content-class: urn:content-classes:message Subject: RE: [P2PSIP] do we need a client protocol? MIME-Version: 1.0 Date: Mon, 16 Jul 2007 09:48:22 +0800 Message-ID: <1DB91DF937A4544C81E636468B91C21C864721@CNSHGSMBS03.ad4.ad.alcatel.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <039301c7c4ee$6397ecf0$5105a40a@china.huawei.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] do we need a client protocol? Thread-Index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQAAIh/D AACaerMAAXkVEgAAYmkvA= References: <1DB91DF937A4544C81E636468B91C21C863E5F@CNSHGSMBS03.ad4.ad.alcat el.com> <039301c7c4ee$6397ecf0$5105a40a@china.huawei.com> From: "HUANG Ping B" To: "Zheng Hewen" , "Michal Giermasinski" , , X-OriginalArrivalTime: 16 Jul 2007 01:48:24.0115 (UTC) FILETIME=[65683030:01C7C74B] X-imss-version: 2.047 X-imss-result: Passed X-imss-approveListMatch: *@alcatel-sbell.com.cn X-Spam-Score: 1.6 (+) X-Scan-Signature: 011fc67488a99a17f716be0c5cfa3a2d Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2045981106==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============2045981106== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C7C74B.64BE1287" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C74B.64BE1287 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7C74B.64BE1287" ------_=_NextPart_002_01C7C74B.64BE1287 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable hello Zheng "Our discussion focus is whether all peers in P2PSIP overlay must = recognize SIP", I have never said(once again) P2PSIP overlay must = recognize SIP, I just said Peers in P2PSIP overlay SHOULD recognize SIP. = I have already read those drafts before you and Marcin suggested me to = read them, any way, thanks your suggestions. in my opinion, P2PSIP is not equal to P2P. P2P is a big picture, = but P2PSIP is a small one. I think, we SHOULD not put all peers that may = be suit for P2P overlay into P2PSIP overlay.=20 in your reply :"the true and only cause is that we try to = provide a method to determine the correct destination for SIP = requests...... this is the current and only relation between SIP and = P2PSIP." I'm afraid that I can not agree with your opinions.in = "draft-ietf-p2psip-concepts-00", the definition of "P2PSIP" is below:=20 P2PSIP:=20 A suite of communications protocols related to the Session Initiation = Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., = Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, = =A1=B0SIP: Session Initiation Protocol,=A1=B1 June 2002.) = = that enable SIP to use peer-to-peer techniques for resolving the = targets of SIP requests, providing SIP message transport, and providing = other SIP-related functions. The exact contents of this protocol suite = are still under discussion, but is likely to include the P2PSIP Peer = Protocol and may include a P2PSIP Client Protocol (see definitions = below).=20 =20 if destination resolving is the only relationship between P2PSIP = and SIP, IMHO, P2PSIP SHALL not be called "P2PSIP". I think we should make several things clear: where, when and why P2PSIP is born? just noly because the P2PSIP can = find destination for SIP request? =20 =20 ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Friday, July 13, 2007 9:38 AM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org; = marcin.matuszewski@nokia.com Subject: RE: [P2PSIP] do we need a client protocol? Hi Huang =20 Your reply puzzled me. Our discussion focus is whether all peers in P2PSIP overlay must = recognize SIP. You think that all peers must recognize SIP messages, but = I think that some peers may not recognize SIP messages, do I = misunderstand? By the way, in detail, there are three modes compatible with the = P2PSIP WG charter. As you said, the first is SIP over P2P, P2P provides = transport service such as tunneling SIP; the second is P2P over SIP, SIP = is extended so that P2P is embedded in SIP messages; the last is that = P2P is independent of SIP and SIP is independent of P2P at the same = time, P2P only provides the service determining the correct destination = for SIP requests to SIP terminals, it is the simplest and clearest. I suggest that you might read these drafts as Marcin's advice. http://www.p2psip.org/drafts/draft-bryan-p2psip-requirements-00.txt http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt http://www.p2psip.org/drafts/draft-jennings-p2psip-asp-00.txt=20 =20 ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 22:27 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org; = marcin.matuszewski@nokia.com Subject: RE: [P2PSIP] do we need a client protocol? Hi Zheng and marcin I have never said that P2PSIP is IP or use SIP. as we know, there are = two mode in P2PSIP, one is SIP over P2P and the other is P2P over = SIP.SIP is just in application layer and P2P or P2PSIP are more like = transport layer. in SIP over P2P, SIP is just one of the protocols = interacting with P2P or P2PSIP overlay. in P2P over SIP, SIP is made = some extension. I have never said that P2PSIP peer protocol shall use = SIP, SIP is over P2PSIP! And as I said, peers "SHOULD" not "SHALL" recognize SIP. maybe you = "SHALL" read RFC2119 ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 5:33 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT = service but not recognize SIP messages should be admitted as one = member/peer of P2PSIP overlay, we do not have to update the device to = support SIP and then provide DHT service, the cost introduced due to the = update is unnecessary.=20 =20 =20 ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP = offers an alternative mechanism for determining the correct destination = for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of = cause, is you use another protocol, P2PSIP may be called another name, = such as P2PXXX. Peers in P2PSIP overlay are responsible not just for = location (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? = this name means that there is a relationship between P2PSIP and SIP, = maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. = then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize SIP = message. Ok, you can say that a tunnel protocol could be used to deliver = SIP protocol, this is a choice, but not good choice. if a tunnel = protocol is used, then SIP has nothing with P2P overlay, this tunnel = protocol could deliver any protocols besides SIP, then name "P2PSIP" = does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which = overlay users are identified and provides mechanisms for locating users = or resources within the P2PSIP overlay. P2PSIP clients differ from = P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers use the resolution services of the peers as an alternative to = the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP = requests. The working group's initial charter scope will be to produce = protocols to enable this alternate mechanism for RFC 3263 = functionality." =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP = is SIP, P2PSIP peer is P2PSIP peer, let them be. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. =20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could = be peers in P2PSIP overlay. peers in P2PSIP overlay are not equal to = peers in P2P overlay. when we discuss IMS, although legacy equipments = does not support SIP, but some AGWs do translation or agent for those = equipments. then, when we discuss P2PSIP, shall we involve all peers who = know SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, = and vice versa. and I think that Peers in P2PSIP overlay should have = some common base functionalitis such as SIP recognition. I think we = shall make P2PSIP more simple but not more complex. ________________________________ From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which = do not support SIP, such as some PCs, they can provide all required DHT = services, but there is only a pity that they can not recognize any SIP = message, maybe they think that the capability is unnecessary. In this = case, some client protocol is desirable. Certainly this protocol may be = the subset of general Peer Protocol if we regard those clients as Lame = Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. =20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= ------------------------------------------------------------ This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 ________________________________ From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known = for years it obviously will not be able to use a new one that will be = designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and = the peer in the overlay). The only issue is to create a proxy-like peer = that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, =09 A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. =09 =09 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo =09 =09 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com = -------------------------------------------------------------------------= ---------------------------------------------------=20 --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed = above. Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 =09 =09 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? =09 Folks, =09 Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: =09 - Limited battery in mobile devices, and=20 =09 - Other uses besides SIP. Business planning folks may not care about = the WG charter, but about the return on the investment. =09 Thanks, Henry =09 -----Original Message----- From: Dean Willis [mailto: dean.willis@softarmor.com = ] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 =09 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store = resources (not > typical for most current DHT algorithms) =09 Well, that certainly depends on the DHT algorithm involved. It = certainly seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. =09 > My concern all along has been that I don't understand why something = is=20 > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of = confusion. =09 A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 =09 > If we do go this way, there is one subtle point. If I join the = overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services =09 That's "offer no other services", since routing is itself a service.=20 =09 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) =09 I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. =09 I think we distinguish based on the service advertisements from the = peer.=20 =09 > If we are so opposed to client for confusion with SIP UAs, lets pick = a new > name, but why some flavor of peer when it does nothing remotely peer like? =09 Because in 15 minutes it might roam onto a WiFi net and therefore = change it service offering.=20 =09 -- Dean =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 =09 =09 =09 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip=20 =09 ------_=_NextPart_002_01C7C74B.64BE1287 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
hello Zheng
     "Our=20 discussion focus is whether all peers in P2PSIP overlay must recognize=20 SIP", I have never said(once again) = P2PSIP=20 overlay must recognize SIP, I=20 just said Peers in P2PSIP overlay SHOULD = recognize SIP. I have already read those drafts before = you and=20 Marcin suggested me to read them, any way, thanks your=20 suggestions.
        in = my opinion,=20 P2PSIP is not equal to P2P. P2P is a big picture, but P2PSIP is a = small=20 one. I think, we SHOULD not put all peers that may be suit for = P2P=20 overlay into P2PSIP overlay.
        in = your reply=20 :"the true and only cause is that we try to provide a method to = determine the=20 correct destination for SIP requests...... this is the current and only = relation=20 between SIP and P2PSIP."
    I'm = afraid that I=20 can not agree with your opinions.in = "draft-ietf-p2psip-concepts-00",=20 the definition of "P2PSIP" is = below:
P2PSIP:
A suite of communications protocols = related to=20 the Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., = Schulzrinne, H.,=20 Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and = E.=20 Schooler, =A1=B0SIP: Session Initiation Protocol,=A1=B1=20 June 2002.) that enable SIP to use = peer-to-peer=20 techniques for resolving the targets of SIP requests, providing SIP = message=20 transport, and providing other SIP-related functions. The exact = contents=20 of this protocol suite are still under discussion, but is likely to = include the=20 P2PSIP Peer Protocol and may include a P2PSIP Client Protocol (see = definitions=20 below).
 
     if=20 destination resolving is the only relationship between P2PSIP  = and=20 SIP, IMHO, P2PSIP SHALL not be called = "P2PSIP".
    I think we should make several things=20 clear:
   where, when and why = P2PSIP is=20 born? just noly because the P2PSIP can find destination for SIP=20 request?
 
        =20

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Friday, July 13, 2007 9:38 AM
To: HUANG Ping = B;=20 'Michal Giermasinski'; p2psip@ietf.org;=20 marcin.matuszewski@nokia.com
Subject: RE: [P2PSIP] do we need = a client=20 protocol?

Hi Huang
 
    Your reply puzzled=20 me.
    Our discussion focus is = whether all=20 peers in P2PSIP overlay must recognize SIP. You think that all peers = must=20 recognize SIP messages, but I think that some peers may not recognize = SIP=20 messages, do I misunderstand?
    By the way, in detail, = there are=20 three modes compatible with the P2PSIP WG charter. As=20 you said, the first is = SIP=20 over P2P, P2P provides transport service such as = tunneling SIP;=20 the second is P2P over SIP, SIP is extended so that P2P is embedded = in SIP=20 messages; the last is that P2P is independent of SIP and SIP is = independent=20 of P2P at the same time, P2P only provides the service determining = the=20 correct destination for SIP requests to SIP terminals, it is the = simplest and=20 clearest.
    I suggest that you might = read these=20 drafts as Marcin's advice.
   http://www.p2psip.org/drafts/draft-bryan-p2psip-requirements-00.txt
  =20 http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt=
  =20 ht= tp://www.p2psip.org/drafts/draft-jennings-p2psip-asp-00.txt=20
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 22:27
To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org;=20 marcin.matuszewski@nokia.com
Subject: RE: [P2PSIP] do we need = a client=20 protocol?

Hi Zheng and marcin
   I have never said that P2PSIP is = IP or use=20 SIP. as we know, there are two mode in P2PSIP, one is SIP over P2P and = the other=20 is P2P over SIP.SIP is just in application layer and P2P or P2PSIP are = more like=20 transport layer. in SIP over P2P, SIP is just one of the protocols = interacting=20 with P2P or P2PSIP overlay. in P2P over SIP, SIP is made some extension. = I have=20 never said that P2PSIP peer protocol shall use SIP, SIP is over=20 P2PSIP!
   And as I said, peers "SHOULD" = not "SHALL"=20 recognize SIP. maybe you "SHALL" read RFC2119

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 5:33 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
   One supplement, = FYI.
   In the future P2PSIP = deployment,=20 one device that can provide DHT service but not recognize SIP messages = should be=20 admitted as one member/peer of P2PSIP overlay, we do not have to update = the=20 device to support SIP and then provide DHT service, the cost = introduced due=20 to the update is unnecessary. 
 
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 16:57
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

I have never said that P2PSIP = is equal to=20 SIP, P2PSIP is just an overlay as an alternative to the SIP discovery = process of=20 RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct=20 destination for SIP requests. SIP is session layer protocol, P2PSIP is = under=20 SIP. of cause, is you use another protocol, P2PSIP may be called another = name,=20 such as P2PXXX. Peers in P2PSIP = overlay are=20 responsible not just for location (done by P2PSIP protocol). Why we = called=20 P2PSIP as "P2PSIP"?  this name means that there is a relationship = between=20 P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP = should be=20 used. then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize = SIP=20 message. Ok, you can say that a tunnel protocol could be used to deliver = SIP=20 protocol, this is a choice, but not good choice. if a tunnel protocol is = used,=20 then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any=20 protocols besides SIP, then name "P2PSIP" does not make=20 sense.
when peers in P2PSIP = overlay do not=20 recognize SIP message, then let them out of = overlay.

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
  If I do not misunderstand, P2PSIP is not = equal to=20 SIP.
  Essentially in P2PSIP overlay, P2PSIP = peers have=20 nothing with SIP. Why must we bind SIP to P2PSIP peers?=20
 
  Here is the description about P2PSIP = peers in WG=20 charter, FYI.
  "The work focuses on collections of = nodes called=20 "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed = namespace in which overlay users are identified and provides mechanisms = for=20 locating users or resources within the P2PSIP overlay. P2PSIP clients = differ=20 from P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers=20 use the resolution services of the peers as an alternative to the SIP = discovery=20 process of RFC 3263. In this way, P2PSIP offers an alternative mechanism = for=20 determining the correct destination for SIP requests. The working = group's=20 initial charter scope will be to produce protocols to enable this = alternate=20 mechanism for RFC 3263 functionality."
 
  Nothing says that P2PSIP = peers must=20 support SIP or have anything with SIP.
  From the charter, functionality of = P2PSIP=20 peers is so clear and simple, why do we make it complicated? I = think we can=20 do it simpler, SIP is SIP, P2PSIP peer is P2PSIP = peer, let=20 them be.
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = 3Dhuawei_logo=20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 10:22
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi all
    P2P is great topic, but = P2PSIP is the=20 subset or certain instance of P2P. when we discuss P2PSIP, we shall not = involve=20 all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are=20 not equal to peers in P2P overlay. when we discuss IMS, although legacy=20 equipments does not support SIP, but some AGWs do translation or agent = for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers who = know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some common = base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more simple=20 but not more complex.
From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,
 
    Please let me describe the = case in=20 detail.
    In the case, all clients support SIP, but = some=20 peers in the overlay network do not support SIP and some support SIP. = For those=20 peers which do not support SIP, such as some PCs, they can provide all = required=20 DHT services, but there is only a pity that they can not recognize any = SIP=20 message, maybe they think that the capability is unnecessary. In this = case, some=20 client protocol is desirable. Certainly this protocol may be the subset = of=20 general Peer Protocol if we regard those clients as Lame Peers and = regard those=20 peers as Pure Peers who only provide required DHT=20 services.
    IMHO, this case does not care those = clients not=20 supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. 3Dhuawei_logo


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: = [P2PSIP]=20 do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. = If a=20 client application is not able to use SIP protocol that is well known = for years=20 it obviously will not be able to use a new one that will be designed = especially=20 for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing = is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that will = be able=20 to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do not = support=20 SIP, those peers are only responsible to
provide distributed = storage,=20 location and transport services for information about SIP, but those = peers do=20 not recognize any
SIP messages at all.
  In this case, = how to=20 maintain the relation between clients (UA) and the hosting peer(s)? = One client=20 protocol is desirable
at this time.


Zheng = Hewen
HUAWEI=20 TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong=20 Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel:=20 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
--------------------= -------------------------------------------------------------------------= -------------------------------=20
---------
This e-mail and its attachments contain confidential=20 information from HUAWEI, which
is intended only for the person or = entity=20 whose address is listed above. Any use of the
information contained = herein=20 in any way (including, but not limited to, total or partial =
disclosure,=20 reproduction, or dissemination) by persons other than the=20 intended
recipient(s) is prohibited. If you receive this e-mail in = error,=20 please notify the sender by
phone or email immediately and delete = it!=20


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26?=20 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP = Mailing=20 List; Philip Matthews
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives for = the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks, = Henry

-----Original=20 Message-----
From: Dean Willis [mailto:=20 dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better than=20 active/passive) entities
have a
> Peer-ID? In otherwords, are = they=20 part of the overlay at all? If so,
for
> most
> DHTs, = how do=20 we allow you to be in the overlay and not store = resources
(not
>=20 typical for most current DHT algorithms)

Well, that certainly = depends=20 on the DHT algorithm involved. It certainly seems that a peer that = moves=20 between contributing
and non-contributing might HAVE a peer ID, = but=20 whether it chooses to insert itself into the DHT "right now" might=20 determine
whether it is contributing "right now"
or = not.

> My=20 concern all along has been that I don't understand why something is =
> a=20 peer if it isn't doing anything other than talking to someone = and
>=20 making requests, hence why I supported client in the first=20 place.
>  I fail to see how something that isn't = contributing=20 anything, and
> instead talks to a peer to get resources, is in = any way=20 a peer. It
> seems completely not in keeping with the idea of = P2P. I=20 also worry it
> is likely to be very confusing since we've been = using=20 the other
> terminology for over a year now. Just looks like a = souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection and=20 wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality make=20 it two different nodes?

> If we do go this way, there is = one subtle=20 point. If I join the overlay
but
> don't happen to offer any = services=20 (other than maybe
storage...depending on
> how we definie it, = that=20 might or might not be mandatory), would I be
> contributing? If = joining=20 the overlay (in the sense that we have a
PeerID
> and
> = we=20 route traffic) doesn't require me to store, I could offer=20 no
services

That's "offer no other services", since routing = is=20 itself a service.

> and
> still be a peer. How do we=20 distinguish between this case and a
> "non-contributing peer" = who isn't=20 even part of the overlay (i.e., no
> Peer-ID)

I think = there's a=20 range of "contributing" in play. For most DHT models, a minimally = contributing=20 node will route a request
it receives. It might ask nicely = (perhaps a=20 q-value mechanism) to not have to route requests, but would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam onto = a WiFi=20 net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

_______________________________________________
P2PSIP = mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

------_=_NextPart_002_01C7C74B.64BE1287-- ------_=_NextPart_001_01C7C74B.64BE1287 Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <653241504@13072007-26FC> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C74B.64BE1287 Content-Type: image/jpeg; name="outlook_huawei_logo_en.jpg" Content-Transfer-Encoding: base64 Content-ID: <653241504@13072007-2703> Content-Description: outlook_huawei_logo_en.jpg Content-Location: outlook_huawei_logo_en-1.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= ------_=_NextPart_001_01C7C74B.64BE1287-- --===============2045981106== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2045981106==-- From p2psip-bounces@ietf.org Sun Jul 15 23:51:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAHcK-0007CM-OR; Sun, 15 Jul 2007 23:51:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAHcJ-0006st-18 for p2psip@ietf.org; Sun, 15 Jul 2007 23:51:23 -0400 Received: from mta3.prod1.dngr.net ([216.220.209.222]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAHbx-0000zc-PN for p2psip@ietf.org; Sun, 15 Jul 2007 23:51:22 -0400 Received: from mfe5.prod.danger.com (unknown [10.253.33.100]) by px04.prod1.dngr.org (Postfix) with ESMTP id 28B6510F464B; Sun, 15 Jul 2007 20:50:37 -0700 (PDT) Received: from [10.253.33.100] (HELO localhost.localdomain) by mfe5.prod.danger.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 718640207; Sun, 15 Jul 2007 20:50:37 -0700 Date: Sun, 15 Jul 2007 20:50:32 -0700 Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion X-Mailer: Danger Service X-Danger-Send-Id: AABJpUaa6w0AAYa+ Content-Transfer-Encoding: 7bit In-Reply-To: <20d2bdfb0707151916p6e83bd31y8f34e2020fc564d6@mail.gmail.com> Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Bruce Lowekamp Mime-Version: 1.0 References: <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> <20d2bdfb0707151916p6e83bd31y8f34e2020fc564d6@mail.gmail.com> From: David Barrett Message-Id: <1184557836.A23680A@fd4.dngr.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: David Barrett List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org What I read in the P2PSIP charter is we commit to one DHT while leaving the option open for more. I interpret that to mean we pick one DHT now for certain, and at some undefined point in the future we determine how to generalize that. In other words, I feel a modular DHT system isn't strictly required at this time, and anything not strictly required shouldn't be discussed. So I've got nothing against the drafts. I just think they solve a problem we don't need to solve today, and thus shouldn't be. Perhaps it would help if we began talking in terms of versions: I think P2PSIP v1.0 should take an absolute minimalist interpretation of the fewest, most crucial features necessary to have something that works in the most constrained possible way. Everything else -- even discussion about anything else -- should be deferred until v1.0 is done, and modular DHTs fits in that category for me. Do you agree we should take a minimalist, iterative interpretation of scope? Do you feel modular DHTs absolutely must be in the first iteration? -david On Sun, 15 Jul 2007 8:00 pm, Bruce Lowekamp wrote: > On 7/15/07, David Barrett wrote: >> Well, I'd suggest that before we've done it once for real, we probably >> don't >> know enough to make smart modularity decisions. If we just picked one >> DHT >> and focused on nothing but that, we stand the highest chance of getting >> *something* working in short order for P2PSIP 1.0. Then I expect we'd >> be in >> a good position to make modularization decisions for P2PSIP 2.0. > > Nearly all of the current peer protocol proposals support pluggable > DHTs. dSIP actually had two separate drafts to demonstrate how it > could work. Marcia didn't have time to rewrite them for RELOAD, but > essentially it's just a matter of providing attribute numbers for > what were headers in dSIP. P2PP supports different DHTs and actually > has tried to even support unstructured overlays. > > Given that there are specific, concrete proposals out already, do you > have specific criticisms or concerns after reading the drafts? > > Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 01:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAIoB-0000Rn-NK; Mon, 16 Jul 2007 01:07:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAIoA-0000LW-46 for p2psip@ietf.org; Mon, 16 Jul 2007 01:07:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAIo6-0006ed-Oe for p2psip@ietf.org; Mon, 16 Jul 2007 01:07:42 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6G57ZDI022073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 15 Jul 2007 22:07:35 -0700 Received: from [76.102.92.155] (vpn-10-50-16-13.qualcomm.com [10.50.16.13]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6G57Wf4027399; Sun, 15 Jul 2007 22:07:33 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> References: <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com> <20070716012015.99E246F82AB@mail.sipeerior.com> <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> Date: Sun, 15 Jul 2007 22:07:31 -0700 To: "David A. Bryan" , "David Barrett" From: Ted Hardie Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At 9:31 PM -0400 7/15/07, David A. Bryan wrote: >That said, I do agree with the point Henning made that if we picked >only one DHT and didn't allow modularity (which I don't think anyone >is really suggesting, anyway) I'm really glad to see this, as your earlier statements looked like they were saying just that. Designing for one to the exclusion of others certainly sounded like that to my ears. The point I think that is missing here in much of this discussion is that the agility-with-a-default means, in essence, that the default will be around forever. Some set of overlays will be created with it and some set of devices/programs will be written such that only the default is supported. The protocol is agile, but the programs aren't, and the justification in this case is the standard. Those of us coming from other areas have seen a lot of cruft piled on cruft to deal with installed base in those cases. Coming from that background, this decision sounds like a very short-term win, with a long term cruft penalty that will keep biting for a long, long time. Yes, the vendor lock-in problem is real (where Vendor A does Chord and vendor B does Kademlia), but unless Vendor A pics a DHT which is not available to B for implementation, the answer to that emerges quickly. B codes Chord and eliminates A's lock-in; A must either then code Kademlia or lose clients to B. I think that the working group should consider language that says "for interop testing required to reach Draft, the group will use DHT X". Anybody who wants to play right now will implement X. That's a useful thing to do, without any lock-in at the protocol level that will haunt us later. Still the weekend, so no new cents have come in. Please accept my, regards, Ted Hardie _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 01:11:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAIrx-0003Rt-RU; Mon, 16 Jul 2007 01:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAIrv-0003ON-KL for p2psip@ietf.org; Mon, 16 Jul 2007 01:11:35 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAIrr-0006l3-5Z for p2psip@ietf.org; Mon, 16 Jul 2007 01:11:35 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6G5BRjG022707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 15 Jul 2007 22:11:28 -0700 Received: from [76.102.92.155] (vpn-10-50-16-13.qualcomm.com [10.50.16.13]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6G5BLK4007282; Sun, 15 Jul 2007 22:11:25 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com> <20070716012015.99E246F82AB@mail.sipeerior.com> <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> Date: Sun, 15 Jul 2007 22:11:19 -0700 To: "David A. Bryan" , "David Barrett" From: Ted Hardie Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Just realized that I probably had a confusion of Davids in the message below; my apologies for attributing some of David Barrett's sentiments to David Bryan. Ted At 10:07 PM -0700 7/15/07, Ted Hardie wrote: >At 9:31 PM -0400 7/15/07, David A. Bryan wrote: >>That said, I do agree with the point Henning made that if we picked >>only one DHT and didn't allow modularity (which I don't think anyone >>is really suggesting, anyway) > >I'm really glad to see this, as your earlier statements looked like >they were saying just that. Designing for one to the exclusion of >others certainly sounded like that to my ears. > >The point I think that is missing here in much of this discussion is that >the agility-with-a-default means, in essence, that the default will be >around forever. Some set of overlays will be created with it and some >set of devices/programs will be written such that only the default is >supported. The protocol is agile, but the programs aren't, and the justification >in this case is the standard. Those of us coming from other areas have >seen a lot of cruft piled on cruft to deal with installed base in those cases. >Coming from that background, this decision sounds like a very short-term >win, with a long term cruft penalty that will keep biting for a long, long >time. > >Yes, the vendor lock-in problem is real (where Vendor A does Chord and vendor B does Kademlia), but unless Vendor A pics a DHT which is not available to B for >implementation, the answer to that emerges quickly. B codes Chord and >eliminates A's lock-in; A must either then code Kademlia or lose clients to B. > >I think that the working group should consider language that says "for interop >testing required to reach Draft, the group will use DHT X". Anybody who wants >to play right now will implement X. That's a useful thing to do, without any >lock-in at the protocol level that will haunt us later. > >Still the weekend, so no new cents have come in. Please accept my, > regards, > Ted Hardie > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 03:57:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IALSf-0005fp-Ca; Mon, 16 Jul 2007 03:57:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IALSd-0005bq-C5 for p2psip@ietf.org; Mon, 16 Jul 2007 03:57:39 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IALSM-0005dK-56 for p2psip@ietf.org; Mon, 16 Jul 2007 03:57:39 -0400 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 <0JL9005JU22J3L@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 10:11:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL9008NP22CP4@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 10:11:07 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL9000L42272E@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 10:11:00 +0800 (CST) Date: Mon, 16 Jul 2007 10:10:55 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] do we need a client protocol? In-reply-to: <1DB91DF937A4544C81E636468B91C21C864721@CNSHGSMBS03.ad4.ad.alcatel.com> To: 'HUANG Ping B' , 'Michal Giermasinski' , p2psip@ietf.org, marcin.matuszewski@nokia.com Message-id: <00cc01c7c74e$8b0055e0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfEArudCMm2duX/SymVkGs47R709QAH5t6AAAHCSMAAB5ky4AAFqQhQAAIh/DAACaerMAAXkVEgAAYmkvAAkhnkAA== X-Spam-Score: 0.6 (/) X-Scan-Signature: b9beb0202bf83859e84cb11140b6be91 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1093750521==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1093750521== Content-type: multipart/related; boundary="Boundary_(ID_CjozlPVJjhbmx2neTst0vQ)" This is a multi-part message in MIME format. --Boundary_(ID_CjozlPVJjhbmx2neTst0vQ) Content-type: multipart/alternative; boundary="Boundary_(ID_YzVlOTZJRtMZYRsOUPTVJA)" --Boundary_(ID_YzVlOTZJRtMZYRsOUPTVJA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Huang, =20 Surely, as you said, draft-ietf-p2psip-concepts-00 defines P2PSIP as = below "A suite of communications protocols related to the Session Initiation Protocol (SIP) [RFC3261] that enable SIP to = use peer-to-peer techniques for resolving the targets of SIP requests, providing SIP message transport, and providing other = SIP-related functions." Its scope is bigger than current WG charter's initial scope as described in = http://www.ietf.org/html.charters/p2psip-charter.html, but it does not influence my viewpoint. P2PSIP uses ***peer-to-peer techniques*** for resolving the targets = of SIP requests, providing SIP message transport, and providing other SIP-related functions, so it is called P2PSIP. In = this definition, P2P is basic technology, and SIP is provided as application service such as STUN service. Essentially, = services are independent of P2PSIP peers, vice versa. =20 All guys, please forgive my repeat here: Let's end this discussion about whether one client protocol is = desirable using draft-ietf-p2psip-concepts-00's description as below: "If the P2PSIP model also contains clients, then a protocol is = needed for client - peer communication." (Section 2.4 Relationship of Peer and Client Protocols) "Since P2PSIP is about peer-to-peer networks for real-time = communication, it is expected that most (if not all) peers and clients will be coupled with SIP entities. ... However, there is no = hard requirement that every P2PSIP node (peer or client) be coupled to a SIP entity, and some proposed architectures = include peer nodes that have no SIP function whatsoever. " (Section 2.5, Relationship Between P2PSIP and SIP) You can get detailed info from draft-ietf-p2psip-concepts-00. =20 It is my pleasure to discuss with you. =20 Best regards, Hewen _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C216=C8=D5 9:48 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org; = marcin.matuszewski@nokia.com Subject: RE: [P2PSIP] do we need a client protocol? hello Zheng "Our discussion focus is whether all peers in P2PSIP overlay must = recognize SIP", I have never said(once again) P2PSIP overlay must recognize SIP, I just said Peers in P2PSIP overlay SHOULD = recognize SIP. I have already read those drafts before you and Marcin suggested me to read them, any way, thanks your = suggestions. in my opinion, P2PSIP is not equal to P2P. P2P is a big picture, = but P2PSIP is a small one. I think, we SHOULD not put all peers that may be suit for P2P overlay into P2PSIP overlay.=20 in your reply :"the true and only cause is that we try to = provide a method to determine the correct destination for SIP requests...... this is the current and only relation between SIP and = P2PSIP." I'm afraid that I can not agree with your opinions.in = "draft-ietf-p2psip-concepts-00", the definition of "P2PSIP" is below:=20 P2PSIP:=20 A suite of communications protocols related to the Session Initiation = Protocol (SIP) = [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and = E. Schooler, =A1=B0SIP: Session Initiation Protocol,=A1=B1 June 2002.) that enable SIP to use peer-to-peer techniques for resolving = the targets of SIP requests, providing SIP message transport, and providing other SIP-related functions. The exact contents = of this protocol suite are still under discussion, but is likely to include the P2PSIP Peer Protocol and may include a = P2PSIP Client Protocol (see definitions below).=20 =20 if destination resolving is the only relationship between P2PSIP = and SIP, IMHO, P2PSIP SHALL not be called "P2PSIP". I think we should make several things clear: where, when and why P2PSIP is born? just noly because the P2PSIP can = find destination for SIP request? =20 =20 _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Friday, July 13, 2007 9:38 AM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org; = marcin.matuszewski@nokia.com Subject: RE: [P2PSIP] do we need a client protocol? Hi Huang =20 Your reply puzzled me. Our discussion focus is whether all peers in P2PSIP overlay must = recognize SIP. You think that all peers must recognize SIP messages, but I think that some peers may not recognize SIP = messages, do I misunderstand? By the way, in detail, there are three modes compatible with the = P2PSIP WG charter. As you said, the first is SIP over P2P, P2P provides transport service such as tunneling SIP; the second is = P2P over SIP, SIP is extended so that P2P is embedded in SIP messages; the last is that P2P is independent of SIP and = SIP is independent of P2P at the same time, P2P only provides the service determining the correct destination for SIP = requests to SIP terminals, it is the simplest and clearest. I suggest that you might read these drafts as Marcin's advice. http://www.p2psip.org/drafts/draft-bryan-p2psip-requirements-00.txt http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt http://www.p2psip.org/drafts/draft-jennings-p2psip-asp-00.txt=20 =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 22:27 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org; = marcin.matuszewski@nokia.com Subject: RE: [P2PSIP] do we need a client protocol? Hi Zheng and marcin I have never said that P2PSIP is IP or use SIP. as we know, there are = two mode in P2PSIP, one is SIP over P2P and the other is P2P over SIP.SIP is just in application layer and P2P or P2PSIP = are more like transport layer. in SIP over P2P, SIP is just one of the protocols interacting with P2P or P2PSIP overlay. in = P2P over SIP, SIP is made some extension. I have never said that P2PSIP peer protocol shall use SIP, SIP is over P2PSIP! And as I said, peers "SHOULD" not "SHALL" recognize SIP. maybe you = "SHALL" read RFC2119 _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 5:33 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT = service but not recognize SIP messages should be admitted as one member/peer of P2PSIP overlay, we do not have to update = the device to support SIP and then provide DHT service, the cost introduced due to the update is unnecessary.=20 =20 =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct destination for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of cause, is you use another = protocol, P2PSIP may be called another name, such as P2PXXX. Peers in P2PSIP overlay are responsible not just for location = (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? this name means that there is a relationship between P2PSIP = and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. then Peers in P2PSIP overlay( not P2PXXX = overlay) should recognize SIP message. Ok, you can say that a tunnel protocol could be used to deliver SIP protocol, this is a = choice, but not good choice. if a tunnel protocol is used, then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any protocols besides SIP, then name "P2PSIP" does not make sense. when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms = for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they = do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the = resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope = will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality." =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some = AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or = not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should = have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more = complex. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide = all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the = capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of = general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT = services. IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it! =20 _____ =20 From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new = one that will be designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is = to create a proxy-like peer that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?" let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and=20 - Other uses besides SIP. Business planning folks may not care about the = WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: = dean.willis@softarmor.com] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly = seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is = > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service.=20 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the = peer.=20 > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change = it service offering.=20 -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 --Boundary_(ID_YzVlOTZJRtMZYRsOUPTVJA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Hi Huang,
 
    Surely, as you said,=20 draft-ietf-p2psip-concepts-00 defines P2PSIP as below "A suite of = communications=20 protocols related to the Session Initiation Protocol (SIP) [RFC3261] = that enable=20 SIP to use peer-to-peer techniques for resolving the targets of SIP = requests,=20 providing SIP message transport, and providing other SIP-related = functions." Its=20 scope is bigger than current WG charter's initial scope as described in = http://www= .ietf.org/html.charters/p2psip-charter.html,=20 but it does not influence my viewpoint.
     P2PSIP uses = ***peer-to-peer=20 techniques*** for resolving the targets of SIP requests, providing SIP = message=20 transport, and providing other SIP-related functions, so it is called = P2PSIP. In=20 this definition, P2P is basic technology, and SIP is provided as = application=20 service such as STUN service. Essentially, services are = independent of=20 P2PSIP peers, vice versa.
 
     All guys, please = forgive my=20 repeat here:
    Let's end this discussion = about=20 whether one client protocol is desirable using = draft-ietf-p2psip-concepts-00's=20 description as below:
    "If the P2PSIP model also = contains=20 clients, then a protocol is needed for client - peer communication." = (Section=20 2.4 Relationship of Peer and Client Protocols)
    = "Since=20 P2PSIP is about peer-to-peer networks for real-time communication, it is = expected that most (if not all) peers and clients will be coupled with = SIP=20 entities. ... However, there is no hard requirement that every P2PSIP = node (peer=20 or client) be coupled to a SIP entity, and some proposed architectures = include=20 peer nodes that have no SIP function whatsoever." (Section 2.5, = Relationship=20 Between P2PSIP and SIP)
    You can get detailed info = from=20 draft-ietf-p2psip-concepts-00.
    =
    It=20 is my pleasure to discuss with you.
 
Best regards,
Hewen

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C216=C8=D5=20 9:48
To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org;=20 marcin.matuszewski@nokia.com
Subject: RE: [P2PSIP] do we need = a client=20 protocol?

hello Zheng
     "Our=20 discussion focus is whether all peers in P2PSIP overlay must recognize=20 SIP", I have never said(once again) = P2PSIP=20 overlay must recognize SIP, I=20 just said Peers in P2PSIP overlay SHOULD = recognize SIP. I have already read those drafts before = you and=20 Marcin suggested me to read them, any way, thanks your=20 suggestions.
        in = my opinion,=20 P2PSIP is not equal to P2P. P2P is a big picture, but P2PSIP is a = small=20 one. I think, we SHOULD not put all peers that may be suit for = P2P=20 overlay into P2PSIP overlay.
        in = your reply=20 :"the true and only cause is that we try to provide a method to = determine the=20 correct destination for SIP requests...... this is the current and only = relation=20 between SIP and P2PSIP."
    I'm = afraid that I=20 can not agree with your opinions.in = "draft-ietf-p2psip-concepts-00",=20 the definition of "P2PSIP" is = below:=20
P2PSIP:
A suite of communications protocols = related to=20 the Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., = Schulzrinne, H.,=20 Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and = E.=20 Schooler, =A1=B0SIP: Session Initiation Protocol,=A1=B1=20 June 2002.) that enable SIP to use = peer-to-peer=20 techniques for resolving the targets of SIP requests, providing SIP = message=20 transport, and providing other SIP-related functions. The exact = contents=20 of this protocol suite are still under discussion, but is likely to = include the=20 P2PSIP Peer Protocol and may include a P2PSIP Client Protocol (see = definitions=20 below).
 
     if=20 destination resolving is the only relationship between P2PSIP  = and=20 SIP, IMHO, P2PSIP SHALL not be called = "P2PSIP".
    I think we should make several things=20 clear:
   where, when and why = P2PSIP is=20 born? just noly because the P2PSIP can find destination for SIP=20 request?
 
        =20

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Friday, July 13, 2007 9:38 AM
To: HUANG Ping = B;=20 'Michal Giermasinski'; p2psip@ietf.org;=20 marcin.matuszewski@nokia.com
Subject: RE: [P2PSIP] do we need = a client=20 protocol?

Hi Huang
 
    Your reply puzzled=20 me.
    Our discussion focus is = whether all=20 peers in P2PSIP overlay must recognize SIP. You think that all peers = must=20 recognize SIP messages, but I think that some peers may not recognize = SIP=20 messages, do I misunderstand?
    By the way, in detail, = there are=20 three modes compatible with the P2PSIP WG charter. As=20 you said, the first is = SIP=20 over P2P, P2P provides transport service such as = tunneling SIP;=20 the second is P2P over SIP, SIP is extended so that P2P is embedded = in SIP=20 messages; the last is that P2P is independent of SIP and SIP is = independent=20 of P2P at the same time, P2P only provides the service determining = the=20 correct destination for SIP requests to SIP terminals, it is the = simplest and=20 clearest.
    I suggest that you might = read these=20 drafts as Marcin's advice.
   http://www.p2psip.org/drafts/draft-bryan-p2psip-requirements-00.txt
  =20 http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-00.txt=
  =20 ht= tp://www.p2psip.org/drafts/draft-jennings-p2psip-asp-00.txt=20
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 22:27
To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org;=20 marcin.matuszewski@nokia.com
Subject: RE: [P2PSIP] do we need = a client=20 protocol?

Hi Zheng and marcin
   I have never said that P2PSIP is = IP or use=20 SIP. as we know, there are two mode in P2PSIP, one is SIP over P2P and = the other=20 is P2P over SIP.SIP is just in application layer and P2P or P2PSIP are = more like=20 transport layer. in SIP over P2P, SIP is just one of the protocols = interacting=20 with P2P or P2PSIP overlay. in P2P over SIP, SIP is made some extension. = I have=20 never said that P2PSIP peer protocol shall use SIP, SIP is over=20 P2PSIP!
   And as I said, peers "SHOULD" = not "SHALL"=20 recognize SIP. maybe you "SHALL" read RFC2119

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 5:33 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
   One supplement, = FYI.
   In the future P2PSIP = deployment,=20 one device that can provide DHT service but not recognize SIP messages = should be=20 admitted as one member/peer of P2PSIP overlay, we do not have to update = the=20 device to support SIP and then provide DHT service, the cost = introduced due=20 to the update is unnecessary. 
 
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 16:57
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

I have never said that P2PSIP = is equal to=20 SIP, P2PSIP is just an overlay as an alternative to the SIP discovery = process of=20 RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct=20 destination for SIP requests. SIP is session layer protocol, P2PSIP is = under=20 SIP. of cause, is you use another protocol, P2PSIP may be called another = name,=20 such as P2PXXX. Peers in P2PSIP = overlay are=20 responsible not just for location (done by P2PSIP protocol). Why we = called=20 P2PSIP as "P2PSIP"?  this name means that there is a relationship = between=20 P2PSIP and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP = should be=20 used. then Peers in P2PSIP overlay( not P2PXXX overlay) should recognize = SIP=20 message. Ok, you can say that a tunnel protocol could be used to deliver = SIP=20 protocol, this is a choice, but not good choice. if a tunnel protocol is = used,=20 then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any=20 protocols besides SIP, then name "P2PSIP" does not make=20 sense.
when peers in P2PSIP = overlay do not=20 recognize SIP message, then let them out of = overlay.

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] = do we=20 need a client protocol?

Hi,
 
  If I do not misunderstand, P2PSIP is not = equal to=20 SIP.
  Essentially in P2PSIP overlay, P2PSIP = peers have=20 nothing with SIP. Why must we bind SIP to P2PSIP peers?=20
 
  Here is the description about P2PSIP = peers in WG=20 charter, FYI.
  "The work focuses on collections of = nodes called=20 "P2PSIP peers" and "P2PSIP clients". P2PSIP peers manifest a distributed = namespace in which overlay users are identified and provides mechanisms = for=20 locating users or resources within the P2PSIP overlay. P2PSIP clients = differ=20 from P2PSIP peers primarily in that they do not store information in the = overlay, but only use it to locate users and resources. P2PSIP clients = and peers=20 use the resolution services of the peers as an alternative to the SIP = discovery=20 process of RFC 3263. In this way, P2PSIP offers an alternative mechanism = for=20 determining the correct destination for SIP requests. The working = group's=20 initial charter scope will be to produce protocols to enable this = alternate=20 mechanism for RFC 3263 functionality."
 
  Nothing says that P2PSIP = peers must=20 support SIP or have anything with SIP.
  From the charter, functionality of = P2PSIP=20 peers is so clear and simple, why do we make it complicated? I = think we can=20 do it simpler, SIP is SIP, P2PSIP peer is P2PSIP = peer, let=20 them be.
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = 3Dhuawei_logo=20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: HUANG Ping B=20 [mailto:Ping.b.Huang@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 10:22
To: Zheng Hewen; Michal Giermasinski;=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Hi all
    P2P is great topic, but = P2PSIP is the=20 subset or certain instance of P2P. when we discuss P2PSIP, we shall not = involve=20 all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are=20 not equal to peers in P2P overlay. when we discuss IMS, although legacy=20 equipments does not support SIP, but some AGWs do translation or agent = for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers who = know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some common = base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more simple=20 but not more complex.
From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Hi,
 
    Please let me describe the = case in=20 detail.
    In the case, all clients support SIP, but = some=20 peers in the overlay network do not support SIP and some support SIP. = For those=20 peers which do not support SIP, such as some PCs, they can provide all = required=20 DHT services, but there is only a pity that they can not recognize any = SIP=20 message, maybe they think that the capability is unnecessary. In this = case, some=20 client protocol is desirable. Certainly this protocol may be the subset = of=20 general Peer Protocol if we regard those clients as Lame Peers and = regard those=20 peers as Pure Peers who only provide required DHT=20 services.
    IMHO, this case does not care those = clients not=20 supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. 3Dhuawei_logo


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax: = 025-84565354
Mobile:=20 13611508264
E-mail: = hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------
= This=20 e-mail and its attachments contain confidential information from HUAWEI, = which=20
is intended only for the person or entity whose address is listed = above. Any=20 use of the
information contained herein in any way (including, but = not=20 limited to, total or partial
disclosure, reproduction, or = dissemination) by=20 persons other than the intended
recipient(s) is prohibited. If you = receive=20 this e-mail in error, please notify the sender by
phone or email = immediately=20 and delete it!
 

From: Michal Giermasinski=20 [mailto:michal.giermasinski@gmail.com]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: = [P2PSIP]=20 do we need a client protocol?

Hi!
 
Well, in my oppinion it is not a good for creating a new protocol. = If a=20 client application is not able to use SIP protocol that is well known = for years=20 it obviously will not be able to use a new one that will be designed = especially=20 for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better thing = is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that will = be able=20 to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do not = support=20 SIP, those peers are only responsible to
provide distributed = storage,=20 location and transport services for information about SIP, but those = peers do=20 not recognize any
SIP messages at all.
  In this case, = how to=20 maintain the relation between clients (UA) and the hosting peer(s)? = One client=20 protocol is desirable
at this time.


Zheng = Hewen
HUAWEI=20 TECHNOLOGIES CO.,LTD.  huawei_logo


Huihong=20 Mansion
No.91 Baixia Road
NanJing, P.R.China
Tel:=20 025-84565467
Fax: 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
--------------------= -------------------------------------------------------------------------= -------------------------------=20
---------
This e-mail and its attachments contain confidential=20 information from HUAWEI, which
is intended only for the person or = entity=20 whose address is listed above. Any use of the
information contained = herein=20 in any way (including, but not limited to, total or partial =
disclosure,=20 reproduction, or dissemination) by persons other than the=20 intended
recipient(s) is prohibited. If you receive this e-mail in = error,=20 please notify the sender by
phone or email immediately and delete = it!=20


-----Original Message-----
From: Henry Sinnreich = [mailto:hsinnrei@adobe.com]
Sent: = 2007?6?26?=20 1:39
To: Dean Willis; David A. Bryan
Cc: Avshalom Houri; P2PSIP = Mailing=20 List; Philip Matthews
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives for = the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks, = Henry

-----Original=20 Message-----
From: Dean Willis [mailto:=20 dean.willis@softarmor.com]
Sent: Thursday, June 14, 2007 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better than=20 active/passive) entities
have a
> Peer-ID? In otherwords, are = they=20 part of the overlay at all? If so,
for
> most
> DHTs, = how do=20 we allow you to be in the overlay and not store = resources
(not
>=20 typical for most current DHT algorithms)

Well, that certainly = depends=20 on the DHT algorithm involved. It certainly seems that a peer that = moves=20 between contributing
and non-contributing might HAVE a peer ID, = but=20 whether it chooses to insert itself into the DHT "right now" might=20 determine
whether it is contributing "right now"
or = not.

> My=20 concern all along has been that I don't understand why something is =
> a=20 peer if it isn't doing anything other than talking to someone = and
>=20 making requests, hence why I supported client in the first=20 place.
>  I fail to see how something that isn't = contributing=20 anything, and
> instead talks to a peer to get resources, is in = any way=20 a peer. It
> seems completely not in keeping with the idea of = P2P. I=20 also worry it
> is likely to be very confusing since we've been = using=20 the other
> terminology for over a year now. Just looks like a = souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection and=20 wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality make=20 it two different nodes?

> If we do go this way, there is = one subtle=20 point. If I join the overlay
but
> don't happen to offer any = services=20 (other than maybe
storage...depending on
> how we definie it, = that=20 might or might not be mandatory), would I be
> contributing? If = joining=20 the overlay (in the sense that we have a
PeerID
> and
> = we=20 route traffic) doesn't require me to store, I could offer=20 no
services

That's "offer no other services", since routing = is=20 itself a service.

> and
> still be a peer. How do we=20 distinguish between this case and a
> "non-contributing peer" = who isn't=20 even part of the overlay (i.e., no
> Peer-ID)

I think = there's a=20 range of "contributing" in play. For most DHT models, a minimally = contributing=20 node will route a request
it receives. It might ask nicely = (perhaps a=20 q-value mechanism) to not have to route requests, but would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam onto = a WiFi=20 net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

_______________________________________________
P2PSIP = mailing=20 list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip=20

--Boundary_(ID_YzVlOTZJRtMZYRsOUPTVJA)-- --Boundary_(ID_CjozlPVJjhbmx2neTst0vQ) Content-id: <933435801@16072007-1D4A> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_CjozlPVJjhbmx2neTst0vQ) Content-id: <933435801@16072007-1D51> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_CjozlPVJjhbmx2neTst0vQ)-- --===============1093750521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1093750521==-- From p2psip-bounces@ietf.org Mon Jul 16 04:42:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMAF-0004b9-3G; Mon, 16 Jul 2007 04:42:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMAD-0004aw-Q1 for p2psip@ietf.org; Mon, 16 Jul 2007 04:42:41 -0400 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAMAD-0007Pm-7R for p2psip@ietf.org; Mon, 16 Jul 2007 04:42:41 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6G8gGaa029050; Mon, 16 Jul 2007 11:42:21 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 11:42:20 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 11:42:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] HBH vs. E2E SIP in P2PSIP Date: Mon, 16 Jul 2007 11:45:27 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04CC5CC5@esebe102.NOE.Nokia.com> In-Reply-To: <4697F367.6000809@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] HBH vs. E2E SIP in P2PSIP Thread-Index: AcfFl7PCK2MLLA4/ScmBODB/syRC0wB66e4g References: <4697F367.6000809@cisco.com> From: To: , X-OriginalArrivalTime: 16 Jul 2007 08:42:20.0582 (UTC) FILETIME=[39184C60:01C7C785] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Jonathan, The authors discussed this problem and decided to leave two options. As Henry said there are pros and cons of either these but... I agree with you that the first option should be a MUST from the security perspective. Actually this issue is discussed in http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-re quirements-01.txt document. Marcin =20 >-----Original Message----- >From: ext Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 >Sent: 14 July, 2007 00:49 >To: P2PSIP WG >Subject: [P2PSIP] HBH vs. E2E SIP in P2PSIP > >draft-bryan-p2psip-requirements-00 talks about how SIP relates=20 >to the P2P protocol. It says: > >> The above discussion suggests at least two paradigms for SIP=20 >> operation in a p2p setting: the end-to-end paradigm where=20 >a SIP user=20 >> agent uses the p2p location service to discover the location of=20 >> callee, and then send the SIP message directly to the=20 >callee, or a=20 >> hop-by-hop paradigm where each peer forwards the SIP request to a=20 >> peer which is more 'closer' to the callee. The former can=20 >be thought=20 >> of as a RPC whereas the later can be thought of as a=20 >local procedure=20 >> call to determine the next hop.=20 > >I'd like to propose that, any model which views the peers in=20 >the p2p network as proxies (things that add Via headers,=20 >follow proxy rules as defined in RFC 3261, and so on), is=20 >basically fatally flawed from a security perspective. > >SIP was not designed on a model of untrusted proxies. I know=20 >this keeps coming up time and time again in the core SIP=20 >mailing list. The problem is, the design of SIP quite=20 >purposefully gives SIP proxies pretty wide latitude in=20 >manipulating message contents and doing things. We have some=20 >limited protection, if you believe in things like S/MIME, but=20 >by its very definition, SIP allows proxies to do lots of=20 >stuff. They can send requests to different places, they can=20 >fork, they can send responses, they can add and remove=20 >headers, they can change the destination of a request. All of=20 >it is legal and makes sense in a proxy-routed model. > >However, in P2PSIP, if you think of the peers as proxies, you=20 >enter a use case where you trust none of the proxies, and in=20 >fact every call has a whole lot of them on the signaling path=20 >(O(logN)). I guarantee you that these untrusted proxies will=20 >launch attacks that are hard to fix without basically=20 >completely changing the way the SIP protocol works. > >So, don't do it. > >The way you limit what peers can do is by using a protocol to=20 >communicate with peers whose very design limits what can be=20 >done. A protocol built from the ground up to do nothing but=20 >give an intermediary the ability to move a message around=20 >based on DHT topology. You wouldn't need to worry about things=20 >modifying media destinations since there is no SDP. You=20 >needn't worry about spoofing caller ID since there is no=20 >caller ID in the protocol. All you do is use this protocol to=20 >allow you to set up a secure, e2e, TLS connection between you=20 >and the UA you want to talk to, and then run SIP over that. > >The great benefit is that SIP already allows UA to UA=20 >communications. It always has. P2PSIP then slides in as a=20 >pure, clean replacement for RFC3263, allowing you to identify=20 >the target UA that you want to connect to, and provide a means=20 >for connecting to them through firewalls and NATs. > >Thus I'd like to suggest that the E2E SIP model described in=20 >the requirements document be the one we are shooting for. > >Thanks, >Jonathan R. > > >--=20 >Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >Cisco Fellow Parsippany, NJ=20 >07054-2711 >Cisco Systems >jdrosen@cisco.com FAX: (973) 952-5050 >http://www.jdrosen.net PHONE: (973) 952-5000 >http://www.cisco.com > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 05:27:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMrY-0001XH-QE; Mon, 16 Jul 2007 05:27:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAMrY-0001U0-8B for p2psip@ietf.org; Mon, 16 Jul 2007 05:27:28 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAMrL-0008BK-30 for p2psip@ietf.org; Mon, 16 Jul 2007 05:27:28 -0400 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 <0JL9006FGM63AQ@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 17:25:15 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL9007PFM63RY@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 17:25:15 +0800 (CST) Received: from h58820 ([10.85.28.230]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL900F0CM5ZU8@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 17:25:15 +0800 (CST) Date: Mon, 16 Jul 2007 17:25:11 +0800 From: "He, Jingtong" Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-reply-to: <1184557836.A23680A@fd4.dngr.org> To: 'David Barrett' , 'Bruce Lowekamp' Message-id: <009901c7c78b$355bf8f0$e61c550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfHXJ98xv7p5gMcSzSluD2cIc2sCgAKquxQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'Henry Sinnreich' , 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Sorry to interrupt! I am wondering if we are designing a widely-used internet protocol once-and-for-all and update it (if necessary) when we meet with new problems/requirements. Or we are designing the first version of software, just using minimal methods to satisfy minimal requirements, and update/patch it year-by-year. -- Regards, Jingtong >-----Original Message----- >From: David Barrett [mailto:dbarrett@quinthar.com] >Sent: Monday, July 16, 2007 11:51 AM >To: Bruce Lowekamp >Cc: Henry Sinnreich; P2PSIP WG >Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > >What I read in the P2PSIP charter is we commit to one DHT while leaving >the option open for more. I interpret that to mean we pick one DHT now >for certain, and at some undefined point in the future we determine how >to generalize that. In other words, I feel a modular DHT system isn't >strictly required at this time, and anything not strictly required >shouldn't be discussed. > >So I've got nothing against the drafts. I just think they solve a >problem we don't need to solve today, and thus shouldn't be. > >Perhaps it would help if we began talking in terms of versions: I think >P2PSIP v1.0 should take an absolute minimalist interpretation of the >fewest, most crucial features necessary to have something that works in >the most constrained possible way. Everything else -- even discussion >about anything else -- should be deferred until v1.0 is done, and >modular DHTs fits in that category for me. > >Do you agree we should take a minimalist, iterative interpretation of >scope? Do you feel modular DHTs absolutely must be in the first >iteration? > >-david > >On Sun, 15 Jul 2007 8:00 pm, Bruce Lowekamp wrote: >> On 7/15/07, David Barrett wrote: >>> Well, I'd suggest that before we've done it once for real, we probably >>> don't >>> know enough to make smart modularity decisions. If we just picked one >>> DHT >>> and focused on nothing but that, we stand the highest chance of getting >>> *something* working in short order for P2PSIP 1.0. Then I expect we'd >>> be in >>> a good position to make modularization decisions for P2PSIP 2.0. >> >> Nearly all of the current peer protocol proposals support pluggable >> DHTs. dSIP actually had two separate drafts to demonstrate how it >> could work. Marcia didn't have time to rewrite them for RELOAD, but >> essentially it's just a matter of providing attribute numbers for >> what were headers in dSIP. P2PP supports different DHTs and actually >> has tried to even support unstructured overlays. >> >> Given that there are specific, concrete proposals out already, do you >> have specific criticisms or concerns after reading the drafts? >> >> Bruce > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 06:08:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IANVB-000331-3p; Mon, 16 Jul 2007 06:08:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IANV8-0002t0-HJ for p2psip@ietf.org; Mon, 16 Jul 2007 06:08:23 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IANV4-0000Sc-0Z for p2psip@ietf.org; Mon, 16 Jul 2007 06:08:22 -0400 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 <0JL900I4AJC8IQ@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 16:24:09 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL900AF1JC0V8@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 16:24:08 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL900HIWJBUPG@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 16:24:00 +0800 (CST) Date: Mon, 16 Jul 2007 16:23:54 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] do we need a client protocol? In-reply-to: To: 'CHEN Duan' , 'HUANG Ping B' Message-id: <002301c7c782$a5d98380$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfE7bz3jyA9r9lcQ+WMHEJaYkThEwASRQJwAIKDqLAAEEsQoA== X-Spam-Score: 0.6 (/) X-Scan-Signature: 6801f129b9672ecbb1b9b6500e5aba4e Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0532802823==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0532802823== Content-type: multipart/related; boundary="Boundary_(ID_kCqrx7kMBswedEh9SMDxrQ)" This is a multi-part message in MIME format. --Boundary_(ID_kCqrx7kMBswedEh9SMDxrQ) Content-type: multipart/alternative; boundary="Boundary_(ID_TcqdQj1hjXq78C94LaGpDg)" --Boundary_(ID_TcqdQj1hjXq78C94LaGpDg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Dear Chen, =20 Sorry, I have to repeat this Email due to mail server problem. = Please ignore it if you have received one copy. =20 As you said, the approach 2 is something like "SIP message routing", = but it is not "SIP message routing", the intermediate peers do not have to recognize SIP header if routing = decision is based on not SIP header but Peer-ID. Something is missed; routing using P2P in P2PSIP overlay is = preferred. IMHO, the distributed transport function that the peers offer in P2PSIP must be based on P2P, do you think so? BTW, one general transport mechanism independent of application = services such as SIP, STUN is preferred in P2PSIP, some mechanism already exists (e.g., RELOAD Tunneling technology). All those = services' messages are encapsulated and transported over peer connections, Tunneling technology is most appropriate. =20 Let's end this discussion about whether one client protocol is = desirable using draft-ietf-p2psip-concepts-00's description as below: "If the P2PSIP model also contains clients, then a protocol is = needed for client - peer communication." (Section 2.4 Relationship of Peer and Client Protocols) "Since P2PSIP is about peer-to-peer networks for real-time = communication, it is expected that most (if not all) peers and clients will be coupled with SIP entities. ... However, there is no = hard requirement that every P2PSIP node (peer or client) be coupled to a SIP entity, and some proposed architectures = include peer nodes that have no SIP function whatsoever. " (Section 2.5, Relationship Between P2PSIP and SIP) As the description of draft-ietf-p2psip-concepts-00, a client = protocol is desirable if P2PSIP model contains clients as WG charter, and at the same time all peers in P2PSIP overlay network = ***may*** support SIP (i.e., recognizing SIP messages' headers). You can get detailed info from draft-ietf-p2psip-concepts-00. =20 It is my pleasure to discuss with you. =20 Best regards, Zheng Hewen _____ =20 From: CHEN Duan [mailto:Duan.Chen@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C216=C8=D5 8:49 To: Zheng Hewen; Duan Chen; HUANG Ping B Cc: p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Dear Zheng: =20 There are basically two approaches to transport the SIP message in the = overlay. =20 1. End to end tunnel (Multiplexing along the peer connections,like = RELOAD) =20 2. Hop by hop transport (Encapsulation along the peer connections) =20 IMHO, the approach 2 is something like "SIP message routing", and in = this case it does not necessarily mean that the peer should be coupled with a SIP entity, however it has to be able to = recognize the SIP header to do the routing decision. =20 What I am trying to say is that if you have devices joining the DHT = but not recognize the SIP message, then approach 2 is not available. =20 Is that clear? =20 BR _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: 2007=C4=EA7=D4=C213=C8=D5 18:35 To: 'Duan Chen'; HUANG Ping B Cc: p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Dear Chen, =20 As you pointed out, section 5.3 of draft-ietf-p2psip-concepts-00 = says: "In addition to Peer Protocol and Client Protocol messages, a P2PSIP = Overlay must also provide a solution to the NAT Traversal problem for SIP messages. If it does not, there is no reliable = way for a peer behind one NAT to send a SIP INVITE to a peer behind another NAT. One way to solve this problem is to = transport SIP messages along Peer and Client Protocol connections: this could be done either by encapsulating the SIP messages = inside Peer and Client Protocol messages or by multiplexing SIP with the Peer (resp.Client) Protocol on a Peer (resp. = Client) Protocol connection." =20 In this case, those end-point peers (i.e., source and sink peers = transmitting SIP Invite) at least must be able to determine whether the received packets are SIP message, but please pay = attention to this point, it does not mean that all the peers support SIP (i.e., providing SIP functions such as proxy). The peers can forward those SIP messages by some mechanism such as = RELOAD TRANSPORT-TUNNEL method, at this time those messages are transparent for intermediate peers, it is not necessary to = recognize SIP messages for those intermediate peers because those intermediate peers only provide P2P distributed = storage/lookup/routing services not requiring SIP. P2PSIP Peers can support SIP, but it not required that P2PSIP Peers = must support SIP. Best regards, Zheng Hewen _____ =20 From: Duan Chen [mailto:duan.chen@gmail.com]=20 Sent: 2007=C4=EA7=D4=C213=C8=D5 9:33 To: HUANG Ping B Cc: p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi, Huang & Zheng: =20 One comment: If I understand correctly, the P2PSIP overlay should be able to = transport the SIP message because of the NAT traversal issue between peers. If it does not, there is no reliable way for a peer = behind one NAT to send a SIP INVITE to a peer behind another NAT (see section 5.3 of = draft-ietf-p2psip-concepts-00.txt), a P2PSIP peer may or may not be = coupled with a SIP entity, but it should be able to recognize the SIP message; or how = can it encapsulate or multiplex a SIP message along the peer to peer connections?=20 =20 Thus if there is a device joining the DHT overlay but not able to = recognize the SIP message, it would preclude the approach mentioned above to solve the NAT issue. =20 thanks and regards! =20 On 7/12/07, HUANG Ping B wrote:=20 Hi Zheng and marcin I have never said that P2PSIP is IP or use SIP. as we know, there are = two mode in P2PSIP, one is SIP over P2P and the other is P2P over SIP.SIP is just in application layer and P2P or P2PSIP = are more like transport layer. in SIP over P2P, SIP is just one of the protocols interacting with P2P or P2PSIP overlay. in = P2P over SIP, SIP is made some extension. I have never said that P2PSIP peer protocol shall use SIP, SIP is over P2PSIP!=20 And as I said, peers "SHOULD" not "SHALL" recognize SIP. maybe you = "SHALL" read RFC2119 _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 5:33 PM=20 To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol?=20 =20 Hi, =20 One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT = service but not recognize SIP messages should be admitted as one member/peer of P2PSIP overlay, we do not have to update = the device to support SIP and then provide DHT service, the cost introduced due to the update is unnecessary.=20 =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct destination for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of cause, is you use another = protocol, P2PSIP may be called another name, such as P2PXXX. P eers in P2PSIP overlay are responsible not just for location = (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? this name means that there is a relationship between P2PSIP = and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. then Peers in P2PSIP overlay( not P2PXXX = overlay) should recognize SIP message. Ok, you can say that a tunnel protocol could be used to deliver SIP protocol, this is a = choice, but not good choice. if a tunnel protocol is used, then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any protocols besides SIP, then name "P2PSIP" does not make sense.=20 when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM=20 To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol?=20 =20 Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms = for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they = do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the = resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope = will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality."=20 =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be.=20 =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 -------------------------------------------------------------------------= --------------------------------------------------- ---------=20 This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it!=20 =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some = AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or = not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should = have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more = complex.=20 =20 _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM=20 To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol?=20 =20 Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide = all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the = capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of = general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT = services.=20 IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 -------------------------------------------------------------------------= --------------------------------------------------- ---------=20 This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it!=20 =20 _____ =20 From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com ]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol?=20 =20 Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new = one that will be designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is = to create a proxy-like peer that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 -----Original Message----- From: Henry Sinnreich [mailto: = hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?"=20 let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and=20 - Other uses besides SIP. Business planning folks may not care about the = WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: = dean.willis@softarmor.com ] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly = seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is = > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service.=20 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the = peer.=20 > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change = it service offering.=20 -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org=20 https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________=20 P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_TcqdQj1hjXq78C94LaGpDg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Dear Chen,
 
    Sorry, I have to repeat this Email due to = mail server=20 problem. Please ignore it if you have received one=20 copy.
 
    As you said, the = approach 2 is=20 something like "SIP message routing", but it is not "SIP message = routing", the=20 intermediate peers do not have to recognize SIP header if routing = decision is=20 based on not SIP header but Peer-ID.
    Something is = missed;=20 routing using P2P in P2PSIP overlay is preferred. IMHO, the distributed=20 transport function that the peers offer in P2PSIP must be based on P2P, = do you=20 think so?
    BTW, one general transport mechanism = independent=20 of application services such as SIP, STUN is preferred in P2PSIP, some = mechanism=20 already exists (e.g., RELOAD Tunneling technology). All those services' = messages=20 are encapsulated and transported over peer connections, Tunneling = technology is=20 most appropriate.
   
    Let's end = this=20 discussion about whether one client protocol is desirable using=20 draft-ietf-p2psip-concepts-00's description as = below:
    "If=20 the P2PSIP model also contains clients, then a protocol is needed for = client -=20 peer communication." (Section 2.4 Relationship of Peer and Client=20 Protocols)
    "Since P2PSIP is about peer-to-peer = networks=20 for real-time communication, it is expected that most (if not all) peers = and=20 clients will be coupled with SIP entities. ... However, there is no hard = requirement that every P2PSIP node (peer or client) be coupled to a SIP = entity,=20 and some proposed architectures include peer nodes that have no SIP = function=20 whatsoever." (Section 2.5, Relationship Between P2PSIP and=20 SIP)
    As the=20 description of draft-ietf-p2psip-concepts-00, a client protocol is = desirable if=20 P2PSIP model contains clients as WG charter, and at the same time all = peers in=20 P2PSIP overlay network ***may*** support SIP (i.e., recognizing SIP = messages'=20 headers).
    You can get = detailed info=20 from = draft-ietf-p2psip-concepts-00.
    =
    It is=20 my pleasure to discuss with you.
 
Best regards,
Zheng Hewen

From: CHEN Duan=20 [mailto:Duan.Chen@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C216=C8=D5=20 8:49
To: Zheng Hewen; Duan Chen; HUANG Ping B
Cc:=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Dear Zheng:
 
  There are basically two approaches to = transport=20 the SIP message in the overlay.
 
1. End to end tunnel (Multiplexing along the = peer=20 connections,like RELOAD)
 
2. Hop by hop transport (Encapsulation along = the peer=20 connections)
 
  IMHO, the approach 2 is something like = "SIP=20 message routing", and in this case it does not necessarily mean that the = peer=20 should be coupled with a SIP entity, however it has to be able=20 to recognize the SIP header to do the routing = decision.
 
  What I am trying to say is that = if you have=20 devices joining the DHT but not recognize the SIP message, then approach = 2 is=20 not available.
 
  Is that clear?
 
BR

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: 2007=C4=EA7=D4=C213=C8=D5 18:35
To: 'Duan = Chen'; HUANG Ping=20 B
Cc: p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Dear Chen,
 
   As you = pointed=20 out, section 5.3 of draft-ietf-p2psip-concepts-00 says:
   = "In=20 addition to Peer Protocol and Client Protocol messages, a P2PSIP Overlay = must=20 also provide a solution to the NAT Traversal problem for SIP messages. = If it=20 does not, there is no reliable way for a peer behind one NAT to send a = SIP=20 INVITE to a peer behind another NAT. One way to solve this problem is to = transport SIP messages along Peer and Client Protocol connections: this = could be=20 done either by encapsulating the SIP messages inside Peer and Client = Protocol=20 messages or by multiplexing SIP with the Peer (resp.Client) Protocol on = a Peer=20 (resp. Client) Protocol connection."
  
   In = this=20 case, those end-point peers (i.e., source and sink peers transmitting = SIP=20 Invite) at least must be able to determine whether the received packets = are SIP=20 message, but please pay attention to this point, it does not mean that = all the=20 peers support SIP (i.e., providing SIP functions such as = proxy).
  =20 The peers can forward those SIP messages by some mechanism such as = RELOAD=20 TRANSPORT-TUNNEL method, at this time those messages are transparent for = intermediate peers, it is not necessary to recognize SIP messages for = those=20 intermediate peers because those intermediate peers only provide P2P = distributed=20 storage/lookup/routing services not requiring SIP.
  P2PSIP = Peers can=20 support SIP, but it not required that P2PSIP Peers must support = SIP.

Best=20 regards,
Zheng Hewen

From: Duan Chen = [mailto:duan.chen@gmail.com]=20
Sent: 2007=C4=EA7=D4=C213=C8=D5 9:33
To: HUANG Ping = B
Cc:=20 p2psip@ietf.org
Subject: Re: [P2PSIP] do we need a client=20 protocol?

Hi, Huang & Zheng:
 
One comment:
  If I understand correctly, the P2PSIP overlay should be able = to=20 transport the SIP message because of the NAT traversal issue between = peers. If=20 it does not, there is no reliable way for a peer behind one NAT to send = a SIP=20 INVITE to a peer behind another NAT (see section 5.3=20 of draft-ietf-p2psip-concepts-00.txt), a P2PSIP peer may or may not = be=20 coupled with a SIP entity, but it should be able to recognize the SIP = message;=20 or how can it encapsulate or multiplex a SIP message along the peer = to peer=20 connections?
 
Thus if there is a device joining the DHT overlay but not able to = recognize=20 the SIP message, it would preclude the approach mentioned above to solve = the NAT=20 issue.
 
thanks and regards!

 
On 7/12/07, HUANG Ping=20 B <Ping.b.Huang@alcatel-sb= ell.com.cn>=20 wrote:=20
Hi = Zheng and=20 marcin
   I have=20 never said that P2PSIP is IP or use SIP. as we know, there are two = mode in=20 P2PSIP, one is SIP over P2P and the other is P2P over SIP.SIP is just = in=20 application layer and P2P or P2PSIP are more like transport layer. in = SIP over=20 P2P, SIP is just one of the protocols interacting with P2P or P2PSIP = overlay.=20 in P2P over SIP, SIP is made some extension. I have never said that = P2PSIP=20 peer protocol shall use SIP, SIP is over P2PSIP! =
   And as I=20 said, peers "SHOULD" not "SHALL" recognize SIP. maybe you "SHALL" read = RFC2119

From: Zheng Hewen [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 5:33 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a=20 client protocol?

 
Hi,
 
   One supplement, FYI.
   In the future P2PSIP deployment, one = device=20 that can provide DHT service but not recognize SIP messages should be = admitted=20 as one member/peer of P2PSIP overlay, we do not have to update the = device to=20 support SIP and then provide DHT service, the cost introduced due = to the=20 update is unnecessary.
 

From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ] =
Sent:=20 2007=C4=EA7=D4=C212=C8=D5 16:57
To: Zheng Hewen; Michal = Giermasinski; p2psip@ietf.org
Subject:=20 RE: [P2PSIP] do we need a client = protocol?

 
I have never said that P2PSIP is equal to = SIP, P2PSIP=20 is just an overlay as an alternative to the SIP discovery process of = RFC 3263,=20 P2PSIP offers an alternative mechanism for determining the correct = destination=20 for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. = of=20 cause, is you use another protocol, P2PSIP may be called another name, = such as=20 P2PXXX. P eers in P2PSIP overlay are = responsible not just for=20 location (done by P2PSIP protocol). Why we called P2PSIP as = "P2PSIP"? =20 this name means that there is a relationship between P2PSIP and SIP, = maybe SIP=20 over P2P or P2P over SIP. but any way, SIP should be used. then Peers = in=20 P2PSIP overlay( not P2PXXX overlay) should recognize SIP message. Ok, = you can=20 say that a tunnel protocol could be used to deliver SIP protocol, this = is a=20 choice, but not good choice. if a tunnel protocol is used, then SIP = has=20 nothing with P2P overlay, this tunnel protocol could deliver any = protocols=20 besides SIP, then name "P2PSIP" does not make sense. =
when peers in P2PSIP overlay do not recognize SIP message, = then let=20 them out of overlay.

From: Zheng Hewen [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a=20 client protocol?

 
Hi,
 
  If=20 I do not misunderstand, P2PSIP is not equal to = SIP.
 =20 Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP.=20 Why must we bind SIP to P2PSIP peers?
  =
 =20 Here is the description about P2PSIP peers in WG charter,=20 FYI.
 =20 "The work focuses on collections of nodes called "P2PSIP peers" = and=20 "P2PSIP clients". P2PSIP peers manifest a distributed namespace in = which=20 overlay users are identified and provides mechanisms for locating = users or=20 resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP = peers=20 primarily in that they do not store information in the overlay, but = only use=20 it to locate users and resources. P2PSIP clients and peers use the = resolution=20 services of the peers as an alternative to the SIP discovery process = of RFC=20 3263. In this way, P2PSIP offers an alternative mechanism for = determining the=20 correct destination for SIP requests. The working group's initial = charter=20 scope will be to produce protocols to enable this alternate mechanism = for RFC=20 3263 functionality."
 
 =20 Nothing says that P2PSIP peers must support SIP or have = anything=20 with SIP.
 =20 From the charter, functionality of P2PSIP peers is so clear and = simple,=20 why do we make it complicated? I think we can do it = simpler, SIP is=20 SIP, P2PSIP peer is P2PSIP peer, let them be. =
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = =20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax:=20 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------=20
This e-mail and its attachments contain confidential information = from=20 HUAWEI, which
is intended only for the person or entity whose = address is=20 listed above. Any use of the
information contained herein in any = way=20 (including, but not limited to, total or partial
disclosure, = reproduction,=20 or dissemination) by persons other than the intended
recipient(s) = is=20 prohibited. If you receive this e-mail in error, please notify the = sender by=20
phone or email immediately and delete it!
 

From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ] =
Sent:=20 2007=C4=EA7=D4=C212=C8=D5 10:22
To: Zheng Hewen; Michal = Giermasinski; p2psip@ietf.org
Subject:=20 RE: [P2PSIP] do we need a client = protocol?

 
Hi=20 all
    P2P is great topic, but P2PSIP is the = subset or=20 certain instance of P2P. when we discuss P2PSIP, we shall not involve = all=20 nodes which could be peers in P2PSIP overlay. peers in P2PSIP overlay = are not=20 equal to peers in P2P overlay. when we discuss IMS, although legacy = equipments=20 does not support SIP, but some AGWs do translation or agent for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers = who know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some = common base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more=20 simple but not more complex.
 
From: Zheng Hewen [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: = 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a=20 client protocol?

 
Hi,
 
    Please let me describe the case in=20 detail.
    In the case, all clients support SIP, = but some=20 peers in the overlay network do not support SIP and some support SIP. = For=20 those peers which do not support SIP, such as some PCs, they can = provide all=20 required DHT services, but there is only a pity that they can not = recognize=20 any SIP message, maybe they think that the capability is unnecessary. = In this=20 case, some client protocol is desirable. Certainly this protocol may = be the=20 subset of general Peer Protocol if we regard those clients as Lame = Peers and=20 regard those peers as Pure Peers who only provide required DHT = services.=20
    IMHO, this case does not care those clients not = supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. =


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax:=20 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------=20
This e-mail and its attachments contain confidential information = from=20 HUAWEI, which
is intended only for the person or entity whose = address is=20 listed above. Any use of the
information contained herein in any = way=20 (including, but not limited to, total or partial
disclosure, = reproduction,=20 or dissemination) by persons other than the intended
recipient(s) = is=20 prohibited. If you receive this e-mail in error, please notify the = sender by=20
phone or email immediately and delete it!
 

From: Michal Giermasinski = [mailto:michal.giermasinski@gmail.com ]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: [P2PSIP] do = we need a=20 client protocol?

 
Hi!
 
Well, in my oppinion it is not a good for creating a new = protocol. If a=20 client application is not able to use SIP protocol that is well known = for=20 years it obviously will not be able to use a new one that will be = designed=20 especially for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better = thing is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that = will be=20 able to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do = not=20 support SIP, those peers are only responsible to
provide = distributed=20 storage, location and transport services for information about SIP, = but=20 those peers do not recognize any
SIP messages at = all.
  In=20 this case, how to maintain the relation between clients (UA) and the = hosting=20 peer(s)? One client protocol is desirable
at this = time.


Zheng=20 Hewen
HUAWEI TECHNOLOGIES=20 CO.,LTD.  huawei_logo


Huihong Mansion
No.91 = Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax:=20 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
-----------------------------------= -------------------------------------------------------------------------= ----------------=20
---------
This e-mail and its attachments contain = confidential=20 information from HUAWEI, which
is intended only for the person = or entity=20 whose address is listed above. Any use of the
information = contained=20 herein in any way (including, but not limited to, total or partial=20
disclosure, reproduction, or dissemination) by persons other = than the=20 intended
recipient(s) is prohibited. If you receive this e-mail = in=20 error, please notify the sender by
phone or email immediately and = delete=20 it!


-----Original Message-----
From: Henry Sinnreich=20 [mailto:=20 hsinnrei@adobe.com]
Sent: 2007?6?26? 1:39
To: Dean Willis; = David=20 A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews =
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives = for the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks,=20 Henry

-----Original Message-----
From: Dean Willis = [mailto:=20 dean.willis@softarmor.com ]
Sent: Thursday, June 14, 2007 = 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better=20 than active/passive) entities
have a
> Peer-ID? In = otherwords, are=20 they part of the overlay at all? If so,
for
> most
> = DHTs,=20 how do we allow you to be in the overlay and not store=20 resources
(not
> typical for most current DHT=20 algorithms)

Well, that certainly depends on the DHT algorithm = involved. It certainly seems that a peer that moves between = contributing=20
and non-contributing might HAVE a peer ID, but whether it = chooses to=20 insert itself into the DHT "right now" might determine
whether it = is=20 contributing "right now"
or not.

> My concern all along = has=20 been that I don't understand why something is
> a peer if it = isn't=20 doing anything other than talking to someone and
> making = requests,=20 hence why I supported client in the first = place.
>  I fail=20 to see how something that isn't contributing anything, and
> = instead=20 talks to a peer to get resources, is in any way a peer. It
> = seems=20 completely not in keeping with the idea of P2P. I also worry = it
> is=20 likely to be very confusing since we've been using the other =
>=20 terminology for over a year now. Just looks like a souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection=20 and wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality=20 make it two different nodes?

> If we do go this way, = there is one=20 subtle point. If I join the overlay
but
> don't happen to = offer any=20 services (other than maybe
storage...depending on
> how we = definie=20 it, that might or might not be mandatory), would I be
> = contributing?=20 If joining the overlay (in the sense that we have = a
PeerID
>=20 and
> we route traffic) doesn't require me to store, I could = offer=20 no
services

That's "offer no other services", since = routing is=20 itself a service.

> and
> still be a peer. How do = we=20 distinguish between this case and a
> "non-contributing peer" = who=20 isn't even part of the overlay (i.e., no
> Peer-ID)

I = think=20 there's a range of "contributing" in play. For most DHT models, a = minimally=20 contributing node will route a request
it receives. It might ask = nicely=20 (perhaps a q-value mechanism) to not have to route requests, but = would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam = onto a=20 WiFi net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org =
https://www1.ietf.org/mailman/listinfo/p2psip=20

_______________________________________________ =
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip=20 =

 

__________________________= _____________________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

=

--Boundary_(ID_TcqdQj1hjXq78C94LaGpDg)-- --Boundary_(ID_kCqrx7kMBswedEh9SMDxrQ) Content-id: <294361908@16072007-1859> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_kCqrx7kMBswedEh9SMDxrQ) Content-id: <294361908@16072007-1860> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_kCqrx7kMBswedEh9SMDxrQ)-- --===============0532802823== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0532802823==-- From p2psip-bounces@ietf.org Mon Jul 16 07:00:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAOJ7-0006o2-J3; Mon, 16 Jul 2007 07:00:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAOJ5-0006nw-Ka for p2psip@ietf.org; Mon, 16 Jul 2007 06:59:59 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAOJ1-0005hS-CK for p2psip@ietf.org; Mon, 16 Jul 2007 06:59:59 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6GAxaex024910 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Jul 2007 06:59:41 -0400 (EDT) In-Reply-To: <1184557836.A23680A@fd4.dngr.org> References: <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> <20d2bdfb0707151916p6e83bd31y8f34e2020fc564d6@mail.gmail.com> <1184557836.A23680A@fd4.dngr.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <081C1118-5B1F-48CD-915D-911DF174CD2F@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Mon, 16 Jul 2007 06:59:15 -0400 To: David Barrett X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The IETF experience with trying to do a version 2.0 of anything has not been good. We generally do a RFCXYZbis, which fix glaring problems in RFCXYZ, but the core functionality remains the same. See SMTP, SIP and HTTP, for starters. Thus, I disagree with your conclusion; this is my last post on the subject, since this is a largely theoretical debate. As mentioned, everybody who actually does protocol work in the working group has decided that modularity comes at almost no cost. I don't see a reason to be stifled by FUD. You are obviously free to propose solutions that satisfy your artificial constraints; the working group can then decide which ones it likes better. Henning On Jul 15, 2007, at 11:50 PM, David Barrett wrote: > What I read in the P2PSIP charter is we commit to one DHT while > leaving the option open for more. I interpret that to mean we pick > one DHT now for certain, and at some undefined point in the future > we determine how to generalize that. In other words, I feel a > modular DHT system isn't strictly required at this time, and > anything not strictly required shouldn't be discussed. > > So I've got nothing against the drafts. I just think they solve a > problem we don't need to solve today, and thus shouldn't be. > > Perhaps it would help if we began talking in terms of versions: I > think P2PSIP v1.0 should take an absolute minimalist interpretation > of the fewest, most crucial features necessary to have something > that works in the most constrained possible way. Everything else > -- even discussion about anything else -- should be deferred until > v1.0 is done, and modular DHTs fits in that category for me. > > Do you agree we should take a minimalist, iterative interpretation > of scope? Do you feel modular DHTs absolutely must be in the first > iteration? > > -david > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 11:45:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASlF-0006QQ-TY; Mon, 16 Jul 2007 11:45:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IASlE-0006QK-SH for p2psip@ietf.org; Mon, 16 Jul 2007 11:45:21 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IASlA-0002RJ-8v for p2psip@ietf.org; Mon, 16 Jul 2007 11:45:20 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL90047J0RBWJ@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 09:42:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JL900JVM0R4IV@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 09:42:47 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JL900BLV0QYMT@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 16 Jul 2007 09:42:40 +0800 (CST) Date: Mon, 16 Jul 2007 09:42:33 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] do we need a client protocol? In-reply-to: To: 'CHEN Duan' , 'Duan Chen' , 'HUANG Ping B' Message-id: <00c301c7c74a$9487bee0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcfE7bz3jyA9r9lcQ+WMHEJaYkThEwASRQJwAIKDqLAAAYTNYA== X-Spam-Score: 0.6 (/) X-Scan-Signature: b54c114e377ffd3b8a24b9a620caaf11 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1372854619==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1372854619== Content-type: multipart/related; boundary="Boundary_(ID_6cHHonb7InYBFK3lHBZM5A)" This is a multi-part message in MIME format. --Boundary_(ID_6cHHonb7InYBFK3lHBZM5A) Content-type: multipart/alternative; boundary="Boundary_(ID_LPsW24kl5dMfdf9RjcD0lg)" --Boundary_(ID_LPsW24kl5dMfdf9RjcD0lg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Dear Chen, =20 As you said, the approach 2 is something like "SIP message routing", = but it is not "SIP message routing", the intermediate peers do not have to recognize SIP header if routing = decision is based on not SIP header but Peer-ID. Something is missed; routing using P2P in P2PSIP overlay is = preferred. IMHO, the distributed transport function that the peers offer in P2PSIP must be based on P2P, do you think so? BTW, one general transport mechanism independent of application = services such as SIP, STUN is preferred in P2PSIP, some mechanism already exists (e.g., RELOAD Tunneling technology). All those = services' messages are encapsulated and transported over peer connections, Tunneling technology is most appropriate. =20 Let's end this discussion about whether one client protocol is = desirable using draft-ietf-p2psip-concepts-00's description as below: "If the P2PSIP model also contains clients, then a protocol is = needed for client - peer communication." (Section 2.4 Relationship of Peer and Client Protocols) "Since P2PSIP is about peer-to-peer networks for real-time = communication, it is expected that most (if not all) peers and clients will be coupled with SIP entities. ... However, there is no = hard requirement that every P2PSIP node (peer or client) be coupled to a SIP entity, and some proposed architectures = include peer nodes that have no SIP function whatsoever. " (Section 2.5, Relationship Between P2PSIP and SIP) You can get detailed info from draft-ietf-p2psip-concepts-00. =20 It is my pleasure to discuss with you. =20 Best regards, Zheng Hewen _____ =20 From: CHEN Duan [mailto:Duan.Chen@alcatel-sbell.com.cn]=20 Sent: 2007=C4=EA7=D4=C216=C8=D5 8:49 To: Zheng Hewen; Duan Chen; HUANG Ping B Cc: p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Dear Zheng: =20 There are basically two approaches to transport the SIP message in the = overlay. =20 1. End to end tunnel (Multiplexing along the peer connections,like = RELOAD) =20 2. Hop by hop transport (Encapsulation along the peer connections) =20 IMHO, the approach 2 is something like "SIP message routing", and in = this case it does not necessarily mean that the peer should be coupled with a SIP entity, however it has to be able to = recognize the SIP header to do the routing decision. =20 What I am trying to say is that if you have devices joining the DHT = but not recognize the SIP message, then approach 2 is not available. =20 Is that clear? =20 BR _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: 2007=C4=EA7=D4=C213=C8=D5 18:35 To: 'Duan Chen'; HUANG Ping B Cc: p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? Dear Chen, =20 As you pointed out, section 5.3 of draft-ietf-p2psip-concepts-00 = says: "In addition to Peer Protocol and Client Protocol messages, a P2PSIP = Overlay must also provide a solution to the NAT Traversal problem for SIP messages. If it does not, there is no reliable = way for a peer behind one NAT to send a SIP INVITE to a peer behind another NAT. One way to solve this problem is to = transport SIP messages along Peer and Client Protocol connections: this could be done either by encapsulating the SIP messages = inside Peer and Client Protocol messages or by multiplexing SIP with the Peer (resp.Client) Protocol on a Peer (resp. = Client) Protocol connection." =20 In this case, those end-point peers (i.e., source and sink peers = transmitting SIP Invite) at least must be able to determine whether the received packets are SIP message, but please pay = attention to this point, it does not mean that all the peers support SIP (i.e., providing SIP functions such as proxy). The peers can forward those SIP messages by some mechanism such as = RELOAD TRANSPORT-TUNNEL method, at this time those messages are transparent for intermediate peers, it is not necessary to = recognize SIP messages for those intermediate peers because those intermediate peers only provide P2P distributed = storage/lookup/routing services not requiring SIP. P2PSIP Peers can support SIP, but it not required that P2PSIP Peers = must support SIP. Best regards, Zheng Hewen _____ =20 From: Duan Chen [mailto:duan.chen@gmail.com]=20 Sent: 2007=C4=EA7=D4=C213=C8=D5 9:33 To: HUANG Ping B Cc: p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol? Hi, Huang & Zheng: =20 One comment: If I understand correctly, the P2PSIP overlay should be able to = transport the SIP message because of the NAT traversal issue between peers. If it does not, there is no reliable way for a peer = behind one NAT to send a SIP INVITE to a peer behind another NAT (see section 5.3 of = draft-ietf-p2psip-concepts-00.txt), a P2PSIP peer may or may not be = coupled with a SIP entity, but it should be able to recognize the SIP message; or how = can it encapsulate or multiplex a SIP message along the peer to peer connections?=20 =20 Thus if there is a device joining the DHT overlay but not able to = recognize the SIP message, it would preclude the approach mentioned above to solve the NAT issue. =20 thanks and regards! =20 On 7/12/07, HUANG Ping B wrote:=20 Hi Zheng and marcin I have never said that P2PSIP is IP or use SIP. as we know, there are = two mode in P2PSIP, one is SIP over P2P and the other is P2P over SIP.SIP is just in application layer and P2P or P2PSIP = are more like transport layer. in SIP over P2P, SIP is just one of the protocols interacting with P2P or P2PSIP overlay. in = P2P over SIP, SIP is made some extension. I have never said that P2PSIP peer protocol shall use SIP, SIP is over P2PSIP!=20 And as I said, peers "SHOULD" not "SHALL" recognize SIP. maybe you = "SHALL" read RFC2119 _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 5:33 PM=20 To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol?=20 =20 Hi, =20 One supplement, FYI. In the future P2PSIP deployment, one device that can provide DHT = service but not recognize SIP messages should be admitted as one member/peer of P2PSIP overlay, we do not have to update = the device to support SIP and then provide DHT service, the cost introduced due to the update is unnecessary.=20 =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 16:57 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 I have never said that P2PSIP is equal to SIP, P2PSIP is just an overlay = as an alternative to the SIP discovery process of RFC 3263, P2PSIP offers an alternative mechanism for determining the = correct destination for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. of cause, is you use another = protocol, P2PSIP may be called another name, such as P2PXXX. P eers in P2PSIP overlay are responsible not just for location = (done by P2PSIP protocol). Why we called P2PSIP as "P2PSIP"? this name means that there is a relationship between P2PSIP = and SIP, maybe SIP over P2P or P2P over SIP. but any way, SIP should be used. then Peers in P2PSIP overlay( not P2PXXX = overlay) should recognize SIP message. Ok, you can say that a tunnel protocol could be used to deliver SIP protocol, this is a = choice, but not good choice. if a tunnel protocol is used, then SIP has nothing with P2P overlay, this tunnel protocol could = deliver any protocols besides SIP, then name "P2PSIP" does not make sense.=20 when peers in P2PSIP overlay do not recognize SIP message, then let them = out of overlay. _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 2:01 PM=20 To: HUANG Ping B; 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol?=20 =20 Hi, =20 If I do not misunderstand, P2PSIP is not equal to SIP. Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP. Why = must we bind SIP to P2PSIP peers?=20 =20 Here is the description about P2PSIP peers in WG charter, FYI. "The work focuses on collections of nodes called "P2PSIP peers" and = "P2PSIP clients". P2PSIP peers manifest a distributed namespace in which overlay users are identified and provides mechanisms = for locating users or resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP peers primarily in that they = do not store information in the overlay, but only use it to locate users and resources. P2PSIP clients and peers use the = resolution services of the peers as an alternative to the SIP discovery process of RFC 3263. In this way, P2PSIP offers an = alternative mechanism for determining the correct destination for SIP requests. The working group's initial charter scope = will be to produce protocols to enable this alternate mechanism for RFC 3263 functionality."=20 =20 Nothing says that P2PSIP peers must support SIP or have anything with = SIP. From the charter, functionality of P2PSIP peers is so clear and = simple, why do we make it complicated? I think we can do it simpler, SIP is SIP, P2PSIP peer is P2PSIP peer, let them be.=20 =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 -------------------------------------------------------------------------= --------------------------------------------------- ---------=20 This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it!=20 =20 _____ =20 From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 10:22 To: Zheng Hewen; Michal Giermasinski; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol? =20 Hi all P2P is great topic, but P2PSIP is the subset or certain instance of = P2P. when we discuss P2PSIP, we shall not involve all nodes which could be peers in P2PSIP overlay. peers in P2PSIP = overlay are not equal to peers in P2P overlay. when we discuss IMS, although legacy equipments does not support SIP, but some = AGWs do translation or agent for those equipments. then, when we discuss P2PSIP, shall we involve all peers who know SIP or = not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and vice versa. and I think that Peers in P2PSIP overlay should = have some common base functionalitis such as SIP recognition. I think we shall make P2PSIP more simple but not more = complex.=20 =20 _____ =20 From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Thursday, July 12, 2007 9:34 AM=20 To: 'Michal Giermasinski'; p2psip@ietf.org Subject: RE: [P2PSIP] do we need a client protocol?=20 =20 Hi, =20 Please let me describe the case in detail. In the case, all clients support SIP, but some peers in the overlay = network do not support SIP and some support SIP. For those peers which do not support SIP, such as some PCs, they can provide = all required DHT services, but there is only a pity that they can not recognize any SIP message, maybe they think that the = capability is unnecessary. In this case, some client protocol is desirable. Certainly this protocol may be the subset of = general Peer Protocol if we regard those clients as Lame Peers and regard those peers as Pure Peers who only provide required DHT = services.=20 IMHO, this case does not care those clients not supporting SIP. =20 Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo=20 Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 -------------------------------------------------------------------------= --------------------------------------------------- ---------=20 This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the=20 information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by=20 phone or email immediately and delete it!=20 =20 _____ =20 From: Michal Giermasinski [mailto:michal.giermasinski@gmail.com ]=20 Sent: 2007=C4=EA7=D4=C212=C8=D5 5:31 To: Zheng Hewen; p2psip@ietf.org Subject: Re: [P2PSIP] do we need a client protocol?=20 =20 Hi! =20 Well, in my oppinion it is not a good for creating a new protocol. If a = client application is not able to use SIP protocol that is well known for years it obviously will not be able to use a new = one that will be designed especially for cooperation with p2psip overlay.=20 =20 If we follow this understanding we can assume that the better thing is = to use SIP on this interface (between client outstanding the overlay and the peer in the overlay). The only issue is = to create a proxy-like peer that will be able to help client to get benefits of the overlay.=20 =20 What we should consider is how to filter the traffic unwanted by regular = client that do not want to take part in the routing decision. =20 best regards Michal Giermasinski =20 2007/7/11, Zheng Hewen :=20 Hi, A client protocol will be useful when some peers in the overlay do = not support SIP, those peers are only responsible to=20 provide distributed storage, location and transport services for = information about SIP, but those peers do not recognize any SIP messages at all. In this case, how to maintain the relation between clients (UA) and = the hosting peer(s)? One client protocol is desirable=20 at this time. Zheng Hewen HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo Huihong Mansion No.91 Baixia Road NanJing, P.R.China Tel: 025-84565467 Fax: 025-84565354 Mobile: 13611508264 E-mail: hwzheng@huaweic.om www.huawei.com =20 -------------------------------------------------------------------------= --------------------------------------------------- --------- This e-mail and its attachments contain confidential information from = HUAWEI, which=20 is intended only for the person or entity whose address is listed above. = Any use of the information contained herein in any way (including, but not limited to, = total or partial=20 disclosure, reproduction, or dissemination) by persons other than the = intended=20 recipient(s) is prohibited. If you receive this e-mail in error, please = notify the sender by phone or email immediately and delete it!=20 -----Original Message----- From: Henry Sinnreich [mailto: = hsinnrei@adobe.com] Sent: 2007?6?26? 1:39 To: Dean Willis; David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews=20 Subject: [P2PSIP] do we need a client protocol? Folks, Given the length of the discussion on "do we need a client protocol?"=20 let me repeat the simple imperatives for the client: - Limited battery in mobile devices, and=20 - Other uses besides SIP. Business planning folks may not care about the = WG charter, but about the return on the investment. Thanks, Henry -----Original Message----- From: Dean Willis [mailto: = dean.willis@softarmor.com ] Sent: Thursday, June 14, 2007 11:23 PM To: David A. Bryan Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews Subject: Re: [P2PSIP] Concepts document: proposal for active/passive = peerterminology=20 David A. Bryan wrote: > If I understand this right, not sure I like it. Do these "non-contributing > peer" (I *do* like contributing better than active/passive) entities have a > Peer-ID? In otherwords, are they part of the overlay at all? If so,=20 for > most > DHTs, how do we allow you to be in the overlay and not store resources (not > typical for most current DHT algorithms) Well, that certainly depends on the DHT algorithm involved. It certainly = seems that a peer that moves between contributing=20 and non-contributing might HAVE a peer ID, but whether it chooses to = insert itself into the DHT "right now" might determine whether it is contributing "right now" or not. > My concern all along has been that I don't understand why something is = > a peer if it isn't doing anything other than talking to someone and > making requests, hence why I supported client in the first place. > I fail to see how something that isn't contributing anything, and=20 > instead talks to a peer to get resources, is in any way a peer. It > seems completely not in keeping with the idea of P2P. I also worry it > is likely to be very confusing since we've been using the other=20 > terminology for over a year now. Just looks like a souce of confusion. A node might sometimes have a high-bandwidth connection and wish to = contribute resources, and sometimes not have a high-bandwidth connection and therefore not wish to offer resources. = Does this modality make it two different nodes?=20 > If we do go this way, there is one subtle point. If I join the overlay but > don't happen to offer any services (other than maybe storage...depending on > how we definie it, that might or might not be mandatory), would I be=20 > contributing? If joining the overlay (in the sense that we have a PeerID > and > we route traffic) doesn't require me to store, I could offer no services That's "offer no other services", since routing is itself a service.=20 > and > still be a peer. How do we distinguish between this case and a > "non-contributing peer" who isn't even part of the overlay (i.e., no > Peer-ID) I think there's a range of "contributing" in play. For most DHT models, = a minimally contributing node will route a request=20 it receives. It might ask nicely (perhaps a q-value mechanism) to not = have to route requests, but would probably mathematically still have to route something it gets. I think we distinguish based on the service advertisements from the = peer.=20 > If we are so opposed to client for confusion with SIP UAs, lets pick a new > name, but why some flavor of peer when it does nothing remotely peer like? Because in 15 minutes it might roam onto a WiFi net and therefore change = it service offering.=20 -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org=20 https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________=20 P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_LPsW24kl5dMfdf9RjcD0lg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable
Dear Chen,
 
    As you said, the approach 2 = is something=20 like "SIP message routing", but it is not "SIP message routing", the=20 intermediate peers do not have to recognize SIP header if routing = decision is=20 based on not SIP header but Peer-ID.
    Something is = missed;=20 routing using P2P in P2PSIP overlay is preferred. IMHO, the distributed=20 transport function that the peers offer in P2PSIP must be based on P2P, = do you=20 think so?
    BTW, one general transport mechanism = independent=20 of application services such as SIP, STUN is preferred in P2PSIP, some = mechanism=20 already exists (e.g., RELOAD Tunneling technology). All those services' = messages=20 are encapsulated and transported over peer connections, Tunneling = technology is=20 most appropriate.
   
    Let's end = this=20 discussion about whether one client protocol is desirable using=20 draft-ietf-p2psip-concepts-00's description as = below:
    "If=20 the P2PSIP model also contains clients, then a protocol is needed for = client -=20 peer communication." (Section 2.4 Relationship of Peer and Client=20 Protocols)
    "Since P2PSIP is about peer-to-peer = networks=20 for real-time communication, it is expected that most (if not all) peers = and=20 clients will be coupled with SIP entities. ... However, there is no hard = requirement that every P2PSIP node (peer or client) be coupled to a SIP = entity,=20 and some proposed architectures include peer nodes that have no SIP = function=20 whatsoever." (Section 2.5, Relationship Between P2PSIP and=20 SIP)
    You can get detailed info from=20 draft-ietf-p2psip-concepts-00.
    =
    It=20 is my pleasure to discuss with you.
 
Best regards,
Zheng Hewen

From: CHEN Duan=20 [mailto:Duan.Chen@alcatel-sbell.com.cn]
Sent: = 2007=C4=EA7=D4=C216=C8=D5=20 8:49
To: Zheng Hewen; Duan Chen; HUANG Ping B
Cc:=20 p2psip@ietf.org
Subject: RE: [P2PSIP] do we need a client=20 protocol?

Dear Zheng:
 
  There are basically two approaches to = transport=20 the SIP message in the overlay.
 
1. End to end tunnel (Multiplexing along the = peer=20 connections,like RELOAD)
 
2. Hop by hop transport (Encapsulation along = the peer=20 connections)
 
  IMHO, the approach 2 is something like = "SIP=20 message routing", and in this case it does not necessarily mean that the = peer=20 should be coupled with a SIP entity, however it has to be able=20 to recognize the SIP header to do the routing = decision.
 
  What I am trying to say is that = if you have=20 devices joining the DHT but not recognize the SIP message, then approach = 2 is=20 not available.
 
  Is that clear?
 
BR

From: Zheng Hewen = [mailto:hwzheng@huawei.com]=20
Sent: 2007=C4=EA7=D4=C213=C8=D5 18:35
To: 'Duan = Chen'; HUANG Ping=20 B
Cc: p2psip@ietf.org
Subject: RE: [P2PSIP] do we = need a=20 client protocol?

Dear Chen,
 
   As you = pointed=20 out, section 5.3 of draft-ietf-p2psip-concepts-00 says:
   = "In=20 addition to Peer Protocol and Client Protocol messages, a P2PSIP Overlay = must=20 also provide a solution to the NAT Traversal problem for SIP messages. = If it=20 does not, there is no reliable way for a peer behind one NAT to send a = SIP=20 INVITE to a peer behind another NAT. One way to solve this problem is to = transport SIP messages along Peer and Client Protocol connections: this = could be=20 done either by encapsulating the SIP messages inside Peer and Client = Protocol=20 messages or by multiplexing SIP with the Peer (resp.Client) Protocol on = a Peer=20 (resp. Client) Protocol connection."
  
   In = this=20 case, those end-point peers (i.e., source and sink peers transmitting = SIP=20 Invite) at least must be able to determine whether the received packets = are SIP=20 message, but please pay attention to this point, it does not mean that = all the=20 peers support SIP (i.e., providing SIP functions such as = proxy).
  =20 The peers can forward those SIP messages by some mechanism such as = RELOAD=20 TRANSPORT-TUNNEL method, at this time those messages are transparent for = intermediate peers, it is not necessary to recognize SIP messages for = those=20 intermediate peers because those intermediate peers only provide P2P = distributed=20 storage/lookup/routing services not requiring SIP.
  P2PSIP = Peers can=20 support SIP, but it not required that P2PSIP Peers must support = SIP.

Best=20 regards,
Zheng Hewen

From: Duan Chen = [mailto:duan.chen@gmail.com]=20
Sent: 2007=C4=EA7=D4=C213=C8=D5 9:33
To: HUANG Ping = B
Cc:=20 p2psip@ietf.org
Subject: Re: [P2PSIP] do we need a client=20 protocol?

Hi, Huang & Zheng:
 
One comment:
  If I understand correctly, the P2PSIP overlay should be able = to=20 transport the SIP message because of the NAT traversal issue between = peers. If=20 it does not, there is no reliable way for a peer behind one NAT to send = a SIP=20 INVITE to a peer behind another NAT (see section 5.3=20 of draft-ietf-p2psip-concepts-00.txt), a P2PSIP peer may or may not = be=20 coupled with a SIP entity, but it should be able to recognize the SIP = message;=20 or how can it encapsulate or multiplex a SIP message along the peer = to peer=20 connections?
 
Thus if there is a device joining the DHT overlay but not able to = recognize=20 the SIP message, it would preclude the approach mentioned above to solve = the NAT=20 issue.
 
thanks and regards!

 
On 7/12/07, HUANG Ping=20 B <Ping.b.Huang@alcatel-sb= ell.com.cn>=20 wrote:=20
Hi = Zheng and=20 marcin
   I have=20 never said that P2PSIP is IP or use SIP. as we know, there are two = mode in=20 P2PSIP, one is SIP over P2P and the other is P2P over SIP.SIP is just = in=20 application layer and P2P or P2PSIP are more like transport layer. in = SIP over=20 P2P, SIP is just one of the protocols interacting with P2P or P2PSIP = overlay.=20 in P2P over SIP, SIP is made some extension. I have never said that = P2PSIP=20 peer protocol shall use SIP, SIP is over P2PSIP! =
   And as I=20 said, peers "SHOULD" not "SHALL" recognize SIP. maybe you "SHALL" read = RFC2119

From: Zheng Hewen [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 5:33 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a=20 client protocol?

 
Hi,
 
   One supplement, FYI.
   In the future P2PSIP deployment, one = device=20 that can provide DHT service but not recognize SIP messages should be = admitted=20 as one member/peer of P2PSIP overlay, we do not have to update the = device to=20 support SIP and then provide DHT service, the cost introduced due = to the=20 update is unnecessary.
 

From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ] =
Sent:=20 2007=C4=EA7=D4=C212=C8=D5 16:57
To: Zheng Hewen; Michal = Giermasinski; p2psip@ietf.org
Subject:=20 RE: [P2PSIP] do we need a client = protocol?

 
I have never said that P2PSIP is equal to = SIP, P2PSIP=20 is just an overlay as an alternative to the SIP discovery process of = RFC 3263,=20 P2PSIP offers an alternative mechanism for determining the correct = destination=20 for SIP requests. SIP is session layer protocol, P2PSIP is under SIP. = of=20 cause, is you use another protocol, P2PSIP may be called another name, = such as=20 P2PXXX. P eers in P2PSIP overlay are = responsible not just for=20 location (done by P2PSIP protocol). Why we called P2PSIP as = "P2PSIP"? =20 this name means that there is a relationship between P2PSIP and SIP, = maybe SIP=20 over P2P or P2P over SIP. but any way, SIP should be used. then Peers = in=20 P2PSIP overlay( not P2PXXX overlay) should recognize SIP message. Ok, = you can=20 say that a tunnel protocol could be used to deliver SIP protocol, this = is a=20 choice, but not good choice. if a tunnel protocol is used, then SIP = has=20 nothing with P2P overlay, this tunnel protocol could deliver any = protocols=20 besides SIP, then name "P2PSIP" does not make sense. =
when peers in P2PSIP overlay do not recognize SIP message, = then let=20 them out of overlay.

From: Zheng Hewen [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 2:01 PM
To: HUANG = Ping B;=20 'Michal Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a=20 client protocol?

 
Hi,
 
  If=20 I do not misunderstand, P2PSIP is not equal to = SIP.
 =20 Essentially in P2PSIP overlay, P2PSIP peers have nothing with SIP.=20 Why must we bind SIP to P2PSIP peers?
  =
 =20 Here is the description about P2PSIP peers in WG charter,=20 FYI.
 =20 "The work focuses on collections of nodes called "P2PSIP peers" = and=20 "P2PSIP clients". P2PSIP peers manifest a distributed namespace in = which=20 overlay users are identified and provides mechanisms for locating = users or=20 resources within the P2PSIP overlay. P2PSIP clients differ from P2PSIP = peers=20 primarily in that they do not store information in the overlay, but = only use=20 it to locate users and resources. P2PSIP clients and peers use the = resolution=20 services of the peers as an alternative to the SIP discovery process = of RFC=20 3263. In this way, P2PSIP offers an alternative mechanism for = determining the=20 correct destination for SIP requests. The working group's initial = charter=20 scope will be to produce protocols to enable this alternate mechanism = for RFC=20 3263 functionality."
 
 =20 Nothing says that P2PSIP peers must support SIP or have = anything=20 with SIP.
 =20 From the charter, functionality of P2PSIP peers is so clear and = simple,=20 why do we make it complicated? I think we can do it = simpler, SIP is=20 SIP, P2PSIP peer is P2PSIP peer, let them be. =
 

Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. = =20


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax:=20 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------=20
This e-mail and its attachments contain confidential information = from=20 HUAWEI, which
is intended only for the person or entity whose = address is=20 listed above. Any use of the
information contained herein in any = way=20 (including, but not limited to, total or partial
disclosure, = reproduction,=20 or dissemination) by persons other than the intended
recipient(s) = is=20 prohibited. If you receive this e-mail in error, please notify the = sender by=20
phone or email immediately and delete it!
 

From: HUANG Ping B [mailto:Ping.b.Huang@alcatel-sbell.com.cn ] =
Sent:=20 2007=C4=EA7=D4=C212=C8=D5 10:22
To: Zheng Hewen; Michal = Giermasinski; p2psip@ietf.org
Subject:=20 RE: [P2PSIP] do we need a client = protocol?

 
Hi=20 all
    P2P is great topic, but P2PSIP is the = subset or=20 certain instance of P2P. when we discuss P2PSIP, we shall not involve = all=20 nodes which could be peers in P2PSIP overlay. peers in P2PSIP overlay = are not=20 equal to peers in P2P overlay. when we discuss IMS, although legacy = equipments=20 does not support SIP, but some AGWs do translation or agent for those=20 equipments. then, when we discuss P2PSIP, shall we involve all peers = who know=20 SIP or not in P2PSIP overlay? I think P2P is not equal to P2PSIP, and = vice=20 versa. and I think that Peers in P2PSIP overlay should have some = common base=20 functionalitis such as SIP recognition. I think we shall make P2PSIP = more=20 simple but not more complex.
 
From: Zheng Hewen [mailto:hwzheng@huawei.com]=20
Sent: Thursday, July 12, 2007 9:34 AM
To: = 'Michal=20 Giermasinski'; p2psip@ietf.org
Subject: RE: [P2PSIP] do = we need a=20 client protocol?

 
Hi,
 
    Please let me describe the case in=20 detail.
    In the case, all clients support SIP, = but some=20 peers in the overlay network do not support SIP and some support SIP. = For=20 those peers which do not support SIP, such as some PCs, they can = provide all=20 required DHT services, but there is only a pity that they can not = recognize=20 any SIP message, maybe they think that the capability is unnecessary. = In this=20 case, some client protocol is desirable. Certainly this protocol may = be the=20 subset of general Peer Protocol if we regard those clients as Lame = Peers and=20 regard those peers as Pure Peers who only provide required DHT = services.=20
    IMHO, this case does not care those clients not = supporting SIP.
 
Zheng = Hewen
HUAWEI TECHNOLOGIES CO.,LTD. =


Huihong = Mansion
No.91 Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax:=20 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
----------------------------------------------------------------= ---------------------------------------------------------------------=20
This e-mail and its attachments contain confidential information = from=20 HUAWEI, which
is intended only for the person or entity whose = address is=20 listed above. Any use of the
information contained herein in any = way=20 (including, but not limited to, total or partial
disclosure, = reproduction,=20 or dissemination) by persons other than the intended
recipient(s) = is=20 prohibited. If you receive this e-mail in error, please notify the = sender by=20
phone or email immediately and delete it!
 

From: Michal Giermasinski = [mailto:michal.giermasinski@gmail.com ]
Sent: = 2007=C4=EA7=D4=C212=C8=D5=20 5:31
To: Zheng Hewen; p2psip@ietf.org
Subject: Re: [P2PSIP] do = we need a=20 client protocol?

 
Hi!
 
Well, in my oppinion it is not a good for creating a new = protocol. If a=20 client application is not able to use SIP protocol that is well known = for=20 years it obviously will not be able to use a new one that will be = designed=20 especially for cooperation with p2psip overlay.
 
If we follow this understanding we can assume that the better = thing is to=20 use SIP on this interface (between client outstanding the overlay and = the peer=20 in the overlay). The only issue is to create a proxy-like peer that = will be=20 able to help client to get benefits of the overlay.
 
What we should consider is how to filter the traffic unwanted by = regular=20 client that do not want to take part in the routing decision.
 
best regards
Michal Giermasinski


 
2007/7/11, Zheng Hewen <hwzheng@huawei.com>:=20
Hi,

  =20 A client protocol will be useful when some peers in the overlay do = not=20 support SIP, those peers are only responsible to
provide = distributed=20 storage, location and transport services for information about SIP, = but=20 those peers do not recognize any
SIP messages at = all.
  In=20 this case, how to maintain the relation between clients (UA) and the = hosting=20 peer(s)? One client protocol is desirable
at this = time.


Zheng=20 Hewen
HUAWEI TECHNOLOGIES=20 CO.,LTD.  huawei_logo


Huihong Mansion
No.91 = Baixia=20 Road
NanJing, P.R.China
Tel: 025-84565467
Fax:=20 025-84565354
Mobile: 13611508264
E-mail: hwzheng@huaweic.om
www.huawei.com
-----------------------------------= -------------------------------------------------------------------------= ----------------=20
---------
This e-mail and its attachments contain = confidential=20 information from HUAWEI, which
is intended only for the person = or entity=20 whose address is listed above. Any use of the
information = contained=20 herein in any way (including, but not limited to, total or partial=20
disclosure, reproduction, or dissemination) by persons other = than the=20 intended
recipient(s) is prohibited. If you receive this e-mail = in=20 error, please notify the sender by
phone or email immediately and = delete=20 it!


-----Original Message-----
From: Henry Sinnreich=20 [mailto:=20 hsinnrei@adobe.com]
Sent: 2007?6?26? 1:39
To: Dean Willis; = David=20 A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; Philip Matthews =
Subject: [P2PSIP] do we need a client=20 protocol?

Folks,

Given the length of the discussion on = "do we=20 need a client protocol?"
let me repeat the simple imperatives = for the=20 client:

- Limited battery in mobile devices, and

- = Other uses=20 besides SIP. Business planning folks may not care about the WG = charter, but=20 about the return on the investment.

Thanks,=20 Henry

-----Original Message-----
From: Dean Willis = [mailto:=20 dean.willis@softarmor.com ]
Sent: Thursday, June 14, 2007 = 11:23=20 PM
To: David A. Bryan
Cc: Avshalom Houri; P2PSIP Mailing List; = Philip=20 Matthews
Subject: Re: [P2PSIP] Concepts document: proposal for=20 active/passive peerterminology

David A. Bryan wrote:
> = If I=20 understand this right, not sure I like it. Do=20 these
"non-contributing
> peer" (I *do* like contributing = better=20 than active/passive) entities
have a
> Peer-ID? In = otherwords, are=20 they part of the overlay at all? If so,
for
> most
> = DHTs,=20 how do we allow you to be in the overlay and not store=20 resources
(not
> typical for most current DHT=20 algorithms)

Well, that certainly depends on the DHT algorithm = involved. It certainly seems that a peer that moves between = contributing=20
and non-contributing might HAVE a peer ID, but whether it = chooses to=20 insert itself into the DHT "right now" might determine
whether it = is=20 contributing "right now"
or not.

> My concern all along = has=20 been that I don't understand why something is
> a peer if it = isn't=20 doing anything other than talking to someone and
> making = requests,=20 hence why I supported client in the first = place.
>  I fail=20 to see how something that isn't contributing anything, and
> = instead=20 talks to a peer to get resources, is in any way a peer. It
> = seems=20 completely not in keeping with the idea of P2P. I also worry = it
> is=20 likely to be very confusing since we've been using the other =
>=20 terminology for over a year now. Just looks like a souce of=20 confusion.

A node might sometimes have a high-bandwidth = connection=20 and wish to contribute resources, and sometimes not have = a
high-bandwidth=20 connection and therefore not wish to offer resources. Does this = modality=20 make it two different nodes?

> If we do go this way, = there is one=20 subtle point. If I join the overlay
but
> don't happen to = offer any=20 services (other than maybe
storage...depending on
> how we = definie=20 it, that might or might not be mandatory), would I be
> = contributing?=20 If joining the overlay (in the sense that we have = a
PeerID
>=20 and
> we route traffic) doesn't require me to store, I could = offer=20 no
services

That's "offer no other services", since = routing is=20 itself a service.

> and
> still be a peer. How do = we=20 distinguish between this case and a
> "non-contributing peer" = who=20 isn't even part of the overlay (i.e., no
> Peer-ID)

I = think=20 there's a range of "contributing" in play. For most DHT models, a = minimally=20 contributing node will route a request
it receives. It might ask = nicely=20 (perhaps a q-value mechanism) to not have to route requests, but = would=20 probably
mathematically still have to route something it = gets.

I=20 think we distinguish based on the service advertisements from the = peer.=20

> If we are so opposed to client for confusion with SIP = UAs, lets=20 pick a
new
> name, but why some flavor of peer when it does = nothing=20 remotely peer
like?

Because in 15 minutes it might roam = onto a=20 WiFi net and therefore change it service offering.=20 =

--
Dean

_______________________________________________=
P2PSIP=20 mailing list
P2PSIP@ietf.org =
https://www1.ietf.org/mailman/listinfo/p2psip=20

_______________________________________________ =
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip=20 =




_______________________________________________P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip=20 =

 

__________________________= _____________________
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip

=

--Boundary_(ID_LPsW24kl5dMfdf9RjcD0lg)-- --Boundary_(ID_6cHHonb7InYBFK3lHBZM5A) Content-id: <956331601@16072007-1D3C> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_6cHHonb7InYBFK3lHBZM5A) Content-id: <956331601@16072007-1D43> Content-type: image/jpeg; name=outlook_huawei_logo_en.jpg Content-transfer-encoding: base64 Content-disposition: attachment; filename=outlook_huawei_logo_en.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --Boundary_(ID_6cHHonb7InYBFK3lHBZM5A)-- --===============1372854619== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1372854619==-- From p2psip-bounces@ietf.org Mon Jul 16 14:28:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVJQ-0003ph-LD; Mon, 16 Jul 2007 14:28:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAVJQ-0003pU-7A for p2psip@ietf.org; Mon, 16 Jul 2007 14:28:48 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAVJM-0006Up-MR for p2psip@ietf.org; Mon, 16 Jul 2007 14:28:48 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6GISfve021915; Mon, 16 Jul 2007 21:28:42 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 21:28:40 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 21:28:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Restated question: do we need a client protocol? Date: Mon, 16 Jul 2007 21:31:48 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04CC5E87@esebe102.NOE.Nokia.com> In-Reply-To: <14C8E3BD-5C43-4F22-9AD0-C5B39DB5623B@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Restated question: do we need a client protocol? Thread-Index: AcfFdioMu0vJvFCXRQyQScTWaNE6+wCYE2rw References: <3F18E76823C95E4795181D74BAC7664F04BAFE71@esebe102.NOE.Nokia.com><001801c7c2f9$ed8a2f50$a507740a@DELLWEI><4d4304a00707100710j7bb3d528q886d5a91ec074445@mail.gmail.com> <14C8E3BD-5C43-4F22-9AD0-C5B39DB5623B@softarmor.com> From: To: , X-OriginalArrivalTime: 16 Jul 2007 18:28:40.0895 (UTC) FILETIME=[22320CF0:01C7C7D7] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Dean, I have not seen any solution that allows to turn off DHT maintenance, message-passing, and data storage. From this reason I would prefer the second option, but I am open for new proposals. =20 I would suggest to form a design team that would list a minimum set of functionalities the client protocol must support.=20 Marcin >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com]=20 >Sent: 13 July, 2007 20:48 >To: David A. Bryan >Cc: p2psip@ietf.org >Subject: [P2PSIP] Restated question: do we need a client protocol? > > >On Jul 10, 2007, at 9:10 AM, David A. Bryan wrote: > > >> >> So getting back to the question Brian Rosen raised in Prauge: >> >> Can anyone find a reason we need a client protocol for *SIP* using=20 >> P2P? > > >Clearly we have a reason to have some nodes that have lesser capacity =20 >and therefore offer fewer resources or services or whatever we might =20 >call them to the overlay. There's absolutely no doubt about this in =20 >my mind -- I think we can take it as a postulate. > >So we're not asking the right question. Let's see if we can get some =20 >better questions: > >1) Can the range of capacities of nodes be accommodated by one =20 >protocol that includes the ability to turn certain capabilities on =20 >and off (so that lesser-capable nodes could just not offer the things =20 >that are hard for them) or do we need an entirely different protocol =20 >for some class of nodes? > >2) Assuming that we do need an entirely different protocol for the =20 >least-capable nodes, is there a requirement for the least-capable =20 >nodes to do anything that cannot already be done with SIP? > > > >How could we make this decision? > >If the peer protocol requires participation in a DHT, such that the =20 >node must store data hashed to its peer-ID, OR if the peer protocol =20 >requires message-passing capability in all peers, then we probably =20 >have a protocol that isn't suitable for nodes connected via 2.5G =20 >mobile or something similar. We can either fix this by 1) changing =20 >the protocol for all peers such that not all peers require these =20 >capabilities, or 2) using a different protocol for peers with these =20 >constraints. > >The current concepts-and-terminology document allows for both =20 >approaches, but I'd very much like to come to consensus on a path =20 >here, because I think this is going to drive a lot of the work going =20 >forward. > >-- >Dean=20 > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 15:14:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAW18-0002uM-PV; Mon, 16 Jul 2007 15:13:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAW17-0002u2-Mi for p2psip@ietf.org; Mon, 16 Jul 2007 15:13:57 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAW13-0007th-7r for p2psip@ietf.org; Mon, 16 Jul 2007 15:13:57 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Mon, 16 Jul 2007 12:13:47 -0700 From: "David Barrett" To: "'Henning Schulzrinne'" Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Mon, 16 Jul 2007 12:13:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfHmHoNGZr81ONSS+SWqzrlPhTkagAQwDDA In-Reply-To: <081C1118-5B1F-48CD-915D-911DF174CD2F@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'Henry Sinnreich' , 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: Got it, this is useful to know: it's really a question of which design process we're using. You're proposing a standard waterfall process: 1) Design everything you'll ever need 2) Build it 3) Patch if necessary I'm proposing an iterative process: 1) Design the minimal set of features necessary to do minimal requirements 2) Build that and nothing else 3) Update design based on real-world lessons 4) Repeat again and again forever So, that'd explain why any attempt to reduce scope must sound so terrifying because you're assuming we only have one shot to get it right. Totally makes sense. Where does everyone else fall? Shall we take the one-shot waterfall approach, or iterative? -david > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, July 16, 2007 3:59 AM > To: David Barrett > Cc: Bruce Lowekamp; Henry Sinnreich; P2PSIP WG > Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > > The IETF experience with trying to do a version 2.0 of anything has > not been good. We generally do a RFCXYZbis, which fix glaring > problems in RFCXYZ, but the core functionality remains the same. See > SMTP, SIP and HTTP, for starters. > > Thus, I disagree with your conclusion; this is my last post on the > subject, since this is a largely theoretical debate. As mentioned, > everybody who actually does protocol work in the working group has > decided that modularity comes at almost no cost. I don't see a reason > to be stifled by FUD. You are obviously free to propose solutions > that satisfy your artificial constraints; the working group can then > decide which ones it likes better. > > Henning > > On Jul 15, 2007, at 11:50 PM, David Barrett wrote: > > > What I read in the P2PSIP charter is we commit to one DHT while > > leaving the option open for more. I interpret that to mean we pick > > one DHT now for certain, and at some undefined point in the future > > we determine how to generalize that. In other words, I feel a > > modular DHT system isn't strictly required at this time, and > > anything not strictly required shouldn't be discussed. > > > > So I've got nothing against the drafts. I just think they solve a > > problem we don't need to solve today, and thus shouldn't be. > > > > Perhaps it would help if we began talking in terms of versions: I > > think P2PSIP v1.0 should take an absolute minimalist interpretation > > of the fewest, most crucial features necessary to have something > > that works in the most constrained possible way. Everything else > > -- even discussion about anything else -- should be deferred until > > v1.0 is done, and modular DHTs fits in that category for me. > > > > Do you agree we should take a minimalist, iterative interpretation > > of scope? Do you feel modular DHTs absolutely must be in the first > > iteration? > > > > -david > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 16:13:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAWwY-0002DS-Rc; Mon, 16 Jul 2007 16:13:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAWwX-0002DB-Qi for p2psip@ietf.org; Mon, 16 Jul 2007 16:13:17 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAWwT-00011I-8J for p2psip@ietf.org; Mon, 16 Jul 2007 16:13:17 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 16 Jul 2007 13:13:06 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6GKD0Ws000761; Mon, 16 Jul 2007 13:13:00 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6GKCi0m019019; Mon, 16 Jul 2007 13:13:00 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 13:12:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Mon, 16 Jul 2007 13:12:03 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA034@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfHmHoNGZr81ONSS+SWqzrlPhTkagAQwDDAAAImpSA= References: <081C1118-5B1F-48CD-915D-911DF174CD2F@cs.columbia.edu> From: "Henry Sinnreich" To: "David Barrett" X-OriginalArrivalTime: 16 Jul 2007 20:12:58.0193 (UTC) FILETIME=[B3D5F410:01C7C7E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David, You have gotten it almost right here :-), except the following steps are missing: 1 Publish the code to get cooperation,=20 2 Use and/or develop simulation tools,=20 3 Run simulations, 4 Run the protocol over the Internet, 5 Report the test results 6 Go back to step 2. If the code is a commercial product, then at least steps 2-6 should be implemented. Your companion message to the BEHAVE WG is an excellent role model: =3D=3D=3D=3D=3D=3D=3D=3D I'm dealing with measuring peer connectivity of my own system (non-ICE), and here are some of the results for various NAT types: Type Count Connectivity Open Time Fullcone 150 (9%) 92% 1056ms Fullstatic 397 (25%) 94% 867ms Fw 68 (4%) 2% 374ms Rstrcone 598 (37%) 89% 706ms Rstrstatic 82 ( 5%) 91% 769ms symmetric 293 (18%) 94% 906ms =3D=3D=3D=3D=3D=3D=3D How is anyone supposed to spend resources on a paper design only? This includes our P2P SIP WG where paper designs seem already in oversupply. Henry -----Original Message----- From: David Barrett [mailto:dbarrett@quinthar.com]=20 Sent: Monday, July 16, 2007 12:14 PM To: 'Henning Schulzrinne' Cc: Henry Sinnreich; 'P2PSIP WG' Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Got it, this is useful to know: it's really a question of which design process we're using. You're proposing a standard waterfall process: 1) Design everything you'll ever need 2) Build it 3) Patch if necessary I'm proposing an iterative process: 1) Design the minimal set of features necessary to do minimal requirements 2) Build that and nothing else 3) Update design based on real-world lessons 4) Repeat again and again forever So, that'd explain why any attempt to reduce scope must sound so terrifying because you're assuming we only have one shot to get it right. Totally makes sense. Where does everyone else fall? Shall we take the one-shot waterfall approach, or iterative? -david =20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, July 16, 2007 3:59 AM > To: David Barrett > Cc: Bruce Lowekamp; Henry Sinnreich; P2PSIP WG > Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion >=20 > The IETF experience with trying to do a version 2.0 of anything has > not been good. We generally do a RFCXYZbis, which fix glaring > problems in RFCXYZ, but the core functionality remains the same. See > SMTP, SIP and HTTP, for starters. >=20 > Thus, I disagree with your conclusion; this is my last post on the > subject, since this is a largely theoretical debate. As mentioned, > everybody who actually does protocol work in the working group has > decided that modularity comes at almost no cost. I don't see a reason > to be stifled by FUD. You are obviously free to propose solutions > that satisfy your artificial constraints; the working group can then > decide which ones it likes better. >=20 > Henning >=20 > On Jul 15, 2007, at 11:50 PM, David Barrett wrote: >=20 > > What I read in the P2PSIP charter is we commit to one DHT while > > leaving the option open for more. I interpret that to mean we pick > > one DHT now for certain, and at some undefined point in the future > > we determine how to generalize that. In other words, I feel a > > modular DHT system isn't strictly required at this time, and > > anything not strictly required shouldn't be discussed. > > > > So I've got nothing against the drafts. I just think they solve a > > problem we don't need to solve today, and thus shouldn't be. > > > > Perhaps it would help if we began talking in terms of versions: I > > think P2PSIP v1.0 should take an absolute minimalist interpretation > > of the fewest, most crucial features necessary to have something > > that works in the most constrained possible way. Everything else > > -- even discussion about anything else -- should be deferred until > > v1.0 is done, and modular DHTs fits in that category for me. > > > > Do you agree we should take a minimalist, iterative interpretation > > of scope? Do you feel modular DHTs absolutely must be in the first > > iteration? > > > > -david > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 16:23:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAX6T-0003fI-GP; Mon, 16 Jul 2007 16:23:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAX6R-0003dS-S3 for p2psip@ietf.org; Mon, 16 Jul 2007 16:23:31 -0400 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAX6R-0002aj-Bq for p2psip@ietf.org; Mon, 16 Jul 2007 16:23:31 -0400 Received: from lappy ([68.26.99.170]) by quinthar.com for ; Mon, 16 Jul 2007 13:23:10 -0700 From: "David Barrett" To: "'Henry Sinnreich'" Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Mon, 16 Jul 2007 13:23:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcfHmHoNGZr81ONSS+SWqzrlPhTkagAQwDDAAAImpSAAAJ3GEA== In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AAA034@namail5.corp.adobe.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: So if I read you right, it sounds like you vote for: - MORE real-world iteration - LESS paper design. Is that right? If so, I am in complete agreement with you. Anybody else? -david > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Monday, July 16, 2007 1:12 PM > To: David Barrett > Cc: P2PSIP WG; Henning Schulzrinne > Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > > David, > > You have gotten it almost right here :-), except the following steps are > missing: > > 1 Publish the code to get cooperation, > 2 Use and/or develop simulation tools, > 3 Run simulations, > 4 Run the protocol over the Internet, > 5 Report the test results > 6 Go back to step 2. > > If the code is a commercial product, then at least steps 2-6 should be > implemented. > > Your companion message to the BEHAVE WG is an excellent role model: > > ======== > I'm dealing with measuring peer connectivity of my own system (non-ICE), > and here are some of the results for various NAT types: > > Type Count Connectivity Open Time > Fullcone 150 (9%) 92% 1056ms > Fullstatic 397 (25%) 94% 867ms > Fw 68 (4%) 2% 374ms > Rstrcone 598 (37%) 89% 706ms > Rstrstatic 82 ( 5%) 91% 769ms > symmetric 293 (18%) 94% 906ms > ======= > > How is anyone supposed to spend resources on a paper design only? > This includes our P2P SIP WG where paper designs seem already in > oversupply. > > Henry > > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com] > Sent: Monday, July 16, 2007 12:14 PM > To: 'Henning Schulzrinne' > Cc: Henry Sinnreich; 'P2PSIP WG' > Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > > Got it, this is useful to know: it's really a question of which design > process we're using. You're proposing a standard waterfall process: > > 1) Design everything you'll ever need > 2) Build it > 3) Patch if necessary > > I'm proposing an iterative process: > > 1) Design the minimal set of features necessary to do minimal > requirements > 2) Build that and nothing else > 3) Update design based on real-world lessons > 4) Repeat again and again forever > > So, that'd explain why any attempt to reduce scope must sound so > terrifying > because you're assuming we only have one shot to get it right. Totally > makes sense. > > Where does everyone else fall? Shall we take the one-shot waterfall > approach, or iterative? > > -david > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Monday, July 16, 2007 3:59 AM > > To: David Barrett > > Cc: Bruce Lowekamp; Henry Sinnreich; P2PSIP WG > > Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting > opinion > > > > The IETF experience with trying to do a version 2.0 of anything has > > not been good. We generally do a RFCXYZbis, which fix glaring > > problems in RFCXYZ, but the core functionality remains the same. See > > SMTP, SIP and HTTP, for starters. > > > > Thus, I disagree with your conclusion; this is my last post on the > > subject, since this is a largely theoretical debate. As mentioned, > > everybody who actually does protocol work in the working group has > > decided that modularity comes at almost no cost. I don't see a reason > > to be stifled by FUD. You are obviously free to propose solutions > > that satisfy your artificial constraints; the working group can then > > decide which ones it likes better. > > > > Henning > > > > On Jul 15, 2007, at 11:50 PM, David Barrett wrote: > > > > > What I read in the P2PSIP charter is we commit to one DHT while > > > leaving the option open for more. I interpret that to mean we pick > > > one DHT now for certain, and at some undefined point in the future > > > we determine how to generalize that. In other words, I feel a > > > modular DHT system isn't strictly required at this time, and > > > anything not strictly required shouldn't be discussed. > > > > > > So I've got nothing against the drafts. I just think they solve a > > > problem we don't need to solve today, and thus shouldn't be. > > > > > > Perhaps it would help if we began talking in terms of versions: I > > > think P2PSIP v1.0 should take an absolute minimalist interpretation > > > of the fewest, most crucial features necessary to have something > > > that works in the most constrained possible way. Everything else > > > -- even discussion about anything else -- should be deferred until > > > v1.0 is done, and modular DHTs fits in that category for me. > > > > > > Do you agree we should take a minimalist, iterative interpretation > > > of scope? Do you feel modular DHTs absolutely must be in the first > > > iteration? > > > > > > -david > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 17:45:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYNZ-00015K-TM; Mon, 16 Jul 2007 17:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYNY-00015A-Oj for p2psip@ietf.org; Mon, 16 Jul 2007 17:45:16 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAYNU-0003aP-GN for p2psip@ietf.org; Mon, 16 Jul 2007 17:45:16 -0400 Received: by py-out-1112.google.com with SMTP id f31so4348973pyh for ; Mon, 16 Jul 2007 14:45:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=oKUuZxQ9XVG2RzRsu2cd3j9QiJEbxT2MchLHlklZl5TiloZkYyx4qTDoaNKYDGD+eb0l95suZHGdP8JKGpwVHguJ6qGFrMbKmDeMYtD8b3MDl+99FpF5oGUAFL3mEOvW8b33zzccbR8JPxR7sih88LNQbGFObe5j8n9BCg8Ly0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=VbKv1CAVvIC8IzzzGqBzK9objD9V8lmBaX8bGzN7LnBTguMmzW5lOtp5jXwEfRc1/CNFwOjjSJDs9Fe43vj7dlVppkRxKpCpU6f14WWhJKn5gBhWOr0e8yC7DtQs9VWRYKfDTwapKGCcTw1qBXjROlV3BMMB5qLzdiBEXh16e7Q= Received: by 10.65.138.4 with SMTP id q4mr7638206qbn.1184622307560; Mon, 16 Jul 2007 14:45:07 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Mon, 16 Jul 2007 14:45:04 -0700 (PDT) Message-ID: <4d4304a00707161445ndadaebajde66139aceb2c22d@mail.gmail.com> Date: Mon, 16 Jul 2007 17:45:04 -0400 From: "David A. Bryan" To: "P2PSIP WG" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 5ec7e6a984f7e02a X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [P2PSIP] Possible (late) evening additional ad-hoc on Monday at IETF X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I have spoken with a number of the authors of the various proposed protocols, as well as with the AD, and there seems to be some interest in, and likely space available for, an ad-hoc meeting, outside of the regular Thursday slot, to discuss just the proposed concrete drafts for peer protocols. The idea would be to let the authors of each of the 6 proposed peer protocols present what their proposal is, with an equal time for questions/comments from the floor. Probably 10 minutes of presentation, 10 minutes of questions/comments for each. This would be in addition to the time slated at the on the normal Thursday session. There would be no hums taken or decisions reached at the Monday meeting -- it would only be time to present/discuss the proposals. In our real slot on Thursday I want to focus more on the issues raised by the work of creating the drafts -- this would be dedicated time to discuss the proposals themselves. Here is the bad part...the only slot that appears to be open would be 10pm-midnight (2200-0000) Monday night/early Tuesday. Do people think it is worth doing? Should we add this ad-hoc? David -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 17:56:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYYc-0001B6-C1; Mon, 16 Jul 2007 17:56:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYYa-0001B1-HY for p2psip@ietf.org; Mon, 16 Jul 2007 17:56:40 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAYYW-0003uV-3c for p2psip@ietf.org; Mon, 16 Jul 2007 17:56:40 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 16 Jul 2007 14:56:33 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6GLtBot007947; Mon, 16 Jul 2007 14:55:16 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6GLuC0e000019; Mon, 16 Jul 2007 14:56:23 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 14:56:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Possible (late) evening additional ad-hoc on Monday at IETF Date: Mon, 16 Jul 2007 14:56:08 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA0D8@namail5.corp.adobe.com> In-Reply-To: <4d4304a00707161445ndadaebajde66139aceb2c22d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Possible (late) evening additional ad-hoc on Monday at IETF Thread-Index: AcfH8q0rjURPQOkIShyVd0MWZQSVygAADGFg References: <4d4304a00707161445ndadaebajde66139aceb2c22d@mail.gmail.com> From: "Henry Sinnreich" To: "David A. Bryan" , "P2PSIP WG" X-OriginalArrivalTime: 16 Jul 2007 21:56:14.0337 (UTC) FILETIME=[21067F10:01C7C7F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Not all protocol proposals are equal, since there is a complete spectrum of proposals: * Mature, tested, public code available, * Commercial and the code is confidential, this is understandable, * Protocol proposals and ideas. Using these criteria, I suggest the P2PP meets the top criteria best to be THE candidate P2PSIP protocol. Sure, it can be perfected in the WG. ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-baset-p2psip-p2p p-00.txt=20 The author(s) of P2PP will be at the meeting, so why not having them present P2PP _as the first protocol_ , as part of the P2P SIP WG agenda? Thanks, Henry -----Original Message----- From: David A. Bryan [mailto:dbryan@sipeerior.com]=20 Sent: Monday, July 16, 2007 2:45 PM To: P2PSIP WG Subject: [P2PSIP] Possible (late) evening additional ad-hoc on Monday at IETF --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 21:23:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbn4-0003bP-7Q; Mon, 16 Jul 2007 21:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAbmy-0003Ut-DQ; Mon, 16 Jul 2007 21:23:44 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAbmt-0000YJ-W2; Mon, 16 Jul 2007 21:23:44 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2007 18:23:39 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANO2m0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,544,1175497200"; d="scan'208"; a="503820034:sNHT29354616" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6H1Nc7k013165; Mon, 16 Jul 2007 18:23:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6H1NcTb021446; Tue, 17 Jul 2007 01:23:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 18:23:38 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 18:23:38 -0700 Message-ID: <469C1A1F.2090102@cisco.com> Date: Mon, 16 Jul 2007 21:23:43 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 01:23:38.0346 (UTC) FILETIME=[1A3B94A0:01C7C811] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1845; t=1184635418; x=1185499418; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20ICE=20tutorial=20in=20Chicago=20[DO=20NOT=20REPLY]=20-=20PLEA SE=20ADVISE=20IF=20YOU=20WILL=0A=20ATTEND! |Sender:=20; bh=2mEMezIhgSd4fQtdetbfRv0w1jcLg1hf4bgHjST7IQc=; b=E8JzvIKOXdm/coVCa8PMIpZSSHcW1xP7WCAHJJydd1KTAo4rHvwnnmQbFu0sgmYA2MXhXiTZ 5mrrLKb6+K2doFKdUhVSQSvfLQ1cG+MRM5jN63ABURvqDhDJUyb32NZD; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [P2PSIP] ICE tutorial in Chicago [DO NOT REPLY] - PLEASE ADVISE IF YOU WILL ATTEND! X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I've gotten very few responses indicating interest. If I don't get more acceptances I'll have to cancel. Please, if you do plan on attending, send me mail per the instructions below if you have not done so. (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-16.txt) [-17 should be available shortly] WHEN: Tuesday, July 24, 2007, 1145-1245 (lunch logistics are in progress and will be announced ASAP) WHERE: Red Lacquar WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Please send a note to me with the Subject line "ice-is-nice" (mailto:jdrosen@cisco.com?Subject=ice-is-nice) so I can get a count of the number of participants for lunch purposes. !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 21:42:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAc53-0002hk-Mo; Mon, 16 Jul 2007 21:42:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAc51-0002g3-LV for p2psip@ietf.org; Mon, 16 Jul 2007 21:42:23 -0400 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAc50-00022a-V9 for p2psip@ietf.org; Mon, 16 Jul 2007 21:42:23 -0400 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 <0JLA007LJVCLXP@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 09:41:09 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLA006CUVCK40@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 09:41:09 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLA007DSVCG7P@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 09:41:08 +0800 (CST) Date: Tue, 17 Jul 2007 09:41:04 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Restated question: do we need a client protocol? In-reply-to: <3F18E76823C95E4795181D74BAC7664F04CC5E87@esebe102.NOE.Nokia.com> To: marcin.matuszewski@nokia.com, dean.willis@softarmor.com, dbryan@sipeerior.com Message-id: <005701c7c813$89f69180$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcfFdioMu0vJvFCXRQyQScTWaNE6+wCYE2rwAA8MHGA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Support. The second option is preferred from my viewpoint. The Client-Peer protocol, as which if it is called, is suggested that it would only maintain the relation between P2PSIP-Client and its host P2PSIP-Peer and operate resource(Get/Put). Best regards, Hewen -----Original Message----- From: marcin.matuszewski@nokia.com [mailto:marcin.matuszewski@nokia.com] Sent: 2007?7?17? 2:32 To: dean.willis@softarmor.com; dbryan@sipeerior.com Cc: p2psip@ietf.org Subject: RE: [P2PSIP] Restated question: do we need a client protocol? Hi Dean, I have not seen any solution that allows to turn off DHT maintenance, message-passing, and data storage. From this reason I would prefer the second option, but I am open for new proposals. I would suggest to form a design team that would list a minimum set of functionalities the client protocol must support. Marcin >-----Original Message----- >From: ext Dean Willis [mailto:dean.willis@softarmor.com] >Sent: 13 July, 2007 20:48 >To: David A. Bryan >Cc: p2psip@ietf.org >Subject: [P2PSIP] Restated question: do we need a client protocol? > > >On Jul 10, 2007, at 9:10 AM, David A. Bryan wrote: > > >> >> So getting back to the question Brian Rosen raised in Prauge: >> >> Can anyone find a reason we need a client protocol for *SIP* using >> P2P? > > >Clearly we have a reason to have some nodes that have lesser capacity >and therefore offer fewer resources or services or whatever we might >call them to the overlay. There's absolutely no doubt about this in my >mind -- I think we can take it as a postulate. > >So we're not asking the right question. Let's see if we can get some >better questions: > >1) Can the range of capacities of nodes be accommodated by one protocol >that includes the ability to turn certain capabilities on and off (so >that lesser-capable nodes could just not offer the things that are hard >for them) or do we need an entirely different protocol for some class >of nodes? > >2) Assuming that we do need an entirely different protocol for the >least-capable nodes, is there a requirement for the least-capable nodes >to do anything that cannot already be done with SIP? > > > >How could we make this decision? > >If the peer protocol requires participation in a DHT, such that the >node must store data hashed to its peer-ID, OR if the peer protocol >requires message-passing capability in all peers, then we probably >have a protocol that isn't suitable for nodes connected via 2.5G >mobile or something similar. We can either fix this by 1) changing >the protocol for all peers such that not all peers require these >capabilities, or 2) using a different protocol for peers with these >constraints. > >The current concepts-and-terminology document allows for both >approaches, but I'd very much like to come to consensus on a path >here, because I think this is going to drive a lot of the work going >forward. > >-- >Dean > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 21:57:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAcJu-0007rV-Nj; Mon, 16 Jul 2007 21:57:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAcJt-0007nO-Po for p2psip@ietf.org; Mon, 16 Jul 2007 21:57:45 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAcJo-0001lQ-Dh for p2psip@ietf.org; Mon, 16 Jul 2007 21:57:45 -0400 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 <0JLA002CYW2MOX@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 09:56:46 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLA00478W2LMI@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 09:56:46 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLA00DVRW2HXM@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 09:56:45 +0800 (CST) Date: Tue, 17 Jul 2007 09:56:41 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] HBH vs. E2E SIP in P2PSIP In-reply-to: <4697F367.6000809@cisco.com> To: 'Jonathan Rosenberg' , 'P2PSIP WG' Message-id: <000f01c7c815$b88598a0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcfFl8zLUDbBcWkaSfKv53/WefRjJACelqYA X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Jonathan: My two cents... Yes, E2E paradigm could avoid security issues arising from forwarding SIP message among the peers in the overlay. As for hop-by-hop paradigm, if we could make a overlay tunnel between two peers and make sure that the destination peer for the overlay message, for example, GET message, is the same as the peer where the callee hosts, then the destination peer could use the upper layer application information carried in the peer message to de-multiplex and distribute the applications message encapsulated in the peer messages to the specific application protocol entity, for example, SIP protocol stack. The application messages could be protected by the message sender by making use of various security mechanisms and intermediary peer will not process the application message and only forward the messages according to the DHT routing algorithms. If used in this way, overlay will become a general platform to transport various upper layer messages, for example, SIP message. Obviously, peer protocol should support transporting application protocol first and maybe need do some special work to make the application protocol work as it is used in the Client/Server modes. For example, as for SIP, the destination peer will check some headers and Request-URI to determine whether it is a right message, so peer protocol may do some adaptation work to make the destination does not care about how this message arrived at it. I am not sure it could be done. Presenting here is for your comments? Regards! -- Jiang XingFeng > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Saturday, July 14, 2007 5:49 AM > To: P2PSIP WG > Subject: [P2PSIP] HBH vs. E2E SIP in P2PSIP > > draft-bryan-p2psip-requirements-00 talks about how SIP relates to the > P2P protocol. It says: > > > The above discussion suggests at least two paradigms for SIP > > operation in a p2p setting: the end-to-end paradigm where a SIP user > > agent uses the p2p location service to discover the location of > > callee, and then send the SIP message directly to the callee, or a > > hop-by-hop paradigm where each peer forwards the SIP request to a > > peer which is more 'closer' to the callee. The former can be thought > > of as a RPC whereas the later can be thought of as a local procedure > > call to determine the next hop. > > I'd like to propose that, any model which views the peers in the p2p > network as proxies (things that add Via headers, follow proxy rules as > defined in RFC 3261, and so on), is basically fatally flawed from a > security perspective. > > SIP was not designed on a model of untrusted proxies. I know this keeps > coming up time and time again in the core SIP mailing list. The problem > is, the design of SIP quite purposefully gives SIP proxies pretty wide > latitude in manipulating message contents and doing things. We have some > limited protection, if you believe in things like S/MIME, but by its > very definition, SIP allows proxies to do lots of stuff. They can send > requests to different places, they can fork, they can send responses, > they can add and remove headers, they can change the destination of a > request. All of it is legal and makes sense in a proxy-routed model. > > However, in P2PSIP, if you think of the peers as proxies, you enter a > use case where you trust none of the proxies, and in fact every call has > a whole lot of them on the signaling path (O(logN)). I guarantee you > that these untrusted proxies will launch attacks that are hard to fix > without basically completely changing the way the SIP protocol works. > > So, don't do it. > > The way you limit what peers can do is by using a protocol to > communicate with peers whose very design limits what can be done. A > protocol built from the ground up to do nothing but give an intermediary > the ability to move a message around based on DHT topology. You wouldn't > need to worry about things modifying media destinations since there is > no SDP. You needn't worry about spoofing caller ID since there is no > caller ID in the protocol. All you do is use this protocol to allow you > to set up a secure, e2e, TLS connection between you and the UA you want > to talk to, and then run SIP over that. > > The great benefit is that SIP already allows UA to UA communications. It > always has. P2PSIP then slides in as a pure, clean replacement for > RFC3263, allowing you to identify the target UA that you want to connect > to, and provide a means for connecting to them through firewalls and NATs. > > Thus I'd like to suggest that the E2E SIP model described in the > requirements document be the one we are shooting for. > > Thanks, > Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 22:06:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAcSD-00078w-7z; Mon, 16 Jul 2007 22:06:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAcSC-00078q-JN for p2psip@ietf.org; Mon, 16 Jul 2007 22:06:20 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAcS8-00020K-54 for p2psip@ietf.org; Mon, 16 Jul 2007 22:06:20 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2007 19:06:15 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACLBm0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,544,1175497200"; d="scan'208"; a="183192700:sNHT31207959" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6H26FGv016372; Mon, 16 Jul 2007 19:06:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6H26FSb000384; Tue, 17 Jul 2007 02:06:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 19:06:15 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 19:06:14 -0700 Message-ID: <469C241C.2020108@cisco.com> Date: Mon, 16 Jul 2007 22:06:20 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> <1184450797.2D359846@fc9.dngr.org> <91783A02-1B95-4CBC-A81D-EBFE9EA573A4@cs.columbia.edu> In-Reply-To: <91783A02-1B95-4CBC-A81D-EBFE9EA573A4@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 02:06:14.0909 (UTC) FILETIME=[0E1022D0:01C7C817] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2943; t=1184637975; x=1185501975; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20Mandatory-to-implement=20DHTs=20-=20a=20di ssenting=20opinion |Sender:=20; bh=Bjo+1v/7uhJOziqztOzQjjxU1HcMOtNNlbcUMsEwRCw=; b=FWxRsJsv47zCS8qtlYsHQWGEVyNdW6P3nAODDvB9oUvgbIohunSgJhYB+as+tvS/jSvCk0OL wdWpOLA9cyV/Rm87SZOf/E7wB7jd4NViqaYKjvHEvwPvy6xeVsQ7NRJ4; Authentication-Results: sj-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henning, Just to make sure I understand - I clearly agree that a single protocol can support structured overlay maintenance for large classes of DHTs without (much) new protocol machinery for each new DHT. However, I do not think it is possible that, within a single overlay, you have different clients using different DHTs with the same protocol. In other words, some clients run Kademlia, and the others run Chord, all within the same DHT. Do you agree? -Jonathan R. Henning Schulzrinne wrote: > A number of proposals have moved beyond this stage and demonstrated, in > running code or plausible description, that using a single maintenance > and look-up protocol is quite feasible across multiple different DHTs. > Naturally, there is no way to prove that every conceivable DHT that > somebody may invent in the future can be handled by these protocols, but > I see no reason to regress below working code and good reason to suspect > that at least structured overlays can be maintained by these protocols > if they are designed correctly, i.e., without making unwarranted > assumptions. > > DHTs aren't magic. If we ignore the 'distributed' part, DHTs are > essentially graphs, where vertices are network nodes. Just like a 'graph > maintenance protocol' within a host can build new data structures > beyond, say, trees, it is very likely that the protocol proposals can > maintain new distributed structures, as long as they follow that basic > model. The protocol is really not much more than a pointer establishment > mechanism, with lots of machinery to take into account that network > 'pointers' aren't as nicely behaved as pointers in C/C++. > > Henning > > On Jul 14, 2007, at 6:06 PM, David Barrett wrote: > >> Ah, I agree with you here. I like the goal of separating DHT-specific >> code from general shared code. >> >> The one change I'd make to your proposal (as I understand it) is to >> first just pick a single DHT as if it were the only choice, build >> everything exactly around that DHT, and call that P2PSIP 1.0. Then, >> after we've done it once, we'll have a very detailed understanding of >> its real-word issues and can thus figure out the right abstraction >> layer to enable pluggable DHTs. >> >> But my fear is before doing the specific case once from top to bottom, >> it's premature to try to generalize for other types of DHTs. >> >> -david >> > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 22:10:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAcWN-0000zY-GI; Mon, 16 Jul 2007 22:10:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAcWL-0000yb-Rs for p2psip@ietf.org; Mon, 16 Jul 2007 22:10:37 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAcWL-0002q4-Hk for p2psip@ietf.org; Mon, 16 Jul 2007 22:10:37 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 16 Jul 2007 19:10:29 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABLCm0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,544,1175497200"; d="scan'208"; a="386075058:sNHT26850180" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6H2ASUJ023206; Mon, 16 Jul 2007 19:10:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6H2AOA2017685; Tue, 17 Jul 2007 02:10:28 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 19:10:24 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 19:10:24 -0700 Message-ID: <469C2515.5030205@cisco.com> Date: Mon, 16 Jul 2007 22:10:29 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "David A. Bryan" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion References: <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com> <20070716012015.99E246F82AB@mail.sipeerior.com> <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> In-Reply-To: <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 02:10:24.0174 (UTC) FILETIME=[A2A2F4E0:01C7C817] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1621; t=1184638228; x=1185502228; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20Mandatory-to-implement=20DHTs=20-=20a=20di ssenting=20opinion |Sender:=20; bh=o7g9H8ryeWCtui5WvTkgx9zUZJf0BJzPFZQl/RUDgB0=; b=CCcakPNNQlV/h8FqyRw30jtpRYb5Os6VJE6tK7O/H7yd1n71e3945UGdWUyQKy+MAw0Ja1Vb gzw9nnBoJSc6GZLvw8zaYwIowcqR3sqrfqOK5Sw7H7Lj3l/pVqZPfTUw; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David A. Bryan wrote: > Um, I guess I wasn't clear. Sorry. That was precisely the point I was > making, particularly in my second paragraph below (and did in the > email response to Johnathan that started this thread) > > I was trying to say that while valid, Henning's point that the > protocol won't be different if we pick a DHT is irrelevant to the > argument about whether to choose a must implement or not. If we don't > have at least one mandatory to implement, we will have islands of each > vendor's device not working together, and worse, may be forced into > using one specified by a player with large market share that might > have nasty strings attached. Careful here. The choice is really between one of the following two: 1. we don't pick any must-implement DHT; each 'provider' mandates a specific one. We can write specs (and others can too) for how to use the protocol for various DHT. But this is a market-pressure decision. 2. because the DHT is set when the fist node joins and then basically lasts a really long time, you end up with all p2p networks using the one and only mandatory-to-implement DHT. In that case, you haven't really defined a mandatory-to-implement one, as you've picked the one-and-only DHT for p2psip. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 22:15:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAcb0-0005Fq-5S; Mon, 16 Jul 2007 22:15:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAcaw-00056K-8z for p2psip@ietf.org; Mon, 16 Jul 2007 22:15:22 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAcar-0002Cs-Ss for p2psip@ietf.org; Mon, 16 Jul 2007 22:15:22 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2007 19:15:17 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAErDm0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.16,544,1175497200"; d="scan'208"; a="183196358:sNHT36820080" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6H2FHWN015044; Mon, 16 Jul 2007 19:15:17 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l6H2FGTb006150; Tue, 17 Jul 2007 02:15:16 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 19:15:16 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 19:15:16 -0700 Message-ID: <469C2639.9030404@cisco.com> Date: Mon, 16 Jul 2007 22:15:21 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion References: <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com> <20070716012015.99E246F82AB@mail.sipeerior.com> <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 02:15:16.0253 (UTC) FILETIME=[50BAACD0:01C7C818] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1988; t=1184638517; x=1185502517; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20Mandatory-to-implement=20DHTs=20-=20a=20di ssenting=20opinion |Sender:=20; bh=2efvoCV+W4zZggQZOpVM7BH8iLRi9gzxmJ1Q8jdvUTU=; b=MMXe1e04idZ5E3VqPuCoTbw3yucriXp8Y/pnxMCzDOAtYjBPPrTXmvFELgI4YKHJ/ojEE+eQ e5ad9f3yC6sZBSCm6OYos/7mEYfvqiNMgNIYPVye6KuAvcTFfOqC9NK4K9EtN+ZtS7l6kB73NY pzmYYXgI1QtlCflzUCF3FQ3nU=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org inline. Ted Hardie wrote: > The point I think that is missing here in much of this discussion is that > the agility-with-a-default means, in essence, that the default will be > around forever. Some set of overlays will be created with it and some > set of devices/programs will be written such that only the default is > supported. The protocol is agile, but the programs aren't, and the justification > in this case is the standard. Those of us coming from other areas have > seen a lot of cruft piled on cruft to deal with installed base in those cases. > Coming from that background, this decision sounds like a very short-term > win, with a long term cruft penalty that will keep biting for a long, long > time. This is a problem I am also very worried about. Unfortunately, it can't be solved by mandating DHT or picking a mandatory-to-implement one or anything like that. The only way to solve this is by building into the protocol, from day one, standards on how one forms parallel p2p networks, one using a new DHT and one using the old, and how you gradually (over months perhaps) migrate in a coordinated way. This was one of the features in our proposal. Providing this as a core part of the protocol design is one of the real values that IETF can bring to the table. If the protocol, independent of the DHT, doesn't provide for things like security, extensibility and migration, nat traversal, and so on, its just a bit-format. I personally don't see a lot of value in standardizing something that is nothing more than an encoding format for real protocols that someone else defines. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 22:25:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAckM-0006lG-H8; Mon, 16 Jul 2007 22:25:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAckL-0006lB-OQ for p2psip@ietf.org; Mon, 16 Jul 2007 22:25:05 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAckL-00037j-F2 for p2psip@ietf.org; Mon, 16 Jul 2007 22:25:05 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6H2OPiP002583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 16 Jul 2007 22:24:30 -0400 (EDT) In-Reply-To: <469C241C.2020108@cisco.com> References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> <1184450797.2D359846@fc9.dngr.org> <91783A02-1B95-4CBC-A81D-EBFE9EA573A4@cs.columbia.edu> <469C241C.2020108@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Mon, 16 Jul 2007 22:24:22 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Agreed; a DHT "mash up" isn't likely going to work. On Jul 16, 2007, at 10:06 PM, Jonathan Rosenberg wrote: > Henning, > > Just to make sure I understand - I clearly agree that a single > protocol can support structured overlay maintenance for large > classes of DHTs without (much) new protocol machinery for each new > DHT. However, I do not think it is possible that, within a single > overlay, you have different clients using different DHTs with the > same protocol. In other words, some clients run Kademlia, and the > others run Chord, all within the same DHT. Do you agree? > > -Jonathan R. > > Henning Schulzrinne wrote: >> A number of proposals have moved beyond this stage and >> demonstrated, in running code or plausible description, that using >> a single maintenance and look-up protocol is quite feasible across >> multiple different DHTs. Naturally, there is no way to prove that >> every conceivable DHT that somebody may invent in the future can >> be handled by these protocols, but I see no reason to regress >> below working code and good reason to suspect that at least >> structured overlays can be maintained by these protocols if they >> are designed correctly, i.e., without making unwarranted assumptions. >> DHTs aren't magic. If we ignore the 'distributed' part, DHTs are >> essentially graphs, where vertices are network nodes. Just like a >> 'graph maintenance protocol' within a host can build new data >> structures beyond, say, trees, it is very likely that the protocol >> proposals can maintain new distributed structures, as long as they >> follow that basic model. The protocol is really not much more than >> a pointer establishment mechanism, with lots of machinery to take >> into account that network 'pointers' aren't as nicely behaved as >> pointers in C/C++. >> Henning >> On Jul 14, 2007, at 6:06 PM, David Barrett wrote: >>> Ah, I agree with you here. I like the goal of separating DHT- >>> specific code from general shared code. >>> >>> The one change I'd make to your proposal (as I understand it) is >>> to first just pick a single DHT as if it were the only choice, >>> build everything exactly around that DHT, and call that P2PSIP >>> 1.0. Then, after we've done it once, we'll have a very detailed >>> understanding of its real-word issues and can thus figure out the >>> right abstraction layer to enable pluggable DHTs. >>> >>> But my fear is before doing the specific case once from top to >>> bottom, it's premature to try to generalize for other types of DHTs. >>> >>> -david >>> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 22:30:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAcpJ-0001yX-Ir; Mon, 16 Jul 2007 22:30:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAcpI-0001yR-FL for p2psip@ietf.org; Mon, 16 Jul 2007 22:30:12 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAcpI-0003I3-0e for p2psip@ietf.org; Mon, 16 Jul 2007 22:30:12 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2007 19:30:03 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJfFm0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,544,1175497200"; d="scan'208"; a="503835512:sNHT30354070" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6H2U38E009067; Mon, 16 Jul 2007 19:30:03 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6H2Tw6C027394; Tue, 17 Jul 2007 02:29:58 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 19:29:58 -0700 Received: from [10.32.241.147] ([10.32.241.147]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 19:29:58 -0700 Message-ID: <469C29AC.5090202@cisco.com> Date: Mon, 16 Jul 2007 22:30:04 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] Restated question: do we need a client protocol? References: <3F18E76823C95E4795181D74BAC7664F04BAFE71@esebe102.NOE.Nokia.com> <001801c7c2f9$ed8a2f50$a507740a@DELLWEI> <4d4304a00707100710j7bb3d528q886d5a91ec074445@mail.gmail.com> <14C8E3BD-5C43-4F22-9AD0-C5B39DB5623B@softarmor.com> In-Reply-To: <14C8E3BD-5C43-4F22-9AD0-C5B39DB5623B@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2007 02:29:58.0284 (UTC) FILETIME=[5E75ECC0:01C7C81A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3636; t=1184639403; x=1185503403; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20Restated=20question=3A=20do=20we=20need=20 a=20client=20protocol? |Sender:=20; bh=3YpcfkHQA1pUwhUj3JOB8sqdzGAQvy37v/xq5B8J5tI=; b=Mr0WyyQD8ZotcYKOnPMdvmKNdrwNQMEtdpqA/FGZhOZE9Wf3qybRujg0e1mvw7XYnisigcmQ xU8SwIQJVLjREzU/Yd59crjXpLaf7Vbs851HSLBv8zPClNefJtkR/QaC; Authentication-Results: sj-dkim-3; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org inline. Dean Willis wrote: > > On Jul 10, 2007, at 9:10 AM, David A. Bryan wrote: > > >> >> So getting back to the question Brian Rosen raised in Prauge: >> >> Can anyone find a reason we need a client protocol for *SIP* using P2P? > > > Clearly we have a reason to have some nodes that have lesser capacity > and therefore offer fewer resources or services or whatever we might > call them to the overlay. There's absolutely no doubt about this in my > mind -- I think we can take it as a postulate. > > So we're not asking the right question. Let's see if we can get some > better questions: > > 1) Can the range of capacities of nodes be accommodated by one protocol > that includes the ability to turn certain capabilities on and off (so > that lesser-capable nodes could just not offer the things that are hard > for them) or do we need an entirely different protocol for some class of > nodes? > > 2) Assuming that we do need an entirely different protocol for the > least-capable nodes, is there a requirement for the least-capable nodes > to do anything that cannot already be done with SIP? I'm not sure I would classify it as something 'entirely different'; you could probably define it as a subset by just defining the usage of the read and write primitives. That said, I personally think the client protocol is quite orthogonal to the peer protocol, and something where multiple protocols for this might make sense. In some uses, just having a SIP gateway function to provide a SIP interface makes sense. In other uses, something like a SOAP front end that exposes the DHT services to a web server makes sense. In other cases, using something that looks like the p2p protocol makes sense. I view this a lot like the relationship between interior and exterior routing protocols in the Internet. In the backbone, everyone runs BGP. Its the one and only way to move stuff around. BGP is analagous to the peer protocol. But, each node participating in BGP can use a different interior routing protocol - RIP, OSPF, IS-IS, etc., which all serve to define the data that gets pushed into BGP, and defines what to do with the data that comes out. This is exactly our case here. DIfferent nodes in the same P2P network can have different client protocols, and it will all still work. Considering the use case of a wireless client that wants to use the p2p network for SIP, the question is, is the p2p network SIP or should we define something else? The only difference I can think of is bootstrapping techniques, which may differ for p2p compared to regular SIP. So, I am somewhat agnostic on whether we should define a separate client protocol or not. However, I feel strongly that it is orthogonal, and it is something we should keep out of the peer protocol. In the same way it is a mistake to view an interior routing protocol as something you design into your exterior routing protocol, so too should the client protocol be considered separate from the peer protocol. One way to illustrate this is to consider this scenario: if the peer protocol natively allows a node to be a client or a peer, what happens if all of the nodes elect to be clients? That would be bad. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 22:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdFc-0007dd-2v; Mon, 16 Jul 2007 22:57:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdFb-0007dV-4v for p2psip@ietf.org; Mon, 16 Jul 2007 22:57:23 -0400 Received: from an-out-0708.google.com ([209.85.132.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAdFX-0003XJ-TQ for p2psip@ietf.org; Mon, 16 Jul 2007 22:57:23 -0400 Received: by an-out-0708.google.com with SMTP id c17so286746anc for ; Mon, 16 Jul 2007 19:57:19 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lD11g3i6BPvBezX1PxnlMbTzgdV/hU8ascw+icaImBn1ve4+8un2H9uUWFqdNOqDVRjB0pd3H2+oU6JAWrvkzbMd/nh0SEy7NR0TLVa+G+Duhw0O5FpP7e3Xk7JVgdi6EL5gBSsRHtgrdGvN0t7hlpeCU4R3Pjl6cTHehHR7ZHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=ccKO4rs9Fyf3lR87cyI+wVU4APkOvjFung3hv37/wAtmvg4uooUh+o/e8v6mQPF4NEgSqpcEuTdYHhmf1pt4VjgMBDviNzESq56tJ8etuMDzqrtXL/yaCyXqN7JaRl0FUFfQd5LvcZgMcxpoJnM9ao+X8ALXWL7wDLS1/eEqPDQ= Received: by 10.100.167.7 with SMTP id p7mr938ane.1184641039521; Mon, 16 Jul 2007 19:57:19 -0700 (PDT) Received: by 10.100.112.12 with HTTP; Mon, 16 Jul 2007 19:57:19 -0700 (PDT) Message-ID: <20d2bdfb0707161957k69d7195ex5de2bd1bd2f007f@mail.gmail.com> Date: Mon, 16 Jul 2007 22:57:19 -0400 From: "Bruce Lowekamp" To: "Jonathan Rosenberg" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <469C2515.5030205@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com> <20070716012015.99E246F82AB@mail.sipeerior.com> <4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com> <469C2515.5030205@cisco.com> X-Google-Sender-Auth: 52d313adc98af477 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Henry Sinnreich , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 7/16/07, Jonathan Rosenberg wrote: > Careful here. The choice is really between one of the following two: > > 1. we don't pick any must-implement DHT; each 'provider' mandates a > specific one. We can write specs (and others can too) for how to use the > protocol for various DHT. But this is a market-pressure decision. Consider the "Managed, Private Networks" in Section 3.4 of draft-bryan-p2psip-usecases-00. There isn't a "provider" in any of these cases. There may be multiple equipment vendors, in which case we'll probably have the same situations as we do now with audio codecs. (Although since the negotiation isn't pairwise, there will probably be a greater affinity for the base, but there needs to be a base to start with so that equipment from Cisco, Avaya, and Polycom can interoperate.) > > 2. because the DHT is set when the fist node joins and then basically > lasts a really long time, you end up with all p2p networks using the one > and only mandatory-to-implement DHT. In that case, you haven't really > defined a mandatory-to-implement one, as you've picked the one-and-only > DHT for p2psip. I don't think this is really a significant concern. While it is listed as a usecase (3.1.2), I disbelieve that there will be a large-scale open p2p network that will be formed starting with one individual user and then last forever. In this case, there will likely be providers (or at least an enrollment server), which implies that whoever is responsible for administering the overlay will make the choice based on market-pressure. In the first case, I think we need a mandatory DHT to ensure interop. In the second case, since there's a central authority, I don't think the mandatory DHT is relevant. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 16 23:00:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdIc-00022w-Gx; Mon, 16 Jul 2007 23:00:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdIb-00022m-Cc for p2psip@ietf.org; Mon, 16 Jul 2007 23:00:29 -0400 Received: from mclmx2.mail.saic.com ([149.8.64.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAdIW-00047u-3O for p2psip@ietf.org; Mon, 16 Jul 2007 23:00:29 -0400 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx2.mail.saic.com id BT-MMP-2355656; Mon, 16 Jul 2007 23:00:01 -0400 Received: from 0015-its-exbh02.us.saic.com ([10.43.229.22]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2007071623000229302 ; Mon, 16 Jul 2007 23:00:02 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-its-exbh02.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 23:00:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Mon, 16 Jul 2007 23:00:01 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1D1A1@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfGklUEnYRNFoU5R1OPE72WpYJ0CQAAHylTAGI3NfY= References: <4697F02B.4030506@cisco.com><7b683f3f0707142043n38e4f51fg4126ecd02e160da3@mail.gmail.com> <62D92A9A02BCC845B202323D49A48426E1D19C@0591-ITS-EXMP02.us.saic.com> From: "Roy, Radhika R." To: "Jonathan Rosenberg" X-OriginalArrivalTime: 17 Jul 2007 03:00:01.0515 (UTC) FILETIME=[914523B0:01C7C81E] X-Spam-Score: 1.8 (+) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0666057190==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0666057190== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C81E.91737D5F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C81E.91737D5F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks: =20 >From recent Jonathan's emails, it appears as follows: *=09 For each DHT, there will be one DHT-specific P2PSIP overlay network, = but one single common P2PSIP protocol. *=09 That is, all DHT-specific P2PSIP overlay networks will use a single = common P2PSIP protocol. Is this what P2PSIP WG wants to do? Is it the best interest of P2PSIP standardization?=20 Will it not cause problems, as David pointed out and Jonathan also = agreed, the islands of "non-interworking" P2PSIP overlay networks = negating the most benefits of standardization? Can anyone summarize at a very high-level what values the very = "standardization" of so-called P2PSIP protocol will bring to the table = with non-standardized DHT? Best regards, Radhika ________________________________ From: p2psip-bounces@ietf.org on behalf of Roy, Radhika R. Sent: Sun 7/15/2007 12:01 AM To: Eunsoo Shim; Jonathan Rosenberg Cc: P2PSIP WG Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion The example of G.711 codec is NOT exactly right here although some = aspects of this are applicable in the DHT argument. A couple of things = are as follows: 1.=09 All codecs including G.711 use the same SIP signaling protocol 2.=09 G.711 codec has been used as a reference for all other codecs for = interoperability purpose. For example, if audio bridging with multiple = different codecs are done, then all of them need to be converted into a = single common format, and G.711 is used as a reference common format. So, if we analyze items 1 and 2 very carefully, it again proves the = fact, as David pointed out, we need one standard thing as a reference to = start with as follows: * Only "one" reference standard for the signaling protocol (in this case = it is SIP) to provide interoperability=20 * Only "one" reference standard codec that will offer a reference = standard format that will be used for inter-operability among different = codecs As such, what is the lesson from the above from standardization point of = view when we apply those experiences in DHT standardization? Is it not what David has pointed out? Best regards, Radhika ------_=_NextPart_001_01C7C81E.91737D5F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
Folks:
=0A=
 
=0A=
From recent Jonathan's = emails, it appears as follows:
=0A=
    =0A=
  • =0A=
    For each DHT, there will be one = DHT-specific P2PSIP overlay network, but one single common P2PSIP = protocol.
    • =0A=
  • =0A=
    That is, all DHT-specific P2PSIP = overlay networks will use a single common P2PSIP = protocol.
=0A=

Is this what P2PSIP WG wants to = do?

=0A=

Is it the best interest of P2PSIP = standardization?

=0A=

Will it not cause problems, as David = pointed out and Jonathan also agreed, the islands of "non-interworking" = P2PSIP overlay networks negating the most benefits of = standardization?

=0A=

Can anyone summarize at a very high-level = what values the very "standardization" of so-called P2PSIP = protocol will bring to the table with non-standardized = DHT?

=0A=

Best regards,

=0A=

Radhika

=0A=

=0A=
=0A=
=0A=
=0A=
From: = p2psip-bounces@ietf.org on behalf of Roy, Radhika R.
Sent: Sun = 7/15/2007 12:01 AM
To: Eunsoo Shim; Jonathan = Rosenberg
Cc: P2PSIP WG
Subject: RE: [P2PSIP] = Mandatory-to-implement DHTs - a dissenting opinion

=0A=
=0A=
The example = of G.711 codec is NOT exactly right here although some aspects of this = are applicable in the DHT argument. A couple of things are as = follows:
=0A=
=0A=
    =0A=
  1. =0A=
    All codecs including G.711 use the same = SIP signaling protocol
    =0A=
  2. =0A=
    G.711 codec has been used as a = reference for all other codecs for interoperability purpose. For = example, if audio bridging with multiple different codecs are done, then = all of them need to be converted into a single common format, and G.711 = is used as a reference common format.
=0A=

So, if we analyze items 1 and 2 very = carefully, it again proves the fact, as David pointed out, we need one = standard thing as a reference to start with as follows:

=0A=
    =0A=
  • Only "one" reference standard for = the signaling protocol (in this case it is SIP) to provide = interoperability =0A=
  • Only "one" reference standard codec that = will offer a reference standard format that will be used for = inter-operability among different codecs
=0A=

As such, what is the lesson from the = above from standardization point of view when we apply those experiences = in DHT standardization?

=0A=

Is it not what David has pointed = out?

=0A=

Best regards,

=0A=

Radhika

=0A=

------_=_NextPart_001_01C7C81E.91737D5F-- --===============0666057190== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0666057190==-- From p2psip-bounces@ietf.org Mon Jul 16 23:01:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdJS-0004Vc-3W; Mon, 16 Jul 2007 23:01:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdJR-0004VX-7w for p2psip@ietf.org; Mon, 16 Jul 2007 23:01:21 -0400 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAdJN-0003d0-RS for p2psip@ietf.org; Mon, 16 Jul 2007 23:01:21 -0400 Received: from 0015-its-ieg01.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com id BT-MMP-2213548; Mon, 16 Jul 2007 23:01:08 -0400 Received: from 0015-its-exbh02.us.saic.com ([10.43.229.22]) by 0015-its-ieg01.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2007071623010808775 ; Mon, 16 Jul 2007 23:01:08 -0400 Received: from 0591-ITS-EXMP02.us.saic.com ([10.42.81.248]) by 0015-its-exbh02.us.saic.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 23:01:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Mon, 16 Jul 2007 23:00:28 -0400 Message-Id: <62D92A9A02BCC845B202323D49A48426E1D1A2@0591-ITS-EXMP02.us.saic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Thread-Index: AcfIHjhupCwH2my9QQSHV9AFs6cQigAAGklE References: <4d4304a00707151811x3945be15j5da4949f5214d935@mail.gmail.com><20070716012015.99E246F82AB@mail.sipeerior.com><4d4304a00707151831r1cc9b6a2j63a5dca314f450d5@mail.gmail.com><469C2515.5030205@cisco.com> <20d2bdfb0707161957k69d7195ex5de2bd1bd2f007f@mail.gmail.com> From: "Roy, Radhika R." To: "Bruce Lowekamp" , "Jonathan Rosenberg" X-OriginalArrivalTime: 17 Jul 2007 03:01:08.0466 (UTC) FILETIME=[B92D0D20:01C7C81E] X-Spam-Score: 0.5 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0233468624==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0233468624== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C81E.B963349F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C81E.B963349F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 I also agree with Bruce - Radhika =20 ________________________________ From: p2psip-bounces@ietf.org on behalf of Bruce Lowekamp Sent: Mon 7/16/2007 10:57 PM To: Jonathan Rosenberg Cc: Henry Sinnreich; P2PSIP WG Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion On 7/16/07, Jonathan Rosenberg wrote: > Careful here. The choice is really between one of the following two: > > 1. we don't pick any must-implement DHT; each 'provider' mandates a > specific one. We can write specs (and others can too) for how to use = the > protocol for various DHT. But this is a market-pressure decision. Consider the "Managed, Private Networks" in Section 3.4 of draft-bryan-p2psip-usecases-00. There isn't a "provider" in any of these cases. There may be multiple equipment vendors, in which case we'll probably have the same situations as we do now with audio codecs. (Although since the negotiation isn't pairwise, there will probably be a greater affinity for the base, but there needs to be a base to start with so that equipment from Cisco, Avaya, and Polycom can interoperate.) > > 2. because the DHT is set when the fist node joins and then basically > lasts a really long time, you end up with all p2p networks using the = one > and only mandatory-to-implement DHT. In that case, you haven't really > defined a mandatory-to-implement one, as you've picked the = one-and-only > DHT for p2psip. I don't think this is really a significant concern. While it is listed as a usecase (3.1.2), I disbelieve that there will be a large-scale open p2p network that will be formed starting with one individual user and then last forever. In this case, there will likely be providers (or at least an enrollment server), which implies that whoever is responsible for administering the overlay will make the choice based on market-pressure. In the first case, I think we need a mandatory DHT to ensure interop. In the second case, since there's a central authority, I don't think the mandatory DHT is relevant. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------_=_NextPart_001_01C7C81E.B963349F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [P2PSIP] Mandatory-to-implement DHTs - = a dissenting opinion=0A= =0A= =0A= =0A=
=0A=
 
=0A=
I also agree with Bruce - Radhika
=0A=

 
=0A=
=0A=
=0A=
=0A=
From: = p2psip-bounces@ietf.org on behalf of Bruce Lowekamp
Sent: Mon = 7/16/2007 10:57 PM
To: Jonathan Rosenberg
Cc: Henry = Sinnreich; P2PSIP WG
Subject: Re: [P2PSIP] = Mandatory-to-implement DHTs - a dissenting opinion

=0A=
=0A=

On 7/16/07, Jonathan Rosenberg = <jdrosen@cisco.com> wrote:
> Careful here. The choice is = really between one of the following two:
>
> 1. we don't = pick any must-implement DHT; each 'provider' mandates a
> specific = one. We can write specs (and others can too) for how to use the
> = protocol for various DHT. But this is a market-pressure = decision.

Consider the "Managed, Private Networks" in Section 3.4 = of
draft-bryan-p2psip-usecases-00.  There isn't a "provider" in = any of
these cases.  There may be multiple equipment vendors, in = which case
we'll probably have the same situations as we do now with = audio
codecs.  (Although since the negotiation isn't pairwise, = there will
probably be a greater affinity for the base, but there = needs to be a
base to start with so that equipment from Cisco, Avaya, = and Polycom
can interoperate.)

>
> 2. because the DHT = is set when the fist node joins and then basically
> lasts a = really long time, you end up with all p2p networks using the one
> = and only mandatory-to-implement DHT. In that case, you haven't = really
> defined a mandatory-to-implement one, as you've picked = the one-and-only
> DHT for p2psip.

I don't think this is = really a significant concern.  While it is
listed as a usecase = (3.1.2), I disbelieve that there will be a
large-scale open p2p = network that will be formed starting with one
individual user and = then last forever.  In this case, there will
likely be providers = (or at least an enrollment server), which implies
that whoever is = responsible for administering the overlay will make
the choice based = on market-pressure.

In the first case, I think we need a = mandatory DHT to ensure interop.
 In the second case, since = there's a central authority, I don't think
the mandatory DHT is = relevant.

Bruce

___________________________________________= ____
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.= org/mailman/listinfo/p2psip

------_=_NextPart_001_01C7C81E.B963349F-- --===============0233468624== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0233468624==-- From p2psip-bounces@ietf.org Mon Jul 16 23:14:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdW3-0007E0-VI; Mon, 16 Jul 2007 23:14:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAdW2-0007Du-FP for p2psip@ietf.org; Mon, 16 Jul 2007 23:14:22 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAdW2-0004T5-6V for p2psip@ietf.org; Mon, 16 Jul 2007 23:14:22 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IAdVV-000136-1z; Mon, 16 Jul 2007 23:13:49 -0400 In-Reply-To: <4d4304a00707161445ndadaebajde66139aceb2c22d@mail.gmail.com> References: <4d4304a00707161445ndadaebajde66139aceb2c22d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B3558E8-1F8A-4084-A7CB-91168B65870B@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Possible (late) evening additional ad-hoc on Monday at IETF Date: Mon, 16 Jul 2007 23:13:52 -0400 To: David A. Bryan X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think it is worth doing. I have always felt that time at IETF meetings for productive work is too short, and I think that the extra time to discuss the ideas in proposals is valuable. - Philip PS. Why can't we start at 9 pm (21:00)? On 16-Jul-07, at 17:45 , David A. Bryan wrote: > I have spoken with a number of the authors of the various proposed > protocols, as well as with the AD, and there seems to be some interest > in, and likely space available for, an ad-hoc meeting, outside of the > regular Thursday slot, to discuss just the proposed concrete drafts > for peer protocols. > > The idea would be to let the authors of each of the 6 proposed peer > protocols present what their proposal is, with an equal time for > questions/comments from the floor. Probably 10 minutes of > presentation, 10 minutes of questions/comments for each. > > This would be in addition to the time slated at the on the normal > Thursday session. There would be no hums taken or decisions reached at > the Monday meeting -- it would only be time to present/discuss the > proposals. In our real slot on Thursday I want to focus more on the > issues raised by the work of creating the drafts -- this would be > dedicated time to discuss the proposals themselves. > > Here is the bad part...the only slot that appears to be open would be > 10pm-midnight (2200-0000) Monday night/early Tuesday. > > Do people think it is worth doing? Should we add this ad-hoc? > > David > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 17 04:31:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAiTA-0007fW-9I; Tue, 17 Jul 2007 04:31:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAiT7-0007er-Jw for p2psip@ietf.org; Tue, 17 Jul 2007 04:31:41 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAiT3-0005Mc-2x for p2psip@ietf.org; Tue, 17 Jul 2007 04:31:41 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6H8VJri005511; Tue, 17 Jul 2007 11:31:34 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:31:29 +0300 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 11:31:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Possible (late) evening additional ad-hoc on Monday at IETF Date: Tue, 17 Jul 2007 11:34:37 +0300 Message-ID: <3F18E76823C95E4795181D74BAC7664F04CC5F91@esebe102.NOE.Nokia.com> In-Reply-To: <4d4304a00707161445ndadaebajde66139aceb2c22d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Possible (late) evening additional ad-hoc on Monday at IETF Thread-Index: AcfH8qBFOpFePypnS2Kz7x7joho9LgAWNyug References: <4d4304a00707161445ndadaebajde66139aceb2c22d@mail.gmail.com> From: To: , X-OriginalArrivalTime: 17 Jul 2007 08:31:28.0918 (UTC) FILETIME=[DF160360:01C7C84C] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 I think it is a good idea, however the timing is horrible for Europeans:). Anyway I support it. Marcin >-----Original Message----- >From: ext David A. Bryan [mailto:dbryan@sipeerior.com]=20 >Sent: 17 July, 2007 00:45 >To: P2PSIP WG >Subject: [P2PSIP] Possible (late) evening additional ad-hoc on=20 >Monday at IETF > >I have spoken with a number of the authors of the various=20 >proposed protocols, as well as with the AD, and there seems to=20 >be some interest in, and likely space available for, an ad-hoc=20 >meeting, outside of the regular Thursday slot, to discuss just=20 >the proposed concrete drafts for peer protocols. > >The idea would be to let the authors of each of the 6 proposed=20 >peer protocols present what their proposal is, with an equal=20 >time for questions/comments from the floor. Probably 10=20 >minutes of presentation, 10 minutes of questions/comments for each. > >This would be in addition to the time slated at the on the=20 >normal Thursday session. There would be no hums taken or=20 >decisions reached at the Monday meeting -- it would only be=20 >time to present/discuss the proposals. In our real slot on=20 >Thursday I want to focus more on the issues raised by the work=20 >of creating the drafts -- this would be dedicated time to=20 >discuss the proposals themselves. > >Here is the bad part...the only slot that appears to be open=20 >would be 10pm-midnight (2200-0000) Monday night/early Tuesday. > >Do people think it is worth doing? Should we add this ad-hoc? > >David > >-- >David A. Bryan >dbryan@SIPeerior.com >+1.757.565.0101 x101 >+1.757.565.0088 (fax) >www.SIPeerior.com > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 17 07:00:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAknY-0003De-NB; Tue, 17 Jul 2007 07:00:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAknX-0003DT-5C for p2psip@ietf.org; Tue, 17 Jul 2007 07:00:55 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAknT-0001sJ-EU for p2psip@ietf.org; Tue, 17 Jul 2007 07:00:55 -0400 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 <0JLB005Y3L7VMB@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 18:59:55 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLB00F9SL7U9W@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 18:59:55 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLB006O1L7ROP@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 17 Jul 2007 18:59:54 +0800 (CST) Date: Tue, 17 Jul 2007 18:59:51 +0800 From: JiangXingFeng To: 'P2PSIP WG' Message-id: <000101c7c861$997fc920$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfIYYLSvKDsow29RZyy+786PsVDAAAAAgcg X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Subject: [P2PSIP] FW: some comments on P2PP protocol X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Sorry, forget to copy the P2PSIP community. -- Jiang XingFeng > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Tuesday, July 17, 2007 6:59 PM > To: 'Salman Abdul Baset'; 'hgs@cs.columbia.edu' > Subject: some comments on P2PP protocol > > Hi, > Some comments on draft-baset-p2psip-p2pp-00 are followed. > > 1. In section 4.1, the draft says that Client and peers communicate using the same > protocol as peers do, i.e., there is no distinct protocol for client-to-peer and > peer-to-peer communication. > > Does it mean that Publish, lookupObject, RemoveObject could be used by clients in > the same way as the peer uses them? If it does, how do clients fill the peer-info field > in these messages? After all, clients have no peer ID which peers have. > > 2. In section 5.2.1, it seems that peer will add copy of its routing table and neighbor > table in both directions, not only during forwarding request, but also during > forwarding response. It will add the copy two times and it is enough to do the > operation in either direction. > > 3. In the draft, when a peer receives a request, it will look up the routing table and > find out whether it could give the definitive answer for this request. What does the > definitive answer mean? Does it mean that P2PP protocol will check whether the > peer is the destination peer, then look up in the resource table to get a resource > object keyed by the resource ID? Most of the P2P systems give the definitive > answer according to the above rule. > > But if there are some caches of the resource in the overlay, maybe it could be > incorporated into the resource table and it could be used to answer the request. But > this method may destroy the DHT rule, i,e, peers which are not the resource's root > could give the response. What about your opinions? > > 4. As for Peer-info, how about adding a field to identify which add-on services the > peer supports? In P2PSIP, peers must support routing and storage service. But > maybe some peers may have additional services, for example, STUN or TURN, > which could be used by the other peers. By carrying the service which the peer > supports may facilitate the discovery of these services in the overlay? Comments? > > > > Regards > -- > Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 17 07:56:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAlez-0002TR-E6; Tue, 17 Jul 2007 07:56:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAley-0002TI-RT for p2psip@ietf.org; Tue, 17 Jul 2007 07:56:08 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAleu-0004CK-Av for p2psip@ietf.org; Tue, 17 Jul 2007 07:56:08 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Tue, 17 Jul 2007 04:56:00 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6HBtsWs007029; Tue, 17 Jul 2007 04:55:59 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6HBs0IB011206; Tue, 17 Jul 2007 04:54:00 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 04:55:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Possible (late) evening additional ad-hoc on Monday atIETF Date: Tue, 17 Jul 2007 04:55:30 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AAA206@namail5.corp.adobe.com> In-Reply-To: <3F18E76823C95E4795181D74BAC7664F04CC5F91@esebe102.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Possible (late) evening additional ad-hoc on Monday atIETF Thread-Index: AcfH8qBFOpFePypnS2Kz7x7joho9LgAWNyugAAdqwCA= References: <4d4304a00707161445ndadaebajde66139aceb2c22d@mail.gmail.com> <3F18E76823C95E4795181D74BAC7664F04CC5F91@esebe102.NOE.Nokia.com> From: "Henry Sinnreich" To: , X-OriginalArrivalTime: 17 Jul 2007 11:55:53.0006 (UTC) FILETIME=[6D0D54E0:01C7C869] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >the only slot that appears to be open=20 >would be 10pm-midnight (2200-0000) Monday night/early Tuesday. Please count me in. Thanks, Henry >-----Original Message----- >From: ext David A. Bryan [mailto:dbryan@sipeerior.com]=20 >Sent: 17 July, 2007 00:45 >To: P2PSIP WG >Subject: [P2PSIP] Possible (late) evening additional ad-hoc on=20 >Monday at IETF > >I have spoken with a number of the authors of the various=20 >proposed protocols, as well as with the AD, and there seems to=20 >be some interest in, and likely space available for, an ad-hoc=20 >meeting, outside of the regular Thursday slot, to discuss just=20 >the proposed concrete drafts for peer protocols. > >The idea would be to let the authors of each of the 6 proposed=20 >peer protocols present what their proposal is, with an equal=20 >time for questions/comments from the floor. Probably 10=20 >minutes of presentation, 10 minutes of questions/comments for each. > >This would be in addition to the time slated at the on the=20 >normal Thursday session. There would be no hums taken or=20 >decisions reached at the Monday meeting -- it would only be=20 >time to present/discuss the proposals. In our real slot on=20 >Thursday I want to focus more on the issues raised by the work=20 >of creating the drafts -- this would be dedicated time to=20 >discuss the proposals themselves. > >Here is the bad part...the only slot that appears to be open=20 >would be 10pm-midnight (2200-0000) Monday night/early Tuesday. > >Do people think it is worth doing? Should we add this ad-hoc? > >David > >-- >David A. Bryan >dbryan@SIPeerior.com >+1.757.565.0101 x101 >+1.757.565.0088 (fax) >www.SIPeerior.com > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 17 09:02:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmh7-0003vs-AR; Tue, 17 Jul 2007 09:02:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmh2-0003hF-Iq for p2psip@ietf.org; Tue, 17 Jul 2007 09:02:20 -0400 Received: from ihemail2.lucent.com ([135.245.0.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAmh1-0006YN-90 for p2psip@ietf.org; Tue, 17 Jul 2007 09:02:20 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id l6HD2EvD020065; Tue, 17 Jul 2007 08:02:14 -0500 (CDT) Received: from [135.104.54.151] (vkg-c1.research.bell-labs.com [135.104.54.151]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l6HD2Ea24934; Tue, 17 Jul 2007 08:02:14 -0500 (CDT) Message-ID: <469CBDDA.8050109@alcatel-lucent.com> Date: Tue, 17 Jul 2007 08:02:18 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: JiangXingFeng Subject: Re: [P2PSIP] HBH vs. E2E SIP in P2PSIP References: <000f01c7c815$b88598a0$6905a40a@china.huawei.com> In-Reply-To: <000f01c7c815$b88598a0$6905a40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org JiangXingFeng wrote: > Hi, Jonathan: > > My two cents... Yes, E2E paradigm could avoid security issues arising > from forwarding SIP message among the peers in the overlay. As for > hop-by-hop paradigm, if we could make a overlay tunnel between two > peers and make sure that the destination peer for the overlay > message, for example, GET message, is the same as the peer where the > callee hosts, then the destination peer could use the upper layer > application information carried in the peer message to de-multiplex > and distribute the applications message encapsulated in the peer > messages to the specific application protocol entity, for example, > SIP protocol stack. [...] > I am not sure it could be done. Presenting here is for your comments? It can. See the sipsec URI scheme at http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01 We have an implementation of this as well. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 17 13:39:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAr0o-0007Ua-8H; Tue, 17 Jul 2007 13:39:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAr0m-0007UK-PA for p2psip@ietf.org; Tue, 17 Jul 2007 13:39:01 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAr0l-0008Mn-Ej for p2psip@ietf.org; Tue, 17 Jul 2007 13:39:00 -0400 Received: by py-out-1112.google.com with SMTP id f31so5268433pyh for ; Tue, 17 Jul 2007 10:38:59 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Nb2GgDxIAlzQu5zgu2om3914OMqwACOulsUno+jPsXY6xeO0CxEsONdB8BkQuXKrPFcuxNhyXgj8C+b9GnwGTc+Sn03qjZBAbNjtUlycgi6MbWER4vtLZq/Gn2Ul7RCv6fctTtiTjwJ/AZ7//VSBfTi95/k00kaGvT1jbWkQDZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=OtoxaXTouWmi2ZD6J/aP03yL3fPMHLDT8aiVZJWmFvhXrSJTSvqdjAo50BVa1ChSCt7Mf+2RqB+laxnlhIBLjWy+AwHrEGCWpIViogWaXKRIBM2r3HTTQCO/ouOKIsMRfeuPIHKYhnejfnb1GiEEWx3NB0o0NswsFyekP5uZNZs= Received: by 10.65.151.6 with SMTP id d6mr1263661qbo.1184693938805; Tue, 17 Jul 2007 10:38:58 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Tue, 17 Jul 2007 10:38:58 -0700 (PDT) Message-ID: <4d4304a00707171038s6dde1ef9iedfbfbde1a48cb0a@mail.gmail.com> Date: Tue, 17 Jul 2007 13:38:58 -0400 From: "David A. Bryan" To: "Philip Matthews" Subject: Re: [P2PSIP] Possible (late) evening additional ad-hoc on Monday at IETF In-Reply-To: <1B3558E8-1F8A-4084-A7CB-91168B65870B@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d4304a00707161445ndadaebajde66139aceb2c22d@mail.gmail.com> <1B3558E8-1F8A-4084-A7CB-91168B65870B@magma.ca> X-Google-Sender-Auth: 399ad9a84158cb4e X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org 9 pm cuts things too close for dinner. Ecrit (which many people from P2PSIP will want to attend) runs until 7:50, and people familiar with the area tell me getting dinner and getting back on time seems tight. It sounds like there were quite a few people interested, despite the awful time. Let's plan to try to meet then. I'll send more details as I firm things up. David On 7/16/07, Philip Matthews wrote: > I think it is worth doing. > I have always felt that time at IETF meetings for productive work > is too short, and I think that the extra time to discuss the ideas in > proposals > is valuable. > > - Philip > > PS. Why can't we start at 9 pm (21:00)? > > > On 16-Jul-07, at 17:45 , David A. Bryan wrote: > > > I have spoken with a number of the authors of the various proposed > > protocols, as well as with the AD, and there seems to be some interest > > in, and likely space available for, an ad-hoc meeting, outside of the > > regular Thursday slot, to discuss just the proposed concrete drafts > > for peer protocols. > > > > The idea would be to let the authors of each of the 6 proposed peer > > protocols present what their proposal is, with an equal time for > > questions/comments from the floor. Probably 10 minutes of > > presentation, 10 minutes of questions/comments for each. > > > > This would be in addition to the time slated at the on the normal > > Thursday session. There would be no hums taken or decisions reached at > > the Monday meeting -- it would only be time to present/discuss the > > proposals. In our real slot on Thursday I want to focus more on the > > issues raised by the work of creating the drafts -- this would be > > dedicated time to discuss the proposals themselves. > > > > Here is the bad part...the only slot that appears to be open would be > > 10pm-midnight (2200-0000) Monday night/early Tuesday. > > > > Do people think it is worth doing? Should we add this ad-hoc? > > > > David > > > > -- > > David A. Bryan > > dbryan@SIPeerior.com > > +1.757.565.0101 x101 > > +1.757.565.0088 (fax) > > www.SIPeerior.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 10:04:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBA8V-00039s-2N; Wed, 18 Jul 2007 10:04:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBA8S-00031h-Cv for p2psip@ietf.org; Wed, 18 Jul 2007 10:04:12 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBA8Q-0002vX-Pi for p2psip@ietf.org; Wed, 18 Jul 2007 10:04:11 -0400 Received: from [72.87.190.128] (helo=[192.9.200.1]) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IBA8P-0004Y5-IQ for p2psip@ietf.org; Wed, 18 Jul 2007 10:04:10 -0400 Message-ID: <469E2CA8.3040006@idssoftware.com> Date: Wed, 18 Jul 2007 07:07:20 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: P2PSIP Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940f210cb0b2b005c0286f624682e76f947350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 72.87.190.128 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [P2PSIP] A DHT question on peers running out of storage X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, I have a general DHT question. Say peer X joint the overlay. When another peer registers a resource that should be stored in X, X runs out of storage space for this particular resource. What happen? 1) Should X resign from the overlay? 2) Reply resource registration failure and stay in the overlay? 3) Reply registration success but later reply "not found" when asked for this resource? In this case, the querying party will try the replica peers of this resource. Thanks Michael Chen IDS Software _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 10:53:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAtq-00007G-3p; Wed, 18 Jul 2007 10:53:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAtn-00006t-Ay for p2psip@ietf.org; Wed, 18 Jul 2007 10:53:07 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBAtm-0003ES-1Q for p2psip@ietf.org; Wed, 18 Jul 2007 10:53:07 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IBAtc-0003rj-TY; Wed, 18 Jul 2007 09:52:57 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Jonathan Rosenberg'" References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> <1184450797.2D359846@fc9.dngr.org><91783A02-1B95-4CBC-A81D-EBFE9EA573A4@cs.columbia.edu><469C241C.2020108@cisco.com> Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Wed, 18 Jul 2007 10:53:02 -0400 Message-ID: <154801c7c94b$58b11940$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfIGbIIEYdsmv2tSPmG4tyE5H5GnQBMFyGw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The whole "pluggable DHTs" is not a protocol issue at all, it's an implementation issue. It affects how the code on one peer is written, not how peers interact. I look at the question pretty simply: if I build an implementation and you build an implementation they will interoperate if we have a common DHT and they won't if they don't. It does not bother me AT ALL that it locks in a particular DHT. I think that problem is so far down the list of worries, that it should not enter into the discussion. I think the problem of any 10 implementations not having a DHT in common is not only likely, but guaranteed unless there is a mandatory-to-implement DHT. I think a particular overlay could choose another DHT knowing that not all implementations would work. No problem. If an overlay wants all implementations to work, they pick the mandatory-to-implement one. No problem. Especially in an ad-hoc case, at least for the use cases I'm interested in, it is vital that every device works. I need a choice that I know will work. The only cost to a mandatory to implement DHT is the code that implements it. If you all are into pluggable, it's probably common open source code. This means a tradeoff of universal compatibility WHEN YOU WANT IT for some test time. That's a no-brainer to me. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, July 16, 2007 10:24 PM > To: Jonathan Rosenberg > Cc: P2PSIP WG > Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > > Agreed; a DHT "mash up" isn't likely going to work. > > On Jul 16, 2007, at 10:06 PM, Jonathan Rosenberg wrote: > > > Henning, > > > > Just to make sure I understand - I clearly agree that a single > > protocol can support structured overlay maintenance for large > > classes of DHTs without (much) new protocol machinery for each new > > DHT. However, I do not think it is possible that, within a single > > overlay, you have different clients using different DHTs with the > > same protocol. In other words, some clients run Kademlia, and the > > others run Chord, all within the same DHT. Do you agree? > > > > -Jonathan R. > > > > Henning Schulzrinne wrote: > >> A number of proposals have moved beyond this stage and > >> demonstrated, in running code or plausible description, that using > >> a single maintenance and look-up protocol is quite feasible across > >> multiple different DHTs. Naturally, there is no way to prove that > >> every conceivable DHT that somebody may invent in the future can > >> be handled by these protocols, but I see no reason to regress > >> below working code and good reason to suspect that at least > >> structured overlays can be maintained by these protocols if they > >> are designed correctly, i.e., without making unwarranted assumptions. > >> DHTs aren't magic. If we ignore the 'distributed' part, DHTs are > >> essentially graphs, where vertices are network nodes. Just like a > >> 'graph maintenance protocol' within a host can build new data > >> structures beyond, say, trees, it is very likely that the protocol > >> proposals can maintain new distributed structures, as long as they > >> follow that basic model. The protocol is really not much more than > >> a pointer establishment mechanism, with lots of machinery to take > >> into account that network 'pointers' aren't as nicely behaved as > >> pointers in C/C++. > >> Henning > >> On Jul 14, 2007, at 6:06 PM, David Barrett wrote: > >>> Ah, I agree with you here. I like the goal of separating DHT- > >>> specific code from general shared code. > >>> > >>> The one change I'd make to your proposal (as I understand it) is > >>> to first just pick a single DHT as if it were the only choice, > >>> build everything exactly around that DHT, and call that P2PSIP > >>> 1.0. Then, after we've done it once, we'll have a very detailed > >>> understanding of its real-word issues and can thus figure out the > >>> right abstraction layer to enable pluggable DHTs. > >>> > >>> But my fear is before doing the specific case once from top to > >>> bottom, it's premature to try to generalize for other types of DHTs. > >>> > >>> -david > >>> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Cisco Fellow Parsippany, NJ > > 07054-2711 > > Cisco Systems > > jdrosen@cisco.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.cisco.com > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 11:23:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBMs-0002ad-QP; Wed, 18 Jul 2007 11:23:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBMr-0002aP-FW for p2psip@ietf.org; Wed, 18 Jul 2007 11:23:09 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBBMp-0005Hs-4p for p2psip@ietf.org; Wed, 18 Jul 2007 11:23:09 -0400 Received: from source ([192.150.20.142]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 08:22:58 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IFMjWs023272; Wed, 18 Jul 2007 08:22:51 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IFMN0c010827; Wed, 18 Jul 2007 08:22:34 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 08:22:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 08:22:18 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED6D1@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAP2UuA= From: "Henry Sinnreich" To: X-OriginalArrivalTime: 18 Jul 2007 15:22:23.0197 (UTC) FILETIME=[709830D0:01C7C94F] X-Spam-Score: 0.0 (/) X-Scan-Signature: ecc3a678f36d06d556925e6a5174d2ac Cc: Philip Matthews Subject: [P2PSIP] FW: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0531814677==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0531814677== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C94F.6FB233A3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C94F.6FB233A3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable On 2nd thought, since ICE and the "hole punching for p2p" are of interest for P2PSIP, I though I would share this with the WG. Sorry for any duplicate messages you may have seen from the other lists. ________________________________ From: Henry Sinnreich=20 Sent: Wednesday, July 18, 2007 7:20 AM To: 'Magnus Westerlund' Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC =20 Magnus, =20 I sincerely appreciate your interest and this note! =20 > I don't quite understand why you are requesting a status change of ICE =20 However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas the facts are some cause for serious concern, and I will just mention a few facts: =20 RFC 3489 (STUN) was also presented as a NAT traversal solution back in 2003, but now clearly admits that "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution." http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-07.txt My guess is, in plain English, RFC 3489 turned out just NOT to be an acceptable solution as it was hoped to be.=20 =20 The excellent I-D shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) require 66 messages just for the SIP INVITE! http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-scenarios-07. txt=20 What happens if the two endpoints are in different ISPs that have NAT of their own in addition to the ones in Fig. 22? What happens if one would try ICE along a P2PSIP route with say 5-8 hops? Would there be hundreds of messages? What is the likelihood for failure? =20 By contrast with such approaches based on hope and faith, the BEHAVE WG has produced work based on real measurements and tools to do the measurements, such as =20 "NAT Classification Test Results" =20 "Application Design Guidelines for Traversal through Network Address Translators"=20 The measurements for hole punching are reported in "Peer-to-Peer Communication Across Network Address Translators"=20 http://www.brynosaurus.com/pub/net/p2pnat/ =20 I am also a believer in ICE and have actually urged Jonathan Rosenberg to do this work and he has given his best. Now that we have ICE-17 version, it is in the best interest of the industry and the IETF to make it an experimental RFC, but not yet a standard so that: 1. Independent, compliant implementations will be developed, 2. Testing in events such as SIPit, 3. Reporting the results, such as reported for the "hole punching" above. =20 What happens if indeed hole punching proves to be the far more effective approach? =20 The industry can ill afford a new series of RFC[ICE]-bis and all the years it takes to move from believing to measuring and proving. I am sure IETF procedures were meant in this spirit (though I am not good in producing the right quotes). =20 Thanks again for your attention to this concern about ICE.=20 Also my apology to all the anguish to the numerous contributors to the ICE related I-Ds, but writing test tools and reporting measurements is the right way to go. =20 Henry =20 =20 -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: Wednesday, July 18, 2007 1:11 AM To: Henry Sinnreich Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC =20 Henry Sinnreich skrev: > Following some discussions and soul searching, the best approach for > ICE-17 for LC would be to _go ahead and make it an experimental RFC_. >=20 > This would support the development of interoperable implementations, the > collection of deployment data and also hopefully open source code. >=20 > Though I have full faith in ICE, following the practices that made the > IETF successful take precedent here, I believe. >=20 > This is a change from the attached that I wrote on 7/16/2007. >=20 > Note: We can only hope the proliferation of SBC in VoIP service provider > networks will not make these concerns and ICE for SIP a moot issue, but > this is another topic. =20 Henry, =20 I don't quite understand why you are requesting a status change of ICE?=20 To me it appears that ICE is almost finished spec. It has been=20 implemented, used and feedback has been influencing the protocol. It is=20 definitly one of the better examples of current IETF work that actually=20 has running code. Sure, the implementations may not be fully updated yet to the latest draft version. But I think it is safe to say that ICE=20 works in the intended core cases. If there are some corner cases where=20 it fails, that may be. But that is not information we will have until=20 really large scale deployement or someone makes very extensive tests. =20 I think the IETF and the Internet has much more benefit from a standards track solution than any of the risks existing with ICE of today. =20 And to be clear, proposed standard is allowed to be published without a=20 single implementation exists. It might not be good practice, but it is=20 allowed by our process. And as I said before ICE has had enough=20 implementation that I am very confortable in balloting YES for it when=20 it appears on the IESGs table. =20 Cheers =20 Magnus Westerlund =20 IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM/M ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- ------_=_NextPart_001_01C7C94F.6FB233A3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

On 2nd thought, since = ICE and the “hole punching for p2p” are of interest for P2PSIP, I = though I would share this with the WG. Sorry for any duplicate messages you may = have seen from the other lists.

From: = Henry Sinnreich
Sent: Wednesday, July 18, = 2007 7:20 AM
To: 'Magnus = Westerlund'
Cc: mmusic@ietf.org; = sip@ietf.org; behave@ietf.org
Subject: RE: [BEHAVE] Re: = ICE deployment data before LC for RFC

 

Magnus,

 

I sincerely appreciate your interest and this = note!

 

> I don't quite understand why you are requesting a status = change of ICE

 

However the arguments stated by the WG co-chairs and by you here are procedural in nature, whereas = the facts are some cause for serious concern, and I will just mention a few = facts:

 

RFC 3489 (STUN) was also presented as a NAT traversal solution = back in 2003, but <draft-ietf-behave-rfc3489bis-07> now clearly admits = that "STUN is not a NAT traversal solution by itself. Rather, it is a = tool to be used in the context of a NAT traversal solution. This is an important = change from the previous version of this specification (RFC 3489), which = presented STUN as a complete solution."

http://www.ietf.org/internet-drafts/draft-ietf-behave-rfc3489bis-= 07.txt

My guess is, in plain English, RFC 3489 turned out just NOT to = be an acceptable solution as it was hoped to be.

 

The excellent I-D <draft-ietf-sipping-nat-scenarios-07> = shows the ICE call flow with two endpoints behind two NAT (Fig. 22 on page 38) = require 66 messages just for the SIP INVITE!

http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sc= enarios-07.txt

What happens if the two endpoints are in different ISPs that = have NAT of their own in addition to the ones in Fig. = 22?

What happens if one would try ICE along a P2PSIP route with say = 5-8 hops? Would there be hundreds of messages? What is the likelihood for = failure?

 

By contrast with such approaches based on hope and faith, the = BEHAVE WG has produced work based on real measurements and tools to do the = measurements, such as

 

"NAT Classification Test = Results"

 

"Application Design Guidelines for Traversal through = Network Address Translators"

The measurements for hole punching are reported = in

"Peer-to-Peer Communication Across Network Address Translators"

http://www.brynosauru= s.com/pub/net/p2pnat/

 

I am also a believer in ICE and have actually urged Jonathan Rosenberg to do = this work and he has given his best. Now that we have ICE-17 version, it is in the = best interest of the industry and the IETF to make it an experimental RFC, = but not yet a standard so that:

 1. Independent, compliant implementations will be = developed,

 2. Testing in events such as = SIPit,

 3. Reporting the results, such as reported for the = "hole punching" above.

 

What happens if indeed hole punching proves to be the far more effective approach?

 

The industry can ill afford a new series of RFC[ICE]-bis and all = the years it takes to move from believing to measuring and proving. I am = sure IETF procedures were meant in this spirit (though I am not good in producing the right = quotes).

 

Thanks again for your attention to this concern about ICE. =

Also my apology to all the anguish to the numerous contributors = to the ICE related I-Ds, but writing test tools and reporting measurements is = the right way to go.

 

Henry

 

 

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Wednesday, July 18, 2007 1:11 AM
To: Henry Sinnreich
Cc: mmusic@ietf.org; sip@ietf.org; = behave@ietf.org
Subject: Re: [BEHAVE] Re: ICE deployment data before LC for = RFC

 

Henry = Sinnreich skrev:

> Following some discussions and soul searching, the best = approach for

> ICE-17 for LC would be to _go ahead and make it an = experimental RFC_.

>

> This would support the development of interoperable implementations, the

> collection of deployment data and also hopefully open = source code.

>

> Though I have full faith in ICE, following the practices = that made the

> IETF successful take precedent here, I = believe.

>

> This is a change from the attached that I wrote on = 7/16/2007.

>

> Note: We can only hope the proliferation of SBC in VoIP = service provider

> networks will not make these concerns and ICE for SIP a = moot issue, but

> this is another topic.

 

Henry,

 

I don't quite understand why you are requesting a status change = of ICE?

To me it appears that ICE is almost finished spec. It has been =

implemented, used and feedback has been influencing the = protocol. It is

definitly one of the better examples of current IETF work that = actually

has running code. Sure, the implementations may not be fully = updated yet

to the latest draft version. But I think it is safe to say that = ICE

works in the intended core cases. If there are some corner cases = where

it fails, that may be. But that is not information we will have = until

really large scale deployement or someone makes very extensive = tests.

 

I think the IETF and the Internet has much more benefit from a standards

track solution than any of the risks existing with ICE of = today.

 

And to be clear, proposed standard is allowed to be published = without a

single implementation exists. It might not be good practice, but = it is

allowed by our process. And as I said before ICE has had enough =

implementation that I am very confortable in balloting YES for = it when

it appears on the IESGs table.

 

Cheers

 

Magnus Westerlund

 

IETF Transport Area Director & TSVWG = Chair

-----------------------------------------------------------------= -----

Multimedia Technologies, Ericsson Research = EAB/TVM/M

-----------------------------------------------------------------= -----

Ericsson AB      = ;          | Phone +46 8 4048287

Torshamsgatan 23           | Fax   +46 8 7575550

S-164 80 Stockholm, Sweden | mailto: = magnus.westerlund@ericsson.com

-----------------------------------------------------------------= -----

------_=_NextPart_001_01C7C94F.6FB233A3-- --===============0531814677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0531814677==-- From p2psip-bounces@ietf.org Wed Jul 18 15:20:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBF4w-0006sX-Dq; Wed, 18 Jul 2007 15:20:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBF4r-0006gx-Vh; Wed, 18 Jul 2007 15:20:50 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBF4r-0003p9-3f; Wed, 18 Jul 2007 15:20:49 -0400 Received: from source ([192.150.11.134]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:20:40 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IJJJot025959; Wed, 18 Jul 2007 12:19:20 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IJKI0i013432; Wed, 18 Jul 2007 12:20:34 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:20:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jul 2007 12:20:22 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> In-Reply-To: <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84A== References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> From: "Henry Sinnreich" To: "Dan Wing" , "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 19:20:26.0798 (UTC) FILETIME=[B248BCE0:01C7C970] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: sip@ietf.org, Philip Matthews , behave@ietf.org, mmusic@ietf.org, p2psip@ietf.org Subject: [P2PSIP] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dan, What you say makes sense but there is a lingering suspicion that after admitting that RFC 3489 (STUN), RFC 4091, 4092 (ANAT), etc. just don't work is that such paper evaluations are in no way a replacement for proof and measurements. We still need an explanation why the right approach cannot be taken: * Publish open source code at Sourceforge.net or similar, * Publish a test tool as well, * Gather and publish the results, possibly involving SIPit or another, * Perfect the OS code and the protocol until it works OK. This has been done for "Hole Punching for P2P" in=20 http://www.brynosaurus.com/pub/net/p2pnat/=20 What if ICE proves to be no better than its predecessors?=20 So how can one compare something that has tools, measured and published results with something like ICE that we have to take on pure faith? My assumption is that hole punching is much more effective for P2PSIP and I have copied the P2PSIP WG on this. The ratio of messages is probably 5:1 or higher for ICE vs. hole punching and this is critical when routing a P2PSIP message over an overlay in 5-10 hops. Of course I cannot prove it since as yet ICE cannot be measured. Let's do ICE the right way, there is too much at stake here. Henry -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com]=20 Sent: Wednesday, July 18, 2007 1:19 PM To: Henry Sinnreich; 'Magnus Westerlund' Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: RE: [BEHAVE] Re: ICE deployment data before LC for RFC > The excellent I-D shows=20 > the ICE call flow with two endpoints behind two NAT (Fig. 22=20 > on page 38) require 66 messages just for the SIP INVITE! >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-sce > narios-07.txt=20 That figure does not show 66 messages. That figure is clearly showing how the STUN messages are NATted, which leads to an incorrect conclusion around the number of=20 messages. Specifically, for example, it shows this message exchange which might be counted as "four messages"; yet, there are only two messages (the allocate request and the allocate response), which are NATted: L NAT STUN =20 Server | | | =20 |(1) Alloc Req | | =20 |Src=3DL-PRIV-1 | | =20 |Dest=3DSTUN-PUB-1 | | =20 |--------------->| | =20 | | | =20 | |(2) Alloc Req | =20 | |Src=3DL-NAT-PUB-1 | =20 | |Des=3DSTUN-PUB-1 | =20 | |--------------->| =20 | | | =20 | |(3) Alloc Resp | =20 | |<---------------| =20 | |Src=3DSTUN-PUB-1 | =20 | |Dest=3DL-NAT-PUB-1| =20 | |Map=3DL-NAT-PUB-1 | =20 | |Rel=3DSTUN-PUB-2 | =20 | | | =20 |(4) Alloc Resp | | =20 |<---------------| | =20 |Src=3DSTUN-PUB-1 | | =20 |Dest=3DL-PRIV-1 | | =20 |Map=3DL-NAT-PUB-1 | | =20 |Rel=3DSTUN-PUB-2 | | =20 | | | =20 If we added another NAT on that path, the number of messages on the network does not double. The number of messages on=20 the network stays the same -- the messages merely have their IP and UDP headers rewritten by the NATs. That NAT function does not increase the number of messages on the network. Similarly, another message shown in that same figure is also one message; however, it's shown as two messages: L NAT STUN NAT R Server |(9) SIP INVITE | | | | |------------------------------------------------->| | | | | |(10) SIP INVITE | | | | |--------------->| As you know, there aren't two messages -- it's one message that is NATted. If message 9 and 10 were shown as clearly as messages 1-4, messages 9-10 would be shown as four messages (one from L to its NAT, another=20 from NAT to NAT, and the forth (shown) from NAT to R). But this is just one SIP message, which is NATted. It is inaccurate to count it as two separate messages or as four separate messages, because it is only one packet that is NATted. Counting a STUN packet, or a DNS packet, as a separate message each time it traverses a=20 NAT is similarly inaccurate. By my count, figure 22 exchanges 24 STUN/ICE messages and 6=20 SIP messages. > What happens if the two endpoints are in different ISPs that=20 > have NAT of their own in addition to the ones in Fig. 22? The same 24 STUN/ICE messages would be exchanged, and the same 6 SIP messages would be exchanged. > What happens if one would try ICE along a P2PSIP route with=20 > say 5-8 hops? The SIP signaling messages would traverse those 5-8 additional=20 hops between the P2PSIP nodes participating in the SIP proxy overlay. The STUN/ICE messages are sent peer-to-peer, and=20 would remain the same 24 messages if you're doing the same=20 Figure 22 flow. =20 > Would there be hundreds of messages? No. -d _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 15:32:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFFi-0000fC-75; Wed, 18 Jul 2007 15:32:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFFO-0000KY-UK; Wed, 18 Jul 2007 15:31:43 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFFN-0002zx-EC; Wed, 18 Jul 2007 15:31:42 -0400 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:31:34 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IJVWWs017431; Wed, 18 Jul 2007 12:31:32 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IJVT0e014943; Wed, 18 Jul 2007 12:31:31 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:31:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jul 2007 12:31:18 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> In-Reply-To: <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJWHZz70STkhAQTUWLy398tzWtmAAGFg6w References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" , "Pyda Srisuresh" X-OriginalArrivalTime: 18 Jul 2007 19:31:30.0491 (UTC) FILETIME=[3DE040B0:01C7C972] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, "Frank W. Miller" , p2psip@ietf.org Subject: [P2PSIP] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Phil, > In my view, ICE _is_ a "Hole Punching Technique". Yes, you absolutely right, though the devil is in the details. We cannot go here into a shoot-out between hole punching or other mentioned on the list vs. ICE, but there seems to be a huge difference in effectiveness and performance.=20 Of course I cannot prove it since there are no measurements published for ICE, only faith.=20 Just think of traversing all the NAT while going over 5-10 overlay network hops. Also many ISP are NATed and some are multiple NATed. We are supposed to provide a solution that works across the Internet. A provable (testing tools) and proven solution (measurements). I like ICE and hope to be proven wrong, but the risk is just too big for now. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Wednesday, July 18, 2007 9:27 AM To: Pyda Srisuresh Cc: Frank W. Miller; Henry Sinnreich; 'Magnus Westerlund'; sip@ietf.org; behave@ietf.org; mmusic@ietf.org Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Frank, Henry, Suresh: I agree that ICE is a complex spec. I also agree that it would be =20 very interesting to see more data on which situations result in a direct path between =20 endpoints, as opposed to a path via a TURN server. However, I don't understand the comment that "Hole Punching =20 Techniques" are an alternative. In my view, ICE _is_ a "Hole Punching Technique". Perhaps you are referring to the use of STUN alone??? The problem with using STUN alone is that there are cases where using =20 the reflexive address doesn't work, and there is no way with STUN alone to determine when =20 an endpoint should or should not use a reflexive address. But perhaps you are referring to something else? - Philip On 18-Jul-07, at 11:37 , Pyda Srisuresh wrote: > Thanks to Henry and Frank for so eloquently articulating this. > > As both Henry and Frank mentioned, I fully support standardizing on =20 > HOLE > PUNCHING TECHNIQUE and leveraging the IETF's considerable influence =20 > to force > NAT vendors to migrate towards implementations that are friendly to =20 > Hole > Punching and the Application developers to design applications =20 > using the hole > punching techniques. That should be the FIRST order of priority. > > Yet, what is happening in BEHAVE WG is the other way around. Some =20 > people have > put their weight so heavily in favor of ICE that they asked to drop =20 > the work on > hole punching technique as WG item. THIS IS WRONG. I no longer see =20 > "NAT > Traveral application design guidelines" as BEHAVE WG milestone. > > Magnus - Can you explain why the IETF is not allowing HOLE PUNCHING =20 > TECHNIQUES > to move forward as a WG item? > > regards, > suresh > > --- "Frank W. Miller" wrote: > >> >> >> Greetings, >> >> >> >> What I think Henry is advocating is a systematic approach to =20 >> making sure >> that the content of the ICE spec is right for its intended =20 >> purpose, i.e. a >> complete, general NAT traversal solution. NAT traversal has been =20 >> in my >> opinion one of the most difficult aspects of SIP implementation =20 >> and its very >> important that its eventual standardized solution be right. I =20 >> know I spent >> a lot of time implementing all the "tests" in the first 3489, only to >> discover that they were not that useful. There are two valid =20 >> technical >> concerns that are put forth in this email: >> >> >> >> 1) Viability of correct operation in practical =20 >> implementations. ICE can >> result in very complicated message transfers. >> >> 2) Performance. As pointed out in this email and in other =20 >> places, the >> additional latency associated with ICE operations can be significant. >> >> >> >> Henry also points out that there are competing approaches (e.g. Hole >> Punching) that can perform well in many situations and have better >> performance. IMHO, another approach by the IETF in general would =20 >> be to >> standardize on Hole Punching and leverage the IETF's considerable =20 >> influence >> to force NAT vendors to migrate towards implementations that are =20 >> friendly to >> Hole Punching. >> >> >> >> The bottom line is that I agree with Henry in that labeling ICE as an >> experimental draft is the right thing to do. It will allow those >> implementing ICE (including myself in all likelihood) to proceed =20 >> but signals >> to the users the correct status of the standard's contents. >> >> >> >> I also want to applaud loudly the underlying tone of Henry's =20 >> thread here. >> That is, in solving specific technical problems within the IETF =20 >> forum, >> focusing on empirical observation of working implementations =20 >> should be the >> MO that we all strive for when developing and proposing what may =20 >> become >> protocol standards. >> >> >> >> Thanks, >> >> FM >> >> >> >> >> >> _____ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, July 18, 2007 8:20 AM >> To: Magnus Westerlund >> Cc: sip@ietf.org; behave@ietf.org; mmusic@ietf.org >> Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Magnus, >> >> >> >> I sincerely appreciate your interest and this note! >> >> >> >>> I don't quite understand why you are requesting a status change =20 >>> of ICE >> >> >> >> However the arguments stated by the WG co-chairs and by you here are >> procedural in nature, whereas the facts are some cause for serious =20 >> concern, >> and I will just mention a few facts: >> >> >> >> RFC 3489 (STUN) was also presented as a NAT traversal solution =20 >> back in 2003, >> but now clearly admits that =20 >> "STUN is not a >> NAT traversal solution by itself. Rather, it is a tool to be used =20 >> in the >> context of a NAT traversal solution. This is an important change =20 >> from the >> previous version of this specification (RFC 3489), which presented =20 >> STUN as a >> complete solution." >> >> http://www.ietf.org/internet-drafts/draft-ietf-behave-=20 >> rfc3489bis-07.txt >> >> My guess is, in plain English, RFC 3489 turned out just NOT to be an >> acceptable solution as it was hoped to be. >> >> >> >> The excellent I-D shows the =20 >> ICE call >> flow with two endpoints behind two NAT (Fig. 22 on page 38) =20 >> require 66 >> messages just for the SIP INVITE! >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipping-nat-=20 >> scenarios-07.txt >> >> What happens if the two endpoints are in different ISPs that have =20 >> NAT of >> their own in addition to the ones in Fig. 22? >> >> What happens if one would try ICE along a P2PSIP route with say =20 >> 5-8 hops? >> Would there be hundreds of messages? What is the likelihood for =20 >> failure? >> >> >> >> By contrast with such approaches based on hope and faith, the =20 >> BEHAVE WG has >> produced work based on real measurements and tools to do the =20 >> measurements, >> such as >> >> >> >> "NAT Classification Test Results" >> >> >> >> "Application Design Guidelines for Traversal through Network Address >> Translators" >> >> The measurements for hole punching are reported in >> >> "Peer-to-Peer Communication Across Network Address Translators" >> >> http://www.brynosaurus.com/pub/net/p2pnat/ >> >> >> >> I am also a believer in ICE and have actually urged Jonathan =20 >> Rosenberg to do >> this work and he has given his best. Now that we have ICE-17 =20 >> version, it is >> in the best interest of the industry and the IETF to make it an =20 >> experimental >> RFC, but not yet a standard so that: >> >> 1. Independent, compliant implementations will be developed, >> >> 2. Testing in events such as SIPit, >> >> 3. Reporting the results, such as reported for the "hole =20 >> punching" above. >> >> >> >> What happens if indeed hole punching proves to be the far more =20 >> effective >> approach? >> >> >> >> The industry can ill afford a new series of RFC[ICE]-bis and all =20 >> the years >> it takes to move from believing to measuring and proving. I am =20 >> sure IETF >> procedures were meant in this spirit (though I am not good in =20 >> producing the >> right quotes). >> >> >> >> Thanks again for your attention to this concern about ICE. >> >> Also my apology to all the anguish to the numerous contributors to =20 >> the ICE >> related I-Ds, but writing test tools and reporting measurements is =20 >> the right >> way to go. >> >> >> >> Henry >> >> >> >> >> >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Wednesday, July 18, 2007 1:11 AM >> To: Henry Sinnreich >> Cc: mmusic@ietf.org; sip@ietf.org; behave@ietf.org >> Subject: Re: [BEHAVE] Re: ICE deployment data before LC for RFC >> >> >> >> Henry Sinnreich skrev: >> >>> Following some discussions and soul searching, the best approach for >> >>> ICE-17 for LC would be to _go ahead and make it an experimental =20 >>> RFC_. >> >>> >> >>> This would support the development of interoperable =20 >>> implementations, the >> >>> collection of deployment data and also hopefully open source code. >> >>> >> >>> Though I have full faith in ICE, following the practices that =20 >>> made the >> >>> IETF successful take precedent here, I believe. >> >>> >> >>> This is a change from the attached that I wrote on 7/16/2007. >> >>> >> >>> Note: We can only hope the proliferation of SBC in VoIP service =20 >>> provider >> >>> networks will not make these concerns and ICE for SIP a moot =20 >>> issue, but >> >>> this is another topic. >> >> >> >> Henry, >> >> >> >> I don't quite understand why you are requesting a status change of =20 >> ICE? >> >> To me it appears that ICE is almost finished spec. It has been >> >> implemented, used and feedback has been influencing the protocol. =20 >> It is >> >> definitly one of the better examples of current IETF work that =20 >> actually >> >> has running code. Sure, the implementations may not be fully =20 >> updated yet >> >> to the latest draft version. But I think it is safe to say that ICE >> >> works in the intended core cases. If there are some corner cases =20 >> where >> >> it fails, that may be. But that is not information we will have until >> >> really large scale deployement or someone makes very extensive tests. >> >> >> >> I think the IETF and the Internet has much more benefit from a =20 >> standards >> >> track solution than any of the risks existing with ICE of today. >> >> >> >> And to be clear, proposed standard is allowed to be published =20 >> without a >> >> single implementation exists. It might not be good practice, but =20 >> it is >> >> allowed by our process. And as I said before ICE has had enough >> >> implementation that I am very confortable in balloting YES for it =20 >> when >> >> it appears on the IESGs table. >> >> >> >> Cheers >> >> >> >> Magnus Westerlund >> >> >> >> IETF Transport Area Director & TSVWG Chair >> >> --------------------------------------------------------------------- >> - >> >> Multimedia Technologies, Ericsson Research EAB/TVM/M >> >> --------------------------------------------------------------------- >> - >> >> Ericsson AB | Phone +46 8 4048287 >> >> Torshamsgatan 23 | Fax +46 8 7575550 >> >> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> --------------------------------------------------------------------- >> - >> >>> _______________________________________________ >> Behave mailing list >> Behave@ietf.org >> https://www1.ietf.org/mailman/listinfo/behave >> > > > > > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www1.ietf.org/mailman/listinfo/behave _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 15:43:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFR2-0005tz-Fr; Wed, 18 Jul 2007 15:43:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFQc-0005Oj-CG; Wed, 18 Jul 2007 15:43:19 -0400 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFQb-0003Mr-Pi; Wed, 18 Jul 2007 15:43:18 -0400 Received: from source ([192.150.11.134]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Wed, 18 Jul 2007 12:43:13 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6IJfqot000197; Wed, 18 Jul 2007 12:41:53 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6IJh60c016197; Wed, 18 Jul 2007 12:43:07 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:43:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jul 2007 12:42:57 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AED891@namail5.corp.adobe.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84AABKemAAACP2dA= References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com><08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com><24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> From: "Henry Sinnreich" To: "Francois Audet" , "Dan Wing" , "Magnus Westerlund" X-OriginalArrivalTime: 18 Jul 2007 19:43:06.0466 (UTC) FILETIME=[DCB59C20:01C7C973] X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: sip@ietf.org, mmusic@ietf.org, behave@ietf.org, p2psip@ietf.org, Philip Matthews Subject: [P2PSIP] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Francois, > Heuh, no. This is just "exploratory concept" stuff, certainly not an=20 > interoperable protocol specification. I am happy to report we are in total agreement. Henry -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Wednesday, July 18, 2007 2:38 PM To: Henry Sinnreich; Dan Wing; Magnus Westerlund Cc: sip@ietf.org; p2psip@ietf.org; behave@ietf.org; Philip Matthews; mmusic@ietf.org Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC =20 > * Publish open source code at Sourceforge.net or similar, > * Publish a test tool as well, > * Gather and publish the results, possibly involving SIPit or another, > * Perfect the OS code and the protocol until it works OK. >=20 > This has been done for "Hole Punching for P2P" in=20 > http://www.brynosaurus.com/pub/net/p2pnat/=20 Heuh, no. This is just "exploratory concept" stuff, certainly not an interoperable protocol specification. And if the proponents of this alternative hole punching didn't=20 propose a draft at IETF when we starting working on this back in 2001, it seems to me that it's too late. > My assumption is that hole punching is much more effective=20 > for P2PSIP and I have copied the P2PSIP WG on this. The ratio=20 > of messages is probably 5:1 or higher for ICE vs. hole=20 > punching and this is critical when routing a P2PSIP message=20 > over an overlay in 5-10 hops. Of course I cannot prove it=20 > since as yet ICE cannot be measured. Well, your assumption may be wrong, especially in the absence of a specification for this alternative hole punching technique. The other thing I find funny in here is that the alternative=20 hole punching techique as described on the web site uses a centralize server common to BOTH ends to relay the address, while ICE does not (i.e., each end can use their own STUN server). In other words, the major difference between ICE and the alternative-hole- punching technique seems to be that alternative-hole-punching assumes both ends use the same STUN server, which makes the=20 rest of the exchange simpler (the "magic box" architectural concept is always handy). Ironically, this seems to me to be LESS usable in a global network where you wont't use centralize servers, especially for p2psip. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 15:58:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFfM-0003El-RJ; Wed, 18 Jul 2007 15:58:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBFLr-0004p2-Ep; Wed, 18 Jul 2007 15:38:23 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBFLr-0003Ej-3E; Wed, 18 Jul 2007 15:38:23 -0400 Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l6IJcIa02521; Wed, 18 Jul 2007 19:38:18 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Jul 2007 14:38:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BEHAVE] Re: ICE deployment data before LC for RFC Thread-Index: AcfJEybT1Lqyu4kbSgaZUq/KUlGECAAK8hkgAAmXLLAAAdQ84AABKemA References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> From: "Francois Audet" To: "Henry Sinnreich" , "Dan Wing" , "Magnus Westerlund" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Wed, 18 Jul 2007 15:58:22 -0400 Cc: sip@ietf.org, p2psip@ietf.org, behave@ietf.org, Philip Matthews , mmusic@ietf.org Subject: [P2PSIP] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 > * Publish open source code at Sourceforge.net or similar, > * Publish a test tool as well, > * Gather and publish the results, possibly involving SIPit or another, > * Perfect the OS code and the protocol until it works OK. >=20 > This has been done for "Hole Punching for P2P" in=20 > http://www.brynosaurus.com/pub/net/p2pnat/=20 Heuh, no. This is just "exploratory concept" stuff, certainly not an interoperable protocol specification. And if the proponents of this alternative hole punching didn't=20 propose a draft at IETF when we starting working on this back in 2001, it seems to me that it's too late. > My assumption is that hole punching is much more effective=20 > for P2PSIP and I have copied the P2PSIP WG on this. The ratio=20 > of messages is probably 5:1 or higher for ICE vs. hole=20 > punching and this is critical when routing a P2PSIP message=20 > over an overlay in 5-10 hops. Of course I cannot prove it=20 > since as yet ICE cannot be measured. Well, your assumption may be wrong, especially in the absence of a specification for this alternative hole punching technique. The other thing I find funny in here is that the alternative=20 hole punching techique as described on the web site uses a centralize server common to BOTH ends to relay the address, while ICE does not (i.e., each end can use their own STUN server). In other words, the major difference between ICE and the alternative-hole- punching technique seems to be that alternative-hole-punching assumes both ends use the same STUN server, which makes the=20 rest of the exchange simpler (the "magic box" architectural concept is always handy). Ironically, this seems to me to be LESS usable in a global network where you wont't use centralize servers, especially for p2psip. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 17:09:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGld-0000LH-Bt; Wed, 18 Jul 2007 17:09:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBGi7-0000g0-5W; Wed, 18 Jul 2007 17:05:27 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBGi6-0007eH-PC; Wed, 18 Jul 2007 17:05:27 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 99B4C75807D; Wed, 18 Jul 2007 16:05:25 -0500 (CDT) From: "Frank W. Miller" To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> References: <24CCCC428EFEA2469BF046DB3C7A8D22AED6A0@namail5.corp.adobe.com> <08c801c7c968$1d1cd8c0$7d646b80@amer.cisco.com> <24CCCC428EFEA2469BF046DB3C7A8D22AED871@namail5.corp.adobe.com> <1ECE0EB50388174790F9694F77522CCF1151ABC7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Date: Wed, 18 Jul 2007 15:05:13 -0600 Message-Id: <1184792713.3347.9.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-Mailman-Approved-At: Wed, 18 Jul 2007 17:09:03 -0400 Cc: Magnus Westerlund , behave@ietf.org, p2psip@ietf.org, sip@ietf.org, Henry Sinnreich , Philip Matthews , mmusic@ietf.org Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Wed, 2007-07-18 at 14:38 -0500, Francois Audet wrote: > The other thing I find funny in here is that the alternative > hole punching techique as described on the web site uses a > centralize server common to BOTH ends to relay the address, while > ICE does not (i.e., each end can use their own STUN server). > > In other words, the major difference between ICE and the > alternative-hole- > punching technique seems to be that alternative-hole-punching > assumes both ends use the same STUN server, which makes the > rest of the exchange simpler (the "magic box" architectural > concept is always handy). > > Ironically, this seems to me to be LESS usable in a global network > where you wont't use centralize servers, especially for p2psip. > This may be sufficient, but I don't think its necessary. Each UA punches the hole (and keeps it open, as David described) to whatever STUN server they like, all that's required is that each server have the same view of each client. That is somewhat less restrictive. In the common case of the open Internet, as long as the STUN servers used by each respective UA are in the "open", they don't have to be the same. After that, the "public" or "visible" IP address/port is put in the Contact headers. Regarding the 90% coverage, this is what I'm referring to when I say that it may be preferable to influence the NAT vendors to not do the things that put them in the 10% cases. I sort of thought that was what the NAT guidelines draft was for. In addition, if we are standardizing a protocol based on the 10% cases and imposing potentially huge costs on the 90% to do so, then our approach is incorrect. We should be designing for the 90% case and handling the 10% as exceptional behavior, i.e. a solution where you pay the big cost only in the case where you are actually in the 10%. FM _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 20:01:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBJRw-0004UQ-FI; Wed, 18 Jul 2007 20:00:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBJRv-0004UK-Fh for p2psip@ietf.org; Wed, 18 Jul 2007 20:00:55 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBJRu-0004DI-V4 for p2psip@ietf.org; Wed, 18 Jul 2007 20:00:55 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6J00cLK019913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Jul 2007 17:00:38 -0700 Received: from [76.102.92.155] (vpn-10-50-0-143.qualcomm.com [10.50.0.143]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6J00aM9022558; Wed, 18 Jul 2007 17:00:37 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <154801c7c94b$58b11940$c6e6a8c0@cis.neustar.com> References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> <1184450797.2D359846@fc9.dngr.org><91783A02-1B95-4CBC-A81D-EBFE9EA573A4@cs .columbia.edu><469C241C.2020108@cisco.com> <154801c7c94b$58b11940$c6e6a8c0@cis.neustar.com> Date: Wed, 18 Jul 2007 17:00:35 -0700 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Jonathan Rosenberg'" From: Ted Hardie Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At 10:53 AM -0400 7/18/07, Brian Rosen wrote: >It does not bother me AT ALL that it locks in a >particular DHT. I think that problem is so far down the list of worries, >that it should not enter into the discussion. > If an overlay wants all >implementations to work, they pick the mandatory-to-implement one. No >problem. (I'm assuming your opinion here is as a technical contributor, and that you are not ruling as chair that this should not enter into WG discussion) You've just outlined the scenario that means whatever baseline is selected as mandatory to implement *right now* will be the basis of most DHTs from now on. Anyone wanting to support arbitrary clients chooses that one. Any code or protocol work done to enable arbitrary clients using different overlay strategies to interwork will get exercised rarely, since forming a new one with the old, tried and true baseline is guaranteed to work. Put another way, any limitation we have now in whatever DHT gets selected is kept pretty much forever. I invite you to go look at the discussion in EAI for a moment, and see how much trouble it has cost the email community (or the DRUMS archives, or lots of other places). Keeping compatibility with systems that were near end-of-life at the time 822 was written has cost code complexity, operational complexity, and limited the end users. And that was for a relatively trivial problem--the number of bits being 7 or 8. The rate of evolution in *this* area is high enough that we don't even have a decent guess at what the costs of maintaining this backward compatibility will be. Selecting a mandatory to implement is a very short-sighted choice; it may increase the uptake in the early days, but it will cost you pain in the long run. If the other popular IETF protocols are any guide, it can be a pretty significant amount of pain. I have suggested a compromise in which the WG names a DHT for use in the interop testing which will lead to Draft. I think that will give a nice, large pool of clients that support the same DHT. Anyone expecting to form a large or multi-client overlay would be able to pick from that pool and deploy that DHT. But it does not bake into the clay of the protocol an overlay strategy that we know is likely to be surpassed in the future. regards, Ted Hardie _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 21:19:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKfi-000098-Jd; Wed, 18 Jul 2007 21:19:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKff-00006j-Fv; Wed, 18 Jul 2007 21:19:11 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBKff-00074j-1F; Wed, 18 Jul 2007 21:19:11 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBKfe-0001iS-22; Wed, 18 Jul 2007 21:19:10 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Wed, 18 Jul 2007 21:19:21 -0400 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > Phil, > >> In my view, ICE _is_ a "Hole Punching Technique". > > Yes, you absolutely right, though the devil is in the details. > > We cannot go here into a shoot-out between hole punching or other > mentioned on the list vs. ICE, but there seems to be a huge difference > in effectiveness and performance. What precise algorithm are you talking about when you say this? As far as I am concerned, ICE is simply a well-documented hole punching algorithm. It differs from others that I have seen written up in the following ways: - ICE has the concept of peer reflexive addresses, which other hole- punching techniques that I have seen do not; - ICE has the concept of controlling/controlled endpoint, which gives the controller additional flexibility in choosing a path; - ICE does NOT have the concept of port prediction, which some other techniques do (e.g., Saikat's TCP work). Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 21:22:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKj0-0003dD-IR; Wed, 18 Jul 2007 21:22:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKiy-0003Ul-NQ for p2psip@ietf.org; Wed, 18 Jul 2007 21:22:36 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBKiy-00078w-DH for p2psip@ietf.org; Wed, 18 Jul 2007 21:22:36 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-02.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBKiy-0006I7-0N; Wed, 18 Jul 2007 21:22:36 -0400 In-Reply-To: <469E2CA8.3040006@idssoftware.com> References: <469E2CA8.3040006@idssoftware.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D2E0485-FCA6-449B-919B-EF85ECCE8B5C@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] A DHT question on peers running out of storage Date: Wed, 18 Jul 2007 21:22:49 -0400 To: Michael Chen X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 1.8 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 18-Jul-07, at 11:07 , Michael Chen wrote: > Hi, > > I have a general DHT question. Say peer X joint the overlay. When > another peer registers a resource that should be stored in X, X > runs out of storage space for this particular resource. What happen? > > 1) Should X resign from the overlay? > > 2) Reply resource registration failure and stay in the overlay? > > 3) Reply registration success but later reply "not found" when > asked for this resource? In this case, the querying party will try > the replica peers of this resource. > For the algorithms I have seen, the assumption is that this case cannot happen. In P2PSIP, we have briefly talked about this by saying: Don't try to store too much in the overlay. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 21:39:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKz7-0003hw-Ek; Wed, 18 Jul 2007 21:39:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBKz6-0003hm-J6 for p2psip@ietf.org; Wed, 18 Jul 2007 21:39:16 -0400 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBKz5-000811-KE for p2psip@ietf.org; Wed, 18 Jul 2007 21:39:16 -0400 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 <0JLE00JH6KKEZJ@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 19 Jul 2007 09:38:38 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLE00JLJKKD8Y@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 19 Jul 2007 09:38:38 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLE00DLLKKAE3@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 19 Jul 2007 09:38:37 +0800 (CST) Date: Thu, 19 Jul 2007 09:38:34 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] A DHT question on peers running out of storage In-reply-to: <8D2E0485-FCA6-449B-919B-EF85ECCE8B5C@magma.ca> To: 'Philip Matthews' , 'Michael Chen' Message-id: <005201c7c9a5$857b0fd0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfJo09Dm6+cL8cqQa+sihAQts38GQAALUEg X-Spam-Score: 1.8 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org In P2PSIP community, the assumption is what Philip has just said. In some old P2P file system, for example PAST, it uses some techniques to solve this problem in the layer above the P2P algorithm. One option is to store some information of small size on X, for example, the Key, and a pointer to the data being stored. Where the data is stored is kept in the pointers. PAST will choose another capable peer to store the data of large size. A fallback option is to re-encode the resource and get a different key. So it will be stored on a peer which has enough space. But problem in this option is that peers who will look up this resource could not know the new encoding about this resource exactly, so it is hard for searcher to find this resource. Would we take the data size into consideration when we design peer protocol? Or it is up to upper layer to address this issue? Comments? -- Jiang XingFeng > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Thursday, July 19, 2007 9:23 AM > To: Michael Chen > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] A DHT question on peers running out of storage > > On 18-Jul-07, at 11:07 , Michael Chen wrote: > > > Hi, > > > > I have a general DHT question. Say peer X joint the overlay. When > > another peer registers a resource that should be stored in X, X > > runs out of storage space for this particular resource. What happen? > > > > 1) Should X resign from the overlay? > > > > 2) Reply resource registration failure and stay in the overlay? > > > > 3) Reply registration success but later reply "not found" when > > asked for this resource? In this case, the querying party will try > > the replica peers of this resource. > > > > For the algorithms I have seen, the assumption is that this case > cannot happen. > In P2PSIP, we have briefly talked about this by saying: Don't try to > store too much in the overlay. > > - Philip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 21:57:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLGi-0005On-5Y; Wed, 18 Jul 2007 21:57:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBLGe-0005LB-OZ; Wed, 18 Jul 2007 21:57:24 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBLGe-0008V8-CK; Wed, 18 Jul 2007 21:57:24 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBLGc-0007uL-2v; Wed, 18 Jul 2007 21:57:23 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC Date: Wed, 18 Jul 2007 21:57:34 -0400 To: Henry Sinnreich , Magnus Westerlund , Behave WG , IETF MMUSIC WG , sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 18-Jul-07, at 21:19 , Philip Matthews wrote: > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > >> Phil, >> >>> In my view, ICE _is_ a "Hole Punching Technique". >> >> Yes, you absolutely right, though the devil is in the details. >> >> We cannot go here into a shoot-out between hole punching or other >> mentioned on the list vs. ICE, but there seems to be a huge >> difference >> in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; > - ICE has the concept of controlling/controlled endpoint, which > gives the controller additional flexibility in choosing a path; > - ICE does NOT have the concept of port prediction, which some > other techniques do (e.g., Saikat's TCP work). I should add that ICE also handles: - the case of multi-homed peers, - peers that want to exchange multiple media streams, - media streams which are composed of multiple components (e.g. RTP and RTCP). These are cases that a solution for SIP needs to handle, but I have not seen discussed in other proposals. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 18 22:56:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMBp-0004Ie-Lt; Wed, 18 Jul 2007 22:56:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBMBm-0004HA-Kp; Wed, 18 Jul 2007 22:56:26 -0400 Received: from smtpauth00.csee.onr.siteprotect.com ([64.26.60.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBMBm-00089X-6y; Wed, 18 Jul 2007 22:56:26 -0400 Received: from [192.168.1.120] (c-67-162-139-200.hsd1.co.comcast.net [67.162.139.200]) (Authenticated sender: fwmiller@cornfed.com) by smtpauth00.csee.onr.siteprotect.com (Postfix) with ESMTP id 2E7CD75804E; Wed, 18 Jul 2007 21:56:25 -0500 (CDT) From: "Frank W. Miller" To: Philip Matthews In-Reply-To: References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> Content-Type: text/plain Date: Wed, 18 Jul 2007 20:56:09 -0600 Message-Id: <1184813769.3347.32.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , Henry Sinnreich , p2psip@ietf.org Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Wed, 2007-07-18 at 21:19 -0400, Philip Matthews wrote: > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > > > Phil, > > > >> In my view, ICE _is_ a "Hole Punching Technique". > > > > Yes, you absolutely right, though the devil is in the details. > > > > We cannot go here into a shoot-out between hole punching or other > > mentioned on the list vs. ICE, but there seems to be a huge difference > > in effectiveness and performance. > > What precise algorithm are you talking about when you say this? Well, here's the algorithm I use with my UA (the most recent versions I might add): STUN UA Registrar Server | REGISTER | | |-5060------->| | | w/rport | | | | | | 200 OK | | |<5060--------| | | | | | | | | STUN BReq | | |-5060--------------------->| | STUN BReq | | |-5004--------------------->| | STUN BResp | | |<5060----------------------| | STUN BResp | | |<5004----------------------| | | | | . | | | . | | | 10sec | | | . | | | . | | | | | | STUN BReq | | |-5060--------------------->| | STUN BResp | | |<5060----------------------| | STUN BReq | | |-5004--------------------->| | STUN BResp | | |<5004----------------------| | | | | | | I pick up the rport addressing during the REGISTER transaction because of the way my multithreading is done and because its nice to see the same value coming from two different sources out on the Internet. The port numbers on the UA are local port numbers. STUN BReq is a STUN binding request and STUN BResp is a STUN binding response. Port 5004 is for a single RTP session but the same algorithm is usable for any and all UDP ports you need, e.g. additional session ports and RTCP. The difference in order in the first and second sequence is intentional, the implementation doesn't care when the responses show up. This algorithm lets the UA know what its "visible" IP address and port is all the time (assuming that rport and STUN are working) and keeps it the same assuming that the NAT doesn't change it unilaterally (which I have yet to see BTW). When signaling occurs, the "visible" IP address and port are used in the Contact headers for SIP and in the SDP for offers/answers for RTP. Its just about as simple as it gets and I know you're going to say that it doesn't work 100% of the time. I haven't measured how well its done in deployments I've done as yet. I guess I need to do something along those lines. The good news is, I haven't had anyone complain about it so I guess I've been lucky. So let me have it... ;) Thanks, FM _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 19 07:57:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBUdP-0007Ex-IO; Thu, 19 Jul 2007 07:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBUdM-0007EB-GZ; Thu, 19 Jul 2007 07:57:28 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=smtp-04.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBUdL-0003WS-UH; Thu, 19 Jul 2007 07:57:28 -0400 Received: from [24.139.16.154] (helo=[10.0.1.2]) by smtp-04.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.50) id 1IBUdP-0007Eb-Em; Thu, 19 Jul 2007 07:57:31 -0400 In-Reply-To: <1184813769.3347.32.camel@localhost.localdomain> References: <239224.19734.qm@web33301.mail.mud.yahoo.com> <3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> <1184813769.3347.32.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Thu, 19 Jul 2007 07:57:36 -0400 To: "Frank W. Miller" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.0.1.2]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Magnus Westerlund , Behave WG , IETF MMUSIC WG , sip@ietf.org, Pyda Srisuresh , Henry Sinnreich , P2PSIP Mailing List Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 18-Jul-07, at 22:56 , Frank W. Miller wrote: > > Its just about as simple as it gets and I know you're going to say > that > it doesn't work 100% of the time. I haven't measured how well its > done > in deployments I've done as yet. I guess I need to do something along > those lines. The good news is, I haven't had anyone complain about it > so I guess I've been lucky. So let me have it... ;) This is the original STUN algorithm. One situation where it fails is the following: STUN server | NAT | ------------------ | | UA1 UA2 If the NAT does not support hairpinning, then your algorithm will not work. [http://tools.ietf.org/html/draft-jennings-behave-test-results-04 shows that most NATs today do not support UDP hairpinning, and http://www.guha.cc/saikat/pub/imc05-tcpnat.pdf reports that most do not support TCP hairpinning.] This situation can occur when the two UAs belong to the same company, or both are in the same hotel, or both use the same service provider and the service provider has a NAT in front of its entire network, etc. ICE does to things to solve this problem. First of all, UA1 and UA2 exchange their local addresses and ports as well as their STUN-learned addresses. They then test to see which path works. Second, they also exchange TURN addresses, which serve as a backup in case everything else fails. David Barrett's algorithm, if I understand it correctly, would work in this situation. (As far as I can tell, David's is a simplified version of ICE). - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 19 11:35:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY2M-0004Xo-Ot; Thu, 19 Jul 2007 11:35:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBY2J-0004W0-BF; Thu, 19 Jul 2007 11:35:27 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBY2I-0003tj-Pv; Thu, 19 Jul 2007 11:35:27 -0400 Received: from source ([192.150.11.134]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Jul 2007 08:35:14 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JFXqot020951; Thu, 19 Jul 2007 08:33:53 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6JFZ70c021529; Thu, 19 Jul 2007 08:35:07 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 08:35:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC Date: Thu, 19 Jul 2007 08:30:18 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC Thread-Index: AcfJothpej38ca2VQqWJmM78llWMcwAdAQ6Q References: <239224.19734.qm@web33301.mail.mud.yahoo.com><3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca><24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> From: "Henry Sinnreich" To: "Philip Matthews" X-OriginalArrivalTime: 19 Jul 2007 15:35:07.0342 (UTC) FILETIME=[627936E0:01C7CA1A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Phil, You are right again, but as mentioned, concept papers (a true torrent over many years lately) and discussion lists cannot replace published measurement tools, measured results and tweaking the approach based on measurements; measuring the improvements, etc.=20 This is the reason why I am not going into debating points about the merits of ICE, but rather the best approach to make it successful and be able to prove it. ICE is not a protocol agreement like SIP, but a technology that faces the great physical complexity on the net, so the protocol discussion approach is no replacement for testing and tweaking. This probably explains why we are in this discussion about ICE in the first place. By the same token I-D process arguments and consensus are no replacement either for proof on the net.=20 Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Wednesday, July 18, 2007 8:19 PM To: Henry Sinnreich Cc: Magnus Westerlund; behave@ietf.org; mmusic@ietf.org; sip@ietf.org; Pyda Srisuresh; Frank W. Miller; p2psip@ietf.org Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > Phil, > >> In my view, ICE _is_ a "Hole Punching Technique". > > Yes, you absolutely right, though the devil is in the details. > > We cannot go here into a shoot-out between hole punching or other > mentioned on the list vs. ICE, but there seems to be a huge difference > in effectiveness and performance. What precise algorithm are you talking about when you say this? As far as I am concerned, ICE is simply a well-documented hole =20 punching algorithm. It differs from others that I have seen written up in the following =20 ways: - ICE has the concept of peer reflexive addresses, which other hole-=20 punching techniques that I have seen do not; - ICE has the concept of controlling/controlled endpoint, which gives =20 the controller additional flexibility in choosing a path; - ICE does NOT have the concept of port prediction, which some other =20 techniques do (e.g., Saikat's TCP work). Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 19 13:45:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBa3v-0004es-Gs; Thu, 19 Jul 2007 13:45:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBa3s-0004dE-PZ for p2psip@ietf.org; Thu, 19 Jul 2007 13:45:12 -0400 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBa3r-0005Er-AI for p2psip@ietf.org; Thu, 19 Jul 2007 13:45:12 -0400 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Thu, 19 Jul 2007 10:45:01 -0700 From: "David Barrett" To: "'Philip Matthews'" , "'Frank W. Miller'" Date: Thu, 19 Jul 2007 10:44:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfJ/AEOlBMUriURROWxMoN7RNp/BQALk3Uw X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 'Magnus Westerlund' , 'Behave WG' , 'IETF MMUSIC WG' , sip@ietf.org, 'Pyda Srisuresh' , 'Henry Sinnreich' , 'P2PSIP Mailing List' Subject: [P2PSIP] RE: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Subject: Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC > > David Barrett's algorithm, if I understand it correctly, would work in > this situation. (As far as I can tell, David's is a simplified version > of ICE). That's correct. The major differences (so far as I know) between what I'm doing and what ICE does include: - Peer's needn't exchange SDP before attempting connection establishment (rather, the rendezvous server just tells both sides the others' LAN/NAT addresses and they try to connect immediately). - Paths are evaluated in parallel rather than sequentially (ie, I attempt to contact you direct via the LAN and indirectly via your NAT at the same time, and then pick the faster of the two) - There's no support for TURN servers as my application doesn't require them (though it would be extremely straightforward to add). - Clients attempt NAT classification as a *purely advisory* function to support debugging and feed into certain non-critical pairwise optimizations. (Said another way, even if the classification is totally wrong, it'll still work.) - Clients use adaptive keepalives to a STUN server to keep their NAT/FW "hole" open. By "adaptive" I mean I use probing to determine highest safe keepalive frequency of the NAT/FW. (Incidentally, there's no requirement that any two clients use the same STUN server, and indeed I intend to move to enable a "distributed STUN service" using the peers themselves.) Basically, I do the minimum necessary for my requirements, which I respect are much easier than SIP's. However, know that despite my system being much easier, it has been *extremely difficult and time consuming* to get working, despite dozens of iterations drawing upon a network of hundreds of thousands of machines on which to test. Thus I would suggest that if my solution took as long as it did, and went through as many variations as it did, the SIP/ICE implementers should be very wary of hardening anything too early before it hits the real world. Because the real world is really, really strange and unpredictable, I can guarantee you that. Phillip's asked me to put together a bit more precise overview of the system I use and I'll try to get to that soon. -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 19 13:51:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaA8-0007RN-UC; Thu, 19 Jul 2007 13:51:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaA4-0007Pf-NO; Thu, 19 Jul 2007 13:51:36 -0400 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBaA2-0005Qs-TN; Thu, 19 Jul 2007 13:51:36 -0400 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1IBaA3-0000Eq-0i; Thu, 19 Jul 2007 13:51:35 -0400 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> References: <239224.19734.qm@web33301.mail.mud.yahoo.com><3562CB24-D261-4194-9FAF-D2F0C2B6DE74@magma.ca><24CCCC428EFEA2469BF046DB3C7A8D22AED888@namail5.corp.adobe.com> <24CCCC428EFEA2469BF046DB3C7A8D22AEDAED@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9280291A-AB5A-4AC8-BD63-75AE5339B33D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LCfor RFC Date: Thu, 19 Jul 2007 13:51:47 -0400 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree that it would be very nice to see more published data on when ICE succeeds (and specifically when it succeeds in finding a direct path). It would also be nice to see more open source implementations. It used to be that the Routing area would hold a draft in the "almost done" state until they had some implementation experience, and then publish as an RFC only once they had that data. Is this what you are looking for? - Philip On 19-Jul-07, at 11:30 , Henry Sinnreich wrote: > Phil, > > You are right again, but as mentioned, concept papers (a true torrent > over many years lately) and discussion lists cannot replace published > measurement tools, measured results and tweaking the approach based on > measurements; measuring the improvements, etc. > > This is the reason why I am not going into debating points about the > merits of ICE, but rather the best approach to make it successful > and be > able to prove it. > > ICE is not a protocol agreement like SIP, but a technology that faces > the great physical complexity on the net, so the protocol discussion > approach is no replacement for testing and tweaking. This probably > explains why we are in this discussion about ICE in the first place. > > By the same token I-D process arguments and consensus are no > replacement > either for proof on the net. > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Wednesday, July 18, 2007 8:19 PM > To: Henry Sinnreich > Cc: Magnus Westerlund; behave@ietf.org; mmusic@ietf.org; sip@ietf.org; > Pyda Srisuresh; Frank W. Miller; p2psip@ietf.org > Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data > before > LCfor RFC > > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > >> Phil, >> >>> In my view, ICE _is_ a "Hole Punching Technique". >> >> Yes, you absolutely right, though the devil is in the details. >> >> We cannot go here into a shoot-out between hole punching or other >> mentioned on the list vs. ICE, but there seems to be a huge >> difference >> in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; > - ICE has the concept of controlling/controlled endpoint, which gives > the controller additional flexibility in choosing a path; > - ICE does NOT have the concept of port prediction, which some other > techniques do (e.g., Saikat's TCP work). > > Philip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 19 15:18:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbW7-0008VP-FP; Thu, 19 Jul 2007 15:18:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbW6-0008VI-CG for p2psip@ietf.org; Thu, 19 Jul 2007 15:18:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbW5-0007y5-1Z for p2psip@ietf.org; Thu, 19 Jul 2007 15:18:26 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IBbVj-0003w1-Nz; Thu, 19 Jul 2007 14:18:04 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Jonathan Rosenberg'" References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> <1184450797.2D359846@fc9.dngr.org><91783A02-1B95-4CBC-A81D-EBFE9EA573A4@cs .columbia.edu><469C241C.2020108@cisco.com> <154801c7c94b$58b11940$c6e6a8c0@cis.neustar.com> Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Thu, 19 Jul 2007 15:18:05 -0400 Message-ID: <17d401c7ca39$8ac52130$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfJl9QoJv6wlZ6FSna26YyTBnZzuAABPPXA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org (sorry I did not make that clear in my initial message) I disagree. If the spec says DHTs can change, plan on it, implement at least this one for now, then later, we can add another mandatory to implement one. The cost is the old code. No big deal. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Wednesday, July 18, 2007 8:01 PM > To: Brian Rosen; 'Henning Schulzrinne'; 'Jonathan Rosenberg' > Cc: 'P2PSIP WG' > Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > > At 10:53 AM -0400 7/18/07, Brian Rosen wrote: > > > > >It does not bother me AT ALL that it locks in a > >particular DHT. I think that problem is so far down the list of worries, > >that it should not enter into the discussion. > > > > > > If an overlay wants all > >implementations to work, they pick the mandatory-to-implement one. No > >problem. > > (I'm assuming your opinion here is as a technical contributor, and that > you > are not ruling as chair that this should not enter into WG discussion) > > You've just outlined the scenario that means whatever baseline is > selected as mandatory to implement *right now* will be the basis > of most DHTs from now on. Anyone wanting to support arbitrary > clients chooses that one. Any code or protocol work done to > enable arbitrary clients using different overlay strategies to interwork > will > get exercised rarely, since forming a new one with the old, tried > and true baseline is guaranteed to work. Put another way, any limitation > we > have now in whatever DHT gets selected is kept pretty much forever. > > I invite you to go look at the discussion in EAI for a moment, and see how > much > trouble it has cost the email community (or the DRUMS archives, or lots of > other places). Keeping compatibility with systems that were near end-of- > life > at the time 822 was written has cost code complexity, operational > complexity, > and limited the end users. And that was for a relatively trivial problem- > -the > number of bits being 7 or 8. The rate of evolution in *this* area is high > enough > that we don't even have a decent guess at what the costs of maintaining > this backward compatibility will be. > > Selecting a mandatory to implement is a very short-sighted choice; > it may increase the uptake in the early days, but it will cost you pain > in the long run. If the other popular IETF protocols are any guide, it > can be a pretty significant amount of pain. > > I have suggested a compromise in which the WG names a DHT for > use in the interop testing which will lead to Draft. I think that will > give a nice, large pool of clients that support the same DHT. Anyone > expecting to form a large or multi-client overlay would be able to pick > from that pool and deploy that DHT. But it does not bake into the clay of > the > protocol an overlay strategy that we know is likely to be surpassed in the > future. > > regards, > Ted Hardie > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 19 15:25:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbcX-0005QG-Tb; Thu, 19 Jul 2007 15:25:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbcW-0005Pn-G3 for p2psip@ietf.org; Thu, 19 Jul 2007 15:25:04 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbcU-00088Z-I1 for p2psip@ietf.org; Thu, 19 Jul 2007 15:25:04 -0400 Received: from 206-176-144-210.waymark.net ([206.176.144.210]) by nylon.softarmor.com with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1IBbcT-0007aL-N3; Thu, 19 Jul 2007 14:25:02 -0500 Message-ID: <469FBBAA.5070003@softarmor.com> Date: Thu, 19 Jul 2007 14:29:46 -0500 From: Dean Willis User-Agent: Icedove 1.5.0.12 (X11/20070607) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] A DHT question on peers running out of storage References: <469E2CA8.3040006@idssoftware.com> <8D2E0485-FCA6-449B-919B-EF85ECCE8B5C@magma.ca> In-Reply-To: <8D2E0485-FCA6-449B-919B-EF85ECCE8B5C@magma.ca> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Philip Matthews wrote: > For the algorithms I have seen, the assumption is that this case cannot > happen. > In P2PSIP, we have briefly talked about this by saying: Don't try to > store too much in the overlay. You, sir, are an optimist. Having been clubbed repeatedly about the head and shoulders by Murphy's Law and its various corrollaries I've come to believe O'Tool's commentary: Murphy was an optimist too. http://www.murphys-laws.com/murphy/murphy-laws.html But seriously, I expect that as people learn that things can be stored "in the overlay", they will be. All sorts of things, and lots of them. Work expands to fill the allotted time, and the volume of things stored expands to fill the available storage. That's why I see a requirement for peers to be able to differentiate the amount of whatever resource is used to provide whatever service, above the absolute mininum required to be a peer, they are willing to provide. Further, I believe that not all peers will offer all services. This leads me to ponder a few questions: 1) What, if any, services MUST a peer provide to the overlay in order to be a real peer and not some kind of "client"? 2) What happens when a peer (perhaps one supporting only the minimal set of services in #1 above) gets overloaded? Does it cease to be a peer? Does it crash? Does it break the overlay? 3) What, if any, non-required services might a peer offer? 4) If we have non-required services. how do we go about finding out which services a peer offers, or what peers offer a given service? 5) How do we find the peer most efficiently positioned to provide a service we're looking for? Do we even need to do this, or can we assume all peers are equiefficient in service delivery? 6) Is there a fundamental difference between storing contact info for a client and storing anything else? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 19 15:37:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbot-0008QH-5z; Thu, 19 Jul 2007 15:37:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbor-0008QA-RJ for p2psip@ietf.org; Thu, 19 Jul 2007 15:37:49 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBbor-0002wj-6i for p2psip@ietf.org; Thu, 19 Jul 2007 15:37:49 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6JJbasI009699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jul 2007 12:37:36 -0700 Received: from [129.46.226.38] (carbuncle.qualcomm.com [129.46.226.38]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6JJbY2t009417; Thu, 19 Jul 2007 12:37:35 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <17d401c7ca39$8ac52130$c6e6a8c0@cis.neustar.com> References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> <1184450797.2D359846@fc9.dngr.org><91783A02-1B95-4CBC-A81D-EBFE9EA573A4@cs .columbia.edu><469C241C.2020108@cisco.com> <154801c7c94b$58b11940$c6e6a8c0@cis.neustar.com> <17d401c7ca39$8ac52130$c6e6a8c0@cis.neustar.com> Date: Thu, 19 Jul 2007 12:37:32 -0700 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Jonathan Rosenberg'" From: Ted Hardie Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At 3:18 PM -0400 7/19/07, Brian Rosen wrote: > (sorry I did not make that clear in my initial message) > >I disagree. > >If the spec says DHTs can change, plan on it, implement at least this one >for now, then later, we can add another mandatory to implement one. Add or replace? That is, do you expect to be able to deprecate the original mandatory-to-implement, or add one such that there are a minimum of two? >The cost is the old code. No big deal. On this point, we really do disagree. Old code that must be exercisable has considerable costs. Ted >Brian > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Wednesday, July 18, 2007 8:01 PM >> To: Brian Rosen; 'Henning Schulzrinne'; 'Jonathan Rosenberg' >> Cc: 'P2PSIP WG' >> Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion >> >> At 10:53 AM -0400 7/18/07, Brian Rosen wrote: >> >> >> >> >It does not bother me AT ALL that it locks in a >> >particular DHT. I think that problem is so far down the list of worries, >> >that it should not enter into the discussion. >> >> >> >> >> > If an overlay wants all >> >implementations to work, they pick the mandatory-to-implement one. No >> >problem. >> >> (I'm assuming your opinion here is as a technical contributor, and that >> you >> are not ruling as chair that this should not enter into WG discussion) >> >> You've just outlined the scenario that means whatever baseline is >> selected as mandatory to implement *right now* will be the basis >> of most DHTs from now on. Anyone wanting to support arbitrary >> clients chooses that one. Any code or protocol work done to >> enable arbitrary clients using different overlay strategies to interwork >> will >> get exercised rarely, since forming a new one with the old, tried >> and true baseline is guaranteed to work. Put another way, any limitation >> we >> have now in whatever DHT gets selected is kept pretty much forever. >> >> I invite you to go look at the discussion in EAI for a moment, and see how >> much >> trouble it has cost the email community (or the DRUMS archives, or lots of >> other places). Keeping compatibility with systems that were near end-of- >> life >> at the time 822 was written has cost code complexity, operational >> complexity, >> and limited the end users. And that was for a relatively trivial problem- >> -the >> number of bits being 7 or 8. The rate of evolution in *this* area is high >> enough >> that we don't even have a decent guess at what the costs of maintaining >> this backward compatibility will be. >> >> Selecting a mandatory to implement is a very short-sighted choice; >> it may increase the uptake in the early days, but it will cost you pain >> in the long run. If the other popular IETF protocols are any guide, it >> can be a pretty significant amount of pain. >> >> I have suggested a compromise in which the WG names a DHT for >> use in the interop testing which will lead to Draft. I think that will >> give a nice, large pool of clients that support the same DHT. Anyone >> expecting to form a large or multi-client overlay would be able to pick >> from that pool and deploy that DHT. But it does not bake into the clay of >> the >> protocol an overlay strategy that we know is likely to be surpassed in the >> future. >> >> regards, >> Ted Hardie >> _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 19 16:02:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBcCN-0000il-6f; Thu, 19 Jul 2007 16:02:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBcCL-0000if-TY for p2psip@ietf.org; Thu, 19 Jul 2007 16:02:05 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBcCL-0003To-9G for p2psip@ietf.org; Thu, 19 Jul 2007 16:02:05 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IBcC3-00058y-6z; Thu, 19 Jul 2007 15:01:48 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Jonathan Rosenberg'" References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> <1184450797.2D359846@fc9.dngr.org><91783A02-1B95-4CBC-A81D-EBFE9EA573A4@cs .columbia.edu><469C241C.2020108@cisco.com> <154801c7c94b$58b11940$c6e6a8c0@cis.neustar.com> <17d401c7ca39$8ac52130$c6e6a8c0@cis.neustar.com> Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion Date: Thu, 19 Jul 2007 16:01:54 -0400 Message-ID: <17ee01c7ca3f$aae0fb50$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfKPD36w3sXl3faQBCMlSV8OktEQQAAL8Ug X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I wouldn't mind deprecate, although I doubt you would see it in practice. I think the cost of maintaining an old DHT algorithm is small enough to be ignorable, but I can agree to disagree on that point. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Thursday, July 19, 2007 3:38 PM > To: Brian Rosen; 'Henning Schulzrinne'; 'Jonathan Rosenberg' > Cc: 'P2PSIP WG' > Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > > At 3:18 PM -0400 7/19/07, Brian Rosen wrote: > > (sorry I did not make that clear in my initial message) > > > >I disagree. > > > >If the spec says DHTs can change, plan on it, implement at least this one > >for now, then later, we can add another mandatory to implement one. > > Add or replace? That is, do you expect to be able to deprecate the > original > mandatory-to-implement, or add one such that there are a minimum of two? > > >The cost is the old code. No big deal. > > On this point, we really do disagree. Old code that must be exercisable > has considerable costs. > Ted > > > > >Brian > > > >> -----Original Message----- > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > >> Sent: Wednesday, July 18, 2007 8:01 PM > >> To: Brian Rosen; 'Henning Schulzrinne'; 'Jonathan Rosenberg' > >> Cc: 'P2PSIP WG' > >> Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting > opinion > >> > >> At 10:53 AM -0400 7/18/07, Brian Rosen wrote: > >> > >> > >> > >> >It does not bother me AT ALL that it locks in a > >> >particular DHT. I think that problem is so far down the list of > worries, > >> >that it should not enter into the discussion. > >> > >> > >> > >> > >> > If an overlay wants all > >> >implementations to work, they pick the mandatory-to-implement one. No > >> >problem. > >> > >> (I'm assuming your opinion here is as a technical contributor, and that > >> you > >> are not ruling as chair that this should not enter into WG discussion) > >> > >> You've just outlined the scenario that means whatever baseline is > >> selected as mandatory to implement *right now* will be the basis > >> of most DHTs from now on. Anyone wanting to support arbitrary > >> clients chooses that one. Any code or protocol work done to > >> enable arbitrary clients using different overlay strategies to > interwork > >> will > >> get exercised rarely, since forming a new one with the old, tried > >> and true baseline is guaranteed to work. Put another way, any > limitation > >> we > >> have now in whatever DHT gets selected is kept pretty much forever. > >> > >> I invite you to go look at the discussion in EAI for a moment, and see > how > >> much > >> trouble it has cost the email community (or the DRUMS archives, or lots > of > >> other places). Keeping compatibility with systems that were near end- > of- > >> life > >> at the time 822 was written has cost code complexity, operational > >> complexity, > >> and limited the end users. And that was for a relatively trivial > problem- > >> -the > >> number of bits being 7 or 8. The rate of evolution in *this* area is > high > >> enough > >> that we don't even have a decent guess at what the costs of maintaining > >> this backward compatibility will be. > >> > >> Selecting a mandatory to implement is a very short-sighted choice; > >> it may increase the uptake in the early days, but it will cost you pain > >> in the long run. If the other popular IETF protocols are any guide, it > >> can be a pretty significant amount of pain. > >> > >> I have suggested a compromise in which the WG names a DHT for > >> use in the interop testing which will lead to Draft. I think that will > >> give a nice, large pool of clients that support the same DHT. Anyone > >> expecting to form a large or multi-client overlay would be able to pick > >> from that pool and deploy that DHT. But it does not bake into the clay > of > >> the > >> protocol an overlay strategy that we know is likely to be surpassed in > the > >> future. > >> > >> regards, > >> Ted Hardie > >> _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 19 17:14:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdKk-00014V-DQ; Thu, 19 Jul 2007 17:14:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdKg-0000tc-Pm; Thu, 19 Jul 2007 17:14:46 -0400 Received: from exprod6og54.obsmtp.com ([64.18.1.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBdKg-0005RE-9s; Thu, 19 Jul 2007 17:14:46 -0400 Received: from source ([192.150.20.142]) by exprod6ob54.postini.com ([64.18.5.12]) with SMTP; Thu, 19 Jul 2007 14:14:38 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JLEQWs013301; Thu, 19 Jul 2007 14:14:27 -0700 (PDT) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6JLCUI9025470; Thu, 19 Jul 2007 14:12:30 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 14:14:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jul 2007 14:14:21 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEDCA6@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: ICE deployment data before LC for RFC Thread-Index: AcfKSR+4bsdL7cvpRK+b5k7AGN+GsQ== From: "Henry Sinnreich" To: , , , , X-OriginalArrivalTime: 19 Jul 2007 21:14:25.0847 (UTC) FILETIME=[C9168C70:01C7CA49] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Magnus Westerlund , jon.peterson@neustar.biz Subject: [P2PSIP] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org My apology for the duplicate postings.=20 Having initiated this ample discussion about how to proceed with ICE-17, it seems the following have emerged: ICE-17 is an excellent document (bravo authors and contributors) and can hardly get better at present. The technical points discussed cannot change this fact either way. Ironically, the defense of ICE-17 on procedural grounds makes even less sense, since the culprit is not ICE-17, but the fact that present IETF procedures do not make a clear enough distinction that everyone can understand between I-D categories, such as: * Concept memos; see the torrent in the P2PSIP WG * Protocol standard agreements, such as for SIP * Technology solutions such as ICE-17 or hole punching for NAT traversal * I-Ds to support a business model (excuse me; I will not go there...) Sorry to repeat: Process and consensus in meetings have nothing to do with how good a technology may be. Only measurements and proof will do. How does the IETF support the proof for a technology? (Yes, I have seen all those quotes). Please remember that proving a technology also costs money. This is the reason why I trust more technologies coming out of funded R&D, especially from University research. Vendors of technology may be less likely to share such information. Question: Is a standards organization the best place to develop and promote new technology such as for NAT traversal? (all those p2p companies and Skype did not think so...) Also, be prepared, SBC traversal may come next. In conclusion, there is nothing wrong with the ICE-17 paper IMHO, but rather the IETF processes are either not satisfactory or not well understood by folks like me who avoid reading process documents longer than one web page :-)=20 I have taken therefore the liberty to copy as Adam Roach has suggested. Thanks,=20 Henry Sinnreich _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 20 04:18:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBnhK-00018B-7E; Fri, 20 Jul 2007 04:18:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBnhJ-000186-9u for p2psip@ietf.org; Fri, 20 Jul 2007 04:18:49 -0400 Received: from tcmail23.telekom.de ([217.6.95.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBnhH-0000ao-OU for p2psip@ietf.org; Fri, 20 Jul 2007 04:18:49 -0400 Received: from S4DE9JSAANM.ost.t-com.de (S4DE9JSAANM.ost.t-com.de [10.125.177.122]) by tcmail21.telekom.de with ESMTP; Fri, 20 Jul 2007 10:18:46 +0200 Received: from S4DE9JSAAIG.ost.t-com.de ([10.125.177.192]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Jul 2007 10:18:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Jul 2007 10:18:44 +0200 Message-Id: <1E4CCB2441C5C0409AD8A929482A09F31BB7DC@S4DE9JSAAIG.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PP and lost responses Thread-Index: AcfKps3jg9oC6nLWQYuKO5JNz82KGw== From: "Beck01, Wolfgang" To: , X-OriginalArrivalTime: 20 Jul 2007 08:18:45.0596 (UTC) FILETIME=[975991C0:01C7CAA6] X-Spam-Score: -1.0 (-) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [P2PSIP] P2PP and lost responses X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I'm sure I'm missing something, but the transaction mechanism seems somewhat broken to me.=20 In recursive mode, a peer should respond with '100 Trying' thus preventing request retransmissions. Now, if the final response is lost, the request originator can't do anything until the whole transaction times out.=20 We have the same mechanism in SIP, but get away with it most of the time. '200 OK' responses carrying important information are usually part of an INVITE transaction, where this problem does not occur. A lost '200 OK' response in a MESSAGE transaction is less critical, as the important part of the transaction -- delivery of the text -- has succeeded.=20 In P2PP, responses do carry important information. Retrying a whole transaction just to retransmit a lost response seems not very efficient. solutions? 1. mandate reliable transport for recursive request handling 2. PRACK for P2PP Wolfgang -- T-Systems Enterprise Services GmbH=20 Supervisory Board: Ren=E9 Obermann (Chairman)=20 Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin = Horstmann, Ulrich Kemp, Axel Knobe*, Wilfried Peters*, Dr. Herbert = Schaaff*, Zvezdana Seeger*=20 Commercial register: Amtsgericht Frankfurt am Main HRB 55933=20 Registered office: Frankfurt am Main=20 WEEE -Reg.-No. DE87523644=20 *Member of the Board of Directors as defined under section 35 GmbHG _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 20 09:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBsdb-0003uQ-80; Fri, 20 Jul 2007 09:35:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBsdZ-0003lf-41 for p2psip@ietf.org; Fri, 20 Jul 2007 09:35:17 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBsdY-0007DE-B5 for p2psip@ietf.org; Fri, 20 Jul 2007 09:35:17 -0400 Received: by ug-out-1314.google.com with SMTP id u2so1717554uge for ; Fri, 20 Jul 2007 06:35:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hAtofdVOwXCJchQzr4OPFwYdRIRqfrTEIjS6qY5jWu9pZ3gnifvYl+MFZmXzzJGQWhV3068n8WrfwGezLUmDAuxHuWUgD5ZOIs2NRMTatlwoOu2SNMjXZ+Cb5ZbTPO/5ZmpYDy5zmI+wMvug72p5165ns361BCU+/Zr0pZg69gw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=psLrL/Z/niHGyzPcRmogcA7nKOHFO+bq/rSle+ChY+SXvH2AQGwg+fe1JUGdIBW+Xxb/QkVG8zfkCkbKFMrjz0x2y6EIqZL8hTpGbyebYxCJQskfMNk9repvqJb99oAry6n9FZyZOeV/dz5rdKRB8niUTcAnfIrp//GoEfc3XpM= Received: by 10.78.205.7 with SMTP id c7mr110563hug.1184938515379; Fri, 20 Jul 2007 06:35:15 -0700 (PDT) Received: by 10.78.165.12 with HTTP; Fri, 20 Jul 2007 06:35:15 -0700 (PDT) Message-ID: Date: Fri, 20 Jul 2007 09:35:15 -0400 From: "Bill Mccormick" To: "Brian Rosen" Subject: Re: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion In-Reply-To: <17ee01c7ca3f$aae0fb50$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <625C684F86E06241BD99B08907A58C89018DE5EE@namail5.corp.adobe.com> <625C684F86E06241BD99B08907A58C89018DE5F3@namail5.corp.adobe.com> <1184450797.2D359846@fc9.dngr.org> <469C241C.2020108@cisco.com> <154801c7c94b$58b11940$c6e6a8c0@cis.neustar.com> <17d401c7ca39$8ac52130$c6e6a8c0@cis.neustar.com> <17ee01c7ca3f$aae0fb50$c6e6a8c0@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with Ted. Maintaining working versions of old protocols is expensive and shouldn't be undertaken lightly. Bill. On 7/19/07, Brian Rosen wrote: > I wouldn't mind deprecate, although I doubt you would see it in practice. > > I think the cost of maintaining an old DHT algorithm is small enough to be > ignorable, but I can agree to disagree on that point. > > Brian > > > -----Original Message----- > > From: Ted Hardie [mailto:hardie@qualcomm.com] > > Sent: Thursday, July 19, 2007 3:38 PM > > To: Brian Rosen; 'Henning Schulzrinne'; 'Jonathan Rosenberg' > > Cc: 'P2PSIP WG' > > Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting opinion > > > > At 3:18 PM -0400 7/19/07, Brian Rosen wrote: > > > (sorry I did not make that clear in my initial message) > > > > > >I disagree. > > > > > >If the spec says DHTs can change, plan on it, implement at least this one > > >for now, then later, we can add another mandatory to implement one. > > > > Add or replace? That is, do you expect to be able to deprecate the > > original > > mandatory-to-implement, or add one such that there are a minimum of two? > > > > >The cost is the old code. No big deal. > > > > On this point, we really do disagree. Old code that must be exercisable > > has considerable costs. > > Ted > > > > > > > > >Brian > > > > > >> -----Original Message----- > > >> From: Ted Hardie [mailto:hardie@qualcomm.com] > > >> Sent: Wednesday, July 18, 2007 8:01 PM > > >> To: Brian Rosen; 'Henning Schulzrinne'; 'Jonathan Rosenberg' > > >> Cc: 'P2PSIP WG' > > >> Subject: RE: [P2PSIP] Mandatory-to-implement DHTs - a dissenting > > opinion > > >> > > >> At 10:53 AM -0400 7/18/07, Brian Rosen wrote: > > >> > > >> > > >> > > >> >It does not bother me AT ALL that it locks in a > > >> >particular DHT. I think that problem is so far down the list of > > worries, > > >> >that it should not enter into the discussion. > > >> > > >> > > >> > > >> > > >> > If an overlay wants all > > >> >implementations to work, they pick the mandatory-to-implement one. No > > >> >problem. > > >> > > >> (I'm assuming your opinion here is as a technical contributor, and that > > >> you > > >> are not ruling as chair that this should not enter into WG discussion) > > >> > > >> You've just outlined the scenario that means whatever baseline is > > >> selected as mandatory to implement *right now* will be the basis > > >> of most DHTs from now on. Anyone wanting to support arbitrary > > >> clients chooses that one. Any code or protocol work done to > > >> enable arbitrary clients using different overlay strategies to > > interwork > > >> will > > >> get exercised rarely, since forming a new one with the old, tried > > >> and true baseline is guaranteed to work. Put another way, any > > limitation > > >> we > > >> have now in whatever DHT gets selected is kept pretty much forever. > > >> > > >> I invite you to go look at the discussion in EAI for a moment, and see > > how > > >> much > > >> trouble it has cost the email community (or the DRUMS archives, or lots > > of > > >> other places). Keeping compatibility with systems that were near end- > > of- > > >> life > > >> at the time 822 was written has cost code complexity, operational > > >> complexity, > > >> and limited the end users. And that was for a relatively trivial > > problem- > > >> -the > > >> number of bits being 7 or 8. The rate of evolution in *this* area is > > high > > >> enough > > >> that we don't even have a decent guess at what the costs of maintaining > > >> this backward compatibility will be. > > >> > > >> Selecting a mandatory to implement is a very short-sighted choice; > > >> it may increase the uptake in the early days, but it will cost you pain > > >> in the long run. If the other popular IETF protocols are any guide, it > > >> can be a pretty significant amount of pain. > > >> > > >> I have suggested a compromise in which the WG names a DHT for > > >> use in the interop testing which will lead to Draft. I think that will > > >> give a nice, large pool of clients that support the same DHT. Anyone > > >> expecting to form a large or multi-client overlay would be able to pick > > >> from that pool and deploy that DHT. But it does not bake into the clay > > of > > >> the > > >> protocol an overlay strategy that we know is likely to be surpassed in > > the > > >> future. > > >> > > >> regards, > > >> Ted Hardie > > >> > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Bill McCormick _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 20 10:52:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtqd-0006y0-G9; Fri, 20 Jul 2007 10:52:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBqtV-0002kJ-Io; Fri, 20 Jul 2007 07:43:37 -0400 Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBqtU-0004vw-2E; Fri, 20 Jul 2007 07:43:37 -0400 Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]:49215) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.42) id 1IBqtQ-0003El-Cr; Fri, 20 Jul 2007 12:43:32 +0100 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <40048F36-6069-40A3-BF6E-42D458638709@csperkins.org> Content-Transfer-Encoding: quoted-printable From: Colin Perkins Date: Fri, 20 Jul 2007 12:43:30 +0100 To: MMUSIC WG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Fri, 20 Jul 2007 10:52:49 -0400 Cc: Jean-Francois Mule , Joerg Ott Subject: [P2PSIP] Progressing ICE X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org [This note is sent to MMUSIC, with bcc to BEHAVE, SIP, and P2PSIP =20 since the discussion has included those groups. Replies to MMUSIC =20 only please, as ICE is an MMUSIC working group draft] The MMUSIC chairs have reviewed the mailing list discussion =20 pertaining to ICE over the last few days. While we agree that further =20= implementation experience and publication of deployment results would =20= be valuable, as it is for any new protocol, we do not believe this =20 sufficient cause to revisit the consensus to request publication of =20 draft-ietf-mmusic-ice-17.txt as a Proposed Standard. The characteristics of Proposed Standard specifications are described =20= in RFC 2026 section 4.1.1 as follows: > The entry-level maturity for the standards track is "Proposed > Standard". A specific action by the IESG is required to move a > specification onto the standards track at the "Proposed Standard" > level. > > A Proposed Standard specification is generally stable, has resolved > known design choices, is believed to be well-understood, has =20 > received > significant community review, and appears to enjoy enough community > interest to be considered valuable. However, further experience > might result in a change or even retraction of the specification > before it advances. > > Usually, neither implementation nor operational experience is > required for the designation of a specification as a Proposed > Standard. However, such experience is highly desirable, and will > usually represent a strong argument in favor of a Proposed Standard > designation. > > The IESG may require implementation and/or operational experience > prior to granting Proposed Standard status to a specification that > materially affects the core Internet protocols or that specifies > behavior that may have significant operational impact on the > Internet. > > A Proposed Standard should have no known technical omissions with > respect to the requirements placed upon it. However, the IESG may > waive this requirement in order to allow a specification to advance > to the Proposed Standard state when it is considered to be =20 > useful and > necessary (and timely) even with known technical omissions. > > Implementors should treat Proposed Standards as immature > specifications. It is desirable to implement them in order to gain > experience and to validate, test, and clarify the specification. > However, since the content of Proposed Standards may be changed if > problems are found or better solutions are identified, deploying > implementations of such standards into a disruption-sensitive > environment is not recommended. Our judgement is that ICE meets these requirements, and that there is =20= general working group consensus to request publication. Accordingly, =20 our intention is to proceed as we previously announced, and request =20 that ICE be published as a Proposed Standard RFC. Colin Perkins, J=F6rg Ott, and Jean-Fran=E7ois Mul=E9 MMUSIC chairs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Jul 20 10:52:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtqe-0006yK-1z; Fri, 20 Jul 2007 10:52:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBtmZ-00024t-Fr for p2psip@ietf.org; Fri, 20 Jul 2007 10:48:39 -0400 Received: from web33306.mail.mud.yahoo.com ([68.142.206.121]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IBtmZ-0000Vt-3R for p2psip@ietf.org; Fri, 20 Jul 2007 10:48:39 -0400 Received: (qmail 42524 invoked by uid 60001); 20 Jul 2007 14:48:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=bgOG0vEyxaJUH0jcE3EPAYoUALnk99g5hyCvgkoZR9UDDiSB4ppOhkAXvZuRxvqsetUKD7VaPx7+8VJjpOS6ctqXlE28pht271hlG7yQfowt360CE3eYB0RNJAxw5tPKt5GzzkbQWSH4WNr5c2jzOEFlx9/TLH41xOjF2XjpZME=; X-YMail-OSG: p_naqYoVM1k8h9.pNsw5qeWaWi.N2xoQnYRPbntHxDHAUnSmCZRDU.sd4z7zU7.G_fRTsU6BaQ-- Received: from [69.236.76.222] by web33306.mail.mud.yahoo.com via HTTP; Fri, 20 Jul 2007 07:48:38 PDT Date: Fri, 20 Jul 2007 07:48:38 -0700 (PDT) From: Pyda Srisuresh To: Philip Matthews , Henry Sinnreich In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <615870.42407.qm@web33306.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-Mailman-Approved-At: Fri, 20 Jul 2007 10:52:49 -0400 Cc: Magnus Westerlund , behave@ietf.org, mmusic@ietf.org, sip@ietf.org, Pyda Srisuresh , "Frank W. Miller" , p2psip@ietf.org Subject: [P2PSIP] Re: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org --- Philip Matthews wrote: > > On 18-Jul-07, at 15:31 , Henry Sinnreich wrote: > > > Phil, > > > >> In my view, ICE _is_ a "Hole Punching Technique". > > > > Yes, you absolutely right, though the devil is in the details. > > > > We cannot go here into a shoot-out between hole punching or other > > mentioned on the list vs. ICE, but there seems to be a huge difference > > in effectiveness and performance. > > What precise algorithm are you talking about when you say this? > As far as I am concerned, ICE is simply a well-documented hole > punching algorithm. > It differs from others that I have seen written up in the following > ways: > - ICE has the concept of peer reflexive addresses, which other hole- > punching techniques that I have seen do not; [suresh] I dont know what you are talking about. AFAIK, Peer reflexive address is same as the public endpoint assigned to a node behind NAT. How can that be not part of HOLE-PUNCHING technique? > - ICE has the concept of controlling/controlled endpoint, which gives > the controller additional flexibility in choosing a path; [suresh] HOLE-PUNCHING technique is based on communication along a control path with external rendezvous server(s), which act as the key controller. The peering endpoints either make requests to punch holes or receiving requests to help in hole-punching by a peer. > - ICE does NOT have the concept of port prediction, which some other > techniques do (e.g., Saikat's TCP work). [suresh] Hole punchign technique is not complete by itself to setup connections. It needs a fallback scheme. Port prediction and relays can be effective fallback to hole punching. regards, suresh > > Philip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 23 09:02:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICxYc-0002rf-Gt; Mon, 23 Jul 2007 09:02:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICxYb-0002rO-1K for p2psip@ietf.org; Mon, 23 Jul 2007 09:02:37 -0400 Received: from nz-out-0506.google.com ([64.233.162.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICxYa-0004T7-Na for p2psip@ietf.org; Mon, 23 Jul 2007 09:02:36 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1062183nzf for ; Mon, 23 Jul 2007 06:02:36 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=A6I9HjAiktWa6zJBn7qTMvBaqS5LHxpf3uhyhh7JHYrB8qn40peSWau0XLM6/C2Rkkx3+dF6qgQZ/ixNoZkBr0P5ItKDLeiAjKjs22cWWPQxsVEePiAMvL14U52Cu5MtqfC5gZRpML7M+sCz7iqcyPSnG1QKZrqfC0qT16ewCjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=APSsZtfqAz6b1uKUVeFncvkN94tCFNBgwPJ7kKNmz03wgO+MFjugzpeRGkNYNzqkwMRgqR5FEe13AfI+BHEsnzUj5O15GZ9mbEHSxfvk07HFI8UbardB83KMLOUyVg/a9KYe4VqX7ATK0nSeUNsCfu8qU1KsRHlbO32ZPP9FlYI= Received: by 10.65.133.8 with SMTP id k8mr4393466qbn.1185195755824; Mon, 23 Jul 2007 06:02:35 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Mon, 23 Jul 2007 06:02:35 -0700 (PDT) Message-ID: <4d4304a00707230602p1e771074ib028fecc4060b788@mail.gmail.com> Date: Mon, 23 Jul 2007 08:02:35 -0500 From: "David A. Bryan" To: "P2PSIP WG" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: cd9cbfb42d37e3cd X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [P2PSIP] Late night peer protocol presentations meeting X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hello all: I have spoken with the room coordinator, and it appears we do have our room for tonight, from 10-midnight (2200-2400). We will have the meeting where each group proposing a peer protocol will be given time to present for 10 minutes about their protocol, and then leave 10 minutes for questions and comments. One interesting issue -- it looks like we won't have a projector, so folks will need to do things the old fashioned way! David -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 23 10:16:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyiR-0003MU-Qs; Mon, 23 Jul 2007 10:16:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyiQ-0003MM-Li for p2psip@ietf.org; Mon, 23 Jul 2007 10:16:50 -0400 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICyiQ-0006DL-7c for p2psip@ietf.org; Mon, 23 Jul 2007 10:16:50 -0400 Received: from source ([192.150.11.134]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Mon, 23 Jul 2007 07:16:45 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6NEFQot003878; Mon, 23 Jul 2007 07:15:27 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6NEFk16028679; Mon, 23 Jul 2007 07:16:43 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 07:16:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Late night peer protocol presentations meeting Date: Mon, 23 Jul 2007 07:16:34 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEE227@namail5.corp.adobe.com> In-Reply-To: <4d4304a00707230602p1e771074ib028fecc4060b788@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Late night peer protocol presentations meeting Thread-Index: AcfNKcYkZw/Mank0QsKEUGpyS8PLBQACUbUg References: <4d4304a00707230602p1e771074ib028fecc4060b788@mail.gmail.com> From: "Henry Sinnreich" To: "David A. Bryan" , "P2PSIP WG" X-OriginalArrivalTime: 23 Jul 2007 14:16:36.0374 (UTC) FILETIME=[142B8B60:01C7CD34] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Please let us know the room when we get it. Thanks, Henry -----Original Message----- From: David A. Bryan [mailto:dbryan@sipeerior.com]=20 Sent: Monday, July 23, 2007 8:03 AM To: P2PSIP WG Subject: [P2PSIP] Late night peer protocol presentations meeting Hello all: I have spoken with the room coordinator, and it appears we do have our room for tonight, from 10-midnight (2200-2400). We will have the meeting where each group proposing a peer protocol will be given time to present for 10 minutes about their protocol, and then leave 10 minutes for questions and comments. One interesting issue -- it looks like we won't have a projector, so folks will need to do things the old fashioned way! David --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 23 10:20:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICylh-0004d2-Dm; Mon, 23 Jul 2007 10:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICylg-0004bY-JJ for p2psip@ietf.org; Mon, 23 Jul 2007 10:20:12 -0400 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICylg-0007iS-1x for p2psip@ietf.org; Mon, 23 Jul 2007 10:20:12 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1082912nzf for ; Mon, 23 Jul 2007 07:20:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=SyPkUkQ6V6ygfIs2pitsVqQbG4qxCeJTg7XOjOaKnT0rsK9qLBd6P767yzlFKMzWhctiGOverV2v4T/UknrtOTGFFljSjqAFsuPZ8jRcR92eIUvJfjQIMyv67uHp/23Bk2nBvyZLi7t7/KUJv6dhXKRqG19GvlsFuHdze7TetIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=VMNlsDfr33MIbtHA61H4zJdK+qx0rQg5VmHL0cZxqon7WAsjlQ5CMQqyBeIAY/6cve/H+CiOKSSr6Z+mNMYBjux8yd3ADv5LoYIlO0Fcft7oHkFhctU+xOfiFm/feslYgpVlsGuJuf0etc0DIpRVdKQPkXCjNtRhJa+oKYZ1TZc= Received: by 10.65.200.8 with SMTP id c8mr4551549qbq.1185200411542; Mon, 23 Jul 2007 07:20:11 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Mon, 23 Jul 2007 07:20:11 -0700 (PDT) Message-ID: <4d4304a00707230720i7b30a705lcb7dbd92cbede7d0@mail.gmail.com> Date: Mon, 23 Jul 2007 09:20:11 -0500 From: "David A. Bryan" To: "Henry Sinnreich" Subject: Re: [P2PSIP] Late night peer protocol presentations meeting In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22AEE227@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d4304a00707230602p1e771074ib028fecc4060b788@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D22AEE227@namail5.corp.adobe.com> X-Google-Sender-Auth: 5ae78e58c3697eb4 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Will do. So far I have been told we have it, but not the room #. Now, nobody happened to bring a projector in their carry on luggage, did they? :) David On 7/23/07, Henry Sinnreich wrote: > Please let us know the room when we get it. > > Thanks, Henry > > -----Original Message----- > From: David A. Bryan [mailto:dbryan@sipeerior.com] > Sent: Monday, July 23, 2007 8:03 AM > To: P2PSIP WG > Subject: [P2PSIP] Late night peer protocol presentations meeting > > Hello all: > > I have spoken with the room coordinator, and it appears we do have our > room for tonight, from 10-midnight (2200-2400). We will have the > meeting where each group proposing a peer protocol will be given time > to present for 10 minutes about their protocol, and then leave 10 > minutes for questions and comments. > > One interesting issue -- it looks like we won't have a projector, so > folks will need to do things the old fashioned way! > > David > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 23 10:30:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyw0-0006ii-4G; Mon, 23 Jul 2007 10:30:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICyvy-0006id-Uo for p2psip@ietf.org; Mon, 23 Jul 2007 10:30:50 -0400 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICyvy-0006cl-Ei for p2psip@ietf.org; Mon, 23 Jul 2007 10:30:50 -0400 Received: from source ([192.150.11.134]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Mon, 23 Jul 2007 07:30:48 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6NETTot007694; Mon, 23 Jul 2007 07:29:30 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id l6NEUZ0w001157; Mon, 23 Jul 2007 07:30:46 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 07:30:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Late night peer protocol presentations meeting Date: Mon, 23 Jul 2007 07:30:19 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22AEE233@namail5.corp.adobe.com> In-Reply-To: <4d4304a00707230720i7b30a705lcb7dbd92cbede7d0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Late night peer protocol presentations meeting Thread-Index: AcfNNKAMpz0bvkpPQXmU9YhIWM9AwgAARCkg References: <4d4304a00707230602p1e771074ib028fecc4060b788@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D22AEE227@namail5.corp.adobe.com> <4d4304a00707230720i7b30a705lcb7dbd92cbede7d0@mail.gmail.com> From: "Henry Sinnreich" To: "David A. Bryan" X-OriginalArrivalTime: 23 Jul 2007 14:30:46.0005 (UTC) FILETIME=[0E96F250:01C7CD36] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >Now, nobody happened to bring a projector in their carry on luggage, did they? :) Could we get all the slides by e-mail? If yes, please put in the Subject line "My slides for P2P SIP I-D " Thanks, Henry -----Original Message----- From: amelampus@gmail.com [mailto:amelampus@gmail.com] On Behalf Of David A. Bryan Sent: Monday, July 23, 2007 9:20 AM To: Henry Sinnreich Cc: P2PSIP WG Subject: Re: [P2PSIP] Late night peer protocol presentations meeting Will do. So far I have been told we have it, but not the room #. Now, nobody happened to bring a projector in their carry on luggage, did they? :) David On 7/23/07, Henry Sinnreich wrote: > Please let us know the room when we get it. > > Thanks, Henry > > -----Original Message----- > From: David A. Bryan [mailto:dbryan@sipeerior.com] > Sent: Monday, July 23, 2007 8:03 AM > To: P2PSIP WG > Subject: [P2PSIP] Late night peer protocol presentations meeting > > Hello all: > > I have spoken with the room coordinator, and it appears we do have our > room for tonight, from 10-midnight (2200-2400). We will have the > meeting where each group proposing a peer protocol will be given time > to present for 10 minutes about their protocol, and then leave 10 > minutes for questions and comments. > > One interesting issue -- it looks like we won't have a projector, so > folks will need to do things the old fashioned way! > > David > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 23 14:16:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID2SP-0003DF-3V; Mon, 23 Jul 2007 14:16:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID2SO-0003DA-Dx for p2psip@ietf.org; Mon, 23 Jul 2007 14:16:32 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID2SO-0004zR-5D for p2psip@ietf.org; Mon, 23 Jul 2007 14:16:32 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 14:16:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALaNpEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,571,1175486400"; d="scan'208"; a="126790060:sNHT26394596" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6NIGVGk003703 for ; Mon, 23 Jul 2007 14:16:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NIG9Wk007234 for ; Mon, 23 Jul 2007 18:16:31 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 14:16:28 -0400 Received: from [10.86.240.240] ([10.86.240.240]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 14:16:28 -0400 Message-ID: <46A4F084.6020908@cisco.com> Date: Mon, 23 Jul 2007 14:16:36 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 18:16:28.0317 (UTC) FILETIME=[966FC4D0:01C7CD55] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=473; t=1185214591; x=1186078591; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20My=20slides=20for=20P2P=20SIP=20I-D=20ASP |Sender:=20 |To:=20P2PSIP=20WG=20; bh=UUyla+xABIW/eFOrCIB7P0Kvdq7umpw2uW8oUDfUKGc=; b=WXuxU/pBtrlBzrlOluW0y+RdtNTyzCyC9r7/SUkXGgL+98MEkCWZd0kdWNk4BNNWWatSfncn N1mM40dkRy55R1bcGeUWwW6jAfzRGR5WxonRKjSQ7k2t8jUj/VAbEJ0W; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [P2PSIP] My slides for P2P SIP I-D ASP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Can be found here: http://www.jdrosen.net/papers/ietf69-p2psip-jdrosen-asp.ppt These are for the evening session tonight. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 23 15:56:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID40r-00014U-M5; Mon, 23 Jul 2007 15:56:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID40m-0000t9-2B; Mon, 23 Jul 2007 15:56:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID40l-0000LV-JA; Mon, 23 Jul 2007 15:56:07 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 15:56:07 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACalpEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,572,1175486400"; d="scan'208"; a="126801974:sNHT29190148" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6NJu6Zx023742; Mon, 23 Jul 2007 15:56:06 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NJtvWs017987; Mon, 23 Jul 2007 19:56:06 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 15:55:41 -0400 Received: from [10.86.242.144] ([10.86.242.144]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 15:55:41 -0400 Message-ID: <46A507C5.5060206@cisco.com> Date: Mon, 23 Jul 2007 15:55:49 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 19:55:41.0404 (UTC) FILETIME=[72C0C1C0:01C7CD63] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1840; t=1185220566; x=1186084566; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20ICE=20tutorial=20in=20Chicago=20is=20CONFIRMED=20[DO=20NOT=20 REPLY]=20-=20lunch=20logistics=0A=20below |Sender:=20 |To:=20IETF=20SIP=20List=20, =20IETF=20Sipping=20List=20, =0A=20=20=20=20=20=20=20=20IETF=20MMUSIC=20WG=20, =20Behave=20WG=20, =0A=20=20=20=20=20=20=20=20P2PSI P=20WG=20, =20rai@ietf.org, =0A=20=20=20=20=20=20=20=20=22' avt@ietf.org'=22=20; bh=KpxqDxUhtprUSwrX98Ct3c1X0mBsvpY4gzyMN2aH5Go=; b=Ncyw7y256jwE7lC5Q5QuZfDCdjVn1oabrjGvlOL+VyhF0ZalmP15rKSMhRmaAGHHsSvG2PuK zZyuKd5iE8415bdWZIZuxeIGqTOje15E+zSKCePNlEj5RGkZbwjUABDm; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [P2PSIP] ICE tutorial in Chicago is CONFIRMED [DO NOT REPLY] - lunch logistics below X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org (Apologies to multiple recipients) (DO NOT REPLY) WHAT: Tutorial on Interactive Connectivity Establishment (ICE) (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-17.txt) Slides: http://www.jdrosen.net/papers/ice-ietf-tutorial2.ppt WHEN: Tuesday, July 24, 2007, 1145-1245 lunch will be available to those who RSVPd previously sandwiches, chips, salad and drinks $20/head - please pay Jonathan R. after the tutorial WHERE: Red Lacquar MP3 streaming hopefully available at: http://videolab.uoregon.edu/events/ietf/ietf694.m3u WHO: Anyone that would like to learn more about ICE. WHY: ICE, developed by the mmusic working group, has been defined as the IETF tool for NAT traversal for SIP-based media. It is also seeing increased usage for traversal for other kinds of application traffic - anything worrying about any-to-any communications. In this tutorial, we will overview the background of the problem, consider the requirements driving ICE, and provide an overview of how ICE works. An understanding of SIP is not required. The tutorial will be based on the pending -17 version. RSVP: Anyone may attend without RSVP, but lunch may not be there for you if you have not RSVPd previously. I've ordered a few extra !DO NOT REPLY TO THIS NOTE! -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 23 20:21:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID89Q-0004z1-P9; Mon, 23 Jul 2007 20:21:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID89O-0004vj-6o for p2psip@ietf.org; Mon, 23 Jul 2007 20:21:19 -0400 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID89N-0007in-VK for p2psip@ietf.org; Mon, 23 Jul 2007 20:21:18 -0400 Received: by py-out-1112.google.com with SMTP id f31so5611788pyh for ; Mon, 23 Jul 2007 17:21:17 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=uRhBugHBy1/AjlvxR/VAQ5v1sD57+ig68VgpdH/XlUfSWdfMOrxStRMxJ8M/0OEvR60HfYfDtX3RRVf59bP3s6BqwF4HerHAGXoVNQ8dJLEOG6pnUyLrfWvJ21JSBXzFaOL38oVe10BTyIlsJrWsMVks/ktVAYXBLcFHQYP3tvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=G2MYjVy9SbKMZJ9XsAWf2BPaduRU0Wrgt0pwxUvCt+LbcPaGIDVaCQmowOjFPam4PgaLV6SyeOJL+9U4CqseJvVTd1hnN0KmjG2Aykxyar/BHQAExr5eIXDfu5JWoPdnYPM8g1eV6GNEDbGH9d3POW2GltXiZCPnFnbPUB8ysYQ= Received: by 10.65.248.19 with SMTP id a19mr5488762qbs.1185236477539; Mon, 23 Jul 2007 17:21:17 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Mon, 23 Jul 2007 17:21:17 -0700 (PDT) Message-ID: <4d4304a00707231721h4bd431c3x24cf19b1c0739e0e@mail.gmail.com> Date: Mon, 23 Jul 2007 19:21:17 -0500 From: "David A. Bryan" To: "P2PSIP WG" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 3f4e8b84ca86447c X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [P2PSIP] Room for the ad-hoc tonight X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We'll be meeting in Salon 2. I'll upload the presentations I have so far for people to look at. -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 23 21:01:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8m6-0007VC-Ea; Mon, 23 Jul 2007 21:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8m5-0007Rj-3k for p2psip@ietf.org; Mon, 23 Jul 2007 21:01:17 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID8m4-0008KM-S4 for p2psip@ietf.org; Mon, 23 Jul 2007 21:01:17 -0400 Received: by ug-out-1314.google.com with SMTP id u2so210714uge for ; Mon, 23 Jul 2007 18:01:16 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=f907/ab/wt4gDZgX+ydcELyUx8Q/+/P2ezdH12NjUgjFckNgwc7ldjBrhH/o/GwPQFeL9i6+hkjrxGkGmIJ9Ir9Y6v0Pc9OfYkJv7UmgdYtjH4+5l9iohOBpjlU8i+LjzNPrUatOCPdt9NyLJ9jOKaSA2uY25q2zkf7ret5x2aQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FFRNhj2L5mmXrgZDNPFGKQYaGVjTrheMVWIjvaB4SON/FWcrh9aNbouGZtJ2V6SsD6A84PRbSCb7poIZkPosR1v3AUw2HTpZjeBpiSQ5VoBfwzfAowXITbiU15jTpzwGzGDywuNHO69YyXeMxiAe27fQgk0H7lRcVVRGZnMVuis= Received: by 10.67.96.14 with SMTP id y14mr232755ugl.1185238876029; Mon, 23 Jul 2007 18:01:16 -0700 (PDT) Received: by 10.66.238.6 with HTTP; Mon, 23 Jul 2007 18:01:15 -0700 (PDT) Message-ID: <88ac5c710707231801v5dfe15b2m924339e8beb7e82d@mail.gmail.com> Date: Mon, 23 Jul 2007 20:01:15 -0500 From: "Richard Barnes" To: p2psip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [P2PSIP] Room for ad-hoc tonight? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Has there been a room assigned for the p2psip ad-hoc tonight? Sorry if this has already been discussed, I haven't had access to recent p2psip messages. Thanks, --Richard _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Jul 23 21:32:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID9Gb-0002QG-BM; Mon, 23 Jul 2007 21:32:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID9GZ-0002PQ-OB for p2psip@ietf.org; Mon, 23 Jul 2007 21:32:47 -0400 Received: from qb-out-0506.google.com ([72.14.204.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID9GZ-0000Qi-7m for p2psip@ietf.org; Mon, 23 Jul 2007 21:32:47 -0400 Received: by qb-out-0506.google.com with SMTP id o21so1663469qba for ; Mon, 23 Jul 2007 18:32:47 -0700 (PDT) Received: by 10.65.116.10 with SMTP id t10mr5551718qbm.1185240766648; Mon, 23 Jul 2007 18:32:46 -0700 (PDT) Received: by 10.65.215.4 with HTTP; Mon, 23 Jul 2007 18:32:46 -0700 (PDT) Message-ID: Date: Mon, 23 Jul 2007 20:32:46 -0500 From: "Emil Ivov" To: p2psip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [P2PSIP] XPP slides for the ad-hoc tonight X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0991025443==" Errors-To: p2psip-bounces@ietf.org --===============0991025443== Content-Type: multipart/alternative; boundary="----=_Part_84238_14104820.1185240766622" ------=_Part_84238_14104820.1185240766622 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey all, Here are the slides that I'll be using tonight to present XPP: http://sip-communicator.org/xpp-ietf69.ppt Cheers Emil ------=_Part_84238_14104820.1185240766622 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hey all,

Here are the slides that I'll be using tonight to present XPP:

http://sip-communicator.org/xpp-ietf69.ppt

Cheers
Emil
------=_Part_84238_14104820.1185240766622-- --===============0991025443== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0991025443==-- From p2psip-bounces@ietf.org Mon Jul 23 22:43:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDAMT-0000qO-2H; Mon, 23 Jul 2007 22:42:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDAMR-0000qB-KW for p2psip@ietf.org; Mon, 23 Jul 2007 22:42:55 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDAMO-0002Af-UD for p2psip@ietf.org; Mon, 23 Jul 2007 22:42:55 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 3D1E820AAF for ; Tue, 24 Jul 2007 04:42:52 +0200 (CEST) X-AuditID: c1b4fb3c-ae67bbb0000007e1-09-46a5672c6a49 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1CDF620535 for ; Tue, 24 Jul 2007 04:42:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 04:42:52 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 04:42:50 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5076723F6 for ; Tue, 24 Jul 2007 05:42:50 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 22CC14DBA0 for ; Tue, 24 Jul 2007 05:42:50 +0300 (EEST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 61EB44DB9F for ; Tue, 24 Jul 2007 05:42:47 +0300 (EEST) Message-ID: <46A5672F.1080600@ericsson.com> Date: Mon, 23 Jul 2007 21:42:55 -0500 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: p2psip@ietf.org Content-Type: multipart/mixed; boundary="------------000405020506090801050104" X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 24 Jul 2007 02:42:50.0902 (UTC) FILETIME=[53DE5360:01C7CD9C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 08aa56e70047071f9a3037af5750d40e Subject: [P2PSIP] LOCSER+HIP slides for the ad-hoc tonight X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --------------000405020506090801050104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Here's the "LOCSER+HIP" Peer Protocol proposal slides the P2PSIP ad-hoc tonight. The associated draft are: - draft-hautakorpi-p2psip-peer-protocol-00.txt and - draft-hautakorpi-p2psip-with-hip-00.txt -- Jani --------------000405020506090801050104 Content-Type: application/vnd.ms-powerpoint; name="LOCSER_plus_HIP.ppt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="LOCSER_plus_HIP.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAQAAAAAAA AAAAEAAA/v///wAAAAD+////AAAAAD8AAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////8PAOgDtwoAAAEA6QMoAAAAgBYAAOAQAADgEAAA gBYAAAUAAAAKAAAABwAAAAAAAAABAAAAAAEAAQ8A8gOsAQAALwDIDwwAAAAwANIPBAAAAAEA AAAPANUH5AAAAAAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAACUt7x/ fLe8fxbnBzAIAAAAAAAAAJS3vH96WwkwjLe8fwAABBIQALcPRAAAAEMAbwB1AHIAaQBlAHIA IABOAGUAdwAAAG0AYQBuAAAAlLe8f3y3vH8W5wcwCAAAAAAAAACUt7x/elsJMIy3vH8AAAQx IAC3D0QAAABBAHIAaQBhAGwAAAByACAATgBlAHcAAABtAGEAbgAAAJS3vH98t7x/FucHMAgA AAAAAAAAlLe8f3pbCTCMt7x/AAAEAAAApA8IAAAAgABAAAAA//8AAKUPDAAAAAAAAAguAAIA BwAAAAAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAA AAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAA QAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEOAEAAA8AAPAwAQAAAAAG8LAA AAAEUAAAFQAAAF4AAAAKAAAAAQAAAAcAAAACAAAABAAAAAAAAAAeAAAABgAAAAQAAAAAAAAA AwAAAAUAAAAIAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAUAAAAIAAAAJAAAAAkA AAAEAAAACgAAAAQAAAALAAAABAAAAAAAAAAEAAAAAAAAAAsAAAAAAAAABAAAAA4AAABNAAAA DwAAAAQAAAAAAAAABAAAAIMAC/AwAAAAgQEEAAAIgwEAAAAIhkEAAAAAvwEQABAAwAEBAAAI xUEAAAAA/wEIAAgAAQICAAAIgAAa8SAAAADd3d0A+Pj4AP//zADq6uoAX19fAP9mAAAzmWYA M2b/AEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A8cAAAAAADzAxQAAAACAAAAAAAAAAAA AAAAAACAAAAAAA8A0AfjAQAAHwAUBBwAAAAAABUEFAAAAGaSUAkAypo7gWw9NQDKmjsBAQAA DwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAUgAAAGQAAABSAAAAZAAAAAgAAAAAAAAArLe8 f3pbCTAAAAAAAAAAAIL8//+s////AQC8f3AA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABA CwAAHwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAADYt7x/3x0JMBS5vH9ULYx+AAAA AAAAAAAAAAAAAAAAAAABvH8fABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAANi3vH/f HQkwFLm8f1QtjH4AAAAAAAAAAAAAAAAAAAAAAAG8fx8A/wMUAAAAAgAABAwAAAAAAAAAAAAA AAIAAAAPAIgTpAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAA AA0ECAAAAADAAAAAwAAADwCKE2QAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLE0YAAAAP AK4PPgAAAAAArw8IAAAAAAEAAAYAAAAAAKwPJgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAA AAEAAAAAAAAAAAAAAAAAPwDZDywAAAAAANoPBAAAAAAAJQAgALoPGAAAAEwATwBDAFMARQBS ACAAKwAgAEgASQBQAE8A2Q8MAAAAAADaDwQAAAANAD0ADwDwD9AEAAAAAPMDFAAAAAMAAAAA AAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoD2QAAABMT0NTRVIgKyBISVAgCwsLZHJh ZnQtaGF1dGFrb3JwaS1wMnBzaXAtcGVlci1wcm90b2NvbC0wMC50eHQLZHJhZnQtaGF1dGFr b3JwaS1wMnBzaXAtd2l0aC1oaXAtMDAudHh0AAChD0wAAABlAAAAAAAAACAAAQAGAAAAAABG AAAAMAAAAAACBgAAAAAAAgAwAAIAAAAAAAAAAQAAAAAEIwAABAEAAgASAFYAAAAACAMAAAgB ABIAAACqDx4AAAAOAAAAAAAAAAEAAAAHAAAAAAABBAAAVgAAAAAAAAAQAJ8PBAAAAAUAAAAA AKgPNQAAAEphbmkuSGF1dGFrb3JwaUBlcmljc3Nvbi5jb20gJg1Kb2FraW0uS29za2VsYUBo aWl0LmZpAAChDxQAAAA2AAAAAAAAAAAANgAAAAAAAgAcAAAAqg8kAAAAHAAAAAEAAAADAAMA AAAAAAAAFgAAAAEAAAADAAEAAAAAAAAAAADzAxQAAAAMAAAABAAAAAEAAAAEAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8IAAAAT3ZlcnZpZXcAAKEPFAAAAAkAAAAAAAAAIAABAAkAAAAAAAAA AADzAxQAAAAQAAAABAAAAAEAAAAGAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8eAAAARXhhbXBs ZTogU2Vzc2lvbiBFc3RhYmxpc2htZW50AAChDxQAAAAfAAAAAAAAACAAAQAfAAAAAAAAAAAA 8wMUAAAADgAAAAAAAAACAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPCgAAAEhpZ2hsaWdo dHMQAJ8PBAAAAAEAAAAAAKgPYQEAAEJlbmVmaXRzIG9mIEhJUCBmb3IgUDJQU0lQOg1TdXBw b3J0cyBtb2JpbGl0eSAoaS5lLiBjb25uZWN0aW9ucyBjYW4gc3Vydml2ZSB0aGUgSVAtYWRk cmVzcyBleGNoYW5nZSkNSGFzIGEgSUNFLWxpa2UgTkFUIHRyYXZlcnNhbCBtZWNoYW5pc20N U3VwcG9ydCBmb3IgbGVhcC1vZi1mYWl0IHR5cGUgb2Ygc2VjdXJpdHkgd2l0aCBzZWxmLXNp Z25lZCBjZXJ0aWZpY2F0ZXMNRGlzdGluY3QgZGVzaWduIGNob2ljZXM6DUxPQ1NFUjogTm90 IGdlbmVyaWMsIEhJUDogR2VuZXJpYw1PdmVybGF5IHJvdXRpbmcgaXMgZG9uZSBhYm92ZSB0 aGUgSElQIGxheWVyDU5vIGNoYW5nZXMgdG8gSElQLCBqdXN0IGEgQkNQIGRvY3VtZW50AACh D1wAAAAcAAAAAAAAEAAAWgC4AAAAAQAAEAAAWgAZAAAAAAAAEAAAWgB1AAAAAQAAEAAAWgAc AAAAAAACABwAuAAAAAAAAgAYABkAAAAABAIAAAQcAHUAAAAACAIAAAgYAAAA8wMUAAAABQAA AAAAAAABAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFAAAAFF1ZXN0aW9ucywgY29tbWVu dHM/AAChDxQAAAAVAAAAAAAAACAAAQAVAAAAAAAAAC8A8A9UAAAAAADzAxQAAAANAAAAAAAA AAAAAAABAQAAAAAAAAAA8wMUAAAADwAAAAAAAAAAAAAAAgEAAAAAAAAAAPMDFAAAABEAAAAA AAAAAAAAAAQBAAAAAAAAAADqAwAAAAAPAPgDTAkAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAA AAAAAAAAALx/YADwByAAAAAAAP8A////AAAAAAD//wAA/5kAAAD//wD/AAAAlpaWAGAA8Acg AAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgBgAPAHIAAAAP///wAAAAAAMzMz AAAAAADd3d0AgICAAE1NTQDq6uoAYADwByAAAAD//8wAAAAAAGZmMwCAgAAAM5kzAIAAAAAA M8wA/8xmAGAA8AcgAAAA////AAAAAACAgIAAAAAAAP/MZgAAAP8AzADMAMDAwABgAPAHIAAA AP///wAAAAAAgICAAAAAAADAwMAAAGb/AP8AAAAAmQAAYADwByAAAAD///8AAAAAAICAgAAA AAAAM5n/AJn/zADMAMwAsrKyAAAAow8+AAAAAQD//T8AAAAiIAAAZAAAAAAAAQBkAAAAAAAA AAAAQAIAAAAABwAAAP//7wAAAAAA////////LAAAAAADAAAQAKMPfAAAAAUA//0/AAEAIiAA AGQAAAAAAAAAZAAUAAAA2AAAAEACAAAAAAcAAAD//+8AAAAAAP///////yAAAAAAAQAAgAUA ABMg1AEgAQAAAgAcAIAFAAAiINACQAIAAAIAGACABQAAEyDwA2ADAAACABQAgAUAALsAEAWA BAAAAAAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAcAAAD/ /+8AAAAAAP///////wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMA AAAAAAUAAIAEgAQAAAAAUACjD1IAAAAFAAAAAQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEA AAAAAgABCQAAAAABAEACAAAAAAMAAQkAAAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACj DwwAAAABAAAAAAAAAAAAAABwAKMPPgAAAAUAAAAAAAAAAAACABwAAQAAAAAAAAACABgAAgAA AAAAAAACABQAAwAAAAAAAAACABIABAAAAAAAAAACABIAgACjDz4AAAAFAAAAAAAAAAAAAgAY AAEAAAAAAAAAAgAUAAIAAAAAAAAAAgASAAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAQAA8ADARq BQAADwAC8GIFAAAQAAjwCAAAAAYAAAAGBAAADwAD8PoEAAAPAATwKAAAAAEACfAQAAAAAAAA AAAAAAAAAAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATw4AAAABIACvAIAAAAAgQAAAAKAACT AAvwNgAAAH8AAQAFAIAAXICMfocAAQAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACBMAIvEGAAAAvwMAAAAEAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAAAADDCwgAAAAA AAAAAQCMfg8ADfBUAAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGljayB0byBlZGl0IE1hc3Rl ciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAAAQAAAAAADwAE8CQBAAAS AArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEABQCAAPSCjH6BAQQAAAiDAQAAAAi/AQEAEQDA AQEAAAj/AQEACQABAgIAAAgTACLxBgAAAL8DAAAABAAAEPAIAAAA4ASwAdAUAA8PABHwEAAA AAAAwwsIAAAAAQAAAAIAjH4PAA3wngAAAAAAnw8EAAAAAQAAAAAAqA9SAAAAQ2xpY2sgdG8g ZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVsDUZvdXJ0 aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMADAAA AAQAAACqDwoAAABTAAAAAQAAAAAADwAE8N4AAAASAArwCAAAAAQEAAAACgAAgwAL8DAAAAB/ AAEABQCAAKCJjH6BAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgTACLxBgAA AL8DAAAABAAAEPAIAAAAYA+wAWAGgBAPABHwEAAAAAAAwwsIAAAAAgAAAAcBjH4PAA3wWAAA AAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAA4AAAD4 DwQAAAAAAAAAAACqDxIAAAABAAAAAQAAAAAAAQAAAAAAAAAPAATw4AAAABIACvAIAAAABQQA AAAKAACDAAvwMAAAAH8AAQAFAIAAZI6MfoEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACBMAIvEGAAAAvwMAAAAEAAAQ8AgAAABgD7AH0A6AEA8AEfAQAAAAAADDCwgAAAAD AAAACQKMfg8ADfBaAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgA AAEAAgAAAAAAAgAOAAAA+g8EAAAAAAAAAAAAqg8SAAAAAQAAAAEAAAAAAAEAAAAAAAAADwAE 8OAAAAASAArwCAAAAAYEAAAACgAAgwAL8DAAAAB/AAEABQCAACyTjH6BAQQAAAiDAQAAAAi/ AQEAEQDAAQEAAAj/AQEACQABAgIAAAgTACLxBgAAAL8DAAAABAAAEPAIAAAAYA8gENAUgBAP ABHwEAAAAAAAwwsIAAAABAAAAAgCjH4PAA3wWgAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAA AKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADgAAANgPBAAAAAAAAAAAAKoPEgAAAAEAAAAB AAAAAAABAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABBAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAA AICAgAAAAAAAAMyZADMzzADMzP8AsrKyACAAug84AAAAVQB0AGkAbABpAHoAaQBuAGcAXwBI AEkAUABfAGYAbwByAF8AUAAyAFAAUwBJAFAAXwB2ADAANAAPAPAD+gUAAAEA8QMIAAAAAAAA gAAACjAPAAwEegUAAA8AAvByBQAAUAAI8AgAAAAHAAAABxgAAA8AA/AKBQAADwAE8CgAAAAB AAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAYAAAFAAAADwAE8MgAAAASAArwCAAA AAIYAAAACgAAgwAL8DAAAAB/AAEABQCAAHjnjH6BAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/ AQEACQABAgIAAAgAABDwCAAAAAAAAABQByABDwAR8BAAAAAAAMMLCAAAAAAAAAAKAox+DwAN 8FAAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAM AAAA+Q8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAA8ABPDKAAAAEgAK8AgAAAADGAAAAAoA AIMAC/AwAAAAfwABAAUAgAC07Ix+gQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQIC AAAIAAAQ8AgAAAAAAJAJ4BAgAQ8AEfAQAAAAAADDCwgAAAABAAAABwCMfg8ADfBSAAAAAACf DwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAMAAAA+A8E AAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAA8ABPBkAAAAEgAK8AgAAAAEGAAAAAoAAGMAC/Ak AAAAfwAEAAQAhwABAAAAfwEAAAEAvwERABEA/wEIAAkAPwIBAAEAAAAQ8AgAAACwAdACEA4g Cg8AEfAQAAAAAADDCwgAAAACAAAABQCMfg8ABPAWAQAAEgAK8AgAAAAFGAAAAAoAAIMAC/Aw AAAAfwABAAUAgAD07ox+gQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ 8AgAAACwCkACoA7QFA8AEfAQAAAAAADDCwgAAAADAAAABgKMfg8ADfCeAAAAAACfDwQAAAAC AAAAAACoD1IAAABDbGljayB0byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2 ZWwNVGhpcmQgbGV2ZWwNRm91cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAAN AAAAAQAMAAAAAgANAAAAAwAMAAAABAAAAKoPCgAAAFMAAAABAAAAAAAPAATwzgAAABIACvAI AAAABhgAAAAKAACTAAvwNgAAAH8AAQAFAIAA8PKMfocAAgAAAIEBBAAACIMBAAAACL8BAQAR AMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAYBUAAFAHgBYPABHwEAAAAAAAwwsIAAAABAAA AAkCjH4PAA3wUAAAAAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAAC AAAAAAACAAwAAAD6DwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAADwAE8NAAAAASAArwCAAA AAcYAAAACgAAkwAL8DYAAAB/AAEABQCAAMj3jH6HAAIAAACBAQQAAAiDAQAAAAi/AQEAEQDA AQEAAAj/AQEACQABAgIAAAgAABDwCAAAAGAVkAngEIAWDwAR8BAAAAAAAMMLCAAAAAUAAAAI Aox+DwAN8FIAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgAC AAAAAAACAAwAAADYDwQAAAAAAAAAAACqDwoAAAACAAAAAQAAAAAADwAE8EgAAAASAArwCAAA AAEYAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAd69aACUAY6fiwC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwCI EzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAAD+ k8UB0GeKZg8A7gPkAQAAAgDvAxgAAAAAAAAADxAAAAAAAAAAAACAAAAAAAcAvH8PAAwElAEA AA8AAvCMAQAAIAAI8AgAAAADAAAAAwgAAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAA AAAAAAAAAAAAAAACAArwCAAAAAAIAAAFAAAADwAE8HIAAAASAArwCAAAAAIIAAAgAgAAUwAL 8B4AAAB/AAAABACAALwEBn6/AQAAAQD/AQAAAQABAwIEAAAAABDwCAAAAIAE8AC0FWAJDwAR 8BAAAAAAAMMLCAAAAAAAAAAPAAZ+DwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAI AAAAAwgAACACAABTAAvwHgAAAH8AAAAEAIAAkAUGfr8BAAABAP8BAAABAAEDAwQAAAAAEPAI AAAAgQpgAyAT0Q4PABHwEAAAAAAAwwsIAAAAAQAAABAABn4PAA3wDAAAAAAAng8EAAAAAQAA AA8ABPBIAAAAEgAK8AgAAAABCAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHe vWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAAMyZ ADMzzADMzP8AsrKyAA8A7gP4CAAAAgDvAxgAAAAHAAAADQAAAAAAAAAAAACAAQEAAAcAvH8P AAwEHwgAAA8AAvAXCAAAgAAI8AgAAAAKAAAAIywAAA8AA/B3BwAADwAE8CgAAAABAAnwEAAA AAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAsAAAFAAAADwAE8HgAAAASAArwCAAAAAIsAAAg AgAAYwAL8CQAAAB/AAAABACAAHAoBn6/AQAAAQD/AQAAAQABAwIEAACIAwAAAAAAABDwCAAA AIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAAZ+DwAN8AwAAAAAAJ4PBAAAAAAAAAAP AATwtQAAABIACvAIAAAAAywAAAAKAACjAAvwPAAAAH8AAAAEAIAApCkGfoUAAgAAAIcAAQAA AIEBwMDAAL8BEAAQAMABAQAACMsBnDEAAP8BCAAIAAECAgAACAAAEPAIAAAAMAYwBlAQYAkP AA3wSQAAAAAAnw8EAAAABAAAAAAAqA8VAAAADQ0NTE9DU0VSOiBTSVAgbWV0aG9kAAChDxgA AAAWAAAAAAAACAAAAQAWAAAAAQACAAEAFAAPAATw+AAAABIACvAIAAAAGSwAAAAKAACjAAvw PAAAAH8AAAAEAIAA9LqMfoUAAgAAAIcAAQAAAIEB+Pj4AL8BEAAQAMABAQAACMsBnDEAAP8B CAAIAAECAgAACAAAEPAIAAAAkAZgBiAQQAgPAA3wjAAAAAAAnw8EAAAABAAAAAAAoA9AAAAA UwBJAFAAGSBzACAAYgBvAGQAeQAgAHcAaQB0AGgAIAB3AGUAbABsAC0AZABlAGYAaQBuAGUA ZAAgAFgATQBMAAAAoQ8WAAAAIQAAAAAAAAgAAAEAIQAAAAAAAgAUAAAAqg8SAAAABQAAAAEA AAADABwAAAAAAAAADwAE8KUAAAASAArwCAAAAB4sAAAACgAAowAL8DwAAAB/AAAABACAALy7 jH6FAAIAAACHAAEAAACBAcDAwAC/ARAAEADAAQEAAAjLAZwxAAD/AQgACAABAgIAAAgAABDw CAAAAJAJMAZQEGAMDwAN8DkAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAEhJUA0NAAChDxgAAAAG AAAAAAAACAAAAQAGAAAAAQACAAEAFAAPAATwpwAAABIACvAIAAAAHywAAAAKAACjAAvwPAAA AH8AAAAEAIAAJDEGfoUAAgAAAIcAAQAAAIEBwMDAAL8BEAAQAMABAQAACMsBnDEAAP8BCAAI AAECAgAACAAAEPAIAAAAkAwwBlAQ4A0PAA3wOwAAAAAAnw8EAAAABAAAAAAAqA8HAAAASVB2 NC92NgAAoQ8YAAAACAAAAAAAAAgAAAEACAAAAAEAAgABABQADwAE8PwAAAASAArwCAAAACAs AAAACgAAowAL8DwAAAB/AAAABACAAMQ0Bn6FAAIAAACHAAEAAACBAfj4+AC/ARAAEADAAQEA AAjLAZwxAAD/AQgACAABAgIAAAgAABDwCAAAAOAKYAYgEAAMDwAN8JAAAAAAAJ8PBAAAAAQA AAAAAKAPRAAAAEgASQBQABkgcwAgAE4AQQBUACAAdAByAGEAdgBlAHIAcwBhAGwAIAAoAGIA YQBzAGUAZAAgAG8AbgAgAEkAQwBFACkAAAChDxYAAAAjAAAAAAAACAAAAQAjAAAAAAACABQA AACqDxIAAAAFAAAAAQAAAAMAHgAAAAAAAAAPAATwxQAAANIDCvAIAAAAISwAAAAKAACjAAvw PAAAAIAAwDkGfr8AAAACAEcBhAMAAEgBA4QAAIEB///MAL8BEAAQAMABAQAACP8BCAAIAAEC AgAACH8DAAAMABMAIvEGAAAAvwEAAGAAAAAQ8AgAAADwA8APABXQBQ8ADfBLAAAAAACfDwQA AAAEAAAAAACoDxkAAABHZXQvcHV0ICYNREhUIG1haW50ZW5hbmNlAAChDxYAAAAaAAAAAAAA CAAAAQAaAAAAAAACABQADwAE8L0AAADSAwrwCAAAACIsAAAACgAAowAL8DwAAACAANQ9Bn6/ AAAAAgBHATxzAABIAeB5AACBAf//zAC/ARAAEADAAQEAAAj/AQgACAABAgIAAAh/AwAADAAT ACLxBgAAAL8BAABgAAAAEPAIAAAAkAbgAUAFQAgPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8R AAAAS2V5LWJhc2VkIHJvdXRpbmcAAKEPFgAAABIAAAAAAAAIAAABABIAAAAAAAIAFAAPAATw EAEAANIDCvAIAAAAIywAAAAKAACjAAvwPAAAAIAAgEAGfr8AAAACAEcB+Oz//0gBdCcAAIEB ///MAL8BEAAQAMABAQAACP8BCAAIAAECAgAACH8DAAAMABMAIvEGAAAAvwEAAGAAAAAQ8AgA AADQCOAQMBUwDA8ADfCWAAAAAACfDwQAAAAEAAAAAACgD2QAAABTAGUAdAB0AGkAbgBnACAA dQBwACAAYwBvAG4AbgBlAGMAdABpAG8AbgBzACwADQBtAG8AYgBpAGwAaQB0AHkALAAgAE4A QQBUACAAdAByAGEAdgBlAHIAcwBhAGwALAAgACYgAAChDxYAAAAzAAAAAAAACAAAAQAzAAAA AAACABQADwAE8EgAAAASAArwCAAAAAEsAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6f iwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQA/AAXwMAAAAAAAF/AIAAAAAgAAACEs AAAAABfwCAAAAAMAAAAiLAAAAAAX8AgAAAAEAAAAIywAABAA8AcgAAAA////AAAAAACAgIAA AAAAAADMmQAzM8wAzMz/ALKysgAPAIgTgQAAAA8AihN5AAAAAAC6DxAAAABfAF8AXwBQAFAA VAAxADAAAACLE1kAAAAAAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAA AAAAAAAAAAAAubx//////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gNz HAAAAgDvAxgAAAAHAAAADQAAAAAAAAAAAACABAEAAAcAvH8PAAwEIxwAAA8AAvAbHAAA4AAI 8AgAAAA2AAAATEgAAA8AA/ArGwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC AArwCAAAAABIAAAFAAAADwAE8HgAAAASAArwCAAAAAJIAAAgAgAAYwAL8CQAAAB/AAAABACA AMROBn6/AQAAAQD/AQAAAQABAwIEAACIAwAAAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAA AMMLCAAAAAAAAAANAAZ+DwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwTAAAAEIBCvAIAAAABEgA AAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAI AAAAoAXgBOAEwA8PAATwTAAAAEIBCvAIAAAAFUgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAAB AL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAoAUwCTAJwA8PAATwTAAAAEIBCvAI AAAAFkgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAA CAAAEPAIAAAAoAWADYANwA8PAATwTAAAAEIBCvAIAAAAF0gAAAAKAABjAAvwJAAAAEQBBAAA AH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAoAXQEdARwA8PAATwpwAA ABIACvAIAAAAGEgAAAAKAACTAAvwNgAAAH8AAAAEAIAA3FAGfoUAAgAAAIcAAQAAAIEBwMDA AL8BEAAQAMABAQAACP8BCAAIAAECAgAACBMAIvEGAAAAvwEAAGAAAAAQ8AgAAACwBMADAAag BQ8ADfAzAAAAAACfDwQAAAAEAAAAAACoDwEAAABBAAChDxYAAAACAAAAAAAACAAAAQACAAAA AAACABQADwAE8KcAAAASAArwCAAAABlIAAAACgAAkwAL8DYAAAB/AAAABACAADhUBn6FAAIA AACHAAEAAACBAcDAwAC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgTACLxBgAAAL8BAABgAAAA EPAIAAAAsAQQCFAKoAUPAA3wMwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAQgAAoQ8WAAAAAgAA AAAAAAgAAAEAAgAAAAAAAgAUAA8ABPCnAAAAEgAK8AgAAAAaSAAAAAoAAJMAC/A2AAAAfwAA AAQAgACUVwZ+hQACAAAAhwABAAAAgQHAwMAAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIEwAi 8QYAAAC/AQAAYAAAABDwCAAAALAEYAygDqAFDwAN8DMAAAAAAJ8PBAAAAAQAAAAAAKgPAQAA AEMAAKEPFgAAAAIAAAAAAAAIAAABAAIAAAAAAAIAFAAPAATwpwAAABIACvAIAAAAG0gAAAAK AACTAAvwNgAAAH8AAAAEAIAA8FoGfoUAAgAAAIcAAQAAAIEBwMDAAL8BEAAQAMABAQAACP8B CAAIAAECAgAACBMAIvEGAAAAvwEAAGAAAAAQ8AgAAACwBLAQ8BKgBQ8ADfAzAAAAAACfDwQA AAAEAAAAAACoDwEAAABEAAChDxYAAAACAAAAAAAACAAAAQACAAAAAAACABQADwAD8EICAAAP AATwOAAAAAEACfAQAAAAEAUAAF8GAAAGCQAAgAcAAAIACvAIAAAAIkgAAAECAAAAABDwCAAA AF8GEAUGCYAHDwAE8GgAAAAyAArwCAAAABxIAAACCgAAcwAL8CoAAACFAAIAAACHAAEAAACB Aerq6gC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgTACLxBgAAAL8BAABgAAAAD/AQAAAAEAUA AGAGAABwBQAAgAcAAA8ABPBUAAAAQgEK8AgAAAAeSAAAAgoAAGMAC/AkAAAARAEEAAAAfwEA AAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAP8BAAAABABQAAgAcAANAIAACABwAADwAE 8FQAAABCAQrwCAAAAB9IAAACCgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ ARgAGAABAgIAAAgAAA/wEAAAAEAFAABgBgAA0AgAAGAGAAAPAATw0gAAADIBCvAIAAAAIUgA AEIKAADzAAvwogAAAAQAaI6n/4UAAgAAAIcAAQAAAEIBwKgAAEMBrVYAAEXBJAAAAEcBEnCy AEkBYFQAAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACAkACQDw /wAAAADAqMCoCACtVsCoYFQAAAAAwKjAqAgArVbAqGBUYFRgVAMABAAIAAgAAACtVgAAwKgA AGBUAABgVAAAYFQAAAAAD/AQAAAA0AgAAF8GAAAGCQAAfwcAAA8AA/BQAgAADwAE8EYAAAAB AAnwEAAAABAFAABfBgAABgkAAIAHAAACAArwCAAAACNIAAABAgAAEwAL8AYAAACIAwAAAAAA ABDwCAAAAPAGYAlWDREIDwAE8GgAAAAyAArwCAAAACRIAAACCgAAcwAL8CoAAACFAAIAAACH AAEAAACBAerq6gC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgTACLxBgAAAL8BAABgAAAAD/AQ AAAAEAUAAGAGAABwBQAAgAcAAA8ABPBUAAAAQgEK8AgAAAAlSAAAAgoAAGMAC/AkAAAARAEE AAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAP8BAAAABABQAAgAcAANAIAACA BwAADwAE8FQAAABCAQrwCAAAACZIAAACCgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADA AQEAAAj/ARgAGAABAgIAAAgAAA/wEAAAAEAFAABgBgAA0AgAAGAGAAAPAATw0gAAADIBCvAI AAAAJ0gAAEIKAADzAAvwogAAAAQAaI6n/4UAAgAAAIcAAQAAAEIBwKgAAEMBrVYAAEXBJAAA AEcBEnCyAEkBYFQAAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAA CAkACQDw/wAAAADAqMCoCACtVsCoYFQAAAAAwKjAqAgArVbAqGBUYFRgVAMABAAIAAgAAACt VgAAwKgAAGBUAABgVAAAYFQAAAAAD/AQAAAA0AgAAF8GAAAGCQAAfwcAAA8AA/BQAgAADwAE 8EYAAAABAAnwEAAAABAFAABfBgAABgkAAIAHAAACAArwCAAAAChIAAABAgAAEwAL8AYAAACI AwAAAAAAABDwCAAAAG8IYAlWDZAJDwAE8GgAAAAyAArwCAAAAClIAAACCgAAcwAL8CoAAACF AAIAAACHAAEAAACBAerq6gC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgTACLxBgAAAL8BAABg AAAAD/AQAAAAEAUAAGAGAABwBQAAgAcAAA8ABPBUAAAAQgEK8AgAAAAqSAAAAgoAAGMAC/Ak AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAP8BAAAABABQAAgAcA ANAIAACABwAADwAE8FQAAABCAQrwCAAAACtIAAACCgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/ AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAAA/wEAAAAEAFAABgBgAA0AgAAGAGAAAPAATw0gAA ADIBCvAIAAAALEgAAEIKAADzAAvwogAAAAQAaI6n/4UAAgAAAIcAAQAAAEIBwKgAAEMBrVYA AEXBJAAAAEcBEnCyAEkBYFQAAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BCAAI AAECAgAACAkACQDw/wAAAADAqMCoCACtVsCoYFQAAAAAwKjAqAgArVbAqGBUYFRgVAMABAAI AAgAAACtVgAAwKgAAGBUAABgVAAAYFQAAAAAD/AQAAAA0AgAAF8GAAAGCQAAfwcAAA8AA/BQ AgAADwAE8EYAAAABAAnwEAAAABAFAABfBgAABgkAAIAHAAACAArwCAAAAC1IAAABAgAAEwAL 8AYAAACIAwAAAAAAABDwCAAAAP8ICgUACSAKDwAE8GgAAAAyAArwCAAAAC5IAAACCgAAcwAL 8CoAAACFAAIAAACHAAEAAACBAerq6gC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgTACLxBgAA AL8BAABgAAAAD/AQAAAAEAUAAGAGAABwBQAAgAcAAA8ABPBUAAAAQgEK8AgAAAAvSAAAAgoA AGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAP8BAAAABA BQAAgAcAANAIAACABwAADwAE8FQAAABCAQrwCAAAADBIAAACCgAAYwAL8CQAAABEAQQAAAB/ AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAAA/wEAAAAEAFAABgBgAA0AgAAGAGAAAP AATw0gAAADIBCvAIAAAAMUgAAEIKAADzAAvwogAAAAQAaI6n/4UAAgAAAIcAAQAAAEIBwKgA AEMBrVYAAEXBJAAAAEcBEnCyAEkBYFQAAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAA CP8BCAAIAAECAgAACAkACQDw/wAAAADAqMCoCACtVsCoYFQAAAAAwKjAqAgArVbAqGBUYFRg VAMABAAIAAgAAACtVgAAwKgAAGBUAABgVAAAYFQAAAAAD/AQAAAA0AgAAF8GAAAGCQAAfwcA AA8AA/BQAgAADwAE8EYAAAABAAnwEAAAABAFAABfBgAABgkAAIAHAAACAArwCAAAADJIAAAB AgAAEwAL8AYAAACIAwAAAAAAABDwCAAAAL8MEAWgETAPDwAE8GgAAAAyAArwCAAAADNIAAAC CgAAcwAL8CoAAACFAAIAAACHAAEAAACBAerq6gC/ARAAEADAAQEAAAj/AQgACAABAgIAAAgT ACLxBgAAAL8BAABgAAAAD/AQAAAAEAUAAGAGAABwBQAAgAcAAA8ABPBUAAAAQgEK8AgAAAA0 SAAAAgoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAP 8BAAAABABQAAgAcAANAIAACABwAADwAE8FQAAABCAQrwCAAAADVIAAACCgAAYwAL8CQAAABE AQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAAA/wEAAAAEAFAABgBgAA0AgA AGAGAAAPAATw0gAAADIBCvAIAAAANkgAAEIKAADzAAvwogAAAAQAaI6n/4UAAgAAAIcAAQAA AEIBwKgAAEMBrVYAAEXBJAAAAEcBEnCyAEkBYFQAAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQ AMABAQAACP8BCAAIAAECAgAACAkACQDw/wAAAADAqMCoCACtVsCoYFQAAAAAwKjAqAgArVbA qGBUYFRgVAMABAAIAAgAAACtVgAAwKgAAGBUAABgVAAAYFQAAAAAD/AQAAAA0AgAAF8GAAAG CQAAfwcAAA8ABPC6AAAAEgQK8AgAAAA3SAAAQAoAAMMAC/BIAAAABAAAAEz/fwAAAAQAgAC4 ZQZ+hQACAAAAhwABAAAAiQACAAAARwGlPAAAgQHAwMAAvwEQABAAwAEBAAAI/wEIAAgAAQIC AAAIEwAi8QYAAAC/AQAAYAAAABDwCAAAAIAHsA0wD9AIDwAN8DQAAAAAAJ8PBAAAAAQAAAAA AKgPAgAAAFJSAAChDxYAAAADAAAAAAAACAAAAQADAAAAAAACABQADwAE8GQAAABCAQrwCAAA ADhIAAAACgAAowAL8DwAAABEAQQAAAB/AQAAAQC/AQAAEADAATOZZgDLAWpKAADRAQEAAADU AQIAAADVAQIAAAD/ARgAGAABAgIAAAgAABDwCAAAALAK4ATQEbAKDwAE8GQAAABCAQrwCAAA ADlIAAAACgAAowAL8DwAAABEAQQAAAB/AQAAAQC/AQAAEADAATOZZgDLAWpKAADQAQEAAADS AQIAAADTAQIAAAD/ARgAGAABAgIAAAgAABDwCAAAABAL4ATQERALDwAE8GQAAABCAQrwCAAA ADpIAAAACgAAowAL8DwAAABEAQQAAAB/AQAAAQC/AQAAEADAATOZZgDLAWpKAADRAQEAAADU AQIAAADVAQIAAAD/ARgAGAABAgIAAAgAABDwCAAAAHAL4ATQEXALDwAE8GQAAABCAQrwCAAA ADtIAAAACgAAowAL8DwAAABEAQQAAAB/AQAAAQC/AQAAEADAATOZZgDLAWpKAADQAQEAAADS AQIAAADTAQIAAAD/ARgAGAABAgIAAAgAABDwCAAAANAL4ATQEdALDwAE8GQAAABCAQrwCAAA ADxIAAAACgAAowAL8DwAAABEAQQAAAB/AQAAAQC/AQAAEADAAf9mAADLAWpKAADRAQEAAADU AQIAAADVAQIAAAD/ARgAGAABAgIAAAgAABDwCAAAAPAG4AQwCfAGDwAE8GQAAABCAQrwCAAA AD1IAAAACgAAowAL8DwAAABEAQQAAAB/AQAAAQC/AQAAEADAAf9mAADLAWpKAADRAQEAAADU AQIAAADVAQIAAAD/ARgAGAABAgIAAAgAABDwCAAAAIAHMAmADYAHDwAE8HAAAABCAQrwCAAA AD5IAAAACgAAwwAL8EgAAABEAQQAAAB/AQAAAQC/AQAAEADAAf9mAADLAWpKAADQAQEAAADS AQIAAADTAQIAAADUAQIAAADVAQIAAAD/ARgAGAABAgIAAAgAABDwCAAAAAAJMAmADQAJDwAE 8HAAAABCAQrwCAAAAD9IAAAACgAAwwAL8EgAAABEAQQAAAB/AQAAAQC/AQAAEADAAf9mAADL AWpKAADQAQEAAADSAQIAAADTAQIAAADUAQIAAADVAQIAAAD/ARgAGAABAgIAAAgAABDwCAAA AJAJ4AQwCZAJDwAE8GQAAABCAQrwCAAAAEBIAAAACgAAowAL8DwAAABEAQQAAAB/AQAAAQC/ AQAAEADAATNm/wDLAWpKAADRAQEAAADUAQIAAADVAQIAAAD/ARgAGAABAgIAAAgAABDwCAAA AFAN4ATQEVANDwAE8F4AAABCAQrwCAAAAENIAAAACgAAkwAL8DYAAABEAQQAAAB/AQAAAQC/ AQAAEADAAV9fXwDLAT7fAADQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAHAO4ATQ EXAODwAE8HAAAABCAQrwCAAAAERIAAAACgAAwwAL8EgAAABEAQQAAAB/AQAAAQC/AQAAEADA ATNm/wDLAWpKAADQAQEAAADSAQIAAADTAQIAAADUAQIAAADVAQIAAAD/ARgAGAABAgIAAAgA ABDwCAAAALAN4ATQEbANDwAE8KgAAACiDArwCAAAAEVIAAAACgAAowAL8DwAAACAABRtBn6F AAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgA ABDwCAAAAGAG2gG1BFoHDwAN8DwAAAAAAJ8PBAAAAAQAAAAAAKgPBgAAAExPQ1NFUgAAoQ8a AAAABwAAAAAAAAAAAAcAAAAAAEYAAAAUAP9mAP4PAATwpQAAAKIMCvAIAAAARkgAAAAKAACj AAvwPAAAAIAAcHAGfoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAA CP8BAAAIAAECAgAACAAAEPAIAAAAqgrkAVoDpAsPAA3wOQAAAAAAnw8EAAAABAAAAAAAqA8D AAAASElQAAChDxoAAAAEAAAAAAAAAAAABAAAAAAARgAAABQAM5lm/g8ABPClAAAAogwK8AgA AABHSAAAAAoAAKMAC/A8AAAAgADMcwZ+hQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAI vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAADwDNoBNQPqDQ8ADfA5AAAAAACfDwQA AAAEAAAAAACoDwMAAABTSVAAAKEPGgAAAAQAAAAAAAAAAAAEAAAAAABGAAAAFAAzZv/+DwAE 8KcAAACiDArwCAAAAEhIAAAACgAAowAL8DwAAACAACh3Bn6FAAIAAACHAAYAAAC/AAIAAgCB AQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAOIN4AHsA9wODwAN 8DsAAAAAAJ8PBAAAAAQAAAAAAKgPBQAAAE1lZGlhAAChDxoAAAAGAAAAAAAAAAAABgAAAAAA RgAAABQAX19f/g8ABPDAAAAA0gMK8AgAAABKSAAAAAoAAKMAC/A8AAAAgAA4egZ+vwAAAAIA RwFnjwAASAE+5f//gQH//8wAvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIfwMAAAwAEwAi8QYA AAC/AQAAYAAAABDwCAAAABAIkAAgBMAJDwAN8EYAAAAAAJ8PBAAAAAQAAAAAAKgPFAAAAEV4 aXN0aW5nIGNvbm5lY3Rpb25zAAChDxYAAAAVAAAAAAAACAAAAQAVAAAAAAACABQADwAE8OIA AADSAwrwCAAAAEtIAAAACgAAowAL8DwAAACAAAh/Bn6/AAAAAgBHARGj//9IAYluAACBAf// zAC/ARAAEADAAQEAAAj/AQgACAABAgIAAAh/AwAADAATACLxBgAAAL8BAABgAAAAEPAIAAAA 8AaAENAUIAoPAA3waAAAAAAAnw8EAAAABAAAAAAAqA82AAAAV2l0aCBJQ0UtbGlrZSBOQVQg dHJhdmVyc2FsIHN1cHBvcnQgKG1pZ2h0IGJlIHJlbGF5ZWQpAAChDxYAAAA3AAAAAAAACAAA AQA3AAAAAAACABQADwAE8M4AAADSAwrwCAAAAExIAAAACgAAowAL8DwAAACAAJCCBn6/AAAA AgBHATbe//9IATAnAACBAf//zAC/ARAAEADAAQEAAAj/AQgACAABAgIAAAh/AwAADAATACLx BgAAAL8BAABgAAAAEPAIAAAAQAtgEsAVcA4PAA3wVAAAAAAAnw8EAAAABAAAAAAAqA8iAAAA TmV3DWNvbm5lY3Rpb24gKG1pZ2h0IGJlIFVEUCBlbmMuKQAAoQ8WAAAAIwAAAAAAAAgAAAEA IwAAAAAAAgAUAA8ABPBIAAAAEgAK8AgAAAABSAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAI kwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAjwAF8IAAAAAAABTwCAAAAAQA AAAhSAAAAAAU8AgAAAAFAAAAJ0gAAAAAFPAIAAAABgAAACxIAAAAABTwCAAAAAcAAAAxSAAA AAAU8AgAAAAIAAAANkgAAAAAF/AIAAAACQAAAEpIAAAAABfwCAAAAAoAAABLSAAAAAAX8AgA AAALAAAATEgAABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4D 8AEAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAIBAAAHALx/DwAMBKABAAAPAALwmAEAAKAA CPAIAAAAAwAAAAM0AAAPAAPwMAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAANAAABQAAAA8ABPB4AAAAEgAK8AgAAAACNAAAIAIAAGMAC/AkAAAAfwAAAAQA gACkjwZ+vwEAAAEA/wEAAAEAAQMCBAAAiAMAAAAAAAAQ8AgAAACAAbAB0BRQBA8AEfAQAAAA AADDCwgAAAAAAAAADQAGfg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HgAAAASAArwCAAAAAM0 AAAgAgAAYwAL8CQAAAB/AAAABACAALiFBn6/AQAAAQD/AQAAAQABAwMEAACIAwAAAAAAABDw CAAAAOAEsAHQFAAPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAAZ+DwAN8AwAAAAAAJ4PBAAAAAEA AAAPAATwSAAAABIACvAIAAAAATQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB 3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADM mQAzM8wAzMz/ALKysgAPAO4DagEAAAIA7wMYAAAABwAAAA0AAAAAAAAAAAAAgAAAAAAHALx/ DwAMBBoBAAAPAALwEgEAAGAACPAIAAAAAgAAAAMQAAAPAAPwqgAAAA8ABPAoAAAAAQAJ8BAA AAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAEAAABQAAAA8ABPByAAAAEgAK8AgAAAACEAAA IAIAAFMAC/AeAAAAfwAAAAQAgADgpAZ+vwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACDBrAB 0BRTCQ8AEfAQAAAAAADDCwgAAAAAAAAADQAGfg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8EgA AAASAArwCAAAAAEQAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIA EgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM /wCysrIADwDwA0ACAAABAPEDCAAAAAQBAAAHAAowDwAMBAACAAAPAALw+AEAAJAACPAIAAAA AwAAAAMwAAAPAAPwkAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA AAAAMAAABQAAAA8ABPBeAAAAEgAK8AgAAAACMAAAIAIAAFMAC/AeAAAAfwAEAAQAvwEBAAEA /wEBAAEAAQMEGAAAiAMAAAAAAAAQ8AgAAACwAdACEA4gCg8AEfAQAAAAAADDCwgAAAAAAAAA CwAGfg8ABPDyAAAAEgAK8AgAAAADMAAAIAIAAGMAC/AkAAAAfwAAAAQAgABASQZ+vwEBAAEA /wEBAAEAAQMFGAAAiAMAAAAAAAAQ8AgAAACwCkACoA7QFA8AEfBUAAAAAADDCwgAAAABAAAA DAAGfg8AiBM8AAAADwCKEzQAAAAAALoPDgAAAF8AXwBfAFAAUABUADkAAACLExYAAAAAAKwP DgAAAAAAAAIAAAAAAAAAAAAADwAN8EIAAAAAAJ8PBAAAAAIAAAAAAKEPGAAAAAEAAAAAAJIA AAAAAC0AAAABAAAAAAAAAAAAqg8OAAAAAQAAAAcAAAAAAAAEAAAPAATwSAAAABIACvAIAAAA ATAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB3r1oAJQBjp+LAL8BEgASAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAPAD EAIAAAEA8QMIAAAABQEAAAcACjAPAAwEkAEAAA8AAvCIAQAAsAAI8AgAAAADAAAAAzgAAA8A A/AgAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAAA4AAAFAAAA DwAE8FgAAAASAArwCAAAAAI4AAAgAgAAQwAL8BgAAAB/AAQABAC/AQEAAQD/AQEAAQABAwQY AAAAABDwCAAAALAB0AIQDiAKDwAR8BAAAAAAAMMLCAAAAAAAAAALAAZ+DwAE8IgAAAASAArw CAAAAAM4AAAgAgAAUwAL8B4AAAB/AAAABACAAMSdBn6/AQEAAQD/AQEAAQABAwUYAAAAABDw CAAAALAKQAKgDtAUDwAR8BAAAAAAAMMLCAAAAAEAAAAMAAZ+DwAN8CIAAAAAAJ8PBAAAAAIA AAAAAKoPDgAAAAEAAAAHAAAAAAAABAAADwAE8EgAAAASAArwCAAAAAE4AAAADAAAgwAL8DAA AACBAQAAAAiDAQUAAAiTAd69aACUAY6fiwC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAH IAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwCIEzgAAAAPAIoTMAAAAAAA ug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAACr/cYBQOUFgQ8A8AMcAgAA AQDxAwgAAAAGAQAABwAKMA8ADAScAQAADwAC8JQBAADwAAjwCAAAAAMAAAADTAAADwAD8CwB AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAEwAAAUAAAAPAATw XgAAABIACvAIAAAAAkwAACACAABTAAvwHgAAAH8ABAAEAL8BAQABAP8BAQABAAEDBBgAAIgD AAAAAAAAEPAIAAAAsAHQAhAOIAoPABHwEAAAAAAAwwsIAAAAAAAAAAsABn4PAATwjgAAABIA CvAIAAAAA0wAACACAABjAAvwJAAAAH8AAAAEAIAAZIsGfr8BAQABAP8BAQABAAEDBRgAAIgD AAAAAAAAEPAIAAAAsApAAqAO0BQPABHwEAAAAAAAwwsIAAAAAQAAAAwABn4PAA3wIgAAAAAA nw8EAAAAAgAAAAAAqg8OAAAAAQAAAAcAAAAAAAAEAAAPAATwSAAAABIACvAIAAAAAUwAAAAM AACDAAvwMAAAAIEBAAAACIMBBQAACJMB3r1oAJQBjp+LAL8BEgASAP8BAAAIAAQDCQAAAD8D AQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAIgTOAAAAA8A ihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAKv9xgFA5QWB AAByFzwAAAABADAAAAAAAL8KAAAVGgAABQAQAHRDAAAHABAAExQAAAwAYAABHAAA5kQAAHxB AAAuRwAAASUAAEZJAAAAAPUPHAAAAAABAAA/CgADAAAAAGpLAAABAAAAEgAAAA8AAQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAA AAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAwBEAAA0AAAABAAAAcAAAAAIA AAB4AAAAAwAAAOgAAAAEAAAADAEAAAcAAAAkAQAACAAAAEwBAAAJAAAAZAEAABIAAABwAQAA CgAAAJABAAAMAAAAnAEAAA0AAACoAQAADwAAALQBAAARAAAAvAEAAAIAAADkBAAAHgAAAGUA AABMT0NTRVIgKyBISVAgICAgZHJhZnQtaGF1dGFrb3JwaS1wMnBzaXAtcGVlci1wcm90b2Nv bC0wMC50eHQgZHJhZnQtaGF1dGFrb3JwaS1wMnBzaXAtd2l0aC1oaXAtMDAudHh0AAAwAB4A AAAZAAAAVXRpbGl6aW5nIEhJUCBmb3IgUDJQU0lQAHRhax4AAAAQAAAASmFuaSBIYXV0YWtv cnBpAB4AAAAdAAAAVXRpbGl6aW5nX0hJUF9mb3JfUDJQU0lQX3YwNABycGkeAAAAEAAAAEph bmkgSGF1dGFrb3JwaQAeAAAAAgAAADEAbmkeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50 AFNJUEAAAAAQ2L5OAAAAAEAAAABwxsd0kc3HAUAAAACwE4fDkc3HAQMAAAB2AAAARwAAAPwP AAD/////AwAAAAgAiRBnDAAAAAAAAAAA9gcAAAUAMQAAAAAAAAAEAAAALQEAAAgAAAD6AgUA AAAAAP///wAEAAAALQEBAAwAAABACSEA8AAAAAAAAAAAAAAAAAAAAAgAAAD6AgAAAAAAAAAA AAAEAAAALQECAAQAAAAtAQAAHAAAAPsCAAAAAAAAAACQAQAAAAAAQAASVGltZXMgTmV3IFJv bWFuAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQKAgIAC EAAAADIKAAAAAAYAAABMT0NTRVIAAAAAAAAAAAAAAAAEAAAALgEBABwAAAD7AgAAAAAAAAAA kAEAAAAAAAAAIlN5c3RlbQC35LG8f3fKqH/g9Kt/dP2rf1gAAAAcsrwABAAAAC0BBAAEAAAA 8AEDABwAAAD7AgAAAAAAAAAAkAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgAAAAAAAAAAAAAA AAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAg8AAAAyCgAAAAAFAAAA KyBISVAAAAAAAAAAAAAAAAQAAAAuAQEABAAAAC0BBAAEAAAA8AEDABwAAAD7AgAAAAAAAAAA kAEAAAAAAEAAMUNvdXJpZXIgTmV3AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAA LgEYAAQAAAACAQEABQAAAAkCAAAAAg8AAAAyCgAAAAAFAAAAZHJhZnQAAAAAAAAAAAAAAAQA AAAuAQEABAAAAC0BBAAEAAAA8AEDABwAAAD7AgAAAAAAAAAAkAEAAAAAAEAAMUNvdXJpZXIg TmV3AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkC AAAAAgkAAAAyCgAAAAABAAAALe0AAAQAAAAuAQEABAAAAC0BBAAEAAAA8AEDABwAAAD7AgAA AAAAAAAAkAEAAAAAAEAAMUNvdXJpZXIgTmV3AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0B AwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhYAAAAyCgAAAAAKAAAAaGF1dGFrb3JwaQAA AAAAAAAAAAAAAAAAAAAAAAAABAAAAC4BAQAEAAAALQEEAAQAAADwAQMAHAAAAPsCAAAAAAAA AACQAQAAAAAAQAAxQ291cmllciBOZXcAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQA AAAuARgABAAAAAIBAQAFAAAACQIAAAACCQAAADIKAAAAAAEAAAAt/wAABAAAAC4BAQAEAAAA LQEEAAQAAADwAQMAHAAAAPsCAAAAAAAAAACQAQAAAAAAQAAxQ291cmllciBOZXcAAAAAAAAA AAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACEAAAADIK AAAAAAYAAABwMnBzaXAAAAAAAAAAAAAAAAAEAAAALgEBAAQAAAAtAQQABAAAAPABAwAcAAAA +wIAAAAAAAAAAJABAAAAAABAADFDb3VyaWVyIE5ldwAAAAAAAAAAAAAAAAAAAAAAAAAAAAQA AAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgoAAAAAAQAAAC3/AAAEAAAA LgEBAAQAAAAtAQQABAAAAPABAwAcAAAA+wIAAAAAAAAAAJABAAAAAABAADFDb3VyaWVyIE5l dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAA AAINAAAAMgoAAAAABAAAAHBlZXIAAAAAAAAAAAQAAAAuAQEABAAAAC0BBAAEAAAA8AEDABwA AAD7AgAAAAAAAAAAkAEAAAAAAEAAMUNvdXJpZXIgTmV3AAAAAAAAAAAAAAAAAAAAAAAAAAAA BAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAgkAAAAyCgAAAAABAAAALf8AAAQA AAAuAQEABAAAAC0BBAAEAAAA8AEDABwAAAD7AgAAAAAAAAAAkAEAAAAAAEAAMUNvdXJpZXIg TmV3AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkC AAAAAhMAAAAyCgAAAAAIAAAAcHJvdG9jb2wAAAAAAAAAAAAAAAAAAAAABAAAAC4BAQAEAAAA LQEEAAQAAADwAQMAHAAAAPsCAAAAAAAAAACQAQAAAAAAQAAxQ291cmllciBOZXcAAAAAAAAA AAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACCQAAADIK AAAAAAEAAAAt5wAABAAAAC4BAQAEAAAALQEEAAQAAADwAQMAHAAAAPsCAAAAAAAAAACQAQAA AAAAQAAxQ291cmllciBOZXcAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgA BAAAAAIBAQAFAAAACQIAAAACEAAAADIKAAAAAAYAAAAwMC50eHQAAAAAAAAAAAAAAAAEAAAA LgEBAAQAAAAtAQQABAAAAPABAwAcAAAA+wIAAAAAAAAAAJABAAAAAABAADFDb3VyaWVyIE5l dwAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAA AAIPAAAAMgoAAAAABQAAAGRyYWZ0AAAAAAAAAAAAAAAEAAAALgEBAAQAAAAtAQQABAAAAPAB AwAcAAAA+wIAAAAAAAAAAJABAAAAAABAADFDb3VyaWVyIE5ldwAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIJAAAAMgoAAAAAAQAAAC3n AAAEAAAALgEBAAQAAAAtAQQABAAAAPABAwAcAAAA+wIAAAAAAAAAAJABAAAAAABAADFDb3Vy aWVyIE5ldwAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUA AAAJAgAAAAIWAAAAMgoAAAAACgAAAGhhdXRha29ycGkAAAAAAAAAAAAAAAAAAAAAAAAAAAQA AAAuAQEABAAAAC0BBAAEAAAA8AEDABwAAAD7AgAAAAAAAAAAkAEAAAAAAEAAMUNvdXJpZXIg TmV3AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkC AAAAAgkAAAAyCgAAAAABAAAALf8AAAQAAAAuAQEABAAAAC0BBAAEAAAA8AEDABwAAAD7AgAA AAAAAAAAkAEAAAAAAEAAMUNvdXJpZXIgTmV3AAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0B AwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhAAAAAyCgAAAAAGAAAAcDJwc2lwAAAAAAAA AAAAAAAABAAAAC4BAQAEAAAALQEEAAQAAADwAQMAHAAAAPsCAAAAAAAAAACQAQAAAAAAQAAx Q291cmllciBOZXcAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIB AQAFAAAACQIAAAACCQAAADIKAAAAAAEAAAAt/wAABAAAAC4BAQAEAAAALQEEAAQAAADwAQMA HAAAAPsCAAAAAAAAAACQAQAAAAAAQAAxQ291cmllciBOZXcAAAAAAAAAAAAAAAAAAAAAAAAA AAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACDQAAADIKAAAAAAQAAAB3aXRo AAAAAAAAAAAEAAAALgEBAAQAAAAtAQQABAAAAPABAwAcAAAA+wIAAAAAAAAAAJABAAAAAABA ADFDb3VyaWVyIE5ldwAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAA AgEBAAUAAAAJAgAAAAIJAAAAMgoAAAAAAQAAAC3/AAAEAAAALgEBAAQAAAAtAQQABAAAAPAB AwAcAAAA+wIAAAAAAAAAAJABAAAAAABAADFDb3VyaWVyIE5ldwAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIMAAAAMgoAAAAAAwAAAGhp cH8AAAAAAAAEAAAALgEBAAQAAAAtAQQABAAAAPABAwAcAAAA+wIAAAAAAAAAAJABAAAAAABA ADFDb3VyaWVyIE5ldwAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAA AgEBAAUAAAAJAgAAAAIJAAAAMgoAAAAAAQAAAC3/AAAEAAAALgEBAAQAAAAtAQQABAAAAPAB AwAcAAAA+wIAAAAAAAAAAJABAAAAAABAADFDb3VyaWVyIE5ldwAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIQAAAAMgoAAAAABgAAADAw LnR4dAAAAAAAAAAAAAAAAAQAAAAuAQEABAAAAC0BBAAEAAAA8AEDABwAAAD7AgAAAAAAAAAA kAEAAAAAAEAAElRpbWVzIE5ldyBSb21hbgAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAA LgEYAAQAAAACAQEABQAAAAkCAAAAAjEAAAAyCgAAAAAcAAAASmFuaS5IYXV0YWtvcnBpQGVy aWNzc29uLmNvbQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABAAAAC4BAQAEAAAALQEEAAQAAADwAQMAHAAAAPsCAAAAAAAAAACQAQAA AAAAQAASVGltZXMgTmV3IFJvbWFuAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgA BAAAAAIBAQAFAAAACQIAAAACCQAAADIKAAAAAAEAAAAm/wAABAAAAC4BAQAEAAAALQEEAAQA AADwAQMAHAAAAPsCAAAAAAAAAACQAQAAAAAAQAASVGltZXMgTmV3IFJvbWFuAAAAAAAAAAAA AAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACKAAAADIKAAAAABYA AABKb2FraW0uS29za2VsYUBoaWl0LmZpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAEAAAALgEBAAQAAAAtAQQABAAAAPABAwADAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAA jAIAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAAvAAAAAYAAADEAAAABwAAAMwA AAAIAAAA1AAAAAkAAADcAAAACgAAAOQAAAAXAAAA7AAAAAsAAAD0AAAAEAAAAPwAAAATAAAA BAEAABYAAAAMAQAADQAAABQBAAAMAAAALAIAAAIAAADkBAAAHgAAAA8AAABPbi1zY3JlZW4g U2hvdwAAHgAAAAkAAABFcmljc3NvbgAgU2gDAAAA0ksAAAMAAAApAAAAAwAAAAUAAAADAAAA AwAAAAMAAAAAAAAAAwAAAAAAAAADAAAAQQoKAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsA AAAAAAAAHhAAAAkAAAAQAAAAVGltZXMgTmV3IFJvbWFuAAwAAABDb3VyaWVyIE5ldwAGAAAA QXJpYWwAHQAAAFV0aWxpemluZ19ISVBfZm9yX1AyUFNJUF92MDQAZQAAAExPQ1NFUiArIEhJ UCAgICBkcmFmdC1oYXV0YWtvcnBpLXAycHNpcC1wZWVyLXByb3RvY29sLTAwLnR4dCBkcmFm dC1oYXV0YWtvcnBpLXAycHNpcC13aXRoLWhpcC0wMC50eHQACQAAAE92ZXJ2aWV3AB8AAABF eGFtcGxlOiBTZXNzaW9uIEVzdGFibGlzaG1lbnQACwAAAEhpZ2hsaWdodHMAFQAAAFF1ZXN0 aW9ucywgY29tbWVudHM/AAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAADAAAAHgAA ABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAA BQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 9g8nAAAAFAAAAF/AkeOuSwAADwD0AwMAoH1KYW5pIEhhdXRha29ycGkIAAAASgBhAG4AaQAg AEgAYQB1AHQAYQBrAG8AcgBwAGkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMA AAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAA EQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4A AAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAA/v///ycAAAAoAAAAKQAAACoAAAArAAAA LAAAAC0AAAAuAAAA/v///zAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAD+////OAAAADkA AAA6AAAAOwAAADwAAAA9AAAAPgAAAP7////9////QQAAAP7///////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAAEI2BZJtPzxGG6gCq ALkp6AAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUA cwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgH///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3AAAAABAAAAAA AAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKAACAQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACYAAADwEQAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0A ZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANJLAAAAAAAABQBEAG8AYwB1AG0A ZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgA AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvAAAA ABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAA= --------------000405020506090801050104 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --------------000405020506090801050104-- From p2psip-bounces@ietf.org Tue Jul 24 00:25:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDBxe-000056-9m; Tue, 24 Jul 2007 00:25:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDBxc-00004y-Vr for p2psip@ietf.org; Tue, 24 Jul 2007 00:25:24 -0400 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDBxc-0003qR-NX for p2psip@ietf.org; Tue, 24 Jul 2007 00:25:24 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1275788nzf for ; Mon, 23 Jul 2007 21:25:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=IkgJgfDh3FGLUbbCZOT1gl/CiN1d+BtBH0ToYgrsVCRFIhsXiP12YPhruUhwajc1PWYMYhiC4V57k2A/sHDzDm20ckXG9jbG6n0A2h9VjvHRFXx8+fpz4gN8fnj4qTMfgvxGkv9qt4hDHJSQ+sMcRx8bSkWzC5LHI97eV/QzmoM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:x-google-sender-auth; b=s9X8bajA4r3rDp4DE+AFadYl5rsBmxhI7E5iqxP7h1DpZOWoHvWGRXL5us36IbxHrFyn9ECA4js6r/4wXQLwedded9/Es+kKpxsZ++GmrpYsl61HKjdnS9HdLYD6LqnWImF9pEY+ULV9jDkAReTihK1t9KoSW2xN6Lp08N9AD/M= Received: by 10.115.61.1 with SMTP id o1mr3669797wak.1185251123109; Mon, 23 Jul 2007 21:25:23 -0700 (PDT) Received: by 10.114.171.10 with HTTP; Mon, 23 Jul 2007 21:25:23 -0700 (PDT) Message-ID: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> Date: Tue, 24 Jul 2007 00:25:23 -0400 From: "Medhavi Bhatia" To: "P2PSIP WG" MIME-Version: 1.0 X-Google-Sender-Auth: 23520a35e6781cdf X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [P2PSIP] Forking in P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0892259909==" Errors-To: p2psip-bounces@ietf.org --===============0892259909== Content-Type: multipart/alternative; boundary="----=_Part_156031_12516375.1185251123084" ------=_Part_156031_12516375.1185251123084 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I was curious which (or maybe all) of the proposals for the P2P signaling protocol support the SIP forking behavior and how it is envisioned to work in a P2P environment. It seems to me that the SIP node doing the query for the SIP URI receives multiple contacts which have been registered from the P2P network. The node then goes ahead and sends out the request to one or more contacts. Is this correct? Medhavi. ------=_Part_156031_12516375.1185251123084 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I was curious which (or maybe all) of the proposals for the P2P signaling protocol support the SIP forking behavior and how it is envisioned to work in a P2P environment. It seems to me that the SIP node doing the query for the SIP URI receives multiple contacts which have been registered from the P2P network. The node then goes ahead and sends out the request to one or more contacts. Is this correct?

Medhavi. ------=_Part_156031_12516375.1185251123084-- --===============0892259909== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0892259909==-- From p2psip-bounces@ietf.org Tue Jul 24 01:03:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDCYl-0006dR-0p; Tue, 24 Jul 2007 01:03:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDCYj-0006dM-WD for p2psip@ietf.org; Tue, 24 Jul 2007 01:03:46 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDCYZ-0003YT-0P for p2psip@ietf.org; Tue, 24 Jul 2007 01:03:45 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLO003P737W84@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 23 Jul 2007 21:59:57 -0700 (PDT) Received: from s73602 (dhcp-1722.ietf69.org [130.129.23.34]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLO007SE37TN1@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 23 Jul 2007 21:59:56 -0700 (PDT) Date: Mon, 23 Jul 2007 23:56:49 -0500 From: Spencer Dawkins To: P2PSIP Mailing List Message-id: <11c601c7cdaf$0b777ee0$fb0111ac@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Subject: [P2PSIP] My notes from tonight's ad hoc X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0396042613==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0396042613== Content-type: multipart/alternative; boundary="Boundary_(ID_m1Mazusi5cOx4HCu/ATGxg)" This is a multi-part message in MIME format. --Boundary_(ID_m1Mazusi5cOx4HCu/ATGxg) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Not remotely complete, but just to share with others... Presentation materials are available at https://datatracker.ietf.org/meeting/69/materials.html (scan down to RAI-P2PSIP). Spencer -------------------------------- XPP Focus in this proposal is to be extremely simple. Probably too simple - UDP transport only, for example, and using stop-and-wait strategy with no windowing. Overlay-centric mechanism in XPP - clients don't decide to join overlays, peers in the overlay invite clients to join the overlay as peers. DHT operations are session-oriented - why? Mostly to open ports before sending requests. LOCSER This protocol proposal is based on unmodified HIP. Jonathan Rosenberg does not understand how this proposal works with ICE. This is a bad sign. In this proposal, the HIT is NOT the peer ID. EKR thinks this is a problem, not a detail. RELOAD This proposal evolved from dSIP proposal. He's looking to add details. HIPHOP Presentation is focused on the differences between HIPHOP and other protocols. Proposal is actually to use three separate protocols (distributed transport, distributed databases, and overlay maintenance. Proposal is able to provide this functionality with few-to-no changes to the HIP API, but requires IPv6 to work correctly. EKR is very concerned about proposals that require kernel changes. Jonathan is concerned about the use of public keys related to HITs - it's hard to come up with an exact match to the HIT, but you don't need to guess exact matches - you just have to be able to compute a HIT that puts me closer to the target peer than any other peer is, in order to insert yourself next to the targeted peer. The more peers you have, the better the change you have to guess peer IDs, etc. ASP ASP proposal guards based on two threats - to storage, and to routing. General Discussion Everyone wants to reroute responses if a response is undeliverable because a peer ID has changed - but that's really, really hard. Distinctions - kernel mods required, identifier selections, steps a client takes to establish a connection. whether proposal is considered complete or not, whether the proposal uses HIP or not. whether hop-by-hop security is provided, or only end-to-end security .relationship to SIP. SIP was never designed to work with malicious proxies. ICE inherently has "connection is coming semantics", so all these protocols probably have this model implicitly. All the proposals probably support unmodified SIP clients, although this may not be well-fleshed out. Nobody talked about "non-SIP clients" in these proposals. A couple of proposals claim "mobility", but Jonathan says this comes along with ICE restarts. Whether you route based on HIT or route based on peer ID which may not be a HIT. --Boundary_(ID_m1Mazusi5cOx4HCu/ATGxg) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Not remotely complete, but just to = share with=20 others...

Presentation materials are available at https://d= atatracker.ietf.org/meeting/69/materials.html (scan=20 down to RAI-P2PSIP).
 
Spencer
 
--------------------------------

XPP

Focus in this = proposal is to be=20 extremely simple. Probably too simple =96 UDP transport only, for = example, and=20 using stop-and-wait strategy with no windowing.

Overlay-centric = mechanism in XPP=20 =96 clients don=92t decide to join overlays, peers in the overlay invite = clients to=20 join the overlay as peers.

DHT operations are=20 session-oriented =96 why? Mostly to open ports before sending = requests.

LOCSER

This protocol = proposal is based=20 on unmodified HIP. Jonathan Rosenberg does not understand how this = proposal=20 works with ICE. This is a bad sign=85

In this proposal, = the HIT is NOT=20 the peer ID. EKR thinks this is a problem, not a detail.

RELOAD

This proposal = evolved from dSIP=20 proposal. He=92s looking to add details.

HIPHOP

Presentation is = focused on the=20 differences between HIPHOP and other protocols.

Proposal is actually = to use=20 three separate protocols (distributed transport, distributed databases, = and=20 overlay maintenance. Proposal is able to provide this functionality with = few-to-no changes to the HIP API, but requires IPv6 to work = correctly.

EKR is very = concerned about=20 proposals that require kernel changes.

Jonathan is = concerned about the=20 use of public keys related to HITs =96 it=92s hard to come up with an = exact match to=20 the HIT, but you don=92t need to guess exact matches =96 you just have = to be able to=20 compute a HIT that puts me closer to the target peer than any other peer = is, in=20 order to insert yourself next to the targeted peer. The more peers you = have, the=20 better the change you have to guess peer IDs, etc.

ASP

ASP proposal guards = based on two=20 threats =96 to storage, and to routing.

General = Discussion

Everyone wants to = reroute=20 responses if a response is undeliverable because a peer ID has changed = =96 but=20 that=92s really, really hard.

Distinctions =96 = kernel mods=20 required, identifier selections, steps a client takes to establish a = connection=85=20 whether proposal is considered complete or not, whether the proposal = uses HIP or=20 not=85 whether hop-by-hop security is provided, or only end-to-end = security=20 =85relationship to SIP.

SIP was never = designed to work=20 with malicious proxies.

ICE inherently has = =93connection=20 is coming semantics=94, so all these protocols probably have this model=20 implicitly.

All the proposals = probably=20 support unmodified SIP clients, although this may not be well-fleshed = out.

Nobody talked about = =93non-SIP=20 clients=94 in these proposals.

A couple of = proposals claim=20 =93mobility=94, but Jonathan says this comes along with ICE = restarts.

Whether you route = based on HIT=20 or route based on peer ID which may not be a = HIT.

 --Boundary_(ID_m1Mazusi5cOx4HCu/ATGxg)-- --===============0396042613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0396042613==-- From p2psip-bounces@ietf.org Tue Jul 24 10:19:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLEC-0004WJ-1k; Tue, 24 Jul 2007 10:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLEA-0004W6-DG for p2psip@ietf.org; Tue, 24 Jul 2007 10:19:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDLE9-0008EX-T6 for p2psip@ietf.org; Tue, 24 Jul 2007 10:19:06 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Jul 2007 10:19:05 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALqmpUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,574,1175486400"; d="scan'208"; a="65999605:sNHT62337644" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6OEJ5Ye019649; Tue, 24 Jul 2007 10:19:05 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6OEJ0WI005789; Tue, 24 Jul 2007 14:19:00 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 10:19:00 -0400 Received: from [10.86.242.79] ([10.86.242.79]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 10:19:00 -0400 Message-ID: <46A60A5C.6090307@cisco.com> Date: Tue, 24 Jul 2007 10:19:08 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Medhavi Bhatia Subject: Re: [P2PSIP] Forking in P2PSIP References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> In-Reply-To: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 14:19:00.0410 (UTC) FILETIME=[946F71A0:01C7CDFD] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1333; t=1185286745; x=1186150745; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20Forking=20in=20P2PSIP |Sender:=20 |To:=20Medhavi=20Bhatia=20; bh=HJwOcQ7qUBjyq8w0Qo2jiKAJikmSRFrj4yIzsfzM+Fo=; b=lcKpzrElLGnmbgY1nUFnDZ6RfmrAtYiL23C0RODlq8AhdmDzF+mPWGxRhXGR6aOWHvo7Eb78 89AfziqkV2NExXRephalZh+AurUY2cq8aZ9rS7KWy9S1Np7bxFVPvW35; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is how it works in ASP at least. The only other approach is if one of the nodes in the p2p network acts as a proxy. But then there is a trust issue I don't like, and there is no particular reason that some other node in the network can do the forking better than the originator. -Jonathan R. Medhavi Bhatia wrote: > I was curious which (or maybe all) of the proposals for the P2P > signaling protocol support the SIP forking behavior and how it is > envisioned to work in a P2P environment. It seems to me that the SIP > node doing the query for the SIP URI receives multiple contacts which > have been registered from the P2P network. The node then goes ahead and > sends out the request to one or more contacts. Is this correct? > > Medhavi. > > > ------------------------------------------------------------------------ > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 24 10:29:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLO8-0003Yt-PC; Tue, 24 Jul 2007 10:29:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLO7-0003Ym-OB for p2psip@ietf.org; Tue, 24 Jul 2007 10:29:23 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDLO7-0008QU-4q for p2psip@ietf.org; Tue, 24 Jul 2007 10:29:23 -0400 Received: by nz-out-0506.google.com with SMTP id n1so1387965nzf for ; Tue, 24 Jul 2007 07:29:22 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=HxOpxFwdoinP2SV4ChUhjuYKnWhvG2+bNRaDWhYP0cJnE3W0P/11gQjUr1ElptDCS1OyuKtEHBqPxZK0L8+0Qm+HGx0Wu4sVSsTMu2DiYK30V6HMyRKKBNdhhy/6YtRsGiVhaaH5+i7P6B/QfUnxfe0JnLd41hY6EGmNUH90MUE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=gDb0fiMjInZbSijcX4rzmjb64oFdE3W5OXuaZYTC+4uarxXnEmM7ctDb+OZctWVkwzolBM8PQvGKXz+kuRgPZWnA/W+mKQzR12tqHwuYRL24hvEVOo2qJoFnQH7IkKBKicyIFhEAt78G/vJemshbHKFxdGjdkttKJ4qSA8T2d/Y= Received: by 10.114.196.1 with SMTP id t1mr4112616waf.1185287361845; Tue, 24 Jul 2007 07:29:21 -0700 (PDT) Received: by 10.114.171.10 with HTTP; Tue, 24 Jul 2007 07:29:21 -0700 (PDT) Message-ID: <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> Date: Tue, 24 Jul 2007 10:29:21 -0400 From: "Medhavi Bhatia" To: "Jonathan Rosenberg" Subject: Re: [P2PSIP] Forking in P2PSIP In-Reply-To: <46A60A5C.6090307@cisco.com> MIME-Version: 1.0 References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> X-Google-Sender-Auth: 35012403bbbd6cce X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1096539762==" Errors-To: p2psip-bounces@ietf.org --===============1096539762== Content-Type: multipart/alternative; boundary="----=_Part_161691_10088958.1185287361817" ------=_Part_161691_10088958.1185287361817 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I guess forking will need be implemented in the P2PSIP nodes. MY thinking is that it could be happen at the originator (for cases where location happens before sending request) or at the node where the URI is registered (in cases where P2P network is providing request forwarding service as well). On 7/24/07, Jonathan Rosenberg wrote: > > This is how it works in ASP at least. > > The only other approach is if one of the nodes in the p2p network acts > as a proxy. But then there is a trust issue I don't like, and there is > no particular reason that some other node in the network can do the > forking better than the originator. > > -Jonathan R. > > Medhavi Bhatia wrote: > > I was curious which (or maybe all) of the proposals for the P2P > > signaling protocol support the SIP forking behavior and how it is > > envisioned to work in a P2P environment. It seems to me that the SIP > > node doing the query for the SIP URI receives multiple contacts which > > have been registered from the P2P network. The node then goes ahead and > > sends out the request to one or more contacts. Is this correct? > > > > Medhavi. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > -- Medhavi Bhatia CTO, 3CLogic www.3clogic.com ------=_Part_161691_10088958.1185287361817 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I guess forking will need be implemented in the P2PSIP  nodes. MY thinking is that it could be happen at the originator (for cases where location happens before sending request) or at the node where the URI is registered (in cases where P2P network is providing request forwarding service as well).

On 7/24/07, Jonathan Rosenberg <jdrosen@cisco.com> wrote:
This is how it works in ASP at least.

The only other approach is if one of the nodes in the p2p network acts
as a proxy. But then there is a trust issue I don't like, and there is
no particular reason that some other node in the network can do the
forking better than the originator.

-Jonathan R.

Medhavi Bhatia wrote:
> I was curious which (or maybe all) of the proposals for the P2P
> signaling protocol support the SIP forking behavior and how it is
> envisioned to work in a P2P environment. It seems to me that the SIP
> node doing the query for the SIP URI receives multiple contacts which
> have been registered from the P2P network. The node then goes ahead and
> sends out the request to one or more contacts. Is this correct?
>
> Medhavi.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com



--
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com ------=_Part_161691_10088958.1185287361817-- --===============1096539762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1096539762==-- From p2psip-bounces@ietf.org Tue Jul 24 11:48:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMd3-0005rm-TP; Tue, 24 Jul 2007 11:48:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMd2-0005rc-Fq for p2psip@ietf.org; Tue, 24 Jul 2007 11:48:52 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDMd2-0005tD-3x for p2psip@ietf.org; Tue, 24 Jul 2007 11:48:52 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 24 Jul 2007 11:48:47 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAA+8pUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,574,1175486400"; d="scan'208"; a="66010488:sNHT33691728" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6OFmkQX002821; Tue, 24 Jul 2007 11:48:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6OFmJFB008218; Tue, 24 Jul 2007 15:48:46 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 11:48:38 -0400 Received: from [10.86.242.79] ([10.86.242.79]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 11:48:37 -0400 Message-ID: <46A61F5E.5010006@cisco.com> Date: Tue, 24 Jul 2007 11:48:46 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Medhavi Bhatia Subject: Re: [P2PSIP] Forking in P2PSIP References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> In-Reply-To: <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 15:48:37.0922 (UTC) FILETIME=[19AEA820:01C7CE0A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1022; t=1185292126; x=1186156126; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20Forking=20in=20P2PSIP |Sender:=20 |To:=20Medhavi=20Bhatia=20; bh=8VME4uR4zVyjK3Z7tYPYT8FZjifYT2C7y4QfYDd/LOw=; b=nRY37MxI4WPgJm+Imy99cLUj21HDfnWCRwADyTTB9yfkRhI0za1ACP+vFyXpskzt7hib+0sM HYQ0y26KmCt2Czh+F7EoXhByGIQNp7NpYqInOx0ZoLyGWne5wndpBjyM; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Medhavi Bhatia wrote: > I guess forking will need be implemented in the P2PSIP nodes. MY > thinking is that it could be happen at the originator (for cases where > location happens before sending request) or at the node where the URI is > registered (in cases where P2P network is providing request forwarding > service as well). Well, that introduces a large number of additional attack vectors, for a benefit I don't understand. I think this should be the originator. Anything else requires other nodes in the p2p network, all of which are untrusted, to act as my sip proxy, and brings with it the countless attacks possible when a proxy is malicious. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 24 11:52:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMgd-0006qb-8z; Tue, 24 Jul 2007 11:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMgb-0006qL-CW for p2psip@ietf.org; Tue, 24 Jul 2007 11:52:33 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDMga-0002V3-5m for p2psip@ietf.org; Tue, 24 Jul 2007 11:52:33 -0400 Received: by py-out-1112.google.com with SMTP id f31so6222340pyh for ; Tue, 24 Jul 2007 08:52:31 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=e8RINIkmEd+0LK9P1YA9q7PXqPPoy3EyE8q40ibsuU8U5HuaSLSBe4ROktrRjuIIid5O2oyWIiJ5oJzx1yG2eX1qR4LW2gEFg9sINrMU0nJhClb//FKQdteES3zdM6KAoThWDdBJv/YG/X63d7gJMMPlDKbn5EwmAtr5d2nAamM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=SVxR2nSqpKKQ4pZ4AXgR8uKhKo9wZDzytex+zcQgCSyynOjfWWRvO1HdnSo7ezrLzd8y4vlEJmVQpFcy4gn2fa9sii213jA73CDFoPIbecE2/xyIzrsEkZQYqPK2CtHxylIVsm13Dh8dTfPp7SwNcsOlRIoITHNfEpJmZIVjQZs= Received: by 10.65.189.20 with SMTP id r20mr6717294qbp.1185292351579; Tue, 24 Jul 2007 08:52:31 -0700 (PDT) Received: by 10.65.243.3 with HTTP; Tue, 24 Jul 2007 08:52:31 -0700 (PDT) Message-ID: <4d4304a00707240852q4c799358h978f5e60ac86a8d5@mail.gmail.com> Date: Tue, 24 Jul 2007 10:52:31 -0500 From: "David A. Bryan" To: "Jonathan Rosenberg" Subject: Re: [P2PSIP] Forking in P2PSIP In-Reply-To: <46A61F5E.5010006@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> X-Google-Sender-Auth: 83aa919fd4bad20a X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >From a pure P2P standpoint, and the issue of SIP aside, it is always better (when possible) to have the peer requesting services or the peer providing the service (as opposed to intermediate devices) do the work. In the SIP case, this means that, when possible, the caller and called should do as much of the work as you can. We want it to be as painless as possible to be a peer, so forking is best done by the originator, in my opinion. my 2 cents (as individual) David On 7/24/07, Jonathan Rosenberg wrote: > > > Medhavi Bhatia wrote: > > I guess forking will need be implemented in the P2PSIP nodes. MY > > thinking is that it could be happen at the originator (for cases where > > location happens before sending request) or at the node where the URI is > > registered (in cases where P2P network is providing request forwarding > > service as well). > > Well, that introduces a large number of additional attack vectors, for a > benefit I don't understand. I think this should be the originator. > Anything else requires other nodes in the p2p network, all of which are > untrusted, to act as my sip proxy, and brings with it the countless > attacks possible when a proxy is malicious. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 24 12:28:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNFn-0004Kp-EQ; Tue, 24 Jul 2007 12:28:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNFl-0004JM-LY for p2psip@ietf.org; Tue, 24 Jul 2007 12:28:53 -0400 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDNFl-0004Rm-6W for p2psip@ietf.org; Tue, 24 Jul 2007 12:28:53 -0400 Received: by an-out-0708.google.com with SMTP id c17so439362anc for ; Tue, 24 Jul 2007 09:28:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=T5qb5qpYxdyFMKDnyGqiHCpeDsBBg0p/EKUbvhGRaMsisCER7if5ZRFW7uEuNrebo+Oja5IWJR4K/wnMuCNIyD5/peBP17svHYlHxUlWUu3ndj2m1mgK5aWj3/EcwAsB+deU4HdINNeKiAInIHmec3O5YKpQA24A8j2ZJag2sRQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=SZ6WGw5XUXRf8MVzX4lcRqM9qgE0HufzVOgfrh9JMR1KJIb+8ol+JRUu0qMSf1MEANdOAK2MJY5Kr6o1gCPR97Ppmqr8RRL0yjwrT3v6FtNw3KkyH/zayl+09iHA8slznFhKx2ecm6VirwqL8JcXi6MU2Ff4wkPfyG2ZoYGYwqw= Received: by 10.100.122.8 with SMTP id u8mr2416631anc.1185294532779; Tue, 24 Jul 2007 09:28:52 -0700 (PDT) Received: by 10.100.106.1 with HTTP; Tue, 24 Jul 2007 09:28:44 -0700 (PDT) Message-ID: <20d2bdfb0707240928k52c9638dj9a84c3ec1a41bd20@mail.gmail.com> Date: Tue, 24 Jul 2007 11:28:44 -0500 From: "Bruce Lowekamp" To: "Jonathan Rosenberg" Subject: Re: [P2PSIP] Forking in P2PSIP In-Reply-To: <46A61F5E.5010006@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> X-Google-Sender-Auth: 79add2a9b9ae8846 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org For use cases where P2PSIP is intended to form a proxy (use case "P2P for Redundant SIP Proxies" is the most obvious, but I think there is another use case where clients are configured with a single local proxy that happens to be a peer in a P2PSIP deployment but the clients don't have to be aware of it), the use case implies the same trust relationship that would be present in a conventional SIP deployment (effectively the P2PSIP portion is only a backend). In those cases, because the trust relationship is the same, I think it would be fine to have the P2PSIP peer (in role as proxy) handle the forking. In deployments where such a trust relationship is not present, I agree that the caller should handle the forking. Bruce On 7/24/07, Jonathan Rosenberg wrote: > > > Medhavi Bhatia wrote: > > I guess forking will need be implemented in the P2PSIP nodes. MY > > thinking is that it could be happen at the originator (for cases where > > location happens before sending request) or at the node where the URI is > > registered (in cases where P2P network is providing request forwarding > > service as well). > > Well, that introduces a large number of additional attack vectors, for a > benefit I don't understand. I think this should be the originator. > Anything else requires other nodes in the p2p network, all of which are > untrusted, to act as my sip proxy, and brings with it the countless > attacks possible when a proxy is malicious. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 24 13:16:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDO0A-0000oB-EB; Tue, 24 Jul 2007 13:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDO08-0000nS-Ar for p2psip@ietf.org; Tue, 24 Jul 2007 13:16:48 -0400 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDO06-0005uT-IF for p2psip@ietf.org; Tue, 24 Jul 2007 13:16:48 -0400 Received: by wa-out-1112.google.com with SMTP id k17so3056317waf for ; Tue, 24 Jul 2007 10:16:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=LXAt/IfUUh4KuwIcLYyUVVv1Kh1LDjXuCvT95B1dCqZuTCRskonpeKQgjaqBgkh6sM9FWlgpxubMHVhFzMguEBX6wOU5eaceMLXRrXJ4H78gcpY4trK3OZ2qJZOS2eCLnrAKFQO0GWY0d+rTh4YwkV3CQzrUWh74u+L3/vu29GI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=gTEFcWIZZTx2C8H7DFWD62Nn3l4e8ZepDYY1aUnHhgVLyk6q0toz+tp3E3LN7bRzecJXllyiJ6WmnTI3u1KFIIYjOIgFBTqO/yhCd+AElhKa/SDFhj32emnoBjEZkiSfkGzz6Sl2PU/uU/8Qy/XUNQmH9QVOo6fNZrXvWIctf8w= Received: by 10.114.168.1 with SMTP id q1mr4259343wae.1185297405612; Tue, 24 Jul 2007 10:16:45 -0700 (PDT) Received: by 10.114.171.10 with HTTP; Tue, 24 Jul 2007 10:16:45 -0700 (PDT) Message-ID: <894e079b0707241016m46ab130esc978b0914ac9b410@mail.gmail.com> Date: Tue, 24 Jul 2007 13:16:45 -0400 From: "Medhavi Bhatia" To: "Spencer Dawkins" Subject: Re: [P2PSIP] My notes from tonight's ad hoc In-Reply-To: <11c601c7cdaf$0b777ee0$fb0111ac@china.huawei.com> MIME-Version: 1.0 References: <11c601c7cdaf$0b777ee0$fb0111ac@china.huawei.com> X-Google-Sender-Auth: cea0c057f4e893eb X-Spam-Score: 0.0 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0021068514==" Errors-To: p2psip-bounces@ietf.org --===============0021068514== Content-Type: multipart/alternative; boundary="----=_Part_164769_13477975.1185297405576" ------=_Part_164769_13477975.1185297405576 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I was not there for this session. I don't see any presentations on P2PP/Baset+Schulzrinne. I am assuming that's still an active proposal at this point? On 7/24/07, Spencer Dawkins wrote: > > Not remotely complete, but just to share with others... > > Presentation materials are available at > https://datatracker.ietf.org/meeting/69/materials.html (scan down to > RAI-P2PSIP). > > Spencer > > -------------------------------- > > XPP > > Focus in this proposal is to be extremely simple. Probably too simple =96 > UDP transport only, for example, and using stop-and-wait strategy with no > windowing. > > Overlay-centric mechanism in XPP =96 clients don't decide to join overlay= s, > peers in the overlay invite clients to join the overlay as peers. > > DHT operations are session-oriented =96 why? Mostly to open ports before > sending requests. > > LOCSER > > This protocol proposal is based on unmodified HIP. Jonathan Rosenberg doe= s > not understand how this proposal works with ICE. This is a bad sign=85 > > In this proposal, the HIT is NOT the peer ID. EKR thinks this is a > problem, not a detail. > > RELOAD > > This proposal evolved from dSIP proposal. He's looking to add details. > > HIPHOP > > Presentation is focused on the differences between HIPHOP and other > protocols. > > Proposal is actually to use three separate protocols (distributed > transport, distributed databases, and overlay maintenance. Proposal is ab= le > to provide this functionality with few-to-no changes to the HIP API, but > requires IPv6 to work correctly. > > EKR is very concerned about proposals that require kernel changes. > > Jonathan is concerned about the use of public keys related to HITs =96 it= 's > hard to come up with an exact match to the HIT, but you don't need to gue= ss > exact matches =96 you just have to be able to compute a HIT that puts me > closer to the target peer than any other peer is, in order to insert > yourself next to the targeted peer. The more peers you have, the better t= he > change you have to guess peer IDs, etc. > > ASP > > ASP proposal guards based on two threats =96 to storage, and to routing. > > General Discussion > > Everyone wants to reroute responses if a response is undeliverable becaus= e > a peer ID has changed =96 but that's really, really hard. > > Distinctions =96 kernel mods required, identifier selections, steps a cli= ent > takes to establish a connection=85 whether proposal is considered complet= e or > not, whether the proposal uses HIP or not=85 whether hop-by-hop security = is > provided, or only end-to-end security =85relationship to SIP. > > SIP was never designed to work with malicious proxies. > > ICE inherently has "connection is coming semantics", so all these > protocols probably have this model implicitly. > > All the proposals probably support unmodified SIP clients, although this > may not be well-fleshed out. > > Nobody talked about "non-SIP clients" in these proposals. > > A couple of proposals claim "mobility", but Jonathan says this comes alon= g > with ICE restarts. > > Whether you route based on HIT or route based on peer ID which may not be > a HIT. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > --=20 Medhavi Bhatia CTO, 3CLogic www.3clogic.com ------=_Part_164769_13477975.1185297405576 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I was not there for this session. I don't see any presentations on P2PP/Baset+Schulzrinne. I am assuming that's still an active proposal a= t this point?

On 7/24/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote:
Not remotely complete, but just to sha= re with=20 others...

Presentation materials are available at https://datatracker.ietf.= org/meeting/69/materials.html  (scan=20 down to RAI-P2PSIP).
 
Spencer
 
--------------------------------

XPP

Focus in this proposal is to be=20 extremely simple. Probably too simple =96 UDP transport only, for example, = and=20 using stop-and-wait strategy with no windowing.

Overlay-centric mechanism in XPP=20 =96 clients don't decide to join overlays, peers in the overlay invite clie= nts to=20 join the overlay as peers.

DHT operations are=20 session-oriented =96 why? Mostly to open ports before sending requests.

LOCSER

This protocol proposal is based=20 on unmodified HIP. Jonathan Rosenberg does not understand how this proposal= =20 works with ICE. This is a bad sign=85

In this proposal, the HIT is NOT=20 the peer ID. EKR thinks this is a problem, not a detail.

RELOAD

This proposal evolved from dSIP=20 proposal. He's looking to add details.

HIPHOP

Presentation is focused on the=20 differences between HIPHOP and other protocols.

Proposal is actually to use=20 three separate protocols (distributed transport, distributed databases, and= =20 overlay maintenance. Proposal is able to provide this functionality with=20 few-to-no changes to the HIP API, but requires IPv6 to work correctly.

EKR is very concerned about=20 proposals that require kernel changes.

Jonathan is concerned about the=20 use of public keys related to HITs =96 it's hard to come up with an exact m= atch to=20 the HIT, but you don't need to guess exact matches =96 you just have to be = able to=20 compute a HIT that puts me closer to the target peer than any other peer is= , in=20 order to insert yourself next to the targeted peer. The more peers you have= , the=20 better the change you have to guess peer IDs, etc.

ASP

ASP proposal guards based on two=20 threats =96 to storage, and to routing.

General Discussion

Everyone wants to reroute=20 responses if a response is undeliverable because a peer ID has changed =96 = but=20 that's really, really hard.

Distinctions =96 kernel mods=20 required, identifier selections, steps a client takes to establish a connec= tion=85=20 whether proposal is considered complete or not, whether the proposal uses H= IP or=20 not=85 whether hop-by-hop security is provided, or only end-to-end security= =20 =85relationship to SIP.

SIP was never designed to work=20 with malicious proxies.

ICE inherently has "connection=20 is coming semantics", so all these protocols probably have this model=20 implicitly.

All the proposals probably=20 support unmodified SIP clients, although this may not be well-fleshed out.<= /p>

Nobody talked about "non-SIP=20 clients" in these proposals.

A couple of proposals claim=20 "mobility", but Jonathan says this comes along with ICE restarts.

Whether you route based on HIT=20 or route based on peer ID which may not be a HIT.


_______________________________________________
P2PSIP mailing list<= br>P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip




--
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com ------=_Part_164769_13477975.1185297405576-- --===============0021068514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0021068514==-- From p2psip-bounces@ietf.org Tue Jul 24 13:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOWo-0006hb-SK; Tue, 24 Jul 2007 13:50:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOWn-0006b8-6Z for p2psip@ietf.org; Tue, 24 Jul 2007 13:50:33 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDOWl-00074q-Lg for p2psip@ietf.org; Tue, 24 Jul 2007 13:50:33 -0400 Received: from [130.129.21.36] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IDOWa-00033t-0R; Tue, 24 Jul 2007 12:50:20 -0500 From: "Brian Rosen" To: "'Medhavi Bhatia'" , "'Spencer Dawkins'" References: <11c601c7cdaf$0b777ee0$fb0111ac@china.huawei.com> <894e079b0707241016m46ab130esc978b0914ac9b410@mail.gmail.com> Subject: RE: [P2PSIP] My notes from tonight's ad hoc Date: Tue, 24 Jul 2007 13:50:28 -0400 Message-ID: <040601c7ce1b$209ae750$94168182@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfOFmtprbmQSDCdRQeVZu/KQcmBzgABJiaQ In-Reply-To: <894e079b0707241016m46ab130esc978b0914ac9b410@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0d6b5666eba887052ef5e87a9de0d3b8 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1086748572==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1086748572== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0407_01C7CDF9.99894750" This is a multi-part message in MIME format. ------=_NextPart_000_0407_01C7CDF9.99894750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes it is. No one from that group was available last night to present. Salmon will be here Thursday. Henning is on vacation. Brian _____ From: Medhavi Bhatia [mailto:mbhatia@3clogic.com] Sent: Tuesday, July 24, 2007 1:17 PM To: Spencer Dawkins Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] My notes from tonight's ad hoc I was not there for this session. I don't see any presentations on P2PP/Baset+Schulzrinne. I am assuming that's still an active proposal at this point? On 7/24/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote: Not remotely complete, but just to share with others... Presentation materials are available at https://datatracker.ietf.org/meeting/69/materials.html (scan down to RAI-P2PSIP). Spencer -------------------------------- XPP Focus in this proposal is to be extremely simple. Probably too simple - UDP transport only, for example, and using stop-and-wait strategy with no windowing. Overlay-centric mechanism in XPP - clients don't decide to join overlays, peers in the overlay invite clients to join the overlay as peers. DHT operations are session-oriented - why? Mostly to open ports before sending requests. LOCSER This protocol proposal is based on unmodified HIP. Jonathan Rosenberg does not understand how this proposal works with ICE. This is a bad sign. In this proposal, the HIT is NOT the peer ID. EKR thinks this is a problem, not a detail. RELOAD This proposal evolved from dSIP proposal. He's looking to add details. HIPHOP Presentation is focused on the differences between HIPHOP and other protocols. Proposal is actually to use three separate protocols (distributed transport, distributed databases, and overlay maintenance. Proposal is able to provide this functionality with few-to-no changes to the HIP API, but requires IPv6 to work correctly. EKR is very concerned about proposals that require kernel changes. Jonathan is concerned about the use of public keys related to HITs - it's hard to come up with an exact match to the HIT, but you don't need to guess exact matches - you just have to be able to compute a HIT that puts me closer to the target peer than any other peer is, in order to insert yourself next to the targeted peer. The more peers you have, the better the change you have to guess peer IDs, etc. ASP ASP proposal guards based on two threats - to storage, and to routing. General Discussion Everyone wants to reroute responses if a response is undeliverable because a peer ID has changed - but that's really, really hard. Distinctions - kernel mods required, identifier selections, steps a client takes to establish a connection. whether proposal is considered complete or not, whether the proposal uses HIP or not. whether hop-by-hop security is provided, or only end-to-end security .relationship to SIP. SIP was never designed to work with malicious proxies. ICE inherently has "connection is coming semantics", so all these protocols probably have this model implicitly. All the proposals probably support unmodified SIP clients, although this may not be well-fleshed out. Nobody talked about "non-SIP clients" in these proposals. A couple of proposals claim "mobility", but Jonathan says this comes along with ICE restarts. Whether you route based on HIT or route based on peer ID which may not be a HIT. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip -- Medhavi Bhatia CTO, 3CLogic www.3clogic.com ------=_NextPart_000_0407_01C7CDF9.99894750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes it is.  No one from that = group was available last night to present.  Salmon will be here = Thursday.  Henning is on vacation.

 

Brian

 

From: = Medhavi Bhatia [mailto:mbhatia@3clogic.com]
Sent: Tuesday, July 24, = 2007 1:17 PM
To: Spencer Dawkins
Cc: P2PSIP Mailing = List
Subject: Re: [P2PSIP] My = notes from tonight's ad hoc

 

I was not = there for this session. I don't see any presentations on P2PP/Baset+Schulzrinne. I am = assuming that's still an active proposal at this = point?

On 7/24/07, Spencer Dawkins < spencer@mcsr-labs.org> wrote:

Not remotely complete, but just to share with = others...

Presentation materials are available at https://datatracker.ietf.org/meeting/69/materials.html  (scan down to RAI-P2PSIP).

 

Spencer

 

--------------------------------

 

XPP

Focus in this proposal is to be extremely = simple. Probably too simple – UDP transport only, for example, and using = stop-and-wait strategy with no windowing.

Overlay-centric mechanism in XPP – = clients don't decide to join overlays, peers in the overlay invite clients to join the overlay as peers.

DHT operations are session-oriented – = why? Mostly to open ports before sending requests.

LOCSER

This protocol proposal is based on unmodified = HIP. Jonathan Rosenberg does not understand how this proposal works with ICE. = This is a bad sign…

In this proposal, the HIT is NOT the peer ID. = EKR thinks this is a problem, not a detail.

RELOAD

This proposal evolved from dSIP proposal. = He's looking to add details.

HIPHOP

Presentation is focused on the differences = between HIPHOP and other protocols.

Proposal is actually to use three separate = protocols (distributed transport, distributed databases, and overlay maintenance. Proposal is able to provide this functionality with few-to-no changes to = the HIP API, but requires IPv6 to work = correctly.

EKR is very concerned about proposals that = require kernel changes.

Jonathan is concerned about the use of public = keys related to HITs – it's hard to come up with an exact match to the = HIT, but you don't need to guess exact matches – you just have to be able to = compute a HIT that puts me closer to the target peer than any other peer is, in order = to insert yourself next to the targeted peer. The more peers you have, the = better the change you have to guess peer IDs, etc.

ASP

ASP proposal guards based on two threats = – to storage, and to routing.

General = Discussion

Everyone wants to reroute responses if a = response is undeliverable because a peer ID has changed – but that's really, = really hard.

Distinctions – kernel mods required, = identifier selections, steps a client takes to establish a connection… = whether proposal is considered complete or not, whether the proposal uses HIP or not… = whether hop-by-hop security is provided, or only end-to-end security = …relationship to SIP.

SIP was never designed to work with malicious = proxies.

ICE inherently has "connection is coming semantics", so all these protocols probably have this model = implicitly.

All the proposals probably support unmodified = SIP clients, although this may not be well-fleshed = out.

Nobody talked about "non-SIP = clients" in these proposals.

A couple of proposals claim = "mobility", but Jonathan says this comes along with ICE = restarts.

Whether you route based on HIT or route based = on peer ID which may not be a HIT.


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip<= /o:p>




--
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com =

------=_NextPart_000_0407_01C7CDF9.99894750-- --===============1086748572== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1086748572==-- From p2psip-bounces@ietf.org Tue Jul 24 15:59:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQXV-0001IT-0T; Tue, 24 Jul 2007 15:59:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQXT-0001HX-W6 for p2psip@ietf.org; Tue, 24 Jul 2007 15:59:24 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDQXT-0005NA-CB for p2psip@ietf.org; Tue, 24 Jul 2007 15:59:23 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id l6OJxIO6019116; Tue, 24 Jul 2007 14:59:18 -0500 (CDT) Received: from [135.244.34.214] (vkg.lra.lucent.com [135.244.34.214]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l6OJxHa16976; Tue, 24 Jul 2007 14:59:18 -0500 (CDT) Message-ID: <46A65A15.5040900@alcatel-lucent.com> Date: Tue, 24 Jul 2007 14:59:17 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Bruce Lowekamp Subject: Re: [P2PSIP] Forking in P2PSIP References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> <20d2bdfb0707240928k52c9638dj9a84c3ec1a41bd20@mail.gmail.com> In-Reply-To: <20d2bdfb0707240928k52c9638dj9a84c3ec1a41bd20@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Bruce Lowekamp wrote: > For use cases where P2PSIP is intended to form a proxy (use case "P2P > for Redundant SIP Proxies" is the most obvious, but I think there is > another use case where clients are configured with a single local > proxy that happens to be a peer in a P2PSIP deployment but the clients > don't have to be aware of it), the use case implies the same trust > relationship that would be present in a conventional SIP deployment > (effectively the P2PSIP portion is only a backend). In those cases, > because the trust relationship is the same, I think it would be fine > to have the P2PSIP peer (in role as proxy) handle the forking. > > In deployments where such a trust relationship is not present, I agree > that the caller should handle the forking. In SIP, traditionally we have not encouraged endpoints to fork. Forking is a service provided by proxies. Endpoints are encouraged to handle the results of a fork in the form of expecting multiple 2xx responses, but AFAIK very few, if any SIP endpoints support forking natively. They leave that to a proxy. There are other ways to mitigate the trust relationship. sipsec comes to mind; right now it sort of skirts around the forking issue. But there could be some time spent in making it work with forking. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 24 16:05:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQdB-0005iy-Sy; Tue, 24 Jul 2007 16:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQdA-0005in-Qv for p2psip@ietf.org; Tue, 24 Jul 2007 16:05:16 -0400 Received: from an-out-0708.google.com ([209.85.132.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDQd9-0001q2-Ls for p2psip@ietf.org; Tue, 24 Jul 2007 16:05:16 -0400 Received: by an-out-0708.google.com with SMTP id c17so454304anc for ; Tue, 24 Jul 2007 13:05:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=D4PRMubJ1tVWH7IV77xc7/uDcafQUp7whhKWwsdMJoW4YbEE6fKRJeRBadrVR1UxuASAsBkFtk0khQ4PDd0/JxPUzyQpj7acyUsruZRSJgPfeLPKxp8iE6zNUTceEnBBJnhkahJRxAe/RpBl/rkIWwcv3KDJ+mi7KUTnnvWyvtI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=is+rDBv4ikHiBcFv8Zzv88wP6qXJv2QeWHAOWwTS38pb/MVQkEwo7A2o+BsCnqOjFBBojHr6Xn7uS/9tz5NKD7NkqnGrD4ooXzafIcfSMrK8C63yDkbL3UcK/h3b/pfsDgI0jrRPJYs1/0QYHbg1u0+1bQ1PdDR/P7CK2SZj45o= Received: by 10.100.110.16 with SMTP id i16mr2541431anc.1185307515300; Tue, 24 Jul 2007 13:05:15 -0700 (PDT) Received: by 10.100.106.1 with HTTP; Tue, 24 Jul 2007 13:05:15 -0700 (PDT) Message-ID: <20d2bdfb0707241305r56c4ba37l42745367c856ade8@mail.gmail.com> Date: Tue, 24 Jul 2007 15:05:15 -0500 From: "Bruce Lowekamp" To: "Vijay K. Gurbani" Subject: Re: [P2PSIP] Forking in P2PSIP In-Reply-To: <46A65A15.5040900@alcatel-lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> <20d2bdfb0707240928k52c9638dj9a84c3ec1a41bd20@mail.gmail.com> <46A65A15.5040900@alcatel-lucent.com> X-Google-Sender-Auth: 0027c59be5fe92cf X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 7/24/07, Vijay K. Gurbani wrote: > In SIP, traditionally we have not encouraged endpoints to fork. > Forking is a service provided by proxies. Endpoints are encouraged > to handle the results of a fork in the form of expecting multiple 2xx > responses, but AFAIK very few, if any SIP endpoints support forking > natively. They leave that to a proxy. > > There are other ways to mitigate the trust relationship. sipsec > comes to mind; right now it sort of skirts around the forking > issue. But there could be some time spent in making it work > with forking. I don't think solving that problem is very useful. Or, at least, maybe it might be useful, but it doesn't eliminate needing to have endpoints handle forking. In a pure P2PSIP environment (serverless PBX, let's say, where there are 100 P2PSIP hardphones and maybe a couple gateways) there is no "proxy" box. Forking has to be done on the endpoints. (unless you want to have one phone handling forking for another phone, but I don't see a compelling argument for that.) Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 24 16:44:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDREi-0007ui-L8; Tue, 24 Jul 2007 16:44:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDREf-0007lR-Li for p2psip@ietf.org; Tue, 24 Jul 2007 16:44:02 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDREf-0002cM-By for p2psip@ietf.org; Tue, 24 Jul 2007 16:44:01 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Jul 2007 13:44:00 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOYBpkarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,575,1175497200"; d="scan'208"; a="187861430:sNHT182628936" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6OKi0uP008452; Tue, 24 Jul 2007 13:44:00 -0700 Received: from [130.129.81.226] (sjc-vpn3-750.cisco.com [10.21.66.238]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6OKhx6C021791; Tue, 24 Jul 2007 20:44:00 GMT In-Reply-To: <46A65A15.5040900@alcatel-lucent.com> References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> <20d2bdfb0707240928k52c9638dj9a84c3ec1a41bd20@mail.gmail.com> <46A65A15.5040900@alcatel-lucent.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38F3CF71-A2E2-47A3-B112-CC68805D5F79@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] Forking in P2PSIP Date: Tue, 24 Jul 2007 15:43:53 -0500 To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=393; t=1185309840; x=1186173840; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Forking=20in=20P2PSIP |Sender:=20; bh=QhAtUjNJh+S7I4G9W+zVot2fUSydAAlI4XX8H3sGcn8=; b=PyqYAgDZBoMo8IOcdYgx8lnRgN24CVtvBOnRgMQhfIFgbRIgHmohdwYZ0g7KWXApCIV3xzpY yz8XGwz2C7SbksOIx6xiPeqMSy2b5NKpCvvdS1VrI3A9hNrRCxUHjvgq; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jul 24, 2007, at 2:59 PM, Vijay K. Gurbani wrote: > In SIP, traditionally we have not encouraged endpoints to fork. Hmm ... probably not too relevant for the conversation here but this has been a relatively hot topic in SIP at times. I realize most deployments today fork at the proxy but I'm not sure ti would say that everyone in the SIP WG has exactly encouraged this. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 24 19:22:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTiB-0007ZQ-8C; Tue, 24 Jul 2007 19:22:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTiA-0007YR-CM for p2psip@ietf.org; Tue, 24 Jul 2007 19:22:38 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDTi9-0005ab-Up for p2psip@ietf.org; Tue, 24 Jul 2007 19:22:38 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6ONMY68003750; Tue, 24 Jul 2007 18:22:34 -0500 (CDT) Received: from [135.244.33.213] (vkg.lra.lucent.com [135.244.33.213]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l6ONMYa12887; Tue, 24 Jul 2007 18:22:34 -0500 (CDT) Message-ID: <46A689BA.7040507@alcatel-lucent.com> Date: Tue, 24 Jul 2007 18:22:34 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [P2PSIP] Forking in P2PSIP References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> <20d2bdfb0707240928k52c9638dj9a84c3ec1a41bd20@mail.gmail.com> <46A65A15.5040900@alcatel-lucent.com> <38F3CF71-A2E2-47A3-B112-CC68805D5F79@cisco.com> In-Reply-To: <38F3CF71-A2E2-47A3-B112-CC68805D5F79@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Cullen Jennings wrote: > > On Jul 24, 2007, at 2:59 PM, Vijay K. Gurbani wrote: > >> In SIP, traditionally we have not encouraged endpoints to fork. > > Hmm ... probably not too relevant for the conversation here but this has > been a relatively hot topic in SIP at times. I realize most deployments > today fork at the proxy but I'm not sure ti would say that everyone in > the SIP WG has exactly encouraged this. In rfc3261, the string "fork" (and its variation "forking") appears 25 times. 20 out of 25 times, the string appear in context of a proxy discussion. 5 out of 25 times, it appears alone or in context of an UA. Thus, an implementor, bereft of direct IETF feedback, reading rfc3261 to code up a SIP stack will associate forking with proxies ;-) - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 24 19:24:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTjb-0008RV-0G; Tue, 24 Jul 2007 19:24:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDTja-0008RQ-Ce for p2psip@ietf.org; Tue, 24 Jul 2007 19:24:06 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDTja-0005cO-2J for p2psip@ietf.org; Tue, 24 Jul 2007 19:24:06 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l6ONNxGI004418; Tue, 24 Jul 2007 18:23:59 -0500 (CDT) Received: from [135.244.33.213] (vkg.lra.lucent.com [135.244.33.213]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l6ONNxa13177; Tue, 24 Jul 2007 18:23:59 -0500 (CDT) Message-ID: <46A68A0F.1060900@alcatel-lucent.com> Date: Tue, 24 Jul 2007 18:23:59 -0500 From: "Vijay K. Gurbani" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Bruce Lowekamp Subject: Re: [P2PSIP] Forking in P2PSIP References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> <20d2bdfb0707240928k52c9638dj9a84c3ec1a41bd20@mail.gmail.com> <46A65A15.5040900@alcatel-lucent.com> <20d2bdfb0707241305r56c4ba37l42745367c856ade8@mail.gmail.com> In-Reply-To: <20d2bdfb0707241305r56c4ba37l42745367c856ade8@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Bruce Lowekamp wrote: > I don't think solving that problem is very useful. Or, at least, > maybe it might be useful, but it doesn't eliminate needing to have > endpoints handle forking. In a pure P2PSIP environment (serverless > PBX, let's say, where there are 100 P2PSIP hardphones and maybe a > couple gateways) there is no "proxy" box. Forking has to be done on > the endpoints. (unless you want to have one phone handling forking > for another phone, but I don't see a compelling argument for that.) Agreed. I am just pointing out that we should not make assumptions that existing SIP UAs will support native forking form the get-go. We can certainly mandate that a P2PSIP UA support forking natively. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Jul 24 20:21:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUdH-0005JV-HI; Tue, 24 Jul 2007 20:21:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDUdG-0005JD-Qy for p2psip@ietf.org; Tue, 24 Jul 2007 20:21:38 -0400 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDUdF-0006bY-II for p2psip@ietf.org; Tue, 24 Jul 2007 20:21:38 -0400 Received: by nz-out-0506.google.com with SMTP id n1so18499nzf for ; Tue, 24 Jul 2007 17:21:37 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=Z8cB1xl+Ty4P2El6acl598RzY4/3ilsFNqBDn7jX+nSHPkSSJxb2OYtR+HuCzYG5PTesAu1Qn8wXsMRsVwlHCi+89vA5IOD/0WCGBKovzL6pX55/HxgX1t7Tvvh41eFCTNnwLhDF3a0XkydQIMQNcVll1jL0czG6FmB5WT8uvhE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=UqwzqtD8fJIk9TRtK6B/fc63jcVJ09ZHRRApQn8yu90YraGMwVpeGWHxZIuz9ULwjR9duI6Sh31CMpE7rxGrzjXO20aTkinUfo8Dpsj1l6gEDjD/9pXDNmG3mvxoRQCsUH3zPwpExSVr+1jz9K3Gz6mNHgGXwKKHa9gWksrk21k= Received: by 10.114.160.1 with SMTP id i1mr74843wae.1185322892630; Tue, 24 Jul 2007 17:21:32 -0700 (PDT) Received: by 10.114.171.10 with HTTP; Tue, 24 Jul 2007 17:21:32 -0700 (PDT) Message-ID: <894e079b0707241721w9596336vc48a0e13e0db55a7@mail.gmail.com> Date: Tue, 24 Jul 2007 20:21:32 -0400 From: "Medhavi Bhatia" To: "Vijay K. Gurbani" Subject: Re: [P2PSIP] Forking in P2PSIP In-Reply-To: <46A68A0F.1060900@alcatel-lucent.com> MIME-Version: 1.0 References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> <20d2bdfb0707240928k52c9638dj9a84c3ec1a41bd20@mail.gmail.com> <46A65A15.5040900@alcatel-lucent.com> <20d2bdfb0707241305r56c4ba37l42745367c856ade8@mail.gmail.com> <46A68A0F.1060900@alcatel-lucent.com> X-Google-Sender-Auth: 3af7320dadc11344 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1513141336==" Errors-To: p2psip-bounces@ietf.org --===============1513141336== Content-Type: multipart/alternative; boundary="----=_Part_170740_15614466.1185322892593" ------=_Part_170740_15614466.1185322892593 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/24/07, Vijay K. Gurbani wrote: > > Bruce Lowekamp wrote: > > I don't think solving that problem is very useful. Or, at least, > > maybe it might be useful, but it doesn't eliminate needing to have > > endpoints handle forking. In a pure P2PSIP environment (serverless > > PBX, let's say, where there are 100 P2PSIP hardphones and maybe a > > couple gateways) there is no "proxy" box. Forking has to be done on > > the endpoints. (unless you want to have one phone handling forking > > for another phone, but I don't see a compelling argument for that.) > > Agreed. I am just pointing out that we should not make assumptions > that existing SIP UAs will support native forking form the get-go. > We can certainly mandate that a P2PSIP UA support forking natively. SIP UAs shouldn't need to support Forking. We are talking about P2PSIP Nodes here. Existing SIP UAs should act as client's to the P2P network. I think the entry point (as Bruce said) will act as an interworking proxy for these UAs with the P2PSIP network and it will need to support forking. I think forking should be part of P2PSIP requirements (I haven't checked if the requirements doc already covers this, but will do). - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > WWW: http://www.alcatel-lucent.com/bell-labs > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Medhavi Bhatia CTO, 3CLogic www.3clogic.com ------=_Part_170740_15614466.1185322892593 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 7/24/07, Vijay K. Gurbani <vkg@alcatel-lucent.com> wrote:
Bruce Lowekamp wrote:
> I don't think solving that problem is very useful.  Or, at least,
> maybe it might be useful, but it doesn't eliminate needing to have
> endpoints handle forking.  In a pure P2PSIP environment (serverless
> PBX, let's say, where there are 100 P2PSIP hardphones and maybe a
> couple gateways) there is no "proxy" box.  Forking has to be done on
> the endpoints.  (unless you want to have one phone handling forking
> for another phone, but I don't see a compelling argument for that.)

Agreed.  I am just pointing out that we should not make assumptions
that existing SIP UAs will support native forking form the get-go.
We can certainly mandate that a P2PSIP UA support forking natively.

SIP UAs shouldn't need to support Forking. We are talking about P2PSIP Nodes here. Existing SIP UAs should act as client's to the P2P network. I think the entry point (as Bruce said) will act as an interworking proxy for these UAs with the P2PSIP network and it will need to support forking. I think forking should be part of P2PSIP requirements (I haven't checked if the requirements doc already covers this, but will do).

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip



--
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com ------=_Part_170740_15614466.1185322892593-- --===============1513141336== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1513141336==-- From p2psip-bounces@ietf.org Wed Jul 25 02:47:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDaei-0007vr-PN; Wed, 25 Jul 2007 02:47:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDaeh-0007ol-BG for p2psip@ietf.org; Wed, 25 Jul 2007 02:47:31 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDaeg-0001Yc-BE for p2psip@ietf.org; Wed, 25 Jul 2007 02:47:31 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLQ00DOC2U1K2@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 25 Jul 2007 14:46:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLQ00L912U1C2@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 25 Jul 2007 14:46:49 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLQ004T02TXB0@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 25 Jul 2007 14:46:49 +0800 (CST) Date: Wed, 25 Jul 2007 14:46:45 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Forking in P2PSIP In-reply-to: <46A61F5E.5010006@cisco.com> To: 'Jonathan Rosenberg' Message-id: <006401c7ce87$9171ce50$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcfOCigItJi+SXw3Rum3uw8KETr6qgAfAXaw X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with Jonathan that forking is better implemented by the originator. I want to point out another issue from implementing fork action at the node where the resource is registered. Peer MUST speak peer protocol and some peers may speak other protocol, for example SIP protocol, while some peers only speak peer protocol. In that case, if the node where the resource is registered is to perform fork action, this node should speak the corresponding application protocol, for example SIP protocol and know how to explain the value associated with the registered key. Then it will make use of the information in the key to fork the request. Regards! -- Jiang XingFeng > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Tuesday, July 24, 2007 11:49 PM > To: Medhavi Bhatia > Cc: P2PSIP WG > Subject: Re: [P2PSIP] Forking in P2PSIP > > > > Medhavi Bhatia wrote: > > I guess forking will need be implemented in the P2PSIP nodes. MY > > thinking is that it could be happen at the originator (for cases where > > location happens before sending request) or at the node where the URI is > > registered (in cases where P2P network is providing request forwarding > > service as well). > > Well, that introduces a large number of additional attack vectors, for a > benefit I don't understand. I think this should be the originator. > Anything else requires other nodes in the p2p network, all of which are > untrusted, to act as my sip proxy, and brings with it the countless > attacks possible when a proxy is malicious. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 25 11:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDj4o-000304-Om; Wed, 25 Jul 2007 11:47:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDj4n-0002zv-KM for p2psip@ietf.org; Wed, 25 Jul 2007 11:47:01 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDj4m-0006p7-Q6 for p2psip@ietf.org; Wed, 25 Jul 2007 11:47:01 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6PFktlj005924; Wed, 25 Jul 2007 10:46:55 -0500 (CDT) Received: from [135.244.5.56] (vkg.lra.lucent.com [135.244.5.56]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id l6PFkia22088; Wed, 25 Jul 2007 10:46:55 -0500 (CDT) Message-ID: <46A77062.7010808@alcatel-lucent.com> Date: Wed, 25 Jul 2007 10:46:42 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Medhavi Bhatia Subject: Re: [P2PSIP] Forking in P2PSIP References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> <20d2bdfb0707240928k52c9638dj9a84c3ec1a41bd20@mail.gmail.com> <46A65A15.5040900@alcatel-lucent.com> <20d2bdfb0707241305r56c4ba37l42745367c856ade8@mail.gmail.com> <46A68A0F.1060900@alcatel-lucent.com> <894e079b0707241721w9596336vc48a0e13e0db55a7@mail.gmail.com> In-Reply-To: <894e079b0707241721w9596336vc48a0e13e0db55a7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Medhavi Bhatia wrote: > SIP UAs shouldn't need to support Forking. We are talking about P2PSIP > Nodes here. Existing SIP UAs should act as client's to the P2P network. > I think the entry point (as Bruce said) will act as an interworking > proxy for these UAs with the P2PSIP network and it will need to support > forking. I think forking should be part of P2PSIP requirements (I > haven't checked if the requirements doc already covers this, but will do). Getting forking right is hard; not impossible, but hard. Forking at the endpoint makes certain intractable issues in SIP like HERFP easier since the forking entity does not need to choose a best response to send upstream and has access to all the potential responses to choose a repairable one. OTOH, the maintaining the response context machinery and the rules to handle crossed final responses et al. can get very intricate. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 25 12:35:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjpw-0006Kp-2A; Wed, 25 Jul 2007 12:35:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDjpu-0006EG-4J for p2psip@ietf.org; Wed, 25 Jul 2007 12:35:42 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDjps-0004Sp-RJ for p2psip@ietf.org; Wed, 25 Jul 2007 12:35:42 -0400 Received: from dhcp-16b2.ietf69.org ([130.129.22.178]) by nylon.softarmor.com with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1IDjpp-0008V2-PF; Wed, 25 Jul 2007 11:35:37 -0500 In-Reply-To: <46A61F5E.5010006@cisco.com> References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Forking in P2PSIP Date: Wed, 25 Jul 2007 11:35:28 -0500 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Jul 24, 2007, at 10:48 AM, Jonathan Rosenberg wrote: > > > Medhavi Bhatia wrote: >> I guess forking will need be implemented in the P2PSIP nodes. MY >> thinking is that it could be happen at the originator (for cases >> where location happens before sending request) or at the node >> where the URI is registered (in cases where P2P network is >> providing request forwarding service as well). > > Well, that introduces a large number of additional attack vectors, > for a benefit I don't understand. I think this should be the > originator. Anything else requires other nodes in the p2p network, > all of which are untrusted, to act as my sip proxy, and brings with > it the countless attacks possible when a proxy is malicious. > Devil's advocate question coming: Let's say I have a half-dozen SIP UAs I want to use with an overlay. They register C/S with a SIP proxy under my control. My AOR using RFC 3263 points at this proxy. Why couldn't MY SIP proxy register my AOR into the overlay, then run SIP in the usual way (including evil forking) on my behalf? No trust issues that way, as far as I can see. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 25 14:44:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlqB-0001K3-Vs; Wed, 25 Jul 2007 14:44:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlqA-0001DY-Mu for p2psip@ietf.org; Wed, 25 Jul 2007 14:44:06 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDlqA-0001ML-B6 for p2psip@ietf.org; Wed, 25 Jul 2007 14:44:06 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2007 14:44:06 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAY3p0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175486400"; d="scan'208"; a="66131155:sNHT30567650" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6PIi55u005354; Wed, 25 Jul 2007 14:44:05 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6PIhiWY024923; Wed, 25 Jul 2007 18:44:01 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 14:43:54 -0400 Received: from [10.86.242.175] ([10.86.242.175]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 14:43:53 -0400 Message-ID: <46A799F3.4020802@cisco.com> Date: Wed, 25 Jul 2007 14:44:03 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [P2PSIP] Forking in P2PSIP References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> <20d2bdfb0707240928k52c9638dj9a84c3ec1a41bd20@mail.gmail.com> <46A65A15.5040900@alcatel-lucent.com> <20d2bdfb0707241305r56c4ba37l42745367c856ade8@mail.gmail.com> <46A68A0F.1060900@alcatel-lucent.com> <894e079b0707241721w9596336vc48a0e13e0db55a7@mail.gmail.com> <46A77062.7010808@alcatel-lucent.com> In-Reply-To: <46A77062.7010808@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 18:43:53.0971 (UTC) FILETIME=[C0262430:01C7CEEB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1959; t=1185389045; x=1186253045; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20Forking=20in=20P2PSIP |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20; bh=7nR/B1Lody/Lc0czJS768zfVAYsVCCJDZ+Mm9R4xb74=; b=Howh8rCmZuP72Ba4Frg/AxrI+66Hj2cLz17oRKUQU6NOT4UYH7lljehROvNwxRnaU0/9lcmZ X87MrXmCFUpzZeOCw8LyuX/HjRf0xwNEsmwktq9ajdj2/8zGJ6ezaOa3; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Vijay K. Gurbani wrote: > Medhavi Bhatia wrote: >> SIP UAs shouldn't need to support Forking. We are talking about P2PSIP >> Nodes here. Existing SIP UAs should act as client's to the P2P >> network. I think the entry point (as Bruce said) will act as an >> interworking proxy for these UAs with the P2PSIP network and it will >> need to support forking. I think forking should be part of P2PSIP >> requirements (I haven't checked if the requirements doc already covers >> this, but will do). > > Getting forking right is hard; not impossible, but hard. > Forking at the endpoint makes certain intractable issues in SIP > like HERFP easier since the forking entity does not need to choose > a best response to send upstream and has access to all the > potential responses to choose a repairable one. OTOH, the > maintaining the response context machinery and the rules to > handle crossed final responses et al. can get very intricate. This is not necessary. When the client 'forks', its not like a proxy forking where the request forks downstream and a proxy needs to collect responses for forwarding upstream. The model is effectively redirect. The originating peer would query the DHT, and learn one or more contacts. Each contact would either be another AOR, or identify a peer. If it identifies a peer, the originating peer connects to it, and sends an INVITE. That INVITE cannot fork since its targeted directly to the UAS. Thus, its almost as if the UAC had sent an INVITE to the home proxy, and gotten redirected to each registered contact, and then recursed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Jul 25 14:46:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlsX-00036n-Ub; Wed, 25 Jul 2007 14:46:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlsX-00035w-0I for p2psip@ietf.org; Wed, 25 Jul 2007 14:46:33 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDlsW-0006HR-Jq for p2psip@ietf.org; Wed, 25 Jul 2007 14:46:32 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2007 14:46:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAAY3p0ZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175486400"; d="scan'208"; a="66131444:sNHT27602696" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6PIkWij006640; Wed, 25 Jul 2007 14:46:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6PIkRWM026105; Wed, 25 Jul 2007 18:46:27 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 14:46:27 -0400 Received: from [10.86.242.175] ([10.86.242.175]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 14:46:27 -0400 Message-ID: <46A79A8C.3080908@cisco.com> Date: Wed, 25 Jul 2007 14:46:36 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] Forking in P2PSIP References: <894e079b0707232125ie27c09cx86ef8b25ed3f6f04@mail.gmail.com> <46A60A5C.6090307@cisco.com> <894e079b0707240729q25fb63eckd22d2638fd509d5e@mail.gmail.com> <46A61F5E.5010006@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2007 18:46:27.0198 (UTC) FILETIME=[1B7AB9E0:01C7CEEC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1944; t=1185389192; x=1186253192; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20Forking=20in=20P2PSIP |Sender:=20 |To:=20Dean=20Willis=20; bh=k/R/bDNJg7gYMFT9d0mqWK5TyyRp/WJIZNSgF2qOUL8=; b=sxrdn4jKTgjclQaKk8HyOWWsONIvinNJAOiLrYh60zz3ZT/rvsp2C8BmsmI7MioCzUQVEXnU 49hqfHsskrITMhuaPp1g9qkfjmn3cI6mCV74KdjsbQo0L75oxtqXdN0I; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org inline. Dean Willis wrote: > > On Jul 24, 2007, at 10:48 AM, Jonathan Rosenberg wrote: > >> >> >> Medhavi Bhatia wrote: >>> I guess forking will need be implemented in the P2PSIP nodes. MY >>> thinking is that it could be happen at the originator (for cases >>> where location happens before sending request) or at the node where >>> the URI is registered (in cases where P2P network is providing >>> request forwarding service as well). >> >> Well, that introduces a large number of additional attack vectors, for >> a benefit I don't understand. I think this should be the originator. >> Anything else requires other nodes in the p2p network, all of which >> are untrusted, to act as my sip proxy, and brings with it the >> countless attacks possible when a proxy is malicious. >> > > Devil's advocate question coming: > > Let's say I have a half-dozen SIP UAs I want to use with an overlay. > They register C/S with a SIP proxy under my control. My AOR using RFC > 3263 points at this proxy. > > Why couldn't MY SIP proxy register my AOR into the overlay, then run SIP > in the usual way (including evil forking) on my behalf? No trust issues > that way, as far as I can see. This use case is fine; but it is different from the one we are discussing. In the case we are discussing, you are trusting your own proxy to reach your own UA. What I disagree with, is that a peer in the DHT would trust some other, arbitrary peer, to act as its proxy and to reach towards the UASes on its behalf. That, I believe, is fundamentally a bad idea. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 26 07:12:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1GA-00057A-F7; Thu, 26 Jul 2007 07:11:58 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE1G7-00056f-Cm; Thu, 26 Jul 2007 07:11:55 -0400 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE1G6-0000wj-7h; Thu, 26 Jul 2007 07:11:55 -0400 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Thu, 26 Jul 2007 04:11:32 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6QBBOWs010290; Thu, 26 Jul 2007 04:11:29 -0700 (PDT) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id l6QB9KI9000054; Thu, 26 Jul 2007 04:09:20 -0700 (PDT) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 04:11:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jul 2007 04:09:54 -0700 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D22B3257B@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC Thread-Index: AcfPPzs1liu3JIq4Q8W3OVkLR1AeigANWmeA References: <20070719145334.2EA8B1810C50@mail.iptel.org> <20070719180614.85AB218115BC@mail.iptel.org> <20070721144803.41B4F1810C56@mail.iptel.org> <24CCCC428EFEA2469BF046DB3C7A8D22AEE186@namail5.corp.adobe.com> <20070723205140.EC8031811206@mail.iptel.org> From: "Henry Sinnreich" To: "Adam Fisk" , "Jiri Kuthan" X-OriginalArrivalTime: 26 Jul 2007 11:11:23.0362 (UTC) FILETIME=[B389BC20:01C7CF75] X-Spam-Score: 0.0 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Cc: behave@ietf.org, mmusic@ietf.org, Juha Heinanen , Jan Janak , P2PSIP WG Subject: [P2PSIP] RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1986495164==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1986495164== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CF75.B153F385" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CF75.B153F385 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This insight may be very useful when designing a test tool for ICE.=20 As I have insisted, we need deployment testing for ICE and continued tweaking to make it real. I have no idea what the deployment testing may reveal and the attached is a welcome example. =20 Is anyone on these lists designing a test tool for NAT scenario discovery and for ICE? =20 Henry =20 ________________________________ From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On Behalf Of Adam Fisk Sent: Wednesday, July 25, 2007 11:41 PM To: Jiri Kuthan Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for RFC =20 I had a conversation earlier tonight at the NYC p2p meetup that led me to question my previous assumptions about ICE "working". Supposedly many routers start to do funny things when they see lots of ICE UDP packets flying by and trying lots of candidates.=20 This has me worried. We all know the frightening number of NAT configurations out there. Maybe I missed it, but is there a test matrix somewhere of NAT combinations and their success rates with ICE? If not, could we create one using one of the open source ICE implementations out there (mine's not quite ready)? I'd be happy to contribute my own router if we had a simple test program, maybe based on the work at Nokia.=20 I think performing those simple tests would set everyone's mind at ease. Otherwise, I am concerned that some NAT and firmware combinations would balk at what they see as packet floods. To a person, everyone I've talked to who has implemented this stuff in the "real world" has said the array of problems with specific NAT configurations is much more significant than they realized at first. I think this is the central problem -- the world we're deploying this in is much more chaotic than that of more RFCs, as the BEHAVE group is trying to address.=20 -Adam On 7/24/07, Adam Fisk wrote: I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17. I've implemented what will be open source implementations of STUN and TURN, both client and server. Here are the key points I've taken away from that experience:=20 1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing. 2) ICE is complex as hell and a pain in the ^#* to implement. I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC.=20 3) ICE is solving a very tricky problem. I like Phillip's earlier suggestion that the draft stay in the "almost done" state like used to happen in the Routing group. I realize that's asking a lot given how much work has gone into it and how eager everyone is to finalize it. I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make simpler. In my implementation of ICE, I do think it could be done more simply, but I don't have concrete suggestions right now because I'm still pulling my hair out with the implementation. I'm not talking about drastic changes anywhere, but all the checklist fiddling sure takes a lot of patience to write. Simplifications might just be in the description and not necessarily the algorithm.=20 I think it's a hard enough and important enough problem that we owe it to ourselves to be even more patient with an "almost done" state that adds the final touches based on real-world feedback. I don't doubt for a second that ICE works, but it's so complex that I worry no one outside huge companies will ever implement it. That would be a huge hindrance to ICE's adoption and power.=20 -Adam =20 ------_=_NextPart_001_01C7CF75.B153F385 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

This insight may be very useful = when designing a test tool for ICE.

As I have insisted, we need = deployment testing for ICE and continued tweaking to make it = real.

I have no idea what the deployment = testing may reveal and the attached is a welcome = example.

 

Is anyone on these lists designing = a test tool for NAT scenario discovery and for = ICE?

 

Henry

 

From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On Behalf Of Adam Fisk
Sent: Wednesday, July 25, = 2007 11:41 PM
To: Jiri Kuthan
Cc: Henry Sinnreich; = David Barrett; Jan Janak; Juha Heinanen; mmusic@ietf.org
Subject: Re: [MMUSIC] Re: = [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LC for = RFC

 

I had a = conversation earlier tonight at the NYC p2p meetup that led me to question my = previous assumptions about ICE "working".  Supposedly many routers = start to do funny things when they see lots of ICE UDP packets flying by and = trying lots of candidates.

This has me worried.  We all know the frightening number of NAT configurations out there.  Maybe I missed it, but is there a test = matrix somewhere of NAT combinations and their success rates with ICE?  If = not, could we create one using one of the open source ICE implementations out = there (mine's not quite ready)?  I'd be happy to contribute my own router = if we had a simple test program, maybe based on the work at Nokia.

I think performing those simple tests would set everyone's mind at = ease.  Otherwise, I am concerned that some NAT and firmware combinations would = balk at what they see as packet floods.

To a person, everyone I've talked to who has implemented this stuff in = the "real world" has said the array of problems with specific NAT configurations is much more significant than they realized at = first.  I think this is the central problem -- the world we're deploying this in = is much more chaotic than that of more RFCs, as the BEHAVE group is trying to = address.

-Adam

On 7/24/07, Adam Fisk <a@lastbamboo.org> wrote:

I've followed = ICE development on the sidelines for years now, and I'm currently = implementing ICE 17.  I've implemented what will be open source implementations of = STUN and TURN, both client and server.  Here are the key points I've taken = away from that experience:

1) The patience of Jonathan and everyone else in meticulously getting to = the current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I = was surprised at how hard it was, particularly for a draft that's so close = to becoming an RFC.
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the = "almost done" state like used to happen in the Routing group.  I = realize that's asking a lot given how much work has gone into it and how eager = everyone is to finalize it.  I think the problem is that standardizing NAT traversal is just hard, and hard problems are difficult to make = simpler.  In my implementation of ICE, I do think it could be done more simply, = but I don't have concrete suggestions right now because I'm still pulling my = hair out with the implementation.  I'm not talking about drastic changes = anywhere, but all the checklist fiddling sure takes a lot of patience to = write.  Simplifications might just be in the description and not necessarily the algorithm.

I think it's a hard enough and important enough problem that we owe it = to ourselves to be even more patient with an "almost done" state = that adds the final touches based on real-world feedback.  I don't doubt = for a second that ICE works, but it's so complex that I worry no one outside = huge companies will ever implement it.  That would be a huge hindrance = to ICE's adoption and power.

-Adam

 

------_=_NextPart_001_01C7CF75.B153F385-- --===============1986495164== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1986495164==-- From p2psip-bounces@ietf.org Thu Jul 26 12:19:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE63i-0007DY-Ua; Thu, 26 Jul 2007 12:19:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE63c-000759-H3; Thu, 26 Jul 2007 12:19:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE63b-0002lR-B9; Thu, 26 Jul 2007 12:19:20 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2007 12:19:19 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANxlqEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175486400"; d="scan'208"; a="127119221:sNHT26802332" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6QGJIaP025436; Thu, 26 Jul 2007 12:19:18 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6QGIsWk003600; Thu, 26 Jul 2007 16:19:18 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 12:19:06 -0400 Received: from [10.86.241.65] ([10.86.241.65]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jul 2007 12:19:06 -0400 Message-ID: <46A8C983.4060302@cisco.com> Date: Thu, 26 Jul 2007 12:19:15 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: IETF SIP List , IETF Sipping List , IETF MMUSIC WG , Behave WG , P2PSIP WG , rai@ietf.org, "'avt@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2007 16:19:06.0078 (UTC) FILETIME=[B02C9FE0:01C7CFA0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=740; t=1185466758; x=1186330758; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20ICE=20tutorial=20in=20Chicago=20=20-=20PLEASE=20PAY=20IF=20YO U=20ATE=20LUNCH |Sender:=20 |To:=20IETF=20SIP=20List=20, =20IETF=20Sipping=20List=20, =0A=20=20=20=20=20=20=20=20IETF=20MMUSIC=20WG=20, =20Behave=20WG=20, =0A=20=20=20=20=20=20=20=20P2PSI P=20WG=20, =20rai@ietf.org, =0A=20=20=20=20=20=20=20=20=22' avt@ietf.org'=22=20; bh=Zrtno2xh1JufqqypXQrJG3eaM0QxnaFVcCRKizkJRlU=; b=EAbRlhLzYaOy4oHUNIotoEwBXwvoS8Zp1gyIR9U0ZLbsLNA0SW2PWFoOvExi7DXio14brEfh Ctw1A+j6KiaWFP+lwWplEuOmXoKwNKI3GCkheAO1e18guOsiXHEOunJT; Authentication-Results: rtp-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [P2PSIP] ICE tutorial in Chicago - PLEASE PAY IF YOU ATE LUNCH X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Lunch during the tutorial was paid out of my pocket, and I was expecting to get re-imbursed by everyone that took a sandwich. Though all of the food was taken by the end of the tutorial, I am several hundred dollars short. Please, if you took lunch and did not give me $20, give it to me before you leave, and if you have not, contact me privately and we can arrange for paper mail. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 26 14:01:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE7eA-0006Wk-Jv; Thu, 26 Jul 2007 14:01:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE7e9-0006U9-2j for p2psip@ietf.org; Thu, 26 Jul 2007 14:01:09 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE7e7-0005LE-83 for p2psip@ietf.org; Thu, 26 Jul 2007 14:01:09 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JLS0014TSPT2K@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 26 Jul 2007 11:01:06 -0700 (PDT) Received: from s73602 (dhcp-16f7.ietf69.org [130.129.22.247]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JLS00B4GSPQJD@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 26 Jul 2007 11:01:05 -0700 (PDT) Date: Thu, 26 Jul 2007 12:57:58 -0500 From: Spencer Dawkins To: P2PSIP Mailing List Message-id: <1cfe01c7cfae$80783850$fb0111ac@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [P2PSIP] Good job! X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I'd like to thank the chairs for doing a really good job of focusing our attention on issues, and not on proposals, in our meetings this week, and thank Dean and Philip for the work they've done summarizing proposals and list discussion. You guys are way underpaid ;-) I spent some very dark IETFs attending Sub-IP area meetings where we had 20-25 presentations in a two-and-a-half hour slot, and we never had time to talk about any of them because we had to get to the next one in line... Thanks for not going there. Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Jul 26 14:15:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE7rn-0000J7-EL; Thu, 26 Jul 2007 14:15:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE7rl-0000IQ-6K; Thu, 26 Jul 2007 14:15:13 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE7rj-0005fX-O8; Thu, 26 Jul 2007 14:15:13 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Jul 2007 11:15:10 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMWBqEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,584,1175497200"; d="scan'208"; a="189195896:sNHT91438155" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6QIFA3L015996; Thu, 26 Jul 2007 11:15:10 -0700 Received: from dwingwxp ([10.21.118.134]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6QIF16D025827; Thu, 26 Jul 2007 18:15:02 GMT From: "Dan Wing" To: "'Henry Sinnreich'" , "'Adam Fisk'" , "'Jiri Kuthan'" Date: Thu, 26 Jul 2007 13:14:35 -0500 Message-ID: <05d701c7cfb0$e71ed620$3015590a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D22B3257B@namail5.corp.adobe.com> thread-index: AcfPPzs1liu3JIq4Q8W3OVkLR1AeigANWmeAAAqJ3lA= DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5139; t=1185473710; x=1186337710; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[MMUSIC]=20Re=3A=20[Sip]=20RE=3A=20[BEHAVE]=20Re=3A=2 0ICE=20deploymentdatabefore=20LCfor=20RFC |Sender:=20; bh=ykxSheCBcPAaJEACuzGg9KmUWyl5qLkfBJI6uD/fzmY=; b=WGquyMh/LgJgZG6ORZt/14XukZFS83KmCvPnKRLAs1BzXA2/mNktmo0+/vUwbzQn4eSZ5vzb TBK4Pp6XvH2j3rmDAogyO2IL0iU5tUFE4S91zxQam63awzQhB9iPntDX; Authentication-Results: sj-dkim-2; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: 'Jan Janak' , 'Juha Heinanen' , behave@ietf.org, mmusic@ietf.org, 'P2PSIP WG' Subject: [P2PSIP] RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deploymentdatabefore LCfor RFC X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Thursday, July 26, 2007 6:10 AM > To: Adam Fisk; Jiri Kuthan > Cc: behave@ietf.org; mmusic@ietf.org; Juha Heinanen; Jan > Janak; P2PSIP WG > Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE > deploymentdatabefore LCfor RFC > > This insight may be very useful when designing a test tool for ICE. > > As I have insisted, we need deployment testing for ICE and > continued tweaking to make it real. > > I have no idea what the deployment testing may reveal and the > attached is a welcome example. > > > > Is anyone on these lists designing a test tool for NAT > scenario discovery and for ICE? Awhile back Christian Huitema announced Microsoft's NAT testing tool, http://www1.ietf.org/mail-archive/web/behave/current/msg02117.html > > Microsoft just released a tool that may be interesting for > this list: > http://www.microsoft.com/windows/using/tools/igd/default.mspx > The tool applies various tests against routers to check > how they implement NAT, UPNP, or support of various TCP > options. It is based on Microsoft's "home networking" > requirements for XP and Vista. Arguably, a later version > could implement BEHAVE's requirement, when they are > published by the IETF. > > -- Christian Huitema > It requires a browser that supports Active X. -d > Henry > > > > ________________________________ > > From: adamfisk@gmail.com [mailto:adamfisk@gmail.com] On > Behalf Of Adam Fisk > Sent: Wednesday, July 25, 2007 11:41 PM > To: Jiri Kuthan > Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; > mmusic@ietf.org > Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE > deploymentdatabefore LC for RFC > > > > I had a conversation earlier tonight at the NYC p2p meetup > that led me to question my previous assumptions about ICE > "working". Supposedly many routers start to do funny things > when they see lots of ICE UDP packets flying by and trying > lots of candidates. > > This has me worried. We all know the frightening number of > NAT configurations out there. Maybe I missed it, but is > there a test matrix somewhere of NAT combinations and their > success rates with ICE? If not, could we create one using > one of the open source ICE implementations out there (mine's > not quite ready)? I'd be happy to contribute my own router > if we had a simple test program, maybe based on the work at Nokia. > > I think performing those simple tests would set everyone's > mind at ease. Otherwise, I am concerned that some NAT and > firmware combinations would balk at what they see as packet floods. > > To a person, everyone I've talked to who has implemented this > stuff in the "real world" has said the array of problems with > specific NAT configurations is much more significant than > they realized at first. I think this is the central problem > -- the world we're deploying this in is much more chaotic > than that of more RFCs, as the BEHAVE group is trying to address. > > -Adam > > On 7/24/07, Adam Fisk wrote: > > I've followed ICE development on the sidelines for years now, > and I'm currently implementing ICE 17. I've implemented what > will be open source implementations of STUN and TURN, both > client and server. Here are the key points I've taken away > from that experience: > > 1) The patience of Jonathan and everyone else in meticulously > getting to the current draft is astonishing. > 2) ICE is complex as hell and a pain in the ^#* to implement. > I was surprised at how hard it was, particularly for a draft > that's so close to becoming an RFC. > 3) ICE is solving a very tricky problem. > > I like Phillip's earlier suggestion that the draft stay in > the "almost done" state like used to happen in the Routing > group. I realize that's asking a lot given how much work has > gone into it and how eager everyone is to finalize it. I > think the problem is that standardizing NAT traversal is just > hard, and hard problems are difficult to make simpler. In my > implementation of ICE, I do think it could be done more > simply, but I don't have concrete suggestions right now > because I'm still pulling my hair out with the > implementation. I'm not talking about drastic changes > anywhere, but all the checklist fiddling sure takes a lot of > patience to write. Simplifications might just be in the > description and not necessarily the algorithm. > > I think it's a hard enough and important enough problem that > we owe it to ourselves to be even more patient with an > "almost done" state that adds the final touches based on > real-world feedback. I don't doubt for a second that ICE > works, but it's so complex that I worry no one outside huge > companies will ever implement it. That would be a huge > hindrance to ICE's adoption and power. > > -Adam > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip