From hishigh@gmail.com Mon Jun 10 02:50:30 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2293921F888F for ; Mon, 10 Jun 2013 02:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_73=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvH0LJKt9oJp for ; Mon, 10 Jun 2013 02:50:29 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 37DC621F86FB for ; Mon, 10 Jun 2013 02:50:29 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id n9so5738106oag.0 for ; Mon, 10 Jun 2013 02:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=IMjMEW2TJanS6QI+iHB6z8Tsm1MHvpfV6Pwm0bxwdG4=; b=vaQPLMPtWIkOy0AB9mHzu7AUcog0eoIAgpDCwazisIxN7ePN0F9aYmhloWdPH2E0Ny FshWMfL9MKf5/0xi6kFc2rkPtb0cOGDCK2uw8GkIb6UL09/4O/ywwIOhCy/HpbZ9yTos YoU1ZcRgxg5Q9OR2CCAchrVqkz35g6y2Lp558vKqPLXNmkOufvequZj5o8MT83IQxhp6 KcIQrpAvzTVuFD/cVgMFVdqIPeyQN7RUcWHkonOGVTpXYHfYum+rjF/Mlgn+aDGGKWYV 6R5+MghvXJC1WlT2hBlkU04iS57xb6LzCtHeBMauK8KaOkiNfQudtjuyyoA0stXgamCj 0LdA== MIME-Version: 1.0 X-Received: by 10.182.246.227 with SMTP id xz3mr7247380obc.67.1370857828690; Mon, 10 Jun 2013 02:50:28 -0700 (PDT) Received: by 10.76.35.9 with HTTP; Mon, 10 Jun 2013 02:50:28 -0700 (PDT) Date: Mon, 10 Jun 2013 17:50:28 +0800 Message-ID: From: yunfei zhang To: Rui Cruz , "ppsp@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1f5f0eaafd704dec9b539 Subject: [ppsp] Reviewing the tracker protocol X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 09:50:30 -0000 --001a11c1f5f0eaafd704dec9b539 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I have reviewed the tracker protocol draft and here is my comments: *Overall:* I think this draft is on the right way of a RFC. Implementors can write most of the codes on the communication bw peers and trackers according to the draft. There are clear examples on the syntax and semantics for reference. *Comments:* *1.Abstrct:* Since the main body doesn't invlove in different messages in either adaptive multi-rate, layered (scalable) or multi-view (3D) videos scenarios and this is mainly on different metadata out of scope of this draft, it's better to remove the related description in the abstract (See more in comment #16). *2.Terminology:* a)Adaptive Streaming: "...for the same streaming session" is a little bit confusing. Do you mean in a same viewing or just the same streaming content? b)Chunk: The definition in the Problem statement has been updated according to the review. c)Definition related to presentation: Since the discussion of adaptive multi-rate, layered (scalable) and multi-view (3D) videos scenarios is in the appendix, it seems better to move them in the appendix. d) Media component: It seems not so clear on the definition. e)peer-ID: There is a missing ","after IP address. f) PPSP:The definition in the Problem statement has been updated according to the review. g) Scalable Streaming: MVC is not explained clearly like SVC and MDC. h) Segment: Is it same as Chunk? Do we need the definition of Segement-ID? i) Tracker:The conception of "channel" is not explained. *3.Enrollment and Bootstrap:* 1)Since more roles like player and portal are introduced, it's better to move the description on these roles,e.g., the relationship bw client media player and the peer, currently in appendix, into this part. 2) It's better to clarify that Portal+ MPD file is not the only means to locate the tracker. 4.section 2.3, PPSP-TP should be present in the terminology. 5.Section 2.3.2, in the CONNECT part: a) When a peer registers in the tracker, it may not ask any swarm; b) Peer IP addresses is not sufficient to locate a peer; c) Doesn't the peer registers the Peer mode type informationl? 6. P13, Para2,"each Peer-ID is modeled" or "each peer is modeled"? 7.Section 2.4.1,4)When Tracking, is there a need to send again a "CONNECT"? 8. How to convey the SM state information to the tracker? 9.Section 3.1, transaction-ID is not explained in terminology part. 10. Table 2, it's suggested to add the attribute "battery power"for mobile peers. 11.Section 4.1, it's better to limit the maximum number of the peers in the peerlist to avoild DoS attack or maliciously getting the whole picture of the active peers in short time for profit. 12. P29,Are PEER REGISTERED and TRACKING states in the tracker or peers? 13. Section 6.4, it's not clear about pro-incentive parameter.Needs more descrption. 14.In the security part, the maclious action of asking peer-list with large amount of peers should be noted. 15.Appedix B1, the Authorization header field is not present in the example. And this mechanism should be highlighted. 16. It's better to have sperate drafts to discuss Appedix C. 17. Does OAth 2.0 well suit the authentication bw tracker and peers? I understand that oAuth is best suited in 3rd-party application authorization,not authentication. Am I right? BR Yunfei --001a11c1f5f0eaafd704dec9b539 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
=A0 =A0I have reviewed the tracker protocol dr= aft and here is my comments:

Overall: I thi= nk this draft is on the right way of a RFC. Implementors can write most of = the codes on the communication bw peers and trackers according to the draft= . There are clear examples on the syntax and semantics for reference.

Comments:
1.Abstrct: Since the = main body doesn't invlove in different messages in either adaptive mult= i-rate, layered (scalable) or multi-view (3D) videos scenarios and this is = mainly on different metadata out of scope of this draft, it's better to= remove the related description in the abstract (See more in comment #16).<= /div>
2.Terminology:
=A0 a)Adaptive Streaming: "...for= the same streaming session" is a little bit confusing. Do you mean in= a same viewing or just the same streaming content?
=A0 b)Chunk: = The definition in the Problem statement has been updated according to the r= eview.=A0
=A0 c)Definition related to presentation: Since the discussion of adap= tive multi-rate, layered (scalable)
=A0 =A0and multi-view (3D) vi= deos scenarios is in the appendix, it seems better to move them in the appe= ndix.
=A0 d) Media component: It seems not so clear on the definition.
=
=A0 e)peer-ID: There is a missing ","after IP address.
=
=A0 f) PPSP:The definition in the Problem statement has been updated a= ccording to the review.=A0
=A0 g) Scalable Streaming: MVC is not explained clearly like SVC and M= DC.
=A0 h) Segment: Is it same as Chunk? Do we need the definitio= n of Segement-ID?
=A0 i) Tracker:The conception of "channel&= quot; is not explained.
3.Enrollment and Bootstrap:
=A0 =A01)Since more roles= like player and portal are introduced, it's better to move the descrip= tion on these roles,e.g., the relationship bw client media player and the p= eer, currently in appendix, into this part.
=A0 =A02) It's better to clarify that Portal+ MPD file is not the = only means to locate the tracker.
4.section 2.3, PPSP-TP should b= e present in the terminology.
5.Section 2.3.2, in the CONNECT par= t:
=A0 =A0a) When a peer registers in the tracker, it may not ask any swa= rm;=A0
=A0 =A0b) Peer IP addresses is not sufficient to locate a = peer;
=A0 =A0c) Doesn't the peer registers the Peer mode type= informationl?
6. P13, Para2,"each Peer-ID is modeled" or "each peer i= s modeled"?
7.Section 2.4.1,4)When Tracking, is there a need= to send again a "CONNECT"?
8. How to convey the SM sta= te information to the tracker?
9.Section 3.1, transaction-ID is not explained in terminology part.
10. Table 2, it's suggested to add the attribute "battery = power"for mobile peers.
11.Section 4.1, it's better to l= imit the maximum number of the peers in the peerlist to avoild DoS attack o= r maliciously getting the whole picture of the active peers in short time f= or profit.
12. P29,Are PEER REGISTERED and TRACKING states in the tracker or peer= s?
13. Section 6.4, it's not clear about pro-incentive parame= ter.Needs more descrption.
14.In the security part, the maclious = action of asking peer-list with large amount of peers should be noted.
15.Appedix B1, the Authorization header field is not present in the ex= ample. And this mechanism should be highlighted.
16. It's bet= ter to have sperate drafts to discuss Appedix C.
17. Does OAth 2.= 0 well suit the authentication bw tracker and peers? I understand that oAut= h is best suited in 3rd-party application authorization,not authentication.= Am I right?

BR
Yunfei

--001a11c1f5f0eaafd704dec9b539-- From Martin.Stiemerling@neclab.eu Wed Jun 19 00:47:16 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0297E21F9F7E for ; Wed, 19 Jun 2013 00:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.36 X-Spam-Level: X-Spam-Status: No, score=-103.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKjXPH9D8pr5 for ; Wed, 19 Jun 2013 00:47:11 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5E02321F9C1D for ; Wed, 19 Jun 2013 00:47:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2BA231045B3; Wed, 19 Jun 2013 09:46:49 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viyBeaTtftXu; Wed, 19 Jun 2013 09:46:49 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 1014D1045B5; Wed, 19 Jun 2013 09:46:39 +0200 (CEST) Received: from [10.1.99.64] (10.1.99.64) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Jun 2013 09:45:52 +0200 Message-ID: <51C161DD.1070509@neclab.eu> Date: Wed, 19 Jun 2013 09:46:37 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Wesley Eddy , ppsp References: <517F8C7B.20106@neclab.eu> <518C4D3C.1040302@mti-systems.com> In-Reply-To: <518C4D3C.1040302@mti-systems.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.99.64] Subject: Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:47:16 -0000 On 05/10/2013 03:28 AM, Wesley Eddy wrote: > On 4/30/2013 5:18 AM, Martin Stiemerling wrote: >> 2) LEDBAT as congestion control vs. PPSPP >> The PPSP peer protocol is intended for the Standards Track and relies in >> a normative manner on LEDBAT (RFC 6817). LEDBAT as such is an >> **experimental** delay-based congestion control algorithm. >> A Standards Track protocol cannot normatively rely on an Experimental >> congestion control mechanism (or RFC in general). >> There are ways out of this situation: >> i) Do not use ledbat: this would call for another congestion control >> mechanism to be described in the PPSPP draft. >> ii) Work on an 'upgrade' of the LEDBAT specification to Standards Track: >> Possible, but a very long way. >> iii) Agree on having PPSPP also as Experimental protocol. >> >> I'm currently leaning towards option iii), but this is my pure personal >> opinion as an individual in the IETF. > > > Another option would be to mark it as a DOWNREF during the > IETF Last Call, right? That assumes the WG can make the > case for why this is okay as a DOWNREF (e.g. wide deployment > experience, and lack of cataclysms). This would be one way of dealing with it in a procedural way, but I am not sure if this will solve the issue that we get a lot of push back on using an experimental CC mechanism in a standards track protocol without any real proof that LEDBAT is working on a large scale. I am in support for LEDBAT but I can see a number of valid questions down the road in any further review. One way out would be to have measurements and deployment results that show LEDBAT in action. Martin From Martin.Stiemerling@neclab.eu Wed Jun 19 00:47:30 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE3421F9C1D for ; Wed, 19 Jun 2013 00:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.378 X-Spam-Level: X-Spam-Status: No, score=-103.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQ1O6VdNtLQ5 for ; Wed, 19 Jun 2013 00:47:25 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2E221F9F80 for ; Wed, 19 Jun 2013 00:47:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 34AA71045B6; Wed, 19 Jun 2013 09:47:04 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nx-130pyNaRi; Wed, 19 Jun 2013 09:47:04 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 18A431045B3; Wed, 19 Jun 2013 09:46:49 +0200 (CEST) Received: from [10.1.99.64] (10.1.99.64) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 19 Jun 2013 09:46:08 +0200 Message-ID: <51C161ED.70303@neclab.eu> Date: Wed, 19 Jun 2013 09:46:53 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Riccardo Petrocco References: <517F8C7B.20106@neclab.eu> <518C4D3C.1040302@mti-systems.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.99.64] Cc: ppsp Subject: Re: [ppsp] AD review of draft-ietf-ppsp-peer-protocol-06 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 07:47:30 -0000 On 05/10/2013 10:16 AM, Riccardo Petrocco wrote: > Dear Wesley and All, > > Maybe someone can comment on whether alternatives like TFRC > were investigated or not? TFRC is Standards Track, and intended > for providing a smoother rate like we talked about in the > past (LEDBAT may not be good for relatively rate-inelastic > flows), but I don't know if the feedback it requires would be > compatible with what the PPSPP framing provides or not. > > > We are currently looking into alternatives to LEDBAT for the PPSPP. > The majority of CCs will require some small modifications to the content > of the DATA and ACK messages as defined in the draft. > > I also would not think it wise to change to something else > that doesn't match the implemented and deployed base, unless > the people implementing and deploying agree that something > else is clearly better and will be implemented and deployed > by them. > > > We will also run some large experiments in a controlled environment to > evaluate the effect and feasibility of the different solutions. Good to hear but my question is in what time the WG could expect to see results? This isn't about building up pressure, but more about when the peer protocol should be going for publication as RFC. Martin From dch@jsonified.com Sat Jun 22 02:47:30 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B32621F9F4D for ; Sat, 22 Jun 2013 02:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp-SZKD0Jk1e for ; Sat, 22 Jun 2013 02:47:26 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CBC3C21F9F45 for ; Sat, 22 Jun 2013 02:47:25 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id fr10so8403685lab.32 for ; Sat, 22 Jun 2013 02:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jsonified.com; s=google; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type; bh=mT43emIB2he5bcWbhQTa31yQy59hjvgtUiiE36GEtlY=; b=GnpJJp9ItPOeW/P2pfb6G3qsZP/ZcRGvXgO6rPQK2LNbpIwkl15btahWJLyMBBOoUX j8IhQd2T/VqrJ2XgjZut3rQC730p35eXCy4CthY6kl3bqxdpk1vaEs7Bzt8OscOrh2Wk SA5uXoPvvVwZ1Kb2al8OGOYjcsepuEchLkmqc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=mT43emIB2he5bcWbhQTa31yQy59hjvgtUiiE36GEtlY=; b=F11mk8y0+lMnEACVNn7lhgSxOHkJAPDzi+mMMAoa16R5OanM+GmP/tRrGHyMPPda7n eGkjBS6Q3FvxMsP/0vL2JpE6eFpNXhR/V5TaXuw9Oiqh7QRezIZxN2tHjv403nXZpMCN Nh3AayL+YSMCA+bJKREUDHi3XeoEFFUcukjJI1DLbQGSRnSd2Q2C2CxurkGolUtaB4tL WfDb8xMMDuPgr3MDM8BauoeLXOWHBRL9rYToGUSmks2gQuVPqabp1RkjPbpNpdl6iTGi v0Fz9o11QTQpsiBm8F3CZWmsldmq6DmMNk4T7thkC3dqFjqAM6Zh98fVXJ+UIAYQQiML /bbA== MIME-Version: 1.0 X-Received: by 10.112.181.71 with SMTP id du7mr9122106lbc.24.1371894444423; Sat, 22 Jun 2013 02:47:24 -0700 (PDT) Received: by 10.112.70.229 with HTTP; Sat, 22 Jun 2013 02:47:24 -0700 (PDT) X-Originating-IP: [94.245.250.152] Date: Sat, 22 Jun 2013 11:47:24 +0200 Message-ID: From: Dave Cottlehuber To: ppsp@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQng03WVYTh+QBbaksWRhu8XN92H0TixU+tbmpIeV3dg6UuVquEg2N3r4C0f4Ae7aezI0J0o X-Mailman-Approved-At: Sun, 23 Jun 2013 03:22:32 -0700 Subject: [ppsp] Implementing PPSP in Erlang/OTP X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 09:48:28 -0000 Hi, By way of introduction I'm one of the authors of Apache CouchDB[1], which is a native JSON document database, with a full HTTP "RESTish" API, including multi-master replication and inbuilt conflict management. It's written in a mix of Erlang/OTP[2] for the core, and JavaScript for indexing and processing documents, and filtering results. I've been looking for a peer-to-peer algorithm for a while, and PPSPP aka swift looks like a perfect fit, as well as giving me a taste of implementing a protocol from scratch! I've started on an implementation in Erlang, currently structured in 2 layers: - PPSP layer using native Erlang message passing between nodes. - A UDP layer on top of that to be able to talk to the Real World. I'll have a few questions about the spec along the way no doubt. A+ Dave -- Founder, JSONified dch@jsonified.com [1]: http://couchdb.apache.org/ [2]: http://erlang.org/ From hishigh@gmail.com Sun Jun 23 20:21:42 2013 Return-Path: X-Original-To: ppsp@ietfa.amsl.com Delivered-To: ppsp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE5421F9A00 for ; Sun, 23 Jun 2013 20:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jq6L3md9BaG for ; Sun, 23 Jun 2013 20:21:41 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD1421F99E9 for ; Sun, 23 Jun 2013 20:21:41 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n9so11193604oag.8 for ; Sun, 23 Jun 2013 20:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZKy+yTP7grq4mYEDHC2rpuT+QFFWVBCgSGZf/CrqjPA=; b=iX1NGOPWyjIgN5m5XWKAquQvDCkIxlI9vzIG4yfigNugZAU9gLusYc6bHa+Xfad2tU 9HG5KLCO3zzo1pxv+nrmHEASRMFIlMqcL2GfNI0CWD8VBYsN942iLzSahtJrnGwoviYe ePR/4ZgkZC8C/FaMRVfI2TRi8fLwXhu5q+PkFPSqJ1QKB5zaVHkIZ8wW0zq6naTe/ymi I5+YP4ZIHpr9FdLvHLb8P4VP/w84Y6nZU3wcqu+5vTO+J2QDjzkji2DomuCC8N7d/Spt gQ4cNZRF9xIeLQVxN0e25QeB2hab1+9px7T42IcAEGiO3woboCAagzW+iM0thLv7DKE5 g7gA== MIME-Version: 1.0 X-Received: by 10.182.53.194 with SMTP id d2mr7466450obp.28.1372044101217; Sun, 23 Jun 2013 20:21:41 -0700 (PDT) Received: by 10.76.141.234 with HTTP; Sun, 23 Jun 2013 20:21:41 -0700 (PDT) In-Reply-To: References: Date: Mon, 24 Jun 2013 11:21:41 +0800 Message-ID: From: yunfei zhang To: Dave Cottlehuber Content-Type: multipart/alternative; boundary=089e0158c5ae44f80304dfdde9f7 Cc: "ppsp@ietf.org" Subject: Re: [ppsp] Implementing PPSP in Erlang/OTP X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 03:21:42 -0000 --089e0158c5ae44f80304dfdde9f7 Content-Type: text/plain; charset=ISO-8859-1 Hi Dave, Post any question on the spec draft in the mailing list in your implementation. BR Yunfei 2013/6/22 Dave Cottlehuber > Hi, > > By way of introduction I'm one of the authors of Apache CouchDB[1], > which is a native JSON document database, with a full HTTP "RESTish" > API, including multi-master replication and inbuilt conflict > management. It's written in a mix of Erlang/OTP[2] for the core, and > JavaScript for indexing and processing documents, and filtering > results. > > I've been looking for a peer-to-peer algorithm for a while, and PPSPP > aka swift looks like a perfect fit, as well as giving me a taste of > implementing a protocol from scratch! > > I've started on an implementation in Erlang, currently structured in 2 > layers: > > - PPSP layer using native Erlang message passing between nodes. > - A UDP layer on top of that to be able to talk to the Real World. > > I'll have a few questions about the spec along the way no doubt. > > A+ > Dave > -- > Founder, JSONified > dch@jsonified.com > > [1]: http://couchdb.apache.org/ > [2]: http://erlang.org/ > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp > --089e0158c5ae44f80304dfdde9f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dave,
=A0 =A0 Post any question on the spec d= raft in the mailing list in your implementation.

=
BR
Yunfei


2013/6/22 Dave Cottlehuber <dch@jsonified.com>
Hi,

By way of introduction I'm one of the authors of Apache CouchDB[1],
which is a native JSON document database, with a full HTTP "RESTish&qu= ot;
API, including multi-master replication and inbuilt conflict
management. It's written in a mix of Erlang/OTP[2] for the core, and JavaScript for indexing and processing documents, and filtering
results.

I've been looking for a peer-to-peer algorithm for a while, and PPSPP aka swift looks like a perfect fit, as well as giving me a taste of
implementing a protocol from scratch!

I've started on an implementation in Erlang, currently structured in 2 = layers:

- PPSP layer using native Erlang message passing between nodes.
- A UDP layer on top of that to be able to talk to the Real World.

I'll have a few questions about the spec along the way no doubt.

A+
Dave
--
Founder, JSONified
dch@jsonified.com

[1]: http://couchd= b.apache.org/
[2]: http://erlang.org/
_______________________________________________
ppsp mailing list
ppsp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/ppsp

--089e0158c5ae44f80304dfdde9f7--