From a.bakker@vu.nl Fri Sep 30 01:03:27 2011 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 35E5C21F8C18 for ; Fri, 30 Sep 2011 01:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.504 X-Spam-Level: X-Spam-Status: No, score=-4.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] 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 mwOqkT7wEVuB for ; Fri, 30 Sep 2011 01:03:26 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFDC21F8BA7 for ; Fri, 30 Sep 2011 01:03:25 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 30 Sep 2011 10:06:09 +0200 Received: from PEXMB002A.vu.local ([169.254.7.249]) by PEXHB011B.vu.local ([130.37.236.65]) with mapi id 14.01.0218.012; Fri, 30 Sep 2011 10:06:13 +0200 From: "Bakker, A." To: Rui Cruz , "li.lichun1@zte.com.cn" Thread-Topic: [ppsp] PPSP encoding Thread-Index: AQHMfrfXbnVd927+RkCNPig/SA065pVliu5H Date: Fri, 30 Sep 2011 08:06:12 +0000 Message-ID: <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> References: , <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> In-Reply-To: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.37.166.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sun, 02 Oct 2011 18:50:01 -0700 Cc: 'ppsp' Subject: Re: [ppsp] PPSP encoding 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: Fri, 30 Sep 2011 08:03:27 -0000 Rui Cruz wrote:=0A= > I our implementation, reflected in our proposed draft, the peer is a tiny= HTTP server and client, implements the =0A= > PPSP protocols for signaling over HTTP, as well as the media transfer pro= tocol is over HTTP, and we are able =0A= > to stream high quality media (including scalable media) even in harsh net= work conditions. =0A= =0A= Hi=0A= =0A= I really question whether HTTP is the right choice. First, this means the s= ystem uses at least 2 TCP connections =0A= per pair of peers, where one would suffice to get bidirectional traffic. Mo= reover, one can question (and we do) =0A= whether TCP is the best suited transport layer protocol. It has fixed conge= stion control, so improvements like =0A= IETF's LEDBAT (=3Dmanage user's upload bandwidth such that P2P moves out of= the way when the user e.g. =0A= uploads photos) are not possible. Furthermore, NAT traversal is complex, th= ere is a high per-connection memory =0A= footprint and finally, it pays a price to offer facilities (in-order and re= liable) that you do not necessarily need in a =0A= P2P protocol.=0A= =0A= Hence, we have a strong preference for UDP. As put forward at the meeting, = we would really like to hear=0A= people's opinions on whether they prefer transport over "raw UDP" or would = like PPSP to be a profile of RTP,=0A= in the same way as Secure RTP. Like SRTP i.e., swift would add a layer belo= w RTP that protects the content, =0A= and does P2P signalling, but which is transparent to the RTP consumer.=0A= =0A= Regards,=0A= Arno=0A= =0A= From njaal.borch@gmail.com Mon Oct 3 05:14:23 2011 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 0790321F8AFC for ; Mon, 3 Oct 2011 05:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 7RPHUk8uKH9E for ; Mon, 3 Oct 2011 05:14:22 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 412B421F8AE6 for ; Mon, 3 Oct 2011 05:14:20 -0700 (PDT) Received: by bkaq10 with SMTP id q10so5761211bka.31 for ; Mon, 03 Oct 2011 05:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=w3AQZYs4pW4XkBDnNXOf9kiglzRbMRjbqPs2SXYjADA=; b=FlKSBeV/vjb/uDiX7w1Dz8OAICqnHGkvwka7VNuRHHskiwrrwQZeb5mzwGuK7zUlWV ISRPWW9iXHozU6LIIS96u7JUrVNYA7SESzKG9sZUlm9b/T4fumk/DDWPr7Sj/b7mzyE1 e+ruvLzY4u7GSGfqI4aYoPAgIaR899Qe+Kt54= MIME-Version: 1.0 Received: by 10.204.9.129 with SMTP id l1mr860418bkl.12.1317644242327; Mon, 03 Oct 2011 05:17:22 -0700 (PDT) Sender: njaal.borch@gmail.com Received: by 10.204.116.137 with HTTP; Mon, 3 Oct 2011 05:17:22 -0700 (PDT) In-Reply-To: <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> Date: Mon, 3 Oct 2011 14:17:22 +0200 X-Google-Sender-Auth: Pj4xxbMk95bu35XdxdXyn0Wi-jE Message-ID: From: Njaal Borch To: "Bakker, A." Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Rui Cruz , ppsp Subject: Re: [ppsp] PPSP encoding 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, 03 Oct 2011 12:18:16 -0000 Hi On 30 September 2011 10:06, Bakker, A. wrote: > I really question whether HTTP is the right choice. First, this means the= system uses at least 2 TCP connections > per pair of peers, where one would suffice to get bidirectional traffic. = Moreover, one can question (and we do) > whether TCP is the best suited transport layer protocol. It has fixed con= gestion control, so improvements like > IETF's LEDBAT (=3Dmanage user's upload bandwidth such that P2P moves out = of the way when the user e.g. > uploads photos) are not possible. Furthermore, NAT traversal is complex, = there is a high per-connection memory > footprint and finally, it pays a price to offer facilities (in-order and = reliable) that you do not necessarily need in a > P2P protocol. In my opinion, connectivity issues with TCP makes it highly unsuitable for any P2P based standard, as it will either work suboptimally or depend on external factors for success. A UDP based solution with built in support for NAT and firewall piercing will ensure that available resources can be harvested in pretty much all configurations. Also of great importance is to keep resource usage of "idle swarms" to a minimum to ensure that enough peers can provide resources when needed also for narrow content, allowing it to be efficient also for user generated or long tail content that is seldomly accessed. Regards, Nj=C3=A5l --- Dr. Nj=C3=A5l Borch Northern Research Institute (NORUT) Troms=C3=B8, Norway From rui.cruz@ieee-pt.org Mon Oct 3 07:00:39 2011 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 8E0BC21F8B47 for ; Mon, 3 Oct 2011 07:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 K3c-mfrtmIka for ; Mon, 3 Oct 2011 07:00:38 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B71921F8B40 for ; Mon, 3 Oct 2011 07:00:38 -0700 (PDT) Received: by wwf22 with SMTP id 22so3993277wwf.13 for ; Mon, 03 Oct 2011 07:03:38 -0700 (PDT) Received: by 10.227.58.79 with SMTP id f15mr3013925wbh.55.1317650618705; Mon, 03 Oct 2011 07:03:38 -0700 (PDT) Received: from [10.2.4.17] (vpn.ist.utl.pt. [193.136.132.10]) by mx.google.com with ESMTPS id h39sm23365270wbo.0.2011.10.03.07.03.36 (version=SSLv3 cipher=OTHER); Mon, 03 Oct 2011 07:03:37 -0700 (PDT) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Rui Cruz In-Reply-To: <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> Date: Mon, 3 Oct 2011 15:03:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> References: , <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> To: "Bakker, A." X-Mailer: Apple Mail (2.1244.3) Cc: Rui Cruz , ppsp Subject: Re: [ppsp] PPSP encoding 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, 03 Oct 2011 14:00:39 -0000 Hi, One aspect that needs to be clarified is the one related to the = streaming method. When addressing bitstreaming, UDP would be a natural and obvious choice. However, when the streaming distribution relies on a "chunk" (media = segment) transfer scheme (instead of a bitstream), whereby the original = media data is chopped into small media segments with a short duration = (of a few seconds), decodable on packet and key frame boundaries, TCP = (with HTTP) may come as the natural choice, compatible with the Internet = infrastructure (CDNs, etc), with reliable transfers. The number of messages exchanged is also highly reduced due the = (duration) size of the media segments, in terms of media buffer demands. This is precisely what we have been observing in media streaming in the = Internet, now standardized by ISO as DASH, for HTTP adaptive streaming. In our implementation, for signaling and transport (peer and tracker = protocols), all messages are of request/reply nature, therefore, only = one TCP connection is established for that purpose, between peers or = between peers and trackers. Trackers, as servers, only receive requests = from peers, even for reports (via HTTP_POST). Peers also provide = information about their IP addresses (IPv4 and IPV6) to trackers. Therefore, trackers (knowing the public address of peers and their = private addresses also) are the obvious choice for providing the = adequate means and information (PPSP-ICE parameters) for NAT traversal = purposes, with candidates carried on PPSP messages. I do not foresee PPSP as a re-invention or clone of BitTorrent. Regards, Rui On 30/09/2011, at 09:06, Bakker, A. wrote: > Rui Cruz wrote: >> I our implementation, reflected in our proposed draft, the peer is a = tiny HTTP server and client, implements the=20 >> PPSP protocols for signaling over HTTP, as well as the media transfer = protocol is over HTTP, and we are able=20 >> to stream high quality media (including scalable media) even in harsh = network conditions.=20 >=20 > Hi >=20 > I really question whether HTTP is the right choice. First, this means = the system uses at least 2 TCP connections=20 > per pair of peers, where one would suffice to get bidirectional = traffic. Moreover, one can question (and we do)=20 > whether TCP is the best suited transport layer protocol. It has fixed = congestion control, so improvements like=20 > IETF's LEDBAT (=3Dmanage user's upload bandwidth such that P2P moves = out of the way when the user e.g.=20 > uploads photos) are not possible. Furthermore, NAT traversal is = complex, there is a high per-connection memory=20 > footprint and finally, it pays a price to offer facilities (in-order = and reliable) that you do not necessarily need in a=20 > P2P protocol. >=20 > Hence, we have a strong preference for UDP. As put forward at the = meeting, we would really like to hear > people's opinions on whether they prefer transport over "raw UDP" or = would like PPSP to be a profile of RTP, > in the same way as Secure RTP. Like SRTP i.e., swift would add a layer = below RTP that protects the content,=20 > and does P2P signalling, but which is transparent to the RTP consumer. >=20 > Regards, > Arno >=20 From a.bakker@vu.nl Tue Oct 4 02:33:14 2011 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 1B07A21F8C5E for ; Tue, 4 Oct 2011 02:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] 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 9660wzymW2rP for ; Tue, 4 Oct 2011 02:33:13 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2890821F8B7D for ; Tue, 4 Oct 2011 02:33:12 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 4 Oct 2011 11:36:18 +0200 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 4 Oct 2011 11:36:15 +0200 Message-ID: <4E8AD3CE.9050401@cs.vu.nl> Date: Tue, 4 Oct 2011 11:37:18 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: ppsp References: , <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> In-Reply-To: <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] PPSP encoding X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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: Tue, 04 Oct 2011 09:33:14 -0000 On 03/10/2011 16:03, Rui Cruz wrote: > > In our implementation, for signaling and transport (peer and tracker protocols), > all messages are of request/reply nature, therefore, only one > TCP connection is established for that purpose, between peers or Hi the root of the problem is that HTTP is a client-server protocol. Hence, IMHO it is unnatural to use it as a basis for a streaming protocol where both parties must be able to request services from the other independently. In your proposal I don't see any mechanism to deal with the asymmetry of HTTP, so I don't understand your remark that your implementation only needs 1 TCP connection per pair of peers. Concretely, how do you allow peer A and peer B to simultaneously do a GET_CHUNK for each other's data? Needing two HTTP connections to overcome the asymmetry means double trouble for NAT firewall traversal. Not only does a peer A need to connect to peer B, but B must also connect back to A. Without HTTP, establishing a single TCP connection would suffice. Also I think requiring two connections will not pass the review by the Area Director and higher as we go to standardization. Until bidirectional HTTP comes along, I think we should rule out HTTP as carrier protocol on that ground alone, however unfortunate that may be for compatibility (leaving out a discussion on how compatible a protocol is when it defines a new set of messages that happened to be carried over HTTP.). Ruling out HTTP leaves us with TCP or UDP as candidates. As argued in my previous post, TCP itself is less suited for a swarm of hosts sharing the same content. I think LEDBAT is an important feature for end-user acceptation, and it can only be offered in combination with UDP. Using UDP also allows one to exploit the fact that peers are sharing the same data, meaning a peer can request retransmission from any peer, not just the previous sender. Note that swift has been designed to be used over any protocol, including TCP, but we have a strong preference for UDP. > I do not foresee PPSP as a re-invention or clone of BitTorrent. > Can you please elaborate your viewpoint? Regards, Arno From Martin.Stiemerling@neclab.eu Tue Oct 4 02:47:07 2011 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 B7FCF21F8A62 for ; Tue, 4 Oct 2011 02:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, 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 d1NezJQCMCXG for ; Tue, 4 Oct 2011 02:47:06 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7910121F8A58 for ; Tue, 4 Oct 2011 02:47:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D6A1D280001D8 for ; Tue, 4 Oct 2011 11:50:10 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lduxPgPmp+wP for ; Tue, 4 Oct 2011 11:50:10 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id BA608280001AA for ; Tue, 4 Oct 2011 11:50:05 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.240]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 4 Oct 2011 11:50:05 +0200 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: Draft meeting minutes PPSP virtual interim meeting (Sept. 28th 2011) Thread-Index: AcyCdmoNh2QSxlC4RGqLTLsjaS4TEw== Date: Tue, 4 Oct 2011 09:50:05 +0000 Deferred-Delivery: Tue, 4 Oct 2011 09:50:00 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] Draft meeting minutes PPSP virtual interim meeting (Sept. 28th 2011) 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: Tue, 04 Oct 2011 09:47:07 -0000 Dear PPSP WG, Please find here the draft meeting minutes of the PPSP virtual interim meet= ing, held September 28th.=20 I have recorded the meeting, but the recording was lost, so that some parts= are missing in the notes. They are marked with these brackets <>. The loss= of the audio recording was basically my own fault in not correctly operati= ng Webex.=20 Please read the minutes and send your comments and corrections to me until *** October 6th, 12pm CEST (10 am UTC). *** I will post the final minutes on Thursday night CEST. Thank you Martin IETF PPSP working group Charter: http://datatracker.ietf.org/wg/ppsp/charter/ Chairs: Martin Stiemerling Yunfei Zhang Meeting minutes of the virtual interim meeting, held September 28th, 2011 The meeting was held via the Webex online meeting facility at http://www.webex.com Presented slides are temporally available here, until December 2011: http://www.stiemerling.org/ietf/ppsp/20110928-ppsp-virtual-interim-slides.z= ip Start time: 2:00pm CEST End time: 4:20 pm CEST ** Final Agenda * Agenda bashing * Chair's introduction on PPSP progress * Tracker Protocol and discussion current candidates: http://datatracker.ietf.org/doc/draft-cruz-ppsp-http-tracker-protocol/ http://datatracker.ietf.org/doc/draft-gu-ppsp-tracker-protocol/ * Peer protocol and discussion current candidates: http://datatracker.ietf.org/doc/draft-gu-ppsp-peer-protocol/ http://datatracker.ietf.org/doc/draft-cruz-ppsp-http-peer-protocol/ http://datatracker.ietf.org/doc/draft-grishchenko-ppsp-swift/ * Trails/Interop discussions * Conclusion and next steps =20 **Meeting Minutes Note taker: Martin Stiemerling NB: minutes in <> are added by the note taker or raise missing or unclear parts. The virtual interim meeting started at 2pm CEST.=20 The co-chairs Yunfei Zhang [YZ] and Martin Stiemerling [MS] started the PPS= P virtual interim with the agenda bashing.=20 Johan Pouwelse [JP] asked if the peer protocol slot can also include a shor= t intro about draft-grishchenko-ppsp-swift and if there is time to discuss fu= ture PPSP trails. =20 [MS] The peer protocol slot is for all peer protocols to be discussed and t= here is time to disucss trials.=20 [MS] Short review of the current status of the PPSP WG.=20 [MS] When shall we start with the WGLC for the draft draft-ietf-ppsp-survey before the next IETF meeting or after? Yingjie Gu[YG] Prefer to have it after the IETF meeting. [MS] Will do the WGLC for the draft draft-ietf-ppsp-survey after the IETF#= 82 meeting and will use the time before the meeting to work on the protocols.= =20 * Tracker Protocol and discussion [YG] presented the current status of draft-gu-ppsp-tracker-protocol. [MS] Is draft-gu-ppsp-tracker-protocol already merged with draft-cruz-ppsp-http-tracker-protocol? [YG] No, not yet. Arno Bakker [AB] HTTP is not bidirectional, server cannot send to client wi= thout receiving a request. [YG] STAT_QUERY required for clients Note: There was a longer discussion about if STAT_QUERY is needed and how i= t would be implemented. It was stated that the current HTTP spec does not s= upport this mode of operation yet, but on the other hand, some p2p systems = may need the semantics of STAT_QUERY. This needs to be discussed further on= the list.=20 Rui Cruz[RC] raised a question about the chunk availability on slide 5 of t= he tracker slides (20110928-ppsp-virtual-interim-PPSP-Tracker-Protocol). This lead to the discuss how smart a PPSP tracker should be or if a rather = simple tracker would be sufficient.=20 [AB] why do you not need to learn about new peers? [YG] This is what KEEPALIVE is doing.=20 [RC] Seconds [AB] and adds that the meaning of the message is changed.=20 [MS] Question about whether the XML encoding has been corrected. [YG] XML encoding was revised. [AB] What is the role of the certificates in the messages? Why not using HT= TPS? [YG] =20 [RC] Wouldn't it reasonable to use authentication tokens? [MS] Use HTTPS standard solution, otherwise hard to built and to get throug= h the standards process.=20 Marc Stuart [MaSt] 2 sides discussed here: open tracker, or closed and over= - engineered tracker. Marc supports a more simple tracker protocol. [MS] will continue this simple vs. smart tracker to the mailing list. * Peer protocol and discussion The discussion started about whether the media transport protocol should be part of the peer protocol or not, as the charter states "PPSP is not charte= red to work on media transmission protocols". However, it should be noted that this does not rule out that the WG has to consider what the media transmiss= ion protocols are.=20 [MS] do you have an implementation of draft-gu-ppsp-peer-protocol? [YG] used to have an experimental implementation, but not the same as the one in draft-gu-ppsp-peer-protocol.=20 [AB] What about the encoding of IP addresses? Right now only IPv4 addresses= are specified, IPv6 is missing.=20 [YG] Should consider this, no time yet.=20 [RC] What was the reason to change to a binary encoding? We use HTTP for signaling and media transport. Goes towards DASH.=20 [MS] HTTP is causing too much overhead. [YZ] In HTTP there is a server, in p2p there is no client/sever mode. HTTP = is not suitable, i.e., different from DASH. [RC] We have implemented it and it works well. [JP] No reason for HTTP if you want efficiency. strongly in favor of binary= . HTTP can be used as fallback, but this seems to be outside of PPSP. [MS] Need to take this the mailing list to discuss the details. [JP] Gave an update about draft-grishchenko-ppsp-swift. [MS] draft-grishchenko-ppsp-swift should be casted in more IETF style. [AB] What means media transport: RTP extension or raw UDP? 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 D44AA21F8C4B for ; Tue, 4 Oct 2011 03:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-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 gww5cIG1MmYj for ; Tue, 4 Oct 2011 03:50:54 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id C022221F8C37 for ; Tue, 4 Oct 2011 03:50:53 -0700 (PDT) Received: by wwf22 with SMTP id 22so378777wwf.13 for ; Tue, 04 Oct 2011 03:53:58 -0700 (PDT) Received: by 10.216.209.198 with SMTP id s48mr4688162weo.103.1317725637869; Tue, 04 Oct 2011 03:53:57 -0700 (PDT) Received: from [192.168.1.100] (62.169.110.167.rev.optimus.pt. [62.169.110.167]) by mx.google.com with ESMTPS id gd6sm2599053wbb.1.2011.10.04.03.53.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 03:53:57 -0700 (PDT) References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> In-Reply-To: <4E8AD3CE.9050401@cs.vu.nl> Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> X-Mailer: iPad Mail (8L1) From: Rui Cruz Date: Tue, 4 Oct 2011 11:54:20 +0100 To: "arno@cs.vu.nl" Cc: ppsp Subject: Re: [ppsp] PPSP encoding 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: Tue, 04 Oct 2011 10:50:54 -0000 On 04/10/2011, at 10:37, Arno Bakker wrote: > On 03/10/2011 16:03, Rui Cruz wrote: >>=20 >> In our implementation, for signaling and transport (peer and tracker prot= ocols), > > all messages are of request/reply nature, therefore, only one > > TCP connection is established for that purpose, between peers or >=20 > Hi >=20 > the root of the problem is that HTTP is a client-server protocol. > Hence, IMHO it is unnatural to use it as a basis for a streaming > protocol where both parties must be able to request services from > the other independently. Indeed, that is the point, they request services and data independently, not= requiring a permanent session established. > In your proposal I don't see any mechanism > to deal with the asymmetry of HTTP, so I don't understand your > remark that your implementation only needs 1 TCP connection per > pair of peers. One connection per pair of peers for the Request/Reply. > Concretely, how do you allow peer A and > peer B to simultaneously do a GET_CHUNK for each other's data? The process is asynchronous, so, there is no need to have permanent bilatera= l sessions. >=20 > Needing two HTTP connections to overcome the asymmetry means > double trouble for NAT firewall traversal. Not only does a > peer A need to connect to peer B, but B must also connect back > to A. You are right, but we are dealing with well known HTTP, and NAT/Firewall tra= versal is less problematic in terms of service availability or filtering rul= es. > Without HTTP, establishing a single TCP connection would > suffice. Also I think requiring two connections will not pass > the review by the Area Director and higher as we go to > standardization. As I said connections may not be simultaneous for the duration of a request/= reply. >=20 > Until bidirectional HTTP comes along, I think we should rule out > HTTP as carrier protocol on that ground alone, however unfortunate that > may be for compatibility (leaving out a discussion on how compatible a > protocol is when it defines a new set of messages that happened > to be carried over HTTP.). With TCP (and HTTP) this method of web streaming is just a multi-source meth= od, where each peer behaves as a streaming server and a peer requests the se= gments of interest from other peers claiming to have them. >=20 > Ruling out HTTP leaves us with TCP or UDP as candidates. As argued in > my previous post, TCP itself is less suited for a swarm of hosts > sharing the same content. I think LEDBAT is an important feature > for end-user acceptation, and it can only be offered in combination > with UDP. > Using UDP also allows one to exploit the fact that peers > are sharing the same data, meaning a peer can request retransmission > from any peer, not just the previous=20 I do dot understand, as peers are allways able to request the data from any o= ther peer, not just the "previous" >=20 > Note that swift has been designed to be used over any protocol, > including TCP, but we have a strong preference for UDP. >=20 >=20 >> I do not foresee PPSP as a re-invention or clone of BitTorrent. >>=20 >=20 > Can you please elaborate your viewpoint? >=20 > Regards, > Arno >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp From a.bakker@vu.nl Tue Oct 4 03:53:37 2011 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 4588021F8C22 for ; Tue, 4 Oct 2011 03:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.879 X-Spam-Level: X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] 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 x0mnG8w--+qj for ; Tue, 4 Oct 2011 03:53:36 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 83E0321F8B5B for ; Tue, 4 Oct 2011 03:53:36 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 4 Oct 2011 12:56:38 +0200 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 4 Oct 2011 12:56:40 +0200 Message-ID: <4E8AE6A6.7080903@cs.vu.nl> Date: Tue, 4 Oct 2011 12:57:42 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] Draft meeting minutes PPSP virtual interim meeting (Sept. 28th 2011) X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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: Tue, 04 Oct 2011 10:53:37 -0000 On 04/10/2011 11:50, Martin Stiemerling wrote: > > * Peer protocol and discussion > The discussion started about whether the media transport protocol should be > part of the peer protocol or not, as the charter states "PPSP is not chartered > to work on media transmission protocols". However, it should be noted that > this does not rule out that the WG has to consider what the media transmission > protocols are. > Hi sorry to repeat this again, but just above this statement the charter says "The first task for this WG will be to decide which signaling and media transfer protocols will be used. The WG will consider existing protocols and, if needed, identify potential extensions to these protocols." So extensions are definitely in the scope. > [AB] What means media transport: RTP extension or raw UDP? My question was what people's preference was, based on their own use cases. Regards, Arno From njaal.borch@gmail.com Tue Oct 4 04:08:42 2011 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 275A221F8C4B for ; Tue, 4 Oct 2011 04:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-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 LtyQ9txFLyxJ for ; Tue, 4 Oct 2011 04:08:37 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE57621F8C4A for ; Tue, 4 Oct 2011 04:08:36 -0700 (PDT) Received: by bkaq10 with SMTP id q10so683301bka.31 for ; Tue, 04 Oct 2011 04:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=7d+KwwA8ytVb2PfHC+hw+zNUttCLXqoF/r6PHjd/PzI=; b=Nj1l3xBup1Yw+wWbADWS/eiNUM75HOdg564+RYstjMAOPkMmNreAiIoJfmz/SICOCI PtOglk1AEP01UGFTyu38sRDAEOSj9mWOKMB8pCOi48BSwPaVCAcGAgcu3KlaRf9OXWB9 amNnuMejh42mTafTz2gGiDRrq1Jar8RLMOZZc= MIME-Version: 1.0 Received: by 10.204.9.129 with SMTP id l1mr637954bkl.12.1317726701021; Tue, 04 Oct 2011 04:11:41 -0700 (PDT) Sender: njaal.borch@gmail.com Received: by 10.204.116.137 with HTTP; Tue, 4 Oct 2011 04:11:40 -0700 (PDT) In-Reply-To: <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> Date: Tue, 4 Oct 2011 13:11:40 +0200 X-Google-Sender-Auth: W-rovqMtlCzp6H3yynIb-29Hcmg Message-ID: From: Njaal Borch To: Rui Cruz Content-Type: text/plain; charset=UTF-8 Cc: ppsp Subject: Re: [ppsp] PPSP encoding 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: Tue, 04 Oct 2011 11:08:42 -0000 Hi, On 4 October 2011 12:54, Rui Cruz wrote: > On 04/10/2011, at 10:37, Arno Bakker wrote: >> the root of the problem is that HTTP is a client-server protocol. >> Hence, IMHO it is unnatural to use it as a basis for a streaming >> protocol where both parties must be able to request services from >> the other independently. > Indeed, that is the point, they request services and data independently, not requiring a permanent session established. But HTTP is a client-server protocol where the client sends a request and the server replies with a reply. If this goes both ways (for two peers to exchange data), you will either need two connections, go for a half-duplex solution where one node must wait for the "http channel" to be available or do nasty multiplexing of multiple HTTP sessions over a single TCP connection. Example: Node A sends request for data D1 to Node B, which starts sending D1 as a reply. Node B now wants to request data D4 from Node A, but can't mix a GET (or any other request) into the data stream currently occupying the HTTP connection. I for one have difficulties understanding why you would want to use an extended HTTP protocol over just TCP, or even better, UDP combined with a variety of congestion controls, and it does not seem possible to me to create a clean system based on a full duplex HTTP connection. >> In your proposal I don't see any mechanism >> to deal with the asymmetry of HTTP, so I don't understand your >> remark that your implementation only needs 1 TCP connection per >> pair of peers. > One connection per pair of peers for the Request/Reply. In other words, you go for a half-duplex solution? >> Concretely, how do you allow peer A and >> peer B to simultaneously do a GET_CHUNK for each other's data? > The process is asynchronous, so, there is no need to have permanent bilateral sessions. But HTTP is synchronous - if you in some way change HTTP to be asynchronous, one can easily assume that backwards compatibility with HTTP is broken. >> Needing two HTTP connections to overcome the asymmetry means >> double trouble for NAT firewall traversal. Not only does a >> peer A need to connect to peer B, but B must also connect back >> to A. > You are right, but we are dealing with well known HTTP, and NAT/Firewall traversal is less problematic in terms of service availability or filtering rules. Not less problematic than a UDP based protocol designed to handle NAT and Firewall traversals without any filtering rules presumably. Regards, N From a.bakker@vu.nl Tue Oct 4 04:12:03 2011 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 47D6121F8753 for ; Tue, 4 Oct 2011 04:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.918 X-Spam-Level: X-Spam-Status: No, score=-3.918 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] 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 fXenZdomysPd for ; Tue, 4 Oct 2011 04:12:02 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 86F9621F86A0 for ; Tue, 4 Oct 2011 04:12:02 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 4 Oct 2011 13:15:09 +0200 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 4 Oct 2011 13:15:06 +0200 Message-ID: <4E8AEAF8.4080102@cs.vu.nl> Date: Tue, 4 Oct 2011 13:16:08 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Rui Cruz References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> In-Reply-To: <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp Subject: Re: [ppsp] PPSP encoding X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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: Tue, 04 Oct 2011 11:12:03 -0000 On 04/10/2011 12:54, Rui Cruz wrote: > Indeed, that is the point, they request services and data > independently, not requiring a permanent session established. Hi does this mean you establish a new TCP connection for every request, i.e. do not use persistent connections? This means one has to do NAT/firewall traversal every time. Furthermore, this adds latency to the request. In my view of a peer-to-peer protocol, pairs of peers are continuously requesting pieces from eachother in parallel (e.g. using tit-4-tat for freeriding prevention). Or otherwise, are continuously exchanging information about what chunks they have available, such that when new interesting data becomes available they can request it. In sum, peers should be permanently connected bidirectionally. >> Using UDP also allows one to exploit the fact that peers >> are sharing the same data, meaning a peer can request retransmission >> from any peer, not just the previous > I do dot understand, as peers are allways able to request > the data from any other peer, not just the "previous" I'm referring to TCP's reliability mechanism being tied to the sender for retransmits. When using UDP and sharing the same content one has more flexibility whom to rerequest from. Regards, Arno From rui.cruz@ieee-pt.org Tue Oct 4 13:55:07 2011 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 5F3CA21F8D86 for ; Tue, 4 Oct 2011 13:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-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 0t9DBagaKF00 for ; Tue, 4 Oct 2011 13:55:06 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1628121F8D87 for ; Tue, 4 Oct 2011 13:55:05 -0700 (PDT) Received: by eye4 with SMTP id 4so1007119eye.31 for ; Tue, 04 Oct 2011 13:58:11 -0700 (PDT) Received: by 10.223.48.141 with SMTP id r13mr2277689faf.115.1317761890787; Tue, 04 Oct 2011 13:58:10 -0700 (PDT) Received: from [192.168.1.113] ([149.156.119.98]) by mx.google.com with ESMTPS id o16sm26848278fag.21.2011.10.04.13.58.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 13:58:09 -0700 (PDT) References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1-152300829 Message-Id: X-Mailer: iPad Mail (8L1) From: Rui Cruz Date: Tue, 4 Oct 2011 22:58:36 +0200 To: Njaal Borch Cc: ppsp Subject: Re: [ppsp] PPSP encoding 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: Tue, 04 Oct 2011 20:55:07 -0000 --Apple-Mail-1-152300829 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi On 04/10/2011, at 13:11, Njaal Borch wrote: > Hi, >=20 > On 4 October 2011 12:54, Rui Cruz wrote: >> On 04/10/2011, at 10:37, Arno Bakker wrote: >>> the root of the problem is that HTTP is a client-server protocol. >>> Hence, IMHO it is unnatural to use it as a basis for a streaming >>> protocol where both parties must be able to request services from >>> the other independently. >> Indeed, that is the point, they request services and data independently, n= ot requiring a permanent session established. >=20 > But HTTP is a client-server protocol where the client sends a request > and the server replies with a reply. Correct > If this goes both ways (for two > peers to exchange data), you will either need two connections, go for > a half-duplex solution where one node must wait for the "http channel" > to be available or do nasty multiplexing of multiple HTTP sessions > over a single TCP connection. Example: Node A sends request for data > D1 to Node B, which starts sending D1 as a reply. Node B now wants to > request data D4 from Node A, but can't mix a GET (or any other > request) into the data stream currently occupying the HTTP connection. As I said, the time between requests for the same peers may be much larger t= han the RTT (the HTTP streaming segments have a much bigger size than RTP pa= ckets (considering a media segment with a duration of several seconds), and n= ot all peers may have the required media data (in the case of SVC or stereos= copic MVC, not all layers/views of a media segment may be available at the s= ame peer). As such, a peer requests to several peers the layers of a media s= egment in order to have the maximum quality (it enables a faster response to= rate variations in the network). But similar reasoning can be done for for m= ultiple bitrates of AVC, if we want the capability of adaptive streaming. There are no nasty things done with HTTP, nor any need to multiplexing. > I for one have difficulties understanding why you would want to use an > extended HTTP protocol over just TCP, or even better, UDP combined > with a variety of congestion controls, and it does not seem possible > to me to create a clean system based on a full duplex HTTP connection. >=20 There is no extended HTTP protocol. The proposed protocol facilitates coping= with congestion by allowing on-the-fly adaptation, performed by adding or s= ubtracting layers (in the case of SVC or MVC) or bitrates (in the case of mu= ltibitrate AVC) to match the capabilities of the network at every time insta= nt. >>> In your proposal I don't see any mechanism >>> to deal with the asymmetry of HTTP, so I don't understand your >>> remark that your implementation only needs 1 TCP connection per >>> pair of peers. >> One connection per pair of peers for the Request/Reply. >=20 > In other words, you go for a half-duplex=20 No. Each peer serves the request from other peers, and makes request to othe= r serving peers. >=20 >>> Concretely, how do you allow peer A and >>> peer B to simultaneously do a GET_CHUNK for each other's data? >> The process is asynchronous, so, there is no need to have permanent bilat= eral sessions. >=20 > But HTTP is synchronous - if you in some way change HTTP to be > asynchronous, one can easily assume that backwards compatibility with > HTTP is broken. >=20 I said that the PROCESS is asynchronous, not the protocol. >>> Needing two HTTP connections to overcome the asymmetry means >>> double trouble for NAT firewall traversal. Not only does a >>> peer A need to connect to peer B, but B must also connect back >>> to A. >> You are right, but we are dealing with well known HTTP, and NAT/Firewall t= raversal is less problematic in terms of service availability or filtering r= ules. >=20 > Not less problematic than a UDP based protocol designed to handle NAT > and Firewall traversals without any filtering rules presumably. >=20 Yes, same level of difficulty. > Regards, > N Regards Rui= --Apple-Mail-1-152300829 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi

On 04/10/2011, at 13:1= 1, Njaal Borch <njaal.borch@norut= .no> wrote:

Hi,

On 4 October 2011 12:54, Rui Cruz &= lt;rui.cruz@ieee-pt.org> wrot= e:
On 04/10/2011, at 10:37, Arno B= akker <arno@cs.vu.nl> wrote:
the root of the problem is that HTTP is a client-server protocol.
Hence, IMHO it is unnatural to use it as a basis for a streaming
protocol where both parties must be able to request services= from
the other independently.
Indeed, that is the point, they req= uest services and data independently, not requiring a permanent session esta= blished.

But HTTP is a client-= server protocol where the client sends a request
and the ser= ver replies with a reply.
Correct
 If this goes both ways (for two
peers to exchange data), you will either need two connections, go for
a half-duplex solution where one node must wait for the "http ch= annel"
to be available or do nasty multiplexing of multiple H= TTP sessions
over a single TCP connection.  Example: &n= bsp;Node A sends request for data
D1 to Node B, which starts= sending D1 as a reply.  Node B now wants to
request da= ta D4 from Node A, but can't mix a GET (or any other
request= ) into the data stream currently occupying the HTTP connection.
As I said, the time between requests for the same peers may= be much larger than the RTT (the HTTP streaming segment= s have a much bigger size than RTP packets (considering a media s= egment with a duration of several seconds), and not all peers may have the r= equired media data (in the case of SVC or stereoscopic MVC, not all layers/v= iews of a media segment may be available at the same peer). As such, a peer r= equests to several peers the layers of a media segment in order to have the m= aximum quality (it enables a faster response to rate= variations in the network). But similar reasoning can be done f= or for multiple bitrates of AVC, if we want the capability of adaptive strea= ming.
There are no nasty things done with HTTP, nor any need to multiple= xing.
I for one have difficulties un= derstanding why you would want to use an
extended HTTP proto= col over just TCP, or even better, UDP combined
with a varie= ty of congestion controls, and it does not seem possible
to m= e to create a clean system based on a full duplex HTTP connection.
There is no extended HTTP protocol. The= proposed protocol facilitates coping with congestio= n by allowing on-the-fly adaptation, performed by adding or subtracting laye= rs (in the case of SVC or MVC) or bitrates (in the case of multibitrate AVC)= to match the capabilities of the network at every time instant.
<= blockquote type=3D"cite">
In your proposal I don't see any mechanism
to d= eal with the asymmetry of HTTP, so I don't understand your
remark that your implementation only needs 1 TCP connection per
<= /blockquote>
pair of peers.
One connection per pair of peers for the Request/Reply.<= br>

In other words, you go for a half-dup= lex 
No. Each peer serves the request from= other peers, and makes request to other serving peers.

Concretely, how do you allow peer A and
peer B t= o simultaneously do a GET_CHUNK for each other's data?
The process is asynchronous, s= o, there is no need to have permanent bilateral sessions.

But HTTP is synchronous - if you in some way cha= nge HTTP to be
asynchronous, one can easily assume that back= wards compatibility with
HTTP is broken.

I said that the PROCESS is asynchronous, not the p= rotocol.
Needing two HTTP connections to overcome the asymme= try means
double trouble for NAT firewall traversal. Not o= nly does a
peer A need to connect to peer B, but B must al= so connect back
to A.
=
You are right, but we are dealing with well k= nown HTTP, and NAT/Firewall traversal is less problematic in terms of servic= e availability or filtering rules.

<= span>Not less problematic than a UDP based protocol designed to handle NAT
and Firewall traversals without any filtering rules presumabl= y.

Yes, same level of difficul= ty.

Regards,
N

Regards
Rui= --Apple-Mail-1-152300829-- From rui.cruz@ieee-pt.org Tue Oct 4 14:36:35 2011 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 D17B821F8EB0 for ; Tue, 4 Oct 2011 14:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-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 mogSuY3ObQEv for ; Tue, 4 Oct 2011 14:36:35 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B822421F8E59 for ; Tue, 4 Oct 2011 14:36:34 -0700 (PDT) Received: by eye4 with SMTP id 4so1043903eye.31 for ; Tue, 04 Oct 2011 14:39:40 -0700 (PDT) Received: by 10.223.9.129 with SMTP id l1mr2404980fal.36.1317764380181; Tue, 04 Oct 2011 14:39:40 -0700 (PDT) Received: from [192.168.1.113] ([149.156.119.98]) by mx.google.com with ESMTPS id f25sm27019096faf.7.2011.10.04.14.39.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 04 Oct 2011 14:39:39 -0700 (PDT) References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> <4E8AEAF8.4080102@cs.vu.nl> In-Reply-To: <4E8AEAF8.4080102@cs.vu.nl> Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2-154790715 Message-Id: <71EDB0EE-431A-4DFF-A079-3BA51C0AA71F@ieee-pt.org> X-Mailer: iPad Mail (8L1) From: Rui Cruz Date: Tue, 4 Oct 2011 23:40:05 +0200 To: "" Cc: ppsp Subject: Re: [ppsp] PPSP encoding 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: Tue, 04 Oct 2011 21:36:35 -0000 --Apple-Mail-2-154790715 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cumprimentos/Regards, Rui Cruz Sent from my iPad On 04/10/2011, at 13:16, Arno Bakker wrote: > On 04/10/2011 12:54, Rui Cruz wrote: >> Indeed, that is the point, they request services and data > > independently, not requiring a permanent session established. >=20 > Hi >=20 > does this mean you establish a new TCP connection for every > request, i.e. do not use persistent connections? We use TCP persistent connections for media transport. > This means > one has to do NAT/firewall traversal every time. Furthermore, > this adds latency to the request. In my view of a peer-to-peer > protocol, pairs of peers are continuously requesting pieces from > eachother in parallel (e.g. using tit-4-tat for freeriding > prevention). Due to its barter nature TFT is not adequate for media streaming. Even worse= for the case of Live streaming. > Or otherwise, are continuously exchanging information > about what chunks they have available, such that when new > interesting data becomes available they can request it. > In sum, peers should be permanently connected bidirectionally. >=20 Peers do need need to announce via a gossip type protocol the chunks/segment= s they just got. It is the interested peer that requests chunkmap updates to the other peers i= n order to decide which of them have the adequate data, as the streaming mod= e is not bitstream (media data is not transported in single packets, but in s= mall segments containing a set of media access units). >>> Using UDP also allows one to exploit the fact that peers >>> are sharing the same data, meaning a peer can request retransmission >>> from any peer, not just the previous >> I do dot understand, as peers are allways able to request > > the data from any other peer, not just the "previous" >=20 > I'm referring to TCP's reliability mechanism being tied to > the sender for retransmits. When using UDP and sharing the > same content one has more flexibility whom to rerequest from. >=20 You are reasoning on a single quality, single bitrate media streaming. I am r= easoning on a flexible, multi-source, adaptive quality, multibitrate streami= ng, in which not all serving peers are in posession of the complete media (t= he chunkmap is multidimensional), and so, peers are always requesting segmen= t layers to different peers, assuming there are more than a couple of pees i= n the swarm, being one of them the seeder. Note that for scalable and adapti= ve media, in order to play back media data of a specific interval, all succe= ssfully received adequate layers of a segment, belonging to that time interv= al, have to be combined together before the segment is delivered to the deco= der, meaning that the received media quality is variable. The requested laye= rs are received without errors (due to TCP reliability), and so, unless ther= e is a strong congestion in the network, leading to buffer starvation, the m= edia can be played without interruption or defects (artifacts, etc.).=20 > Regards, > Arno >=20 --Apple-Mail-2-154790715 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Cumprimentos/Regards,
Rui Cruz

Sent from my iPad

On 04/10/2011= , at 13:16, Arno Bakker <arno@cs.vu.nl> wrote:

We use TCP persistent connections for media transport.
This means
one has to do NAT/firew= all traversal every time. Furthermore,
this adds latency to t= he request. In my view of a peer-to-peer
protocol, pairs of p= eers are continuously requesting pieces from
eachother in pa= rallel (e.g. using tit-4-tat for freeriding
prevention).
Due to its barter nature TFT is not adequate for medi= a streaming. Even worse for the case of Live streaming.

Or otherwise, are continuously exchanging info= rmation
about what chunks they have available, such that whe= n new
interesting data becomes available they can request it= .
In sum, peers should be permanently connected bidirectiona= lly.

Peers do need need to ann= ounce via a gossip type protocol the chunks/segments they just got.
It is the interested peer that requests chunkmap updates to the other peer= s in order to decide which of them have the adequate data, as the streaming m= ode is not bitstream (media data is not transported in s= ingle packets, but in small segments containing a set of media access units<= /span>).

<= blockquote type=3D"cite">
Using UDP also allo= ws one to exploit the fact that peers
are sharing the same= data, meaning a peer can request retransmission
from any p= eer, not just the previous
I do dot understand, as peers are allways able to request=
> the data from any other peer, not just th= e "previous"

I'm referring to TCP's reliab= ility mechanism being tied to
the sender for retransmits. Wh= en using UDP and sharing the
same content one has more flexi= bility whom to rerequest from.

Y= ou are reasoning on a single quality, single bitrate media streaming. I am r= easoning on a flexible, multi-source, adaptive quality, multibitrate streami= ng, in which not all serving peers are in posession of the complete media (t= he chunkmap is multidimensional), and so, peers are always requesting segmen= t layers to different peers, assuming there are more than a coupl= e of pees in the swarm, being one of them the seeder. Note that for scalable= and adaptive media, in order to pl= ay back media data of a specific interval, all successfully received adequat= e layers of a segment, belonging to that time interval, have to be combined t= ogether before the segment is delivered to the decoder, meaning that the rec= eived media quality is variable. The requested layers are received without e= rrors (due to TCP reliability), and so, unless there is a strong congestion i= n the network, leading to buffer starvation, the media can be played without= interruption or defects (artifacts, etc.). 

=
Regards,
 =   Arno

<= /body>= --Apple-Mail-2-154790715-- From kiraly@disi.unitn.it Wed Oct 5 03:30:06 2011 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 AC01221F8C15 for ; Wed, 5 Oct 2011 03:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.118 X-Spam-Level: X-Spam-Status: No, score=-4.118 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] 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 Al-SOXmMGlJa for ; Wed, 5 Oct 2011 03:30:05 -0700 (PDT) Received: from mail2.unitn.it (mail2.unitn.it [193.205.206.54]) by ietfa.amsl.com (Postfix) with ESMTP id 821AF21F8C16 for ; Wed, 5 Oct 2011 03:30:03 -0700 (PDT) Received: from mail2.unitn.it (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9E7525031F for ; Wed, 5 Oct 2011 12:33:09 +0200 (CEST) Received: from mailhub2.unitn.it (mailhub2.unitn.it [192.168.206.47]) by mail2.unitn.it (Postfix) with ESMTP id 077995031B for ; Wed, 5 Oct 2011 12:33:09 +0200 (CEST) Received: from disi.unitn.it (dit.unitn.it [193.205.194.4]) by mailhub2.unitn.it (Postfix) with ESMTP id EFB45B0D3D5 for ; Wed, 5 Oct 2011 12:33:08 +0200 (CEST) Received: from [193.205.213.86] (gep.disi.unitn.it [193.205.213.86]) by disi.unitn.it (8.13.8/8.13.8) with ESMTP id p95AX8ab025282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Oct 2011 12:33:08 +0200 Message-ID: <4E8C3264.2010707@disi.unitn.it> Date: Wed, 05 Oct 2011 12:33:08 +0200 From: Csaba Kiraly User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: ppsp@ietf.org References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/alternative; boundary="------------060408000001010109030005" Subject: Re: [ppsp] PPSP encoding 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, 05 Oct 2011 10:30:06 -0000 This is a multi-part message in MIME format. --------------060408000001010109030005 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, I hope you don't mind if I add my 2c to the conversation. Since I've never expressed my thoughts here before, let me start with a quick intro: I'm Csaba Kiraly, working on the NAPA-WINE project, on the WineStreamer and PeerStreamer applications. Let me first of all say that currently we use UDP. Not because TCP is bad or evil, but because it seems to be more suitable for our specific system goals and design. Our target is largely dynamic low delay streaming. These are the two parameters we are optimizing for, which seems to be rather different from the system Rui speaks about. As a consequence, our chunks are not seconds long but 1..5 frames (40..200 ms) long. Our p2p neighbourhood relations can be many and they can be short in time, passing only a small number of chunks. Under these conditions, we can evaluate *TCP vs. UDP* as follows: 1, short-lived TCP connections are known to behave badly providing low average throughput. UDP doesn't have these problems, although you are expected to throw in some "TCP-friendliness". However, since TCP's solutions are not working well in this context, UDP might be a better starting point here. 2, large numbers of short-lived TCP connections are also known to behave badly for congestion control. Thus, you anyway need some other congestion control mechanisms, which at that point can go over UDP as well. 3, even if a chunk is one frame, partial chunks can be useful. Maybe not re-propagated, but it can be used in local playout. UDP gives us this possibility, a short-lived TCP that stalls don't. 4, we do not need reliable delivery, at least not at the level that TCP provides. Actually, we don't even need it for signaling. If e.g. a chunk offer is lost, the peer will receive another one from someone else, etc. 5, UDP seems to be blocked by more firewalls than TCP. The main reason for this originally was the possible aggressiveness of UDP, but IMHO it has long been forgotten and it is simply applied as a system administration practice. This points in the direction of using TCP. *Summarizing*: for our system design, UDP seems a better fit. About using *HTTP+TCP vs. something+TCP*: once TCP has been decided, there is the choice whether to use HTTP or design a custom protocol. Lets see some arguments pro and contra: Reasons to use*HTTP+TCP* could be many: 1, the argument I hear the most is firewall traversal. There is no doubt it is true that today HTTP proxies are still dumb and thus systems can use HTTP+TCP as a backup connectivity solution, or even as their main connectivity solution. IMHO this will change as applications use more-and-more HTTP for sending their nasty traffic over the net. 2, libraries+integration: there are many HTTP libraries which makes it rather easy to create an HTTP based prototype 3, header fields (metadata): HTTP does provide some meta information in its headers, which are even extensible. This has some relevance in designing the protocol for the application (an extensible header mechanism is already available without designing one), and it also has some relevance to the proxies that try to understand/filter the traffic. Reasons to use *TCP with something else* instead: 1, clearly, HTTP provides a restricted use of TCP. The model for bidirectional communication is much more restrictive than what would be allowed by TCP. 2, stability: although it doesn't seem like that, HTTP is a complex protocol. Many of the HTTP libraries have buggy or badly performing, or at least not well tested implementations of some of the less frequently used operation modes. Unfortunately, when you try to stretch the boundaries of HTTP, you happen to use these features, so libraries can easily become a pain instead of a help. 3, network overhead: A custom protocol can easily be designed with less overhead than TCP 4, processing overhead: many of the HTTP libraries are bloated, and indeed if one wants to support all the niche cases, it has to be quite heavy. 5, TCP sockets are not that difficult compared to all the code needed to set-up and tune a HTTP library correctly. *To summarize*: if I would have to choose the one and only application layer protocol + transport protocol combo for a P2P application, today I would be forced to use HTTP simply for the reason of connectivity. With this choice, I seem to sacrifice low delay and some performance, but gain so many more possible clients that it seems to worth it. However, I don't think there is a need to chose one common denominator at such a high level in the protocol stack. I prefer to use something that performs better and use HTTP as a back-off. regards, Csaba On 10/04/2011 10:58 PM, Rui Cruz wrote: > Hi > > On 04/10/2011, at 13:11, Njaal Borch > wrote: > >> Hi, >> >> On 4 October 2011 12:54, Rui Cruz > wrote: >>> On 04/10/2011, at 10:37, Arno Bakker > wrote: >>>> the root of the problem is that HTTP is a client-server protocol. >>>> Hence, IMHO it is unnatural to use it as a basis for a streaming >>>> protocol where both parties must be able to request services from >>>> the other independently. >>> Indeed, that is the point, they request services and data independently, not requiring a permanent session established. >> >> But HTTP is a client-server protocol where the client sends a request >> and the server replies with a reply. > Correct >> If this goes both ways (for two >> peers to exchange data), you will either need two connections, go for >> a half-duplex solution where one node must wait for the "http channel" >> to be available or do nasty multiplexing of multiple HTTP sessions >> over a single TCP connection. Example: Node A sends request for data >> D1 to Node B, which starts sending D1 as a reply. Node B now wants to >> request data D4 from Node A, but can't mix a GET (or any other >> request) into the data stream currently occupying the HTTP connection. > As I said, the time between requests for the same peers may be much larger than the RTT (the HTTP streaming segments have a much bigger size than RTP packets (considering a media segment with a duration of several seconds), and not all peers may have the required media data (in the case of SVC or stereoscopic MVC, not all layers/views of a media segment may be available at the same peer). As such, a peer requests to several peers the layers of a media segment in order to have the maximum quality (it enables a faster response to rate variations in the network). But similar reasoning can be done for for multiple bitrates of AVC, if we want the capability of adaptive streaming. > There are no nasty things done with HTTP, nor any need to multiplexing. >> I for one have difficulties understanding why you would want to use an >> extended HTTP protocol over just TCP, or even better, UDP combined >> with a variety of congestion controls, and it does not seem possible >> to me to create a clean system based on a full duplex HTTP connection. >> > There is no extended HTTP protocol. The proposed protocol facilitates coping with congestion by allowing on-the-fly adaptation, performed by adding or subtracting layers (in the case of SVC or MVC) or bitrates (in the case of multibitrate AVC) to match the capabilities of the network at every time instant. >>>> In your proposal I don't see any mechanism >>>> to deal with the asymmetry of HTTP, so I don't understand your >>>> remark that your implementation only needs 1 TCP connection per >>>> pair of peers. >>> One connection per pair of peers for the Request/Reply. >> >> In other words, you go for a half-duplex > No. Each peer serves the request from other peers, and makes request to other serving peers. >> >>>> Concretely, how do you allow peer A and >>>> peer B to simultaneously do a GET_CHUNK for each other's data? >>> The process is asynchronous, so, there is no need to have permanent bilateral sessions. >> >> But HTTP is synchronous - if you in some way change HTTP to be >> asynchronous, one can easily assume that backwards compatibility with >> HTTP is broken. >> > I said that the PROCESS is asynchronous, not the protocol. >>>> Needing two HTTP connections to overcome the asymmetry means >>>> double trouble for NAT firewall traversal. Not only does a >>>> peer A need to connect to peer B, but B must also connect back >>>> to A. >>> You are right, but we are dealing with well known HTTP, and NAT/Firewall traversal is less problematic in terms of service availability or filtering rules. >> >> Not less problematic than a UDP based protocol designed to handle NAT >> and Firewall traversals without any filtering rules presumably. >> > Yes, same level of difficulty. > >> Regards, >> N > > Regards > Rui > > > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --------------060408000001010109030005 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,

I hope you don't mind if I add my 2c to the conversation. Since I've never expressed my thoughts here before, let me start with a quick intro: I'm Csaba Kiraly, working on the NAPA-WINE project, on the WineStreamer and PeerStreamer applications.

Let me first of all say that currently we use UDP. Not because TCP is bad or evil, but because it seems to be more suitable for our specific system goals and design. Our target is largely dynamic low delay streaming. These are the two parameters we are optimizing for, which seems to be rather different from the system Rui speaks about. As a consequence, our chunks are not seconds long but 1..5 frames (40..200 ms) long. Our p2p neighbourhood relations can be many and they can be short in time, passing only a small number of chunks.

Under these conditions, we can evaluate TCP vs. UDP as follows:

1, short-lived TCP connections are known to behave badly providing low average throughput. UDP doesn't have these problems, although you are expected to throw in some "TCP-friendliness". However, since TCP's solutions are not working well in this context, UDP might be a better starting point here.

2, large numbers of short-lived TCP connections are also known to behave badly for congestion control. Thus, you anyway need  some other congestion control mechanisms, which at that point can go over UDP as well.

3, even if a chunk is one frame, partial chunks can be useful. Maybe not re-propagated, but it can be used in local playout. UDP gives us this possibility, a short-lived TCP that stalls don't.

4, we do not need reliable delivery, at least not at the level that TCP provides. Actually, we don't even need it for signaling. If e.g. a chunk offer is lost, the peer will receive another one from someone else, etc.

5, UDP seems to be blocked by more firewalls than TCP. The main reason for this originally was the possible aggressiveness of UDP, but IMHO it has long been forgotten and it is simply applied as a system administration practice. This points in the direction of using
TCP.

Summarizing: for our system design, UDP seems a better fit.

About using HTTP+TCP vs. something+TCP: once TCP has been decided, there is the choice whether to use HTTP or design a custom protocol. Lets see some arguments pro and contra:

Reasons to use HTTP+TCP could be many:

1, the argument I hear the most is firewall traversal. There is no doubt it is true that today HTTP proxies are still dumb and thus systems can use HTTP+TCP as a backup connectivity solution, or even as their main connectivity solution. IMHO this will change as applications use more-and-more HTTP for sending their nasty traffic over the net.

2, libraries+integration: there are many HTTP libraries which makes it rather easy to create an HTTP based prototype

3, header fields (metadata): HTTP does provide some meta information in its headers, which are even extensible. This has some relevance in designing the protocol for the application (an extensible header mechanism is already available without designing one), and it also has some relevance to the proxies that try to understand/filter the traffic.

Reasons to use TCP with something else instead:

1, clearly, HTTP provides a restricted use of TCP. The model for bidirectional communication is much more restrictive than what would be allowed by TCP.

2, stability: although it doesn't seem like that, HTTP is a complex protocol. Many of the HTTP libraries have buggy or badly performing, or at least not well tested implementations of some of the less frequently used operation modes. Unfortunately, when you try to stretch the boundaries of HTTP, you happen to use these features, so libraries can easily become a pain instead of a help.

3, network overhead: A custom protocol can easily be designed with less overhead than TCP

4, processing overhead: many of the HTTP libraries are bloated, and indeed if one wants to support all the niche cases, it has to be quite heavy.

5, TCP sockets are not that difficult compared to all the code needed to set-up and tune a HTTP library correctly.

To summarize: if I would have to choose the one and only application layer protocol + transport protocol combo for a P2P application, today I would be forced to use HTTP simply for the reason of connectivity. With this choice, I seem to sacrifice low delay and some performance, but gain so many more possible clients that it seems to worth it. However, I don't think there is a need to chose one common denominator at such a high level in the protocol stack. I prefer to use something that performs better and use HTTP as a back-off.

regards,
Csaba

On 10/04/2011 10:58 PM, Rui Cruz wrote:
Hi
Hi,

On 4 October 2011 12:54, Rui Cruz <rui.cruz@ieee-pt.org> wrote:
On 04/10/2011, at 10:37, Arno Bakker <arno@cs.vu.nl> wrote:
the root of the problem is that HTTP is a client-server protocol.
Hence, IMHO it is unnatural to use it as a basis for a streaming
protocol where both parties must be able to request services from
the other independently.
Indeed, that is the point, they request services and data independently, not requiring a permanent session established.

But HTTP is a client-server protocol where the client sends a request
and the server replies with a reply.
Correct
 If this goes both ways (for two
peers to exchange data), you will either need two connections, go for
a half-duplex solution where one node must wait for the "http channel"
to be available or do nasty multiplexing of multiple HTTP sessions
over a single TCP connection.  Example:  Node A sends request for data
D1 to Node B, which starts sending D1 as a reply.  Node B now wants to
request data D4 from Node A, but can't mix a GET (or any other
request) into the data stream currently occupying the HTTP connection.
As I said, the time between requests for the same peers may be much larger than the RTT (the HTTP streaming segments have a much bigger size than RTP packets (considering a media segment with a duration of several seconds), and not all peers may have the required media data (in the case of SVC or stereoscopic MVC, not all layers/views of a media segment may be available at the same peer). As such, a peer requests to several peers the layers of a media segment in order to have the maximum quality (it enables a faster response to rate variations in the network). But similar reasoning can be done for for multiple bitrates of AVC, if we want the capability of adaptive streaming.
There are no nasty things done with HTTP, nor any need to multiplexing.
I for one have difficulties understanding why you would want to use an
extended HTTP protocol over just TCP, or even better, UDP combined
with a variety of congestion controls, and it does not seem possible
to me to create a clean system based on a full duplex HTTP connection.

There is no extended HTTP protocol. The proposed protocol facilitates coping with congestion by allowing on-the-fly adaptation, performed by adding or subtracting layers (in the case of SVC or MVC) or bitrates (in the case of multibitrate AVC) to match the capabilities of the network at every time instant.
In your proposal I don't see any mechanism
to deal with the asymmetry of HTTP, so I don't understand your
remark that your implementation only needs 1 TCP connection per
pair of peers.
One connection per pair of peers for the Request/Reply.

In other words, you go for a half-duplex 
No. Each peer serves the request from other peers, and makes request to other serving peers.

Concretely, how do you allow peer A and
peer B to simultaneously do a GET_CHUNK for each other's data?
The process is asynchronous, so, there is no need to have permanent bilateral sessions.

But HTTP is synchronous - if you in some way change HTTP to be
asynchronous, one can easily assume that backwards compatibility with
HTTP is broken.

I said that the PROCESS is asynchronous, not the protocol.
Needing two HTTP connections to overcome the asymmetry means
double trouble for NAT firewall traversal. Not only does a
peer A need to connect to peer B, but B must also connect back
to A.
You are right, but we are dealing with well known HTTP, and NAT/Firewall traversal is less problematic in terms of service availability or filtering rules.

Not less problematic than a UDP based protocol designed to handle NAT
and Firewall traversals without any filtering rules presumably.

Yes, same level of difficulty.

Regards,
N

Regards
Rui

_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp

--------------060408000001010109030005-- From mellia@tlc.polito.it Wed Oct 5 04:43:06 2011 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 1382221F8C1E for ; Wed, 5 Oct 2011 04:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.482 X-Spam-Level: X-Spam-Status: No, score=0.482 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_57=0.6] 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 OHOP92HFpkr3 for ; Wed, 5 Oct 2011 04:43:04 -0700 (PDT) Received: from mail.tlc.polito.it (baobab.polito.it [130.192.9.198]) by ietfa.amsl.com (Postfix) with SMTP id 4336E21F8BE4 for ; Wed, 5 Oct 2011 04:43:02 -0700 (PDT) Received: (qmail 25406 invoked by uid 88); 5 Oct 2011 11:45:54 -0000 Received: from gramigna.polito.it (HELO gramigna.polito.it) (130.192.9.144) (smtp-auth username mellia@tlc.polito.it, mechanism plain) by mail.tlc.polito.it (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPSA; Wed, 05 Oct 2011 13:45:54 +0200 Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_96D8D3FD-6A1B-414B-A078-2B7A2BE942EC" From: Marco Mellia In-Reply-To: <4E8C3264.2010707@disi.unitn.it> Date: Wed, 5 Oct 2011 13:45:53 +0200 Message-Id: <57A084D0-63E3-4859-9182-C1DAF6E009EC@tlc.polito.it> References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> <4E8C3264.2010707@disi.unitn.it> To: Csaba Kiraly X-Mailer: Apple Mail (2.1244.3) X-TLC-MailScanner-Information: Please contact the ISP for more information X-TLC-MailScanner: Found to be clean X-TLC-MailScanner-SpamCheck: not spam, SpamAssassin (score=-3.615, required 4, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.29, BAYES_00 -2.60, HTML_40_50 0.50, HTML_MESSAGE 0.00) X-TLC-MailScanner-From: mellia@tlc.polito.it Cc: ppsp@ietf.org Subject: Re: [ppsp] PPSP encoding 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, 05 Oct 2011 11:43:06 -0000 --Apple-Mail=_96D8D3FD-6A1B-414B-A078-2B7A2BE942EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ciao Csaba, Let me add some more though about the chunks size issue: Large chunks (several seconds) will definitively cause _long_ delay and = impair the real-time property of the stream. If a chunk has to travel K peers before being received, you have to pay = a "store&forward" delay at each hop/peer. So with chunks of 3s and = K=3D5-10 hops in the overlay, the delay will be in the order of 15-30s. = This without signaling/scheduling delay, and assuming an upload rate = similar to the video rate. In case upload capacity is smaller than the stream rate (as for low = speed peers), or in case the upload capacity is shared by the concurrent = transmission of several chunks (as it happens for TCP), the transmission = time of a large chunk will be much higher... Is that what you like? At the end, small chunks (40-200ms as Csaba is suggesting) allow to keep = the store&forward delay much smaller. Chunks of 40-200ms correspond to few packets. Thus, only UDP seems = reasonable here. It's not surprising the pretty much all p2p-tv software so far is = preferring UDP versus TCP... Said so, HTTP seems the worst solution. It's so bloated and cumbersome = to have HTTP to send 5 packets... --=20 Marco Mellia - Assistant Professor Dipartimento di Elettronica Politecnico di Torino Corso Duca Degli Abruzzi 24 10129 - Torino - IT Tel: +39-011-090-4173 Cel: +39-331-6714789 Skype: mgmellia http://www.tlc-networks.polito.it/mellia On Oct 5, 2011, at 12:33 PM, Csaba Kiraly wrote: > Hi, >=20 > I hope you don't mind if I add my 2c to the conversation. Since I've = never expressed my thoughts here before, let me start with a quick = intro: I'm Csaba Kiraly, working on the NAPA-WINE project, on the = WineStreamer and PeerStreamer applications. >=20 > Let me first of all say that currently we use UDP. Not because TCP is = bad or evil, but because it seems to be more suitable for our specific = system goals and design. Our target is largely dynamic low delay = streaming. These are the two parameters we are optimizing for, which = seems to be rather different from the system Rui speaks about. As a = consequence, our chunks are not seconds long but 1..5 frames (40..200 = ms) long. Our p2p neighbourhood relations can be many and they can be = short in time, passing only a small number of chunks. >=20 > Under these conditions, we can evaluate TCP vs. UDP as follows: >=20 > 1, short-lived TCP connections are known to behave badly providing low = average throughput. UDP doesn't have these problems, although you are = expected to throw in some "TCP-friendliness". However, since TCP's = solutions are not working well in this context, UDP might be a better = starting point here. >=20 > 2, large numbers of short-lived TCP connections are also known to = behave badly for congestion control. Thus, you anyway need some other = congestion control mechanisms, which at that point can go over UDP as = well. >=20 > 3, even if a chunk is one frame, partial chunks can be useful. Maybe = not re-propagated, but it can be used in local playout. UDP gives us = this possibility, a short-lived TCP that stalls don't. >=20 > 4, we do not need reliable delivery, at least not at the level that = TCP provides. Actually, we don't even need it for signaling. If e.g. a = chunk offer is lost, the peer will receive another one from someone = else, etc. >=20 > 5, UDP seems to be blocked by more firewalls than TCP. The main reason = for this originally was the possible aggressiveness of UDP, but IMHO it = has long been forgotten and it is simply applied as a system = administration practice. This points in the direction of using=20 > TCP. >=20 > Summarizing: for our system design, UDP seems a better fit. >=20 > About using HTTP+TCP vs. something+TCP: once TCP has been decided, = there is the choice whether to use HTTP or design a custom protocol. = Lets see some arguments pro and contra: >=20 > Reasons to use HTTP+TCP could be many: >=20 > 1, the argument I hear the most is firewall traversal. There is no = doubt it is true that today HTTP proxies are still dumb and thus systems = can use HTTP+TCP as a backup connectivity solution, or even as their = main connectivity solution. IMHO this will change as applications use = more-and-more HTTP for sending their nasty traffic over the net. >=20 > 2, libraries+integration: there are many HTTP libraries which makes it = rather easy to create an HTTP based prototype >=20 > 3, header fields (metadata): HTTP does provide some meta information = in its headers, which are even extensible. This has some relevance in = designing the protocol for the application (an extensible header = mechanism is already available without designing one), and it also has = some relevance to the proxies that try to understand/filter the traffic. >=20 > Reasons to use TCP with something else instead: >=20 > 1, clearly, HTTP provides a restricted use of TCP. The model for = bidirectional communication is much more restrictive than what would be = allowed by TCP. >=20 > 2, stability: although it doesn't seem like that, HTTP is a complex = protocol. Many of the HTTP libraries have buggy or badly performing, or = at least not well tested implementations of some of the less frequently = used operation modes. Unfortunately, when you try to stretch the = boundaries of HTTP, you happen to use these features, so libraries can = easily become a pain instead of a help. >=20 > 3, network overhead: A custom protocol can easily be designed with = less overhead than TCP >=20 > 4, processing overhead: many of the HTTP libraries are bloated, and = indeed if one wants to support all the niche cases, it has to be quite = heavy. >=20 > 5, TCP sockets are not that difficult compared to all the code needed = to set-up and tune a HTTP library correctly. >=20 > To summarize: if I would have to choose the one and only application = layer protocol + transport protocol combo for a P2P application, today I = would be forced to use HTTP simply for the reason of connectivity. With = this choice, I seem to sacrifice low delay and some performance, but = gain so many more possible clients that it seems to worth it. However, I = don't think there is a need to chose one common denominator at such a = high level in the protocol stack. I prefer to use something that = performs better and use HTTP as a back-off. >=20 > regards, > Csaba >=20 > On 10/04/2011 10:58 PM, Rui Cruz wrote: >>=20 >> Hi >>=20 >> On 04/10/2011, at 13:11, Njaal Borch wrote: >>=20 >>> Hi, >>>=20 >>> On 4 October 2011 12:54, Rui Cruz wrote: >>>> On 04/10/2011, at 10:37, Arno Bakker wrote: >>>>> the root of the problem is that HTTP is a client-server protocol. >>>>> Hence, IMHO it is unnatural to use it as a basis for a streaming >>>>> protocol where both parties must be able to request services from >>>>> the other independently. >>>> Indeed, that is the point, they request services and data = independently, not requiring a permanent session established. >>>=20 >>> But HTTP is a client-server protocol where the client sends a = request >>> and the server replies with a reply. >> Correct >>> If this goes both ways (for two >>> peers to exchange data), you will either need two connections, go = for >>> a half-duplex solution where one node must wait for the "http = channel" >>> to be available or do nasty multiplexing of multiple HTTP sessions >>> over a single TCP connection. Example: Node A sends request for = data >>> D1 to Node B, which starts sending D1 as a reply. Node B now wants = to >>> request data D4 from Node A, but can't mix a GET (or any other >>> request) into the data stream currently occupying the HTTP = connection. >> As I said, the time between requests for the same peers may be much = larger than the RTT (the HTTP streaming segments have a much bigger size = than RTP packets (considering a media segment with a duration of several = seconds), and not all peers may have the required media data (in the = case of SVC or stereoscopic MVC, not all layers/views of a media segment = may be available at the same peer). As such, a peer requests to several = peers the layers of a media segment in order to have the maximum quality = (it enables a faster response to rate variations in the network). But = similar reasoning can be done for for multiple bitrates of AVC, if we = want the capability of adaptive streaming. >> There are no nasty things done with HTTP, nor any need to = multiplexing. >>> I for one have difficulties understanding why you would want to use = an >>> extended HTTP protocol over just TCP, or even better, UDP combined >>> with a variety of congestion controls, and it does not seem possible >>> to me to create a clean system based on a full duplex HTTP = connection. >>>=20 >> There is no extended HTTP protocol. The proposed protocol facilitates = coping with congestion by allowing on-the-fly adaptation, performed by = adding or subtracting layers (in the case of SVC or MVC) or bitrates (in = the case of multibitrate AVC) to match the capabilities of the network = at every time instant. >>>>> In your proposal I don't see any mechanism >>>>> to deal with the asymmetry of HTTP, so I don't understand your >>>>> remark that your implementation only needs 1 TCP connection per >>>>> pair of peers. >>>> One connection per pair of peers for the Request/Reply. >>>=20 >>> In other words, you go for a half-duplex=20 >> No. Each peer serves the request from other peers, and makes request = to other serving peers. >>>=20 >>>>> Concretely, how do you allow peer A and >>>>> peer B to simultaneously do a GET_CHUNK for each other's data? >>>> The process is asynchronous, so, there is no need to have permanent = bilateral sessions. >>>=20 >>> But HTTP is synchronous - if you in some way change HTTP to be >>> asynchronous, one can easily assume that backwards compatibility = with >>> HTTP is broken. >>>=20 >> I said that the PROCESS is asynchronous, not the protocol. >>>>> Needing two HTTP connections to overcome the asymmetry means >>>>> double trouble for NAT firewall traversal. Not only does a >>>>> peer A need to connect to peer B, but B must also connect back >>>>> to A. >>>> You are right, but we are dealing with well known HTTP, and = NAT/Firewall traversal is less problematic in terms of service = availability or filtering rules. >>>=20 >>> Not less problematic than a UDP based protocol designed to handle = NAT >>> and Firewall traversals without any filtering rules presumably. >>>=20 >> Yes, same level of difficulty. >>=20 >>> Regards, >>> N >>=20 >> Regards >> Rui >>=20 >> _______________________________________________ >> ppsp mailing list >> ppsp@ietf.org >> https://www.ietf.org/mailman/listinfo/ppsp >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp --Apple-Mail=_96D8D3FD-6A1B-414B-A078-2B7A2BE942EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ciao = Csaba,

Let me add some more though about the chunks = size issue:

Large chunks (several seconds) will = definitively cause _long_ delay and impair the real-time property of the = stream.

If a chunk has to travel K peers = before being received, you have to pay a "store&forward" delay at = each hop/peer. So with chunks of 3s and K=3D5-10 hops in the = overlay, the delay will be in the order of 15-30s. This without = signaling/scheduling delay, and assuming an upload rate similar to = the video rate.

In case upload capacity is = smaller than the stream rate (as for low speed peers), or in case the = upload capacity is shared by the concurrent transmission of several = chunks (as it happens for TCP), the transmission time of a large = chunk will be much higher...
Is that what you = like?

At the end, small chunks (40-200ms as = Csaba is suggesting) allow to keep the store&forward delay much = smaller.
Chunks of 40-200ms correspond to few packets. Thus, = only UDP seems reasonable here.
It's not surprising the pretty = much all p2p-tv software so far is preferring UDP versus = TCP...

Said so, HTTP seems the worst solution. = It's so bloated and cumbersome to have HTTP to send 5 = packets...

-- 
Marco Mellia = - Assistant Professor
Dipartimento di = Elettronica
Politecnico di Torino
Corso Duca Degli = Abruzzi 24
10129 - Torino - IT
Tel: = +39-011-090-4173
Cel: +39-331-6714789
Skype: = mgmellia

On Oct 5, 2011, at 12:33 PM, Csaba Kiraly wrote:

=20 =20
Hi,

I hope you don't mind if I add my 2c to the conversation. Since I've never expressed my thoughts here before, let me start with a quick intro: I'm Csaba Kiraly, working on the NAPA-WINE project, on the WineStreamer and PeerStreamer applications.

Let me first of all say that currently we use UDP. Not because TCP is bad or evil, but because it seems to be more suitable for our specific system goals and design. Our target is largely dynamic low delay streaming. These are the two parameters we are optimizing for, which seems to be rather different from the system Rui speaks about. As a consequence, our chunks are not seconds long but 1..5 frames (40..200 ms) long. Our p2p neighbourhood relations can be many and they can be short in time, passing only a small number of = chunks.

Under these conditions, we can evaluate TCP vs. UDP as follows:

1, short-lived TCP connections are known to behave badly providing low average throughput. UDP doesn't have these problems, although you are expected to throw in some "TCP-friendliness". However, since TCP's solutions are not working well in this context, UDP might be a better starting point here.

2, large numbers of short-lived TCP connections are also known to behave badly for congestion control. Thus, you anyway need  = some other congestion control mechanisms, which at that point can go over UDP as well.

3, even if a chunk is one frame, partial chunks can be useful. Maybe not re-propagated, but it can be used in local playout. UDP gives us this possibility, a short-lived TCP that stalls don't.

4, we do not need reliable delivery, at least not at the level that TCP provides. Actually, we don't even need it for signaling. If e.g. a chunk offer is lost, the peer will receive another one from someone else, etc.

5, UDP seems to be blocked by more firewalls than TCP. The main reason for this originally was the possible aggressiveness of UDP, but IMHO it has long been forgotten and it is simply applied as a system administration practice. This points in the direction of using
TCP.

Summarizing: for our system design, UDP seems a better = fit.

About using HTTP+TCP vs. something+TCP: once TCP has been decided, there is the choice whether to use HTTP or design a custom protocol. Lets see some arguments pro and contra:

Reasons to use HTTP+TCP could be many:

1, the argument I hear the most is firewall traversal. There is no doubt it is true that today HTTP proxies are still dumb and thus systems can use HTTP+TCP as a backup connectivity solution, or even as their main connectivity solution. IMHO this will change as applications use more-and-more HTTP for sending their nasty traffic over the net.

2, libraries+integration: there are many HTTP libraries which makes it rather easy to create an HTTP based prototype

3, header fields (metadata): HTTP does provide some meta information in its headers, which are even extensible. This has some relevance in designing the protocol for the application (an extensible header mechanism is already available without designing one), and it also has some relevance to the proxies that try to understand/filter the traffic.

Reasons to use TCP with something else instead:

1, clearly, HTTP provides a restricted use of TCP. The model for bidirectional communication is much more restrictive than what would be allowed by TCP.

2, stability: although it doesn't seem like that, HTTP is a complex protocol. Many of the HTTP libraries have buggy or badly performing, or at least not well tested implementations of some of the less frequently used operation modes. Unfortunately, when you try to stretch the boundaries of HTTP, you happen to use these features, so libraries can easily become a pain instead of a help.

3, network overhead: A custom protocol can easily be designed with less overhead than TCP

4, processing overhead: many of the HTTP libraries are bloated, and indeed if one wants to support all the niche cases, it has to be quite heavy.

5, TCP sockets are not that difficult compared to all the code needed to set-up and tune a HTTP library correctly.

To summarize: if I would have to choose the one and only application layer protocol + transport protocol combo for a P2P application, today I would be forced to use HTTP simply for the reason of connectivity. With this choice, I seem to sacrifice low delay and some performance, but gain so many more possible clients that it seems to worth it. However, I don't think there is a need to chose one common denominator at such a high level in the protocol stack. I prefer to use something that performs better and use HTTP as a back-off.

regards,
Csaba

On 10/04/2011 10:58 PM, Rui Cruz wrote:
Hi

On 04/10/2011, at 13:11, Njaal Borch <njaal.borch@norut.no> wrote:

Hi,

On 4 October 2011 12:54, Rui Cruz <rui.cruz@ieee-pt.org> wrote:
On 04/10/2011, at 10:37, Arno Bakker <arno@cs.vu.nl> wrote:
the root of the problem is that HTTP is a client-server protocol.
Hence, IMHO it is unnatural = to use it as a basis for a streaming
protocol where both parties must be able to request services from
the other = independently.
Indeed, that is the point, = they request services and data independently, not requiring a permanent session established.

But HTTP is a client-server protocol where the client sends a request
and the server replies with a reply.
Correct
 If this goes both ways (for two
peers to exchange data), you will either need two connections, go for
a half-duplex solution where one node must wait for the "http channel"
to be available or do nasty multiplexing of multiple HTTP sessions
over a single TCP connection.  Example:  Node = A sends request for data
D1 to Node B, which starts sending D1 as a reply. =  Node B now wants to
request data D4 from Node A, but can't mix a GET (or any other
request) into the data stream currently occupying the HTTP connection.
As I said, the time between requests for the same peers may be much larger than the RTT (the HTTP streaming segments have a much bigger size than RTP = packets (considering a media segment with a duration of several seconds), and not all peers may have the required media data (in the case of SVC or stereoscopic MVC, not all layers/views of a media segment may be available at the same peer). As such, a peer requests to several peers the layers of a media segment in order to have the maximum quality (it enables a faster response to rate variations in the network). But similar reasoning can be done = for for multiple bitrates of AVC, if we want the capability of adaptive streaming.
There are no nasty things done with HTTP, nor any need to multiplexing.
I for one have difficulties understanding why you would want to use an
extended HTTP protocol over just TCP, or even better, UDP combined
with a variety of congestion controls, and it does not seem possible
to me to create a clean system based on a full duplex HTTP connection.

There is no extended HTTP protocol. The proposed protocol facilitates coping with congestion = by allowing on-the-fly adaptation, performed by adding or subtracting layers (in the case of SVC or MVC) or bitrates (in the case of multibitrate AVC) to match the capabilities of the network at every time instant.
In your proposal I don't = see any mechanism
to deal with the asymmetry of HTTP, so I don't understand your
remark that your implementation only needs 1 TCP connection = per
pair of peers.
One connection per pair of peers for the Request/Reply.

In other words, you go for a = half-duplex 
No. Each peer serves the request from other peers, and makes request to other serving peers.

Concretely, how do you = allow peer A and
peer B to simultaneously = do a GET_CHUNK for each other's data?
The process is asynchronous, so, there is no need to have permanent bilateral sessions.

But HTTP is synchronous - if you in some way change HTTP to be
asynchronous, one can easily assume that backwards compatibility with
HTTP is broken.

I said that the PROCESS is asynchronous, not the protocol.
Needing two HTTP = connections to overcome the asymmetry means
double trouble for NAT firewall traversal. Not only does a
peer A need to connect to peer B, but B must also connect back
to A.
You are right, but we are dealing with well known HTTP, and NAT/Firewall traversal is less problematic in terms of service availability or filtering rules.

Not less problematic than a UDP based protocol designed to handle NAT
and Firewall traversals without any filtering rules presumably.

Yes, same level of difficulty.

Regards,
N

Regards
Rui

_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/m=
ailman/listinfo/ppsp

_______________________________________________
ppsp mailing = list
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp

= --Apple-Mail=_96D8D3FD-6A1B-414B-A078-2B7A2BE942EC-- From a.bakker@vu.nl Thu Oct 6 00:37:24 2011 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 8AC2121F8B02 for ; Thu, 6 Oct 2011 00:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] 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 WeA37xDeh6Wr for ; Thu, 6 Oct 2011 00:37:24 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9EB21F8ABE for ; Thu, 6 Oct 2011 00:37:22 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 6 Oct 2011 09:40:32 +0200 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 6 Oct 2011 09:40:29 +0200 Message-ID: <4E8D5BAD.1030805@cs.vu.nl> Date: Thu, 6 Oct 2011 09:41:33 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: ppsp References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> <4E8AEAF8.4080102@cs.vu.nl> <71EDB0EE-431A-4DFF-A079-3BA51C0AA71F@ieee-pt.org> In-Reply-To: <71EDB0EE-431A-4DFF-A079-3BA51C0AA71F@ieee-pt.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] PPSP encoding X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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: Thu, 06 Oct 2011 07:37:24 -0000 On 04/10/2011 23:40, Rui Cruz wrote: >> does this mean you establish a new TCP connection for every >> request, i.e. do not use persistent connections? > We use TCP persistent connections for media transport. Hi for some reason we don't see to be on the same wavelength ;o) If peer A has chunk X that interest peer B and peer B has chunk Y that interest peer A in your system they will need to establish two HTTP connections, one from A to B to do GET_CHUNK Y and one from B to A to do GET_CHUNK X. > Due to its barter nature TFT is not adequate for media streaming. Even > worse for the case of Live streaming. > What do you use for preventing freeriding instead? > Peers do need need to announce via a gossip type protocol the > chunks/segments they just got. > It is the interested peer that requests chunkmap updates to the other > peers in order to decide which of them have the adequate data, as the > streaming mode is not bitstream (media data is not transported in single > packets, but in small segments containing a set of media access units). > Can you elaborate a bit more on how this process works? The above suggests you may have to query multiple peers before finding the chunk you want? Doesn't that cause delays? > You are reasoning on a single quality, single bitrate media streaming. No, I'm not actually. This is irrespective of single, SVC or MDC. It is about whether the transport layer takes care of reliability (TCP) or that you handle reliability in the application layer (i.e. PPSP) where you have more flexibility. In particular, in this case in the application layer we have multiple sources are available for rerequesting lost data, as also remarked by Csaba Kiraly. Regards, Arno From a.bakker@vu.nl Thu Oct 6 00:40:19 2011 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 CD32321F8B70 for ; Thu, 6 Oct 2011 00:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.983 X-Spam-Level: X-Spam-Status: No, score=-3.983 tagged_above=-999 required=5 tests=[AWL=0.521, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] 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 avofd5s0cvIo for ; Thu, 6 Oct 2011 00:40:19 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF0521F8B6E for ; Thu, 6 Oct 2011 00:40:19 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 6 Oct 2011 09:43:27 +0200 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Thu, 6 Oct 2011 09:43:28 +0200 Message-ID: <4E8D5C60.7030207@cs.vu.nl> Date: Thu, 6 Oct 2011 09:44:32 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: ppsp References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> <4E8AEAF8.4080102@cs.vu.nl> <71EDB0EE-431A-4DFF-A079-3BA51C0AA71F@ieee-pt.org> In-Reply-To: <71EDB0EE-431A-4DFF-A079-3BA51C0AA71F@ieee-pt.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] PPSP encoding X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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: Thu, 06 Oct 2011 07:40:19 -0000 Rui Cruz wrote: > We use TCP persistent connections for media transport. > Forgot a remark: Or do you mean that the situation in which peer A and B have interest in each other's chunks does not occur frequently? Regards, Arno From rui.cruz@ieee-pt.org Thu Oct 6 01:59:34 2011 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 E44E821F8C70 for ; Thu, 6 Oct 2011 01:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 6UR1HVPe8F+N for ; Thu, 6 Oct 2011 01:59:34 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id C381421F8C67 for ; Thu, 6 Oct 2011 01:59:33 -0700 (PDT) Received: by eye22 with SMTP id 22so1253601eye.31 for ; Thu, 06 Oct 2011 02:02:43 -0700 (PDT) Received: by 10.223.58.138 with SMTP id g10mr2291025fah.20.1317891763348; Thu, 06 Oct 2011 02:02:43 -0700 (PDT) Received: from [192.168.0.126] (slc1.geol.agh.edu.pl. [149.156.104.2]) by mx.google.com with ESMTPS id l8sm6218124fai.16.2011.10.06.02.02.42 (version=SSLv3 cipher=OTHER); Thu, 06 Oct 2011 02:02:42 -0700 (PDT) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_52AB9962-279D-4C48-9FFD-002712743A5B" From: Rui Cruz In-Reply-To: <4E8D5C60.7030207@cs.vu.nl> Date: Thu, 6 Oct 2011 11:02:43 +0200 Message-Id: References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> <4E8AEAF8.4080102@cs.vu.nl> <71EDB0EE-431A-4DFF-A079-3BA51C0AA71F@ieee-pt.org> <4E8D5C60.7030207@cs.vu.nl> To: arno@cs.vu.nl X-Mailer: Apple Mail (2.1244.3) Cc: Rui Cruz , ppsp Subject: Re: [ppsp] PPSP encoding 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: Thu, 06 Oct 2011 08:59:35 -0000 --Apple-Mail=_52AB9962-279D-4C48-9FFD-002712743A5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 06/10/2011, at 09:44, Arno Bakker wrote: > Rui Cruz wrote: >> We use TCP persistent connections for media transport. >>=20 >=20 > Forgot a remark: Or do you mean that the situation in which peer A and = B have interest in each other's chunks does not occur frequently? >=20 Requests between peer A and peer B may overlap during a short time = interval, but they may be for different purposes like signaling and = media transfer and the connections started and released in different = moments. > Regards, > Arno > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp Regards, Rui Cruz --Apple-Mail=_52AB9962-279D-4C48-9FFD-002712743A5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Rui = Cruz wrote:
We use TCP persistent = connections for media transport.


Forgot a remark: Or do you mean that = the situation in which peer A and B have interest in each other's chunks = does not occur frequently?

Requests between = peer A and peer B may overlap during a short time interval, but = they may be for different purposes like  signaling and media = transfer and the connections started and released in different = moments.

Regards,
=    Arno
_______________________________________________<= br>ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp

In-Reply-To: <4E8D5BAD.1030805@cs.vu.nl> Date: Thu, 6 Oct 2011 12:07:23 +0200 Message-Id: <8ADE31B1-54C3-4D12-9FC1-FA27785E48FA@ieee.org> References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> <4E8AEAF8.4080102@cs.vu.nl> <71EDB0EE-431A-4DFF-A079-3BA51C0AA71F@ieee-pt.org> <4E8D5BAD.1030805@cs.vu.nl> To: arno@cs.vu.nl X-Mailer: Apple Mail (2.1244.3) Cc: Rui Cruz , ppsp Subject: Re: [ppsp] PPSP encoding 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: Thu, 06 Oct 2011 10:04:17 -0000 --Apple-Mail=_08E15ADD-A096-4355-90E2-4B7D7A17D422 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 06/10/2011, at 09:41, Arno Bakker wrote: > On 04/10/2011 23:40, Rui Cruz wrote: >>> does this mean you establish a new TCP connection for every >>> request, i.e. do not use persistent connections? >> We use TCP persistent connections for media transport. >=20 > Hi >=20 > for some reason we don't see to be on the same wavelength ;o) > If peer A has chunk X that interest peer B and peer B has > chunk Y that interest peer A in your system they will need > to establish two HTTP connections, one from A to B to > do GET_CHUNK Y and one from B to A to do GET_CHUNK X. >=20 For both media data transfer and signaling, it may happen indeed. >=20 >> Due to its barter nature TFT is not adequate for media streaming. = Even >> worse for the case of Live streaming. >>=20 >=20 > What do you use for preventing freeriding instead? >=20 Depending on the streaming mode (Live, Time-shifted/VoD) and scenarios = (related with "business models", namely those being worked within the EU = FP7 SARACEN Project), different schemes can be applied and are currently = under development in that project. For PPSP it is important the = contextual awareness of the incentive scheme to use (for scheduling and = control), although the development of these schemes is not in the PPSP = charter.=20 >> Peers do need need to announce via a gossip type protocol the >> chunks/segments they just got. >> It is the interested peer that requests chunkmap updates to the other >> peers in order to decide which of them have the adequate data, as the >> streaming mode is not bitstream (media data is not transported in = single >> packets, but in small segments containing a set of media access = units). >>=20 >=20 > Can you elaborate a bit more on how this process works? The above = suggests you may have to query multiple peers before finding the > chunk you want? Doesn't that cause delays? Depending on the streaming method the chunk availability exchange = between peers also differs. The Tracker plays a role in the peer = selection process, contributing to the "optimization" of the neighbor = set for a certain peer, which will then request the current chunkmaps = from a subset of that neighbor set. The process is quite fast as the = interested peer just filters from the chunkmaps the chunks available = within the current time-window. The next updates of the chunkmaps will = happen in case of missing chunks of future time-windows (eventually = several seconds after the last update). For Live streaming, the Media Presentation Description (content = manifest/index) plays an important role, as the file is being updated = while the media is being released (encoded) for streaming. =20 >=20 >=20 >> You are reasoning on a single quality, single bitrate media = streaming. >=20 > No, I'm not actually. This is irrespective of single, SVC or MDC. It = is > about whether the transport layer takes care of reliability (TCP) or = that you handle reliability in the application layer (i.e. PPSP) where > you have more flexibility. In particular, in this case in the > application layer we have multiple sources are available for > rerequesting lost data, as also remarked by Csaba Kiraly. >=20 > Regards, > Arno >=20 >=20 > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp Regards, Rui Cruz --Apple-Mail=_08E15ADD-A096-4355-90E2-4B7D7A17D422 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = 04/10/2011 23:40, Rui Cruz wrote:
does this mean you establish a new TCP connection for = every
request, i.e. do not use persistent = connections?
We = use TCP persistent connections for media = transport.

Hi

for some reason we don't see to = be on the same wavelength ;o)
If peer A has chunk X that interest = peer B and peer B has
chunk Y that interest peer A in your system = they will need
to establish two HTTP connections, one from A to B = to
do GET_CHUNK Y and one from B to A to do GET_CHUNK = X.

For both media data transfer and signaling, = it may happen indeed.

Due to its barter nature TFT is not adequate for media = streaming. Even
worse for the = case of Live streaming.


What do you use for preventing = freeriding instead?

Depending on the streaming = mode (Live, Time-shifted/VoD) and scenarios (related with "business = models", namely those being worked within the EU FP7 SARACEN Project), = different schemes can be applied and are currently under development in = that project. For PPSP it is important the contextual awareness of the = incentive scheme to use (for scheduling and control), although the = development of these schemes is not in the PPSP = charter. 

Peers do need need to announce via a gossip type protocol = the
chunks/segments they just = got.
It is the interested peer = that requests chunkmap updates to the other
peers in order to decide which of them have the adequate = data, as the
streaming mode is = not bitstream (media data is not transported in = single
packets, but in small = segments containing a set of media access = units).


Can= you elaborate a bit more on how this process works? The above suggests = you may have to query multiple peers before finding the
chunk you = want? Doesn't that cause delays?
Depending on the = streaming method the chunk availability exchange between peers also = differs. The Tracker plays a role in the peer selection process, = contributing to the "optimization" of the neighbor set for a certain = peer, which will then request the current chunkmaps from a subset of = that neighbor set. The process is quite fast as the interested peer just = filters from the chunkmaps the chunks available within the current = time-window. The next updates of the chunkmaps will happen in case of = missing chunks of future time-windows (eventually several seconds after = the last update).
For Live streaming, the Media Presentation = Description (content manifest/index) plays an important role, as the = file is being updated while the media is being released (encoded) for = streaming.   


You are reasoning = on a single quality, single bitrate media = streaming.

No, I'm not actually. This is = irrespective of single, SVC or MDC. It is
about whether the transport = layer takes care of reliability (TCP) or that you handle reliability in = the application layer (i.e. PPSP) where
you have more flexibility. In = particular, in this case in the
application layer we have multiple = sources are available for
rerequesting lost data, as also remarked by = Csaba Kiraly.

Regards,
=    Arno


________________________________________= _______
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ppsp

Thread-Topic: Nomcom 2011-2012: Second Call for Nominations Thread-Index: Acx1p83SvuomhflHTD2ovtWk+fc/jgN/WS9gACIHJ6A= Date: Thu, 6 Oct 2011 13:40:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.202] Content-Type: multipart/mixed; boundary="_002_E84E7B8FF3F2314DA16E48EC89AB49F01CFA5175DAPHNISofficehd_" MIME-Version: 1.0 Subject: [ppsp] FW: Nomcom 2011-2012: Second Call for Nominations 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: Thu, 06 Oct 2011 13:37:33 -0000 --_002_E84E7B8FF3F2314DA16E48EC89AB49F01CFA5175DAPHNISofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Please consider to nominate people -- see below. The deadline is passed, bu= t it seems that the nomination is still open. Please do also go and give feedback about the candidates, as this input is = required by the NOMCOM. Kind regards, Martin > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair > Sent: Saturday, September 17, 2011 10:06 PM > To: IETF Announcement list > Cc: ietf@ietf.org > Subject: Nomcom 2011-2012: Second Call for Nominations >=20 > Hi All, >=20 > We are halfway through the nomination period (it ends on October > 2, 2011) and we need more nominees than we have received so > far. We appreciate the folks that have taken the time to nominate > people and those who have accepted so far. But the fact remains > that the number of nominations have been below average and the > acceptance rates of those nominated has also been low. >=20 > We need **YOUR** input and participation! We cannot properly > execute the task of selecting the best candidates for these > positions with so few nominations and acceptances. So, please > consider making nominations for the open positions, in particular > those for which we have so few nominations it takes just a few > minutes of your time. Right now, we just need the names/email > addresses. >=20 > Why do we need more nominations? Well, even if you think a > willing incumbent is doing a very good job and should be > returned, his or her ability to serve again might be impacted by > unforeseen circumstances between now and March. NomCom needs to > consider multiple nominees to be prepared in the event one or > more candidates is unable to serve come next March and to ensure > we have chosen the best candidate. >=20 > There are several ways you can help the Nomcom >=20 > - You can nominate yourself. > - You can nominate someone you know whom you think would do a > good job. >=20 > Don't worry about whether they might already be nominated. We > would much prefer to receive the same nomination several times > rather than miss a good person we should consider. >=20 > How to submit Nominations: > -------------------------- >=20 > The list of positions we need to fill, and the provided Job > Descriptions, and forms for nominations, can be found in the call > for nominations at: >=20 > https://datatracker.ietf.org/ann/nomcom/3049/ >=20 > You can enter a nomination by going to the following URL: >=20 > https://www.ietf.org/group/nomcom/2011/nominate >=20 > You can also nominate someone by sending an email to > nomcom11@ietf.org and giving us their name, email address and the > open position you are nominating them for. We will take care of > the rest. >=20 > If you are asked for a user name and password, use an existing > ietf login and password. If you need a login and password, > request one from the following URL: >=20 > https://datatracker.ietf.org/accounts/create/ >=20 >=20 > Open List: > ---------- >=20 > As you already know, NomCom 2011-2012 will follow the policy > for "Open Disclosure of Willing Nominees" described in RFC 5680. >=20 > Feedback Collection: > -------------------- >=20 > The open list is currently available on the Nomcom page and the > entire community is invited to provide feedback on all nominees. > You can provide your comments on all willing nominees at the > following URL: >=20 > https://www.ietf.org/group/nomcom/2011/input/ >=20 > Suresh Krishnan > Chair, NomCom 2011-2012 > nomcom-chair@ietf.org > suresh.krishnan@ericsson.com martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 --_002_E84E7B8FF3F2314DA16E48EC89AB49F01CFA5175DAPHNISofficehd_ Content-Type: text/plain; name="ATT00483.txt" Content-Description: ATT00483.txt Content-Disposition: attachment; filename="ATT00483.txt"; size=154; creation-date="Wed, 05 Oct 2011 21:26:29 GMT"; modification-date="Wed, 05 Oct 2011 21:26:29 GMT" Content-ID: <40F98E7297C11B41A1EE869EA56630A1@office.hd> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklFVEYtQW5u b3VuY2UgbWFpbGluZyBsaXN0DQpJRVRGLUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCg== --_002_E84E7B8FF3F2314DA16E48EC89AB49F01CFA5175DAPHNISofficehd_-- From Martin.Stiemerling@neclab.eu Thu Oct 6 23:36:53 2011 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 8CC2121F84DC for ; Thu, 6 Oct 2011 23:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.907 X-Spam-Level: X-Spam-Status: No, score=-101.907 tagged_above=-999 required=5 tests=[AWL=0.692, BAYES_00=-2.599, 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 8+UEzpD9x3vo for ; Thu, 6 Oct 2011 23:36:52 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2C54B21F8B38 for ; Thu, 6 Oct 2011 23:36:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 55E83280001AB; Fri, 7 Oct 2011 08:40:03 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnfXL+vVd+BK; Fri, 7 Oct 2011 08:40:03 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 34A9B280001A7; Fri, 7 Oct 2011 08:39:53 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.240]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 7 Oct 2011 08:39:52 +0200 From: Martin Stiemerling To: "arno@cs.vu.nl" , "ppsp@ietf.org" Thread-Topic: [ppsp] Draft meeting minutes PPSP virtual interim meeting (Sept. 28th 2011) Thread-Index: AQHMgoRYYbCoJ6e42kSUk3LwBsbXRZVwcTqQ Date: Fri, 7 Oct 2011 06:39:53 +0000 Message-ID: References: <4E8AE6A6.7080903@cs.vu.nl> In-Reply-To: <4E8AE6A6.7080903@cs.vu.nl> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ppsp] Draft meeting minutes PPSP virtual interim meeting (Sept. 28th 2011) 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: Fri, 07 Oct 2011 06:36:53 -0000 Hi Arno, all,=20 Thanks for the corrections. Fixed.=20 Attached is the updated version which will be sent out to the proceedings p= eople to publish them.=20 However, you can still send your comments about the correct version until t= oday, Oct 7th, 3pm CEST.=20 Thanks, Martin IETF PPSP working group Charter: http://datatracker.ietf.org/wg/ppsp/charter/ Chairs: Martin Stiemerling Yunfei Zhang Meeting minutes of the virtual interim meeting, held September 28th, 2011 The meeting was held via the Webex online meeting facility at http://www.webex.com Presented slides are temporally available here, until December 2011: http://www.stiemerling.org/ietf/ppsp/20110928-ppsp-virtual-interim-slides.z= ip Start time: 2:00pm CEST End time: 4:20 pm CEST ** Final Agenda * Agenda bashing * Chair's introduction on PPSP progress * Tracker Protocol and discussion current candidates: http://datatracker.ietf.org/doc/draft-cruz-ppsp-http-tracker-protocol/ http://datatracker.ietf.org/doc/draft-gu-ppsp-tracker-protocol/ * Peer protocol and discussion current candidates: http://datatracker.ietf.org/doc/draft-gu-ppsp-peer-protocol/ http://datatracker.ietf.org/doc/draft-cruz-ppsp-http-peer-protocol/ http://datatracker.ietf.org/doc/draft-grishchenko-ppsp-swift/ * Trails/Interop discussions * Conclusion and next steps =20 **Meeting Minutes Note taker: Martin Stiemerling NB: minutes in <> are added by the note taker or raise missing or unclear parts. The virtual interim meeting started at 2pm CEST.=20 The co-chairs Yunfei Zhang [YZ] and Martin Stiemerling [MS] started the PPS= P virtual interim with the agenda bashing.=20 Johan Pouwelse [JP] asked if the peer protocol slot can also include a shor= t intro about draft-grishchenko-ppsp-swift and if there is time to discuss fu= ture PPSP trails. =20 [MS] The peer protocol slot is for all peer protocols to be discussed and t= here is time to disucss trials.=20 [MS] Short review of the current status of the PPSP WG.=20 [MS] When shall we start with the WGLC for the draft draft-ietf-ppsp-survey before the next IETF meeting or after? Yingjie Gu[YG] Prefer to have it after the IETF meeting. [MS] Will do the WGLC for the draft draft-ietf-ppsp-survey after the IETF#= 82 meeting and will use the time before the meeting to work on the protocols.= =20 * Tracker Protocol and discussion [YG] presented the current status of draft-gu-ppsp-tracker-protocol. [MS] Is draft-gu-ppsp-tracker-protocol already merged with draft-cruz-ppsp-http-tracker-protocol? [YG] No, not yet. Arno Bakker [AB] HTTP is not bidirectional, server cannot send to client wi= thout receiving a request. [YG] STAT_QUERY required for clients Note: There was a longer discussion about if STAT_QUERY is needed and how i= t would be implemented. It was stated that the current HTTP spec does not s= upport this mode of operation yet, but on the other hand, some p2p systems = may need the semantics of STAT_QUERY. This needs to be discussed further on= the list.=20 Rui Cruz[RC] raised a question about the chunk availability on slide 5 of t= he tracker slides (20110928-ppsp-virtual-interim-PPSP-Tracker-Protocol). This lead to the discuss how smart a PPSP tracker should be or if a rather = simple tracker would be sufficient.=20 [AB] why do you not need to learn about new peers? [YG] This is what KEEPALIVE is doing.=20 [RC] Seconds [AB] and adds that the meaning of the message is changed.=20 [MS] Question about whether the XML encoding has been corrected. [YG] XML encoding was revised. [AB] What is the role of the certificates in the messages? Why not using HT= TPS? [YG] =20 [RC] Wouldn't it reasonable to use authentication tokens? [MS] Use HTTPS standard solution, otherwise hard to built and to get throug= h the standards process.=20 Marc Stuart [MaSt] 2 sides discussed here: open tracker, or closed and over= - engineered tracker. Marc supports a more simple tracker protocol. [MS] will continue this simple vs. smart tracker to the mailing list. * Peer protocol and discussion The discussion started about whether the media transport protocol should be part of the peer protocol or not, as the charter states "The first task for this WG will be to decide which signaling and media transfer protocols will= be used. The WG will consider existing protocols and, if needed, identify potential extensions to these protocols." and "PPSP is not chartered to wor= k on media transmission protocols". However, it should be noted that this does n= ot rule out that the WG has to consider what the media transmission protocols = are. [MS] do you have an implementation of draft-gu-ppsp-peer-protocol? [YG] used to have an experimental implementation, but not the same as the one in draft-gu-ppsp-peer-protocol.=20 [AB] What about the encoding of IP addresses? Right now only IPv4 addresses= are specified, IPv6 is missing.=20 [YG] Should consider this, no time yet.=20 [RC] What was the reason to change to a binary encoding? We use HTTP for signaling and media transport. Goes towards DASH.=20 [MS] HTTP is causing too much overhead. [YZ] In HTTP there is a server, in p2p there is no client/sever mode. HTTP = is not suitable, i.e., different from DASH. [RC] We have implemented it and it works well. [JP] No reason for HTTP if you want efficiency. strongly in favor of binary= . HTTP can be used as fallback, but this seems to be outside of PPSP. [MS] Need to take this the mailing list to discuss the details. [JP] Gave an update about draft-grishchenko-ppsp-swift. [MS] draft-grishchenko-ppsp-swift should be casted in more IETF style. [AB] What is people's preference was, based on their own use cases in terms of media transport, e.g., a RTP extension or raw UDP? -----Original Message----- > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > Arno Bakker > Sent: Tuesday, October 04, 2011 12:58 PM > To: ppsp@ietf.org > Subject: Re: [ppsp] Draft meeting minutes PPSP virtual interim meeting (S= ept. > 28th 2011) >=20 > On 04/10/2011 11:50, Martin Stiemerling wrote: > > > > * Peer protocol and discussion > > The discussion started about whether the media transport protocol shoul= d be > > part of the peer protocol or not, as the charter states "PPSP is not ch= artered > > to work on media transmission protocols". However, it should be noted t= hat > > this does not rule out that the WG has to consider what the media > transmission > > protocols are. > > >=20 > Hi >=20 > sorry to repeat this again, but just above this statement the charter > says "The first task for this WG will be to decide which signaling and > media transfer protocols will be used. The WG will consider existing > protocols and, if needed, identify potential extensions to these > protocols." So extensions are definitely in the scope. >=20 > > [AB] What means media transport: RTP extension or raw UDP? >=20 > My question was what people's preference was, based on their > own use cases. >=20 > Regards, > Arno > _______________________________________________ > ppsp mailing list > ppsp@ietf.org > https://www.ietf.org/mailman/listinfo/ppsp martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 From Martin.Stiemerling@neclab.eu Fri Oct 7 06:32:25 2011 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 98E4C21F8AB0 for ; Fri, 7 Oct 2011 06:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.921 X-Spam-Level: X-Spam-Status: No, score=-101.921 tagged_above=-999 required=5 tests=[AWL=0.678, BAYES_00=-2.599, 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 7WNAM1IpfiXp for ; Fri, 7 Oct 2011 06:32:25 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id F16D421F88B7 for ; Fri, 7 Oct 2011 06:32:24 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4585D280001AC for ; Fri, 7 Oct 2011 15:35:38 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwnfhTb-otUY for ; Fri, 7 Oct 2011 15:35:38 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 2963F280001A7 for ; Fri, 7 Oct 2011 15:35:33 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.240]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 7 Oct 2011 15:35:33 +0200 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: Proceedings of the PPSP virtual interim meeting (Sept 2011) available Thread-Index: AcyE9egNB67LhzasQQmzTlPjVswawA== Date: Fri, 7 Oct 2011 13:35:32 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.1.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] Proceedings of the PPSP virtual interim meeting (Sept 2011) available 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: Fri, 07 Oct 2011 13:32:25 -0000 Hi, The proceedings of the PPSP virtual interim meeting (Sept 2011) available h= ere: http://www.ietf.org/proceedings/interim/2011/09/28/ppsp/proceedings.html Have a nice weekend Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From zongning@huawei.com Sat Oct 8 02:20:27 2011 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 BFED621F8A58 for ; Sat, 8 Oct 2011 02:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.889 X-Spam-Level: X-Spam-Status: No, score=-103.889 tagged_above=-999 required=5 tests=[AWL=2.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 0bgYwdZ-wehS for ; Sat, 8 Oct 2011 02:20:25 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BB5FF21F8A4B for ; Sat, 8 Oct 2011 02:20:24 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSQ00LLKQ14A5@szxga04-in.huawei.com> for ppsp@ietf.org; Sat, 08 Oct 2011 17:22:17 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSQ003E1Q147N@szxga04-in.huawei.com> for ppsp@ietf.org; Sat, 08 Oct 2011 17:22:16 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEH81287; Sat, 08 Oct 2011 17:21:43 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 08 Oct 2011 17:21:34 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.252]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Sat, 08 Oct 2011 17:21:33 +0800 Date: Sat, 08 Oct 2011 09:21:31 +0000 From: ZongNing X-Originating-IP: [10.138.41.128] To: "ppsp@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_0Xs3TzZG5ZOmzLVVUG+8Og)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-ietf-ppsp-reqs-05.txt Thread-index: AQHMhZtV2i+Nvd7F8EeGqkB6FPqdu5VyK5Ig X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [ppsp] FW: New Version Notification for draft-ietf-ppsp-reqs-05.txt 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, 08 Oct 2011 09:20:28 -0000 --Boundary_(ID_0Xs3TzZG5ZOmzLVVUG+8Og) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT Hi, Folks, A new revision of PPSP requirements has been submitted (see attached draft-ietf-ppsp-reqs-05.txt). Comments are welcome. Thanks. BR, Ning Zong -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Saturday, October 08, 2011 5:16 PM To: ZongNing Cc: lin.xiao@nsn.com; vpascual@acmepacket.com; zhangyunfei@chinamobile.com; carlw@mcsr-labs.org; ZongNing Subject: New Version Notification for draft-ietf-ppsp-reqs-05.txt A new version of I-D, draft-ietf-ppsp-reqs-05.txt has been successfully submitted by Ning Zong and posted to the IETF repository. Filename: draft-ietf-ppsp-reqs Revision: 05 Title: P2P Streaming Protocol (PPSP) Requirements Creation date: 2011-10-08 WG ID: ppsp Number of pages: 14 Abstract: The objective of the PPSP work is to standardize the key signaling protocols that apply to tracker and peers in a Peer-to-Peer (P2P) streaming system. These protocols are called PPSP. This document enumerates the requirements for the PPSP, which should be considered when designing PPSP. The IETF Secretariat --Boundary_(ID_0Xs3TzZG5ZOmzLVVUG+8Og) Content-type: text/plain; name=draft-ietf-ppsp-reqs-05.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-ietf-ppsp-reqs-05.txt; size=27871; creation-date="Sat, 08 Oct 2011 03:44:12 GMT"; modification-date="Sat, 08 Oct 2011 05:40:39 GMT" Content-description: draft-ietf-ppsp-reqs-05.txt PPSP N. Zong, Ed. Internet-Draft Huawei Technologies Intended status: Informational Y. Zhang Expires: April 10, 2012 China Mobile Communication Corporation V. Pascual Acme Packet C. Williams Consultant L. Xiao Nokia Siemens Networks October 08, 2011 P2P Streaming Protocol (PPSP) Requirements draft-ietf-ppsp-reqs-05 Abstract The objective of the PPSP work is to standardize the key signaling protocols that apply to tracker and peers in a Peer-to-Peer (P2P) streaming system. These protocols are called PPSP. This document enumerates the requirements for the PPSP, which should be considered when designing PPSP. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 10, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Zong, et al. Expires April 10, 2012 [Page 1] Internet-Draft PPSP Requirements October 2011 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Zong, et al. Expires April 10, 2012 [Page 2] Internet-Draft PPSP Requirements October 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of PPSP . . . . . . . . . . . . . . . . . . . . . . . 5 4. PPSP Requirements . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 6 4.2. PPSP Tracker Protocol Requirements . . . . . . . . . . . . 8 4.3. PPSP Peer Protocol Requirements . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Zong, et al. Expires April 10, 2012 [Page 3] Internet-Draft PPSP Requirements October 2011 1. Introduction Peer to Peer (P2P) computing has been successfully used in many fields, from one-to-one communication like Voice over IP (VoIP) and Instance Messaging (IM), to one-to-many communication like streaming, file sharing and gaming. In the streaming area, the popularity of P2P real-time and video on demand (VoD) streaming technology has been demonstrated by PPLive [PPLive], PPStream [PPStream], UUSee [UUSee], Pando [Pando] etc. Take PPLive for example, it has over 5 million online users at the same time for real-time streaming. P2P streaming applications account for more and more Internet traffic. According to statistics in a major Chinese Internet Service Provider (ISP), the traffic generated by P2P streaming applications exceeded 50% of the total backbone traffic during peak time in 2008 [I-D.ietf-ppsp-problem-statement]. Given the increasing integration of P2P streaming into the global content delivery infrastructure, the lack of an open, standard P2P streaming protocol has become a major missing component in the Internet protocol stack. Multiple similar but proprietary P2P streaming protocols result in repetitious development efforts and lock-in effects. More importantly, it leads to substantial difficulties when integrating P2P streaming as a component of a global content delivery infrastructure. For example, proprietary P2P streaming protocols do not integrate well with infrastructure devices such as caches and other edge devices [I-D.ietf-ppsp-problem-statement]. The objective of the PPSP work is to standardize the key signaling protocols that apply to tracker and peers in a P2P streaming system. These protocols are called PPSP. PPSP will serve as an enabling technology, building on the development experiences of existing P2P streaming systems. Its design will allow it to integrate with IETF efforts on distributed resource location, traffic localization, and streaming control mechanisms. It allows effective integration with edge infrastructures such as cache and mobile edge equipment [I-D.ietf-ppsp-problem-statement]. This document enumerates the requirements for the PPSP, which should be considered when designing PPSP. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. Zong, et al. Expires April 10, 2012 [Page 4] Internet-Draft PPSP Requirements October 2011 This document uses the following PPSP-related terms, which are defined in [I-D.ietf-ppsp-problem-statement], including: Chunk, Live streaming, Peer/PPSP peer, PPSP, Swarm, Tracker/PPSP tracker, Video-on-demand (VoD). Furthermore, the following additional terms will be used: Peer list: A list of peers which are in a same swarm maintained by the tracker. A peer can fetch the peer list of a swarm from either tracker or other peers to know which peers have the required streaming content. Peer ID: An identifier of a peer such that other peers or tracker can refer the ID for the peer. Swarm ID: An identifier of a swarm containing a group of peers sharing a same streaming content. Chunk ID: An identifier of a chunk in a streaming content. 3. Overview of PPSP As described in [I-D.ietf-ppsp-problem-statement], the following components are considered in the scope of PPSP: 1) Tracker communication. Tracker communication is a component that enables each peer to get peer list from the tracker and/or provide content availability to the tracker. 2) Peer communication. Peer communication is a component that enables each peer to exchange content availability and request content from other peers. 3) Report. Report is a component that enables peers to report streaming status to the tracker. The information may include swarm IDs to show swarms that the peer is taking active part in, chunk list for each swarm to show the current content availability in the peer, inbound/outbound traffic capacity, amount of neighbor peers, peer health degree, total amount of bytes uploaded/downloaded to neighbour peers, and other streaming parameters. Therefore, PPSP includes the PPSP tracker protocol - a signaling protocol between PPSP trackers and PPSP peers, and the PPSP peer protocol - a signaling protocol among PPSP peers. PPSP tracker protocol will define: Zong, et al. Expires April 10, 2012 [Page 5] Internet-Draft PPSP Requirements October 2011 1) Standard format/encoding of information between PPSP peers and PPSP tracker. Some of this exchanged information may be explicitly marked as optional. Exchanged information may include peer list, swarm ID, chunk information, content availability, streaming status including online time, link status, node capability and other streaming parameters. 2) Standard messages between PPSP peers and PPSP trackers defining how PPSP peers report streaming status and request to PPSP trackers, as well as how PPSP trackers reply to the requests. PPSP peer protocol will define: 1) Standard format/encoding of information among PPSP peers, such as chunk description. 2) Standard messages among PPSP peers defining how PPSP peers advertise chunk availability to each other, as well as the signaling for requesting the chunks among PPSP peers. This document itemizes requirements for the following aspects of PPSP: 1) Basic requirements to PPSP protocols (peer and tracker protocols), entities (peer and tracker), streaming content, and QoS issues. 2) General requirements to the tracker protocol. 3) General requirements to the peer protocol. 4) Security requirements. 4. PPSP Requirements 4.1. Basic Requirements PPSP.REQ-1: The tracker and the peer protocols SHOULD be as similar as possible, in terms of design, message formats and flows. It is desirable that the peer protocol would be an extension to the tracker protocol by adding a few message types, or vice versa. PPSP.REQ-2: The tracker protocol and the peer protocol SHOULD enable peers to receive streaming content within the required time constraints, i.e., fulfill streaming feature. PPSP.REQ-3: Each peer MUST have a unique ID (i.e. peer ID) in a Zong, et al. Expires April 10, 2012 [Page 6] Internet-Draft PPSP Requirements October 2011 swarm. It's a basic requirement for a peer to be uniquely identified in a swarm that other peers or tracker can refer to the peer by ID. PPSP.REQ-4: The streaming content MUST be uniquely identified by a swarm ID. A swarm refers to a group of peers sharing the same streaming content. A swarm ID uniquely identifies a swarm. The swarm ID can be used in two cases: 1) a peer requests the tracker for the peer list indexed by a swarm ID; 2) a peer tells the tracker about the swarms it belongs to. PPSP.REQ-5: The streaming content MUST allow to be partitioned into chunks. A key characteristic of P2P streaming system is allowing the data fetching from different peers concurrently. Therefore, the whole streaming content must allow to be partitioned into small pieces or chunks for transmission between peers. PPSP.REQ-6: Each chunk MUST have an unique ID (i.e. chunk ID) in the swarm. Each chunk must have an unique ID in the swarm such as the peer can understand which chunks are stored in which peers and which chunks are requested by other peers. An example for generating the chunk ID is the buffer map approach [I-D.ietf-ppsp-survey]. PPSP.REQ-7: The tracker protocol and peer protocol are Recommended to be carried over TCP (or UDP, when delivery requirements cannot be met by TCP). PPSP.REQ-8: The tracker and peer protocol together MUST facilitate acceptable QoS (e.g. low startup delay, low channel/content switching time and minimal end-to-end delay) for both on-demand and live streaming, even for very popular content. The tracker and peer protocol do not include the algorithm required for scalable streaming. However, the tracker and peer protocol SHALL NOT restrict or place limits on any such algorithm. There are basic QoS requirements for streaming system. Setup time to receive a new streaming channel or to switch between channels should be reasonable small. End to end delay (time between content generation, e.g. camera and content consumption, e.g. user side monitor) will become critical in case of live streaming. Especially in provisioning of sports events, end to end delay of 1 minute and Zong, et al. Expires April 10, 2012 [Page 7] Internet-Draft PPSP Requirements October 2011 more are not acceptable. For instance, the tracker and peer protocols can support carrying QoS related parameters (e.g. video quality, delay requirements) together with the priorities of these parameters, and QoS situation (e.g. performance, available uplink bandwidth) of content providing peers. There are also some other possible mechanisms, e.g. addition of super peers, in-network storage, request of alternative peer addresses, and the usage of QoS information for an advanced peer selection. 4.2. PPSP Tracker Protocol Requirements The tracker protocol defines how the peers report and request information to/from the tracker and how the tracker replies to the requests. The tracker discovery and the possible communication between trackers are out of the scope of tracker protocol. PPSP.TP.REQ-1: The tracker MUST implement the tracker protocol for receiving queries and periodical peer status reports/updates from the peers and for sending the corresponding replies. PPSP.TP.REQ-2: The peer MUST implement the tracker protocol for sending queries and periodical peer status reports/updates to the tracker and receiving the corresponding replies. PPSP.TP.REQ-3: The tracker request message MUST allow the requesting peer to solicit the peer list from the tracker with respect to a specific swarm ID. The tracker request message may also include the requesting peer's preference parameter, e.g. preferred number of peers in the peer list, or preferred downloading bandwidth. The track will then be able to select an appropriate set of peers for the requesting peer according to the preference. PPSP.TP.REQ-4: The tracker reply message MUST allow the tracker to offer the peer list to the requesting peer with respect of a specific swarm ID. PPSP.TP.REQ-5: The tracker SHOULD support generating the peer list with the help of traffic optimization services, e.g. ALTO [I-D.ietf-alto-protocol]. PPSP.TP.REQ-6: The peer status report/update MUST have the ability to inform the tracker about the peer's activity in the swarm. PPSP.TP.REQ-7: The chunk availability information of the peer SHOULD Zong, et al. Expires April 10, 2012 [Page 8] Internet-Draft PPSP Requirements October 2011 be reported to tracker when tracker needs such information to steer peer selection. The chunk information MUST at least contain the chunk ID. PPSP.TP.REQ-8: The chunk availability information between peer and tracker MUST be as expressed as compactly as possible. The peers may report CHUNK AVAILABILTY DIGEST information (i.e. compact expression of chunk availability) to the tracker when possible to decrease the bandwidth consumption for messages in bandwidth constraint environment like mobile network. For example, if a peer has a bitmap like 111111...1(100 continuous 1)xxx..., the 100 continuous "1" can be expressed by one byte with seven bits representing 100 and one bit representing "1". In this example, 100- 8=92 bits are saved. Considering the frequency of exchange of CHUNK AVAILBILITY and the fact that many bitmaps have quite a long length of continuous "1" or "0", such compression makes sense. PPSP.TP.REQ-9: The status of the peer SHOULD be reported to the tracker when tracker needs such information to steer peer selection. For example, peer status can be online time, physical link status including DSL/WIFI/etc, battery status, processing capability, and other capabilities of the peer. Therefore, the tracker is able to select better candidate peers for streaming. 4.3. PPSP Peer Protocol Requirements The peer protocol defines how the peers advertise streaming content availability and exchange status with each other. The peer protocol also defines the requests and responses of the chunks among the peers. The first task for this WG will be to decide which signaling and media transfer protocols will be used. The WG will consider existing protocols and, if needed, identify potential extensions to these protocols. PPSP.PP.REQ-1: The streaming content availability request message MUST allow the peer to solicit the chunk information from other peers in the peer list. The chunk information MUST at least contain the chunk ID. This chunk availability information MUST NOT be passed on to other peer, unless validated (e.g. prevent hearsay and DoS). PPSP.PP.REQ-2: The streaming content availability reply message MUST allow the peer to offer the information of the chunks in its content buffer. The chunk information MUST at least contain the chunk ID. PPSP.PP.REQ-3: The streaming content availability request message SHOULD allow the peer to solicit an additional list of peers to that Zong, et al. Expires April 10, 2012 [Page 9] Internet-Draft PPSP Requirements October 2011 received from the tracker - with the same swarm ID. The reply message MUST contain swarm-membership information of the peers that have explicitly indicated they are part of the swarm, verifiable by the receiver. This additional list of peers MUST only contain peers which have been checked to be valid and online recently (e.g. prevent hearsay and DoS). It is possible that a peer may need additional peers for certain streaming content. Therefore, it is allowed that the peer communicates with the peers in the current peer list to obtain an additional list of peers in the same swarm. PPSP.PP.REQ-4: Streaming content availability update message among the peers MUST be supported by peer protocol. In the push based model, where peers advocate their own chunk availability proactively, the content availability request message described in PP.REQ-1 is not needed. The peer protocol MUST implement either pull-based, push- based or both. Due to the dynamic change of the buffered streaming content in each peer and the frequent join/leave of peers in the swarm, the streaming content availability among a peer's neighbours (i.e. the peers known to a peer by getting the peer lists from either tracker or peers) always changes and thus requires being updated on time. This update should be done at least on demand. For example, when a peer requires finding more peers with certain chunks, it sends a message to some other peers in the swarm for streaming content availability update. Alternatively, each peer in the swarm can advertise its streaming content availability to some other peers periodically. However, the detailed mechanisms for this update such as how far to spread such update message, how often to send this update message, etc should leave to peer algorithms, rather than protocol concerns. PPSP.PP.REQ-5: The chunk availability information between peers MUST be as expressed as compactly as possible. In PP.REQ-1/2/4, the peers may exchange CHUNK AVAILABILTY DIGEST information (i.e. compact expression of chunk availability) to with other peers when possible to decrease the bandwidth consumption for messages in bandwidth constraint environment like mobile network. PPSP.PP.REQ-6: The peer status report/update SHOULD be advertised among the peers to reflect the status of the peer. Peer status information should be advertised among the peers via the peer status report/update message. For example, peer status can be online time, physical link status including DSL/WIFI/etc, battery status, processing capability, and other capabilities of the peer. Zong, et al. Expires April 10, 2012 [Page 10] Internet-Draft PPSP Requirements October 2011 With this information, a peer can select more appropriate peers for streaming. PPSP.PP.REQ-7: The peers MUST implement the peer protocol for chunk data (not availability information) requests and responses among the peers before the streaming content is transmitted. 5. Security Considerations The scope of this section is to analyze the security threats and provide the requirements for PPSP. PPSP.SEC.REQ-1: PPSP MUST support closed swarms, where the peers are authenticated. This ensures that only the authenticated users can access the original media in the P2P streaming system. This can be achieved by security mechanisms such as user authentication and/or key management scheme. PPSP.SEC.REQ-2: Confidentiality of the streaming content in PPSP SHOULD be supported and the corresponding key management scheme SHOULD scale well in P2P streaming system. PPSP.SEC.REQ-3: PPSP MUST provide an option to encrypt the data exchange among the PPSP entities. PPSP.SEC.REQ-4: PPSP MUST have mechanisms to limit potential damage caused by malfunctioning and badly behaving peers in the P2P streaming system. Such an attack will degrade the quality of the rendered media at the receiver. For example, in a P2P live video streaming system a polluter can introduce corrupted chunks. Each receiver integrates into its playback stream the polluted chunks it receives from its other neighbors. Since the peers forwards chunks to other peers, the polluted content can potentially spread through much of the P2P streaming network. PPSP.SEC.REQ-5: PPSP SHOULD support identifying badly behaving peers, and exclude or reject them from the P2P streaming system. PPSP.SEC.REQ-6: PPSP MUST prevent peers from DoS attacks which will exhaust the P2P streaming system's available resource. Given the prevalence of DoS attacks in the Internet, it is important to realize that a similar threat could exist in a large-scale Zong, et al. Expires April 10, 2012 [Page 11] Internet-Draft PPSP Requirements October 2011 streaming system where attackers are capable of consuming a lot of resources with just a small amount of effort. PPSP.SEC.REQ-7: PPSP SHOULD be robust, i.e., when centralized tracker fails the P2P streaming system SHOULD still work by supporting distributed trackers. PPSP.SEC.REQ-8: Existing P2P security mechanisms SHOULD be re-used as much as possible in PPSP, to avoid developing new security mechanisms. PPSP.SEC.REQ-9: Integrity of the streaming content in PPSP MUST be supported to provide a peer with the possibility to identify inauthentic media content (undesirable modified by other entities rather than its genuine source). The corresponding checksum distribution and verification scheme SHOULD scale well in P2P streaming system and be robust against distrustful trackers/peers. 6. IANA Considerations This document presently raises no IANA considerations. 7. Acknowledgements The authors would like to thank many people for discussing P2P streaming. We would particularly like to thank: Yingjie Gu, Haibin Song, Xingfeng Jiang from Huawei, Hui Zhang, Jan Seedorf, Martin Stiemerling from NEC Labs, Jun Lei from University of Goettingen, James Seng from PPLive, Das Saumitra from Qualcomm, Christian Schmidt from NSN, Akbar Rahman from Interdigital, Lingli Deng from China Mobile, Johan Pouwelse, Arno Bakker and Wesley Eddy. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [PPLive] "www.pplive.com". [PPStream] "www.ppstream.com". Zong, et al. Expires April 10, 2012 [Page 12] Internet-Draft PPSP Requirements October 2011 [UUSee] "www.uusee.com". [Pando] "www.pando.com". [I-D.ietf-ppsp-survey] Gu, Y., Zong, N., Zhang, H., Zhang, Y., Lei, J., Camarillo, G., Liu, Y., Montuno, D., and X. Lei, "Survey of P2P Streaming Applications", draft-ietf-ppsp-survey-02 (work in progress), July 2011. [I-D.ietf-alto-protocol] Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-ietf-alto-protocol-09 (work in progress), June 2011. [I-D.ietf-ppsp-problem-statement] Zhang, Y., Zong, N., Camarillo, G., Seng, J., and R. Yang, "Problem Statement of P2P Streaming Protocol (PPSP)", draft-ietf-ppsp-problem-statement-05 (work in progress), September 2011. Authors' Addresses Ning Zong (editor) Huawei Technologies Huawei Base, No.101 Software Avenue, Nanjing, China Phone: +86 25 56624760 Email: zongning@huawei.com Yunfei Zhang China Mobile Communication Corporation Phone: +86 13601032119 Email: zhangyunfei@chinamobile.com Victor Pascual Acme Packet Anabel Segura 10, Madrid 28108, Spain Email: VPascual@acmepacket.com Zong, et al. Expires April 10, 2012 [Page 13] Internet-Draft PPSP Requirements October 2011 Carl Williams Consultant Palo Alto, California 94306 Email: carlw@mcsr-labs.org Lin Xiao Nokia Siemens Networks Phone: +86 10 84358977 Email: lin.xiao@nsn.com Zong, et al. Expires April 10, 2012 [Page 14] --Boundary_(ID_0Xs3TzZG5ZOmzLVVUG+8Og)-- From zongning@huawei.com Sat Oct 8 02:45:20 2011 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 6475F21F8B0F for ; Sat, 8 Oct 2011 02:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.035 X-Spam-Level: X-Spam-Status: No, score=-104.035 tagged_above=-999 required=5 tests=[AWL=2.337, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, 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 xubR6KHPoAkl for ; Sat, 8 Oct 2011 02:45:20 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C6C9A21F8AC9 for ; Sat, 8 Oct 2011 02:45:19 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSQ00ISNR8BSO@szxga05-in.huawei.com> for ppsp@ietf.org; Sat, 08 Oct 2011 17:48:11 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSQ00EA3R7UZI@szxga05-in.huawei.com> for ppsp@ietf.org; Sat, 08 Oct 2011 17:48:11 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEC81482; Sat, 08 Oct 2011 17:48:11 +0800 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 08 Oct 2011 17:48:02 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.252]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Sat, 08 Oct 2011 17:46:01 +0800 Date: Sat, 08 Oct 2011 09:46:00 +0000 From: ZongNing In-reply-to: X-Originating-IP: [10.138.41.128] To: "ppsp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-ietf-ppsp-reqs-05.txt Thread-index: AQHMhZtV2i+Nvd7F8EeGqkB6FPqdu5VyK5IggAAHHFA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [ppsp] New Version Notification for draft-ietf-ppsp-reqs-05.txt 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, 08 Oct 2011 09:45:20 -0000 Or please check the following link: http://tools.ietf.org/html/draft-ietf-ppsp-reqs-05 -----Original Message----- From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of ZongNing Sent: Saturday, October 08, 2011 5:22 PM To: ppsp@ietf.org Subject: [ppsp] FW: New Version Notification for draft-ietf-ppsp-reqs-05.txt Hi, Folks, A new revision of PPSP requirements has been submitted (see attached draft-ietf-ppsp-reqs-05.txt). Comments are welcome. Thanks. BR, Ning Zong -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Saturday, October 08, 2011 5:16 PM To: ZongNing Cc: lin.xiao@nsn.com; vpascual@acmepacket.com; zhangyunfei@chinamobile.com; carlw@mcsr-labs.org; ZongNing Subject: New Version Notification for draft-ietf-ppsp-reqs-05.txt A new version of I-D, draft-ietf-ppsp-reqs-05.txt has been successfully submitted by Ning Zong and posted to the IETF repository. Filename: draft-ietf-ppsp-reqs Revision: 05 Title: P2P Streaming Protocol (PPSP) Requirements Creation date: 2011-10-08 WG ID: ppsp Number of pages: 14 Abstract: The objective of the PPSP work is to standardize the key signaling protocols that apply to tracker and peers in a Peer-to-Peer (P2P) streaming system. These protocols are called PPSP. This document enumerates the requirements for the PPSP, which should be considered when designing PPSP. The IETF Secretariat From zhangyunfei@chinamobile.com Thu Oct 13 23:23:04 2011 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 4724321F8B1A for ; Thu, 13 Oct 2011 23:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.776 X-Spam-Level: X-Spam-Status: No, score=-97.776 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, 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 GKs3ZQPe7aly for ; Thu, 13 Oct 2011 23:23:03 -0700 (PDT) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD2F21F8B07 for ; Thu, 13 Oct 2011 23:23:00 -0700 (PDT) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 58CCCE8AD; Fri, 14 Oct 2011 14:22:58 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id 4F47DE858; Fri, 14 Oct 2011 14:22:58 +0800 (CST) Received: from zyf-PC ([10.2.2.117]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011101414225681-11269 ; Fri, 14 Oct 2011 14:22:56 +0800 Date: Fri, 14 Oct 2011 14:22:51 +0800 From: "zhangyunfei" To: "ppsp@ietf.org" Message-ID: <201110141422517067033@chinamobile.com> X-mailer: Foxmail 6, 2, 103, 20 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-10-14 14:22:56, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-10-14 14:22:58, Serialize complete at 2011-10-14 14:22:58 Content-Type: multipart/alternative; boundary="=====003_Dragon224756400421_=====" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18448.005 X-TM-AS-Result: No--3.839-7.0-31-10 X-imss-scan-details: No--3.839-7.0-31-10;No--3.839-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [ppsp] Tentative time for PPSP session 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: Fri, 14 Oct 2011 06:23:04 -0000 This is a multi-part message in MIME format. --=====003_Dragon224756400421_===== Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="gb2312" Hi all, For those who might be planing their trip (but do remember this is subject to change) , our session in next IETF is currently scheduled for Tuesday, Morning, 0900-1130. Yunfei&Martin zhangyunfei 2011-10-14 --=====003_Dragon224756400421_===== Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="gb2312"
Hi all,
   For those who might be planing their trip (but do remember this is subject to change) , our session in next IETF is currently scheduled for Tuesday, Morning, 0900-1130.
 
 
Yunfei&Martin
zhangyunfei
2011-10-14
 --=====003_Dragon224756400421_=====-- From a.bakker@vu.nl Fri Oct 14 00:28:53 2011 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 D2CE721F8C3A for ; Fri, 14 Oct 2011 00:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] 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 TV-wC+ZSB1tY for ; Fri, 14 Oct 2011 00:28:53 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.16]) by ietfa.amsl.com (Postfix) with ESMTP id E4A7A21F8C14 for ; Fri, 14 Oct 2011 00:28:52 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.16) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 14 Oct 2011 09:28:54 +0200 Received: from [130.37.193.73] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Fri, 14 Oct 2011 09:28:50 +0200 Message-ID: <4E97E4F9.2050400@cs.vu.nl> Date: Fri, 14 Oct 2011 09:30:01 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: ppsp References: <9E5BD23D-E141-4A0F-BFA1-EC4BF4369547@ieee.org> <5D4FA36B7914F747B947371D475E306D53FCC33B@PEXMB002A.vu.local> <0E39FF7D-94A5-4B34-A351-0FE4C9A5AD08@ieee.org> <4E8AD3CE.9050401@cs.vu.nl> <018E5D75-3051-4177-8474-DD12887A4FC2@ieee-pt.org> <4E8AEAF8.4080102@cs.vu.nl> <71EDB0EE-431A-4DFF-A079-3BA51C0AA71F@ieee-pt.org> <4E8D5BAD.1030805@cs.vu.nl> <8ADE31B1-54C3-4D12-9FC1-FA27785E48FA@ieee.org> In-Reply-To: <8ADE31B1-54C3-4D12-9FC1-FA27785E48FA@ieee.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: Re: [ppsp] PPSP encoding X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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: Fri, 14 Oct 2011 07:28:53 -0000 Hi On 06/10/2011 12:07, Rui Cruz wrote: >> >> for some reason we don't see to be on the same wavelength ;o) >> If peer A has chunk X that interest peer B and peer B has >> chunk Y that interest peer A in your system they will need >> to establish two HTTP connections, one from A to B to >> do GET_CHUNK Y and one from B to A to do GET_CHUNK X. >> > For both media data transfer and signaling, it may happen indeed. I'm afraid it will happen a lot. In a P2P system one wants to promote sharing, so ideally each peer should have something to give to another peer, such that most traffic is served by the peers and in a fair manner. > > Depending on the streaming mode (Live, Time-shifted/VoD) and scenarios > (related with "business models", namely those being worked within the EU > FP7 SARACEN Project), different schemes can be applied and are currently > under development in that project. For PPSP it is important the > contextual awareness of the incentive scheme to use (for scheduling and > control), although the development of these schemes is not in the PPSP > charter. > Interesting. Is there documentation on this work, an EU deliverable perhaps? > Depending on the streaming method the chunk availability exchange > between peers also differs. The Tracker plays a role in the peer > selection process, contributing to the "optimization" of the neighbor > set for a certain peer, which will then request the current chunkmaps > from a subset of that neighbor set. The process is quite fast as the > interested peer just filters from the chunkmaps the chunks available > within the current time-window. The next updates of the chunkmaps will > happen in case of missing chunks of future time-windows (eventually > several seconds after the last update). > For Live streaming, the Media Presentation Description (content > manifest/index) plays an important role, as the file is being updated > while the media is being released (encoded) for streaming. So the manifest tells you about the existence of new chunks (live) and then you poll your peers whether they have them already or not. How close in time to the live source do your clients typically get? Regards, Arno From zhangyunfei@chinamobile.com Fri Oct 14 02:52:14 2011 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 1013321F8A55 for ; Fri, 14 Oct 2011 02:52:14 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -98.147 X-Spam-Level: X-Spam-Status: No, score=-98.147 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_20=-0.74, RELAY_IS_221=2.222, 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 I4cgwTxfvo0v for ; Fri, 14 Oct 2011 02:52:13 -0700 (PDT) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 74CD521F8A64 for ; Fri, 14 Oct 2011 02:52:09 -0700 (PDT) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3EC19E8B8; Fri, 14 Oct 2011 17:52:08 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id 37070E8B2; Fri, 14 Oct 2011 17:52:08 +0800 (CST) MIME-Version: 1.0 To: ppsp@ietf.org From: zhangyunfei@chinamobile.com Date: Fri, 14 Oct 2011 17:52:05 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-10-14 17:52:07 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18448.006 X-TM-AS-Result: No--5.325-7.0-31-10 X-imss-scan-details: No--5.325-7.0-31-10;No--5.325-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Subject: [ppsp] ppsp informal demo show in IETF meeting 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: Fri, 14 Oct 2011 09:52:14 -0000 Hi all, Martin and I just plan tentatively to have an informal ppsp demo show in= the lunch time after the PPSP session according to Johan's proposal in las= t interim meeting discussion. The demo show is not a formal session. Rather= we would like to gather people to see the progress of PPSP demos, to have = a better understanding of different proposals based on some agreed metrics = and discuss thoroughly on the differences and finally benefit the WG in the= discussion of protocol selection. Show proposals are welcome to apply. Thanks, =20 BR Yunfei= From Martin.Stiemerling@neclab.eu Mon Oct 17 19:44:22 2011 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 F2BD911E80C4 for ; Mon, 17 Oct 2011 19:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Y6Ym7Cf39QTq for ; Mon, 17 Oct 2011 19:44:21 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 182C311E80BA for ; Mon, 17 Oct 2011 19:44:21 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C1B58280001DA for ; Tue, 18 Oct 2011 04:44:25 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHQVaDw8Du+N for ; Tue, 18 Oct 2011 04:44:25 +0200 (CEST) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id A6010280001AB for ; Tue, 18 Oct 2011 04:44:20 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.12]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 18 Oct 2011 04:43:53 +0200 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: IETF#82: Agenda planning -- send your agenda requests Thread-Index: AcyNP0Bqhglcj+ZWR3e5gE0B15Cvlw== Date: Tue, 18 Oct 2011 02:43:53 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.209] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] IETF#82: Agenda planning -- send your agenda requests 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: Tue, 18 Oct 2011 02:44:22 -0000 Dear all,=20 The IETF 82 meeting in Taipei (November 13-18, 2011) is approaching and we = need to start the planning of the agenda. Please send your agenda requests to Yunfei (zhangyunfei@chinamobile.com) a= nd me (martin.stiemerling@neclab.eu) until **October 21st 9am CEST**. The request for an agenda slot MUST contain: - title of draft - requested time length - presenter Thank you, Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From wes@mti-systems.com Mon Oct 17 21:29:40 2011 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 9866011E80D2 for ; Mon, 17 Oct 2011 21:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599] 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 sOtW86Tbcrrc for ; Mon, 17 Oct 2011 21:29:39 -0700 (PDT) Received: from omr16.networksolutionsemail.com (omr16.networksolutionsemail.com [205.178.146.66]) by ietfa.amsl.com (Postfix) with ESMTP id 65C2211E80C8 for ; Mon, 17 Oct 2011 21:29:34 -0700 (PDT) Received: from cm-omr3 (mail.networksolutionsemail.com [205.178.146.50]) by omr16.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id p9I4TTbP005035 for ; Tue, 18 Oct 2011 00:29:31 -0400 Authentication-Results: cm-omr3 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [174.130.89.114] ([174.130.89.114:9724] helo=[192.168.1.102]) by cm-omr3 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D7/9B-05308-8A00D9E4; Tue, 18 Oct 2011 00:29:29 -0400 Message-ID: <4E9D00AA.4060400@mti-systems.com> Date: Tue, 18 Oct 2011 00:29:30 -0400 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "ppsp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-ppsp-problem-statement@tools.ietf.org Subject: [ppsp] AD review of draft-ietf-ppsp-problem-statement-05 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: Tue, 18 Oct 2011 04:29:40 -0000 I've completed AD review of this document, and while the content is complete, I don't think it's editorially quite ready for IETF Last Call and IESG review. My comments below are intended to help get it there. In some cases, I indicated suggested changes with an arrow "from -> to" between the original "from" text and the suggested "to" text. While it seems like a lot, most of these are actually pretty minor changes. (1) In the abstract (and possibly the title too), P2P should be spelled out as peer-to-peer. In the abstract, "PPSP" should be defined before use since this paragraph will appear in announcements (e.g. for IETF LC) and other places. Note that PPSP is singular ("Protocol", not "Protocols", but the last sentence of the abstract and the title of Section 4 use plural). I think it would be good to be more clear here and say something more like "proposes a Peer to Peer Streaming Protocol (PPSP) including tracker and peer signaling components, and discusses the scope and uses cases of PPSP." (2) section 1, 2nd paragraph - "This is less challenging for highly increasing capability on hardware." I think this sentence is vague at best and likely misleading. The sentence prior to it talks about network efficiency without defining in what sense this is meant (is it efficient use of bandwidth, low-latency, low load on servers, low power usage, etc.). The type of efficiency meant here should be clarified, and consider either removing or further clarifying the sentence following it about hardware capabilities. (3) section 1, 3rd paragraph - Does "source" here refer to the original source of the media being streamed, the root node actually transmitting stream, or something else? I think "heterogeneous kinds of terminals" would be more clear as "heterogeneous types of peer or client device platforms."? (4) section 1, 4th paragraph - "lacking of an" -> "lack of an" (5) section 1, 2nd to last paragraph - when "PPSP" is first used, define it. (6) section 2 - The definition of Chunk is pretty non-specific; for instance, as-used in PPSP, is a chunk intended to fit in a single transmitted packet or is it generally a larger unit of several kB? It's also unclear what's meant by "partitioned streaming" here, as that term is not used or defined elsewhere in the document as to how it differs from just "streaming". (7) section 2 - In the swarm definition, I think it would be reasonable to say that they "distribute chunks of the same content", in order to tie the swarm definition into that other defined term. (8) why is ALTO's problem statement (RFC 5693) listed as normative? I don't believe it really is normative to this PPSP document, though it's certainly informative. (9) Section 3.1, last paragraph. We talk about PPSP here as if it already exists in a usable form. Instead of "can" we probably need to say "should be able to", for instance, and there are other similar changes in this paragraph that should not mislead someone into thinking a PPSP product is already in existence and does these things. (10) Section 3.2 - "P2P-type is accounting for a large portion" -> "systems using P2P account for a large portion". (11) Section 3.2 - "vast of same" -> "vastly the same"? (12) Section 3.2 - "contents, increases" -> "contents, and increases" (13) Section 3.2 - "CDN provider" -> "CDN providers" (14) Section 3.2 - "can be either HTTP or PPSP" -> "could be via something like traditional HTTP requests, or could use streaming setup via PPSP."? (15) Section 3.3 - "seventeen millions" -> "seventeen million", and "more and more studies" -> "multiple prior studies" (16) Section 3.3 - "lower and costly" -> "lower rate, and costly in terms of energy consumption"? (17) Section 3.3 - "relatively frequest to exchange" -> "exchanged relatively frequently" (18) Section 3.3 - I do not understand the sentence "The new-added information should help the tracker/peer to make the decision". Consider removing this or finding a way to clarify what it means, if it's necessary to keep. (19) Section 3.3 - "maybe requires a new expression on "bitmap"" -> "may require alternative methods for distributing bitmap information"? (20) Section 3.4 - "resource-constraint" -> "resource-constrained" in the title and text (21) Section 3.4 - "set top box" -> "set top boxes (STBs)" (22) Section 3.4 - this should be clarified to distinguish between whether the resource that's constrained is the persistent storage or RAM on the devices (23) Section 4 - "are belonging" -> "belong" (24) Section 4 - In the description of push-based and hybrid modes, it's unclear how peers find the head node or how they find each other compared to how they find the tracker in a pull-based mode. This probably requires a brief description. (25) Section 4 - Instead of saying: "PPSP is targeted to standardize the signaling protocols in this tracker-based architectures for supporting both live and VoD streaming." I think it be more accurate to say: "PPSP includes standard signaling protocols for tracker-based architectures that support either live or offline streaming." (26) Section 4 - "In detail, PPSP designs -> "The PPSP design includes"" (27) Section 5.1 - The first paragraph needs to be rewritten, since it seems more likely to refer to content providers (selling bits of media) rather than "vendors" that we usually refer to as people selling boxes. I think the picture is clear, but the text is not. Note that the super-node concept was brought up in this paragraph without any explanation or definition of what we mean by it in PPSP. (28) Section 5.3 - "With PPSP Peers" -> "With PPSP, peers" (29) Section 5.4 - CDS is not defined (30) Section 5.5 - I understand the intent, but the first two paragraphs here need to be cleaned up and clarified. The figure is very clear; the text isn't. (31) The document should consistently use either "P2P" or "p2p" (32) Many of the Informative References are only URLs, and I suspect this RFC will live on much longer than most of those URLs. I think that wherever it's reasonable, those URLs should be replaced with more stable references. I understand that this won't be possible in all cases. Thanks for bearing with these in order to progress this document. -- Wes Eddy MTI Systems From zhangyunfei@chinamobile.com Mon Oct 17 23:08:23 2011 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 2034D11E80D4 for ; Mon, 17 Oct 2011 23:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.16 X-Spam-Level: X-Spam-Status: No, score=-97.16 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, 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 qYBuaD0MJGcV for ; Mon, 17 Oct 2011 23:08:21 -0700 (PDT) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D70C111E8089 for ; Mon, 17 Oct 2011 23:08:20 -0700 (PDT) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 66432E9E0; Tue, 18 Oct 2011 14:08:19 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id 4DD9DE9D8; Tue, 18 Oct 2011 14:08:19 +0800 (CST) Received: from zyf-PC ([10.2.0.5]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2011101814081569-10479 ; Tue, 18 Oct 2011 14:08:15 +0800 Date: Tue, 18 Oct 2011 14:08:15 +0800 From: "zhangyunfei" To: "Wesley Eddy" , "ppsp@ietf.org" References: <4E9D00AA.4060400@mti-systems.com> Message-ID: <201110181408148242523@chinamobile.com> X-mailer: Foxmail 6, 2, 103, 20 [cn] Mime-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-10-18 14:08:16, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-10-18 14:08:18, Serialize complete at 2011-10-18 14:08:18 Content-Type: multipart/alternative; boundary="=====003_Dragon253423115650_=====" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18456.005 X-TM-AS-Result: No--20.301-7.0-31-10 X-imss-scan-details: No--20.301-7.0-31-10;No--20.301-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: draft-ietf-ppsp-problem-statemen Subject: Re: [ppsp] AD review of draft-ietf-ppsp-problem-statement-05 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: Tue, 18 Oct 2011 06:08:23 -0000 This is a multi-part message in MIME format. --=====003_Dragon253423115650_===== Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" VGhhbmtzIFdlcyBmb3IgeW91ciBjYXJlZnVsIHJldmlldy4gSSdsbCB1cGRhdGUgdGhlIGRvY3Vt ZW50IHNvb24gYWNjb3JkaW5nIHRvIHlvdXIgc3VnZ2VzdGlvbnMuIFRoYW5rcyBhZ2Fpbi4NCg0K QlINCll1bmZlaQ0KDQoNCg0KDQp6aGFuZ3l1bmZlaQ0KMjAxMS0xMC0xOA0KDQoNCg0Kt6K8/sjL o7ogV2VzbGV5IEVkZHkNCreiy83Ksbzko7ogMjAxMS0xMC0xOCAxMjoyOTo0Mw0KytW8/sjLo7og cHBzcEBpZXRmLm9yZw0Ks63LzaO6IGRyYWZ0LWlldGYtcHBzcC1wcm9ibGVtLXN0YXRlbWVudEB0 b29scy5pZXRmLm9yZw0K1vfM4qO6IFtwcHNwXSBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1wcHNw LXByb2JsZW0tc3RhdGVtZW50LTA1DQoNCkkndmUgIGNvbXBsZXRlZCAgQUQgIHJldmlldyAgb2Yg IHRoaXMgIGRvY3VtZW50LCAgYW5kICB3aGlsZSAgdGhlICBjb250ZW50ICBpcyAgDQpjb21wbGV0 ZSwgIEkgIGRvbid0ICB0aGluayAgaXQncyAgZWRpdG9yaWFsbHkgIHF1aXRlICByZWFkeSAgZm9y ICBJRVRGICBMYXN0ICBDYWxsICANCmFuZCAgSUVTRyAgcmV2aWV3LiAgICBNeSAgY29tbWVudHMg IGJlbG93ICBhcmUgIGludGVuZGVkICB0byAgaGVscCAgZ2V0ICBpdCAgdGhlcmUuICANCkluICBz b21lICBjYXNlcywgIEkgIGluZGljYXRlZCAgc3VnZ2VzdGVkICBjaGFuZ2VzICB3aXRoICBhbiAg YXJyb3cgICJmcm9tICAtID4gIHRvIiAgDQpiZXR3ZWVuICB0aGUgIG9yaWdpbmFsICAiZnJvbSIg IHRleHQgIGFuZCAgdGhlICBzdWdnZXN0ZWQgICJ0byIgIHRleHQuDQoNCldoaWxlICBpdCAgc2Vl bXMgIGxpa2UgIGEgIGxvdCwgIG1vc3QgIG9mICB0aGVzZSAgYXJlICBhY3R1YWxseSAgcHJldHR5 ICBtaW5vciAgY2hhbmdlcy4NCg0KKDEpICBJbiAgdGhlICBhYnN0cmFjdCAgKGFuZCAgcG9zc2li bHkgIHRoZSAgdGl0bGUgIHRvbyksICBQMlAgIHNob3VsZCAgYmUgIHNwZWxsZWQgIA0Kb3V0ICBh cyAgcGVlci10by1wZWVyLiAgICBJbiAgdGhlICBhYnN0cmFjdCwgICJQUFNQIiAgc2hvdWxkICBi ZSAgZGVmaW5lZCAgYmVmb3JlICANCnVzZSAgc2luY2UgIHRoaXMgIHBhcmFncmFwaCAgd2lsbCAg YXBwZWFyICBpbiAgYW5ub3VuY2VtZW50cyAgKGUuZy4gIGZvciAgSUVURiAgTEMpICANCmFuZCAg b3RoZXIgIHBsYWNlcy4gICAgTm90ZSAgdGhhdCAgUFBTUCAgaXMgIHNpbmd1bGFyICAoIlByb3Rv Y29sIiwgIG5vdCAgDQoiUHJvdG9jb2xzIiwgIGJ1dCAgdGhlICBsYXN0ICBzZW50ZW5jZSAgb2Yg IHRoZSAgYWJzdHJhY3QgIGFuZCAgdGhlICB0aXRsZSAgb2YgIA0KU2VjdGlvbiAgNCAgdXNlICBw bHVyYWwpLiAgICBJICB0aGluayAgaXQgIHdvdWxkICBiZSAgZ29vZCAgdG8gIGJlICBtb3JlICBj bGVhciAgaGVyZSAgDQphbmQgIHNheSAgc29tZXRoaW5nICBtb3JlICBsaWtlICAicHJvcG9zZXMg IGEgIFBlZXIgIHRvICBQZWVyICBTdHJlYW1pbmcgIFByb3RvY29sICANCihQUFNQKSAgaW5jbHVk aW5nICB0cmFja2VyICBhbmQgIHBlZXIgIHNpZ25hbGluZyAgY29tcG9uZW50cywgIGFuZCAgZGlz Y3Vzc2VzICANCnRoZSAgc2NvcGUgIGFuZCAgdXNlcyAgY2FzZXMgIG9mICBQUFNQLiINCg0KDQoo MikgIHNlY3Rpb24gIDEsICAybmQgIHBhcmFncmFwaCAgLSAgIlRoaXMgIGlzICBsZXNzICBjaGFs bGVuZ2luZyAgZm9yICBoaWdobHkgIA0KaW5jcmVhc2luZyAgY2FwYWJpbGl0eSAgb24gIGhhcmR3 YXJlLiIgICAgICBJICB0aGluayAgdGhpcyAgc2VudGVuY2UgIGlzICB2YWd1ZSAgYXQgIA0KYmVz dCAgYW5kICBsaWtlbHkgIG1pc2xlYWRpbmcuICAgIFRoZSAgc2VudGVuY2UgIHByaW9yICB0byAg aXQgIHRhbGtzICBhYm91dCAgDQpuZXR3b3JrICBlZmZpY2llbmN5ICB3aXRob3V0ICBkZWZpbmlu ZyAgaW4gIHdoYXQgIHNlbnNlICB0aGlzICBpcyAgbWVhbnQgIChpcyAgaXQgIA0KZWZmaWNpZW50 ICB1c2UgIG9mICBiYW5kd2lkdGgsICBsb3ctbGF0ZW5jeSwgIGxvdyAgbG9hZCAgb24gIHNlcnZl cnMsICBsb3cgIHBvd2VyICANCnVzYWdlLCAgZXRjLikuICAgIFRoZSAgdHlwZSAgb2YgIGVmZmlj aWVuY3kgIG1lYW50ICBoZXJlICBzaG91bGQgIGJlICBjbGFyaWZpZWQsICANCmFuZCAgY29uc2lk ZXIgIGVpdGhlciAgcmVtb3ZpbmcgIG9yICBmdXJ0aGVyICBjbGFyaWZ5aW5nICB0aGUgIHNlbnRl bmNlICANCmZvbGxvd2luZyAgaXQgIGFib3V0ICBoYXJkd2FyZSAgY2FwYWJpbGl0aWVzLg0KDQoN CigzKSAgc2VjdGlvbiAgMSwgIDNyZCAgcGFyYWdyYXBoICAtICBEb2VzICAic291cmNlIiAgaGVy ZSAgcmVmZXIgIHRvICB0aGUgIG9yaWdpbmFsICANCnNvdXJjZSAgb2YgIHRoZSAgbWVkaWEgIGJl aW5nICBzdHJlYW1lZCwgIHRoZSAgcm9vdCAgbm9kZSAgYWN0dWFsbHkgIHRyYW5zbWl0dGluZyAg DQpzdHJlYW0sICBvciAgc29tZXRoaW5nICBlbHNlPyAgICBJICB0aGluayAgImhldGVyb2dlbmVv dXMgIGtpbmRzICBvZiAgdGVybWluYWxzIiAgDQp3b3VsZCAgYmUgIG1vcmUgIGNsZWFyICBhcyAg ImhldGVyb2dlbmVvdXMgIHR5cGVzICBvZiAgcGVlciAgb3IgIGNsaWVudCAgZGV2aWNlICANCnBs YXRmb3Jtcy4iPw0KDQooNCkgIHNlY3Rpb24gIDEsICA0dGggIHBhcmFncmFwaCAgLSAgImxhY2tp bmcgIG9mICBhbiIgIC0gPiAgImxhY2sgIG9mICBhbiINCg0KKDUpICBzZWN0aW9uICAxLCAgMm5k ICB0byAgbGFzdCAgcGFyYWdyYXBoICAtICB3aGVuICAiUFBTUCIgIGlzICBmaXJzdCAgdXNlZCwg IGRlZmluZSAgaXQuDQoNCig2KSAgc2VjdGlvbiAgMiAgLSAgVGhlICBkZWZpbml0aW9uICBvZiAg Q2h1bmsgIGlzICBwcmV0dHkgIG5vbi1zcGVjaWZpYzsgIGZvciAgDQppbnN0YW5jZSwgIGFzLXVz ZWQgIGluICBQUFNQLCAgaXMgIGEgIGNodW5rICBpbnRlbmRlZCAgdG8gIGZpdCAgaW4gIGEgIHNp bmdsZSAgDQp0cmFuc21pdHRlZCAgcGFja2V0ICBvciAgaXMgIGl0ICBnZW5lcmFsbHkgIGEgIGxh cmdlciAgdW5pdCAgb2YgIHNldmVyYWwgIGtCPyAgICBJdCdzICANCmFsc28gIHVuY2xlYXIgIHdo YXQncyAgbWVhbnQgIGJ5ICAicGFydGl0aW9uZWQgIHN0cmVhbWluZyIgIGhlcmUsICBhcyAgdGhh dCAgdGVybSAgDQppcyAgbm90ICB1c2VkICBvciAgZGVmaW5lZCAgZWxzZXdoZXJlICBpbiAgdGhl ICBkb2N1bWVudCAgYXMgIHRvICBob3cgIGl0ICBkaWZmZXJzICANCmZyb20gIGp1c3QgICJzdHJl YW1pbmciLg0KDQooNykgIHNlY3Rpb24gIDIgIC0gIEluICB0aGUgIHN3YXJtICBkZWZpbml0aW9u LCAgSSAgdGhpbmsgIGl0ICB3b3VsZCAgYmUgIHJlYXNvbmFibGUgIA0KdG8gIHNheSAgdGhhdCAg dGhleSAgImRpc3RyaWJ1dGUgIGNodW5rcyAgb2YgIHRoZSAgc2FtZSAgY29udGVudCIsICBpbiAg b3JkZXIgIHRvICANCnRpZSAgdGhlICBzd2FybSAgZGVmaW5pdGlvbiAgaW50byAgdGhhdCAgb3Ro ZXIgIGRlZmluZWQgIHRlcm0uDQoNCig4KSAgd2h5ICBpcyAgQUxUTydzICBwcm9ibGVtICBzdGF0 ZW1lbnQgIChSRkMgIDU2OTMpICBsaXN0ZWQgIGFzICBub3JtYXRpdmU/ICAgIEkgIA0KZG9uJ3Qg IGJlbGlldmUgIGl0ICByZWFsbHkgIGlzICBub3JtYXRpdmUgIHRvICB0aGlzICBQUFNQICBkb2N1 bWVudCwgIHRob3VnaCAgaXQncyAgDQpjZXJ0YWlubHkgIGluZm9ybWF0aXZlLg0KDQooOSkgIFNl Y3Rpb24gIDMuMSwgIGxhc3QgIHBhcmFncmFwaC4gICAgV2UgIHRhbGsgIGFib3V0ICBQUFNQICBo ZXJlICBhcyAgaWYgIGl0ICANCmFscmVhZHkgIGV4aXN0cyAgaW4gIGEgIHVzYWJsZSAgZm9ybS4g ICAgSW5zdGVhZCAgb2YgICJjYW4iICB3ZSAgcHJvYmFibHkgIG5lZWQgIHRvICANCnNheSAgInNo b3VsZCAgYmUgIGFibGUgIHRvIiwgIGZvciAgaW5zdGFuY2UsICBhbmQgIHRoZXJlICBhcmUgIG90 aGVyICBzaW1pbGFyICANCmNoYW5nZXMgIGluICB0aGlzICBwYXJhZ3JhcGggIHRoYXQgIHNob3Vs ZCAgbm90ICBtaXNsZWFkICBzb21lb25lICBpbnRvICB0aGlua2luZyAgDQphICBQUFNQICBwcm9k dWN0ICBpcyAgYWxyZWFkeSAgaW4gIGV4aXN0ZW5jZSAgYW5kICBkb2VzICB0aGVzZSAgdGhpbmdz Lg0KDQooMTApICBTZWN0aW9uICAzLjIgIC0gICJQMlAtdHlwZSAgaXMgIGFjY291bnRpbmcgIGZv ciAgYSAgbGFyZ2UgIHBvcnRpb24iICAtID4gIA0KInN5c3RlbXMgIHVzaW5nICBQMlAgIGFjY291 bnQgIGZvciAgYSAgbGFyZ2UgIHBvcnRpb24iLg0KDQooMTEpICBTZWN0aW9uICAzLjIgIC0gICJ2 YXN0ICBvZiAgc2FtZSIgIC0gPiAgInZhc3RseSAgdGhlICBzYW1lIj8NCg0KKDEyKSAgU2VjdGlv biAgMy4yICAtICAiY29udGVudHMsICBpbmNyZWFzZXMiICAtID4gICJjb250ZW50cywgIGFuZCAg aW5jcmVhc2VzIg0KDQooMTMpICBTZWN0aW9uICAzLjIgIC0gICJDRE4gIHByb3ZpZGVyIiAgLSA+ ICAiQ0ROICBwcm92aWRlcnMiDQoNCigxNCkgIFNlY3Rpb24gIDMuMiAgLSAgImNhbiAgYmUgIGVp dGhlciAgSFRUUCAgb3IgIFBQU1AiICAtID4gICJjb3VsZCAgYmUgIHZpYSAgDQpzb21ldGhpbmcg IGxpa2UgIHRyYWRpdGlvbmFsICBIVFRQICByZXF1ZXN0cywgIG9yICBjb3VsZCAgdXNlICBzdHJl YW1pbmcgIHNldHVwICANCnZpYSAgUFBTUC4iPw0KDQooMTUpICBTZWN0aW9uICAzLjMgIC0gICJz ZXZlbnRlZW4gIG1pbGxpb25zIiAgLSA+ICAic2V2ZW50ZWVuICBtaWxsaW9uIiwgIGFuZCAgDQoi bW9yZSAgYW5kICBtb3JlICBzdHVkaWVzIiAgLSA+ICAibXVsdGlwbGUgIHByaW9yICBzdHVkaWVz Ig0KDQooMTYpICBTZWN0aW9uICAzLjMgIC0gICJsb3dlciAgYW5kICBjb3N0bHkiICAtID4gICJs b3dlciAgcmF0ZSwgIGFuZCAgY29zdGx5ICBpbiAgDQp0ZXJtcyAgb2YgIGVuZXJneSAgY29uc3Vt cHRpb24iPw0KDQooMTcpICBTZWN0aW9uICAzLjMgIC0gICJyZWxhdGl2ZWx5ICBmcmVxdWVzdCAg dG8gIGV4Y2hhbmdlIiAgLSA+ICAiZXhjaGFuZ2VkICANCnJlbGF0aXZlbHkgIGZyZXF1ZW50bHki DQoNCigxOCkgIFNlY3Rpb24gIDMuMyAgLSAgSSAgZG8gIG5vdCAgdW5kZXJzdGFuZCAgdGhlICBz ZW50ZW5jZSAgIlRoZSAgbmV3LWFkZGVkICANCmluZm9ybWF0aW9uICBzaG91bGQgIGhlbHAgIHRo ZSAgdHJhY2tlci9wZWVyICB0byAgbWFrZSAgdGhlICBkZWNpc2lvbiIuICANCkNvbnNpZGVyICBy ZW1vdmluZyAgdGhpcyAgb3IgIGZpbmRpbmcgIGEgIHdheSAgdG8gIGNsYXJpZnkgIHdoYXQgIGl0 ICBtZWFucywgIGlmICANCml0J3MgIG5lY2Vzc2FyeSAgdG8gIGtlZXAuDQoNCigxOSkgIFNlY3Rp b24gIDMuMyAgLSAgIm1heWJlICByZXF1aXJlcyAgYSAgbmV3ICBleHByZXNzaW9uICBvbiAgImJp dG1hcCIiICAtID4gICJtYXkgIA0KcmVxdWlyZSAgYWx0ZXJuYXRpdmUgIG1ldGhvZHMgIGZvciAg ZGlzdHJpYnV0aW5nICBiaXRtYXAgIGluZm9ybWF0aW9uIj8NCg0KDQooMjApICBTZWN0aW9uICAz LjQgIC0gICJyZXNvdXJjZS1jb25zdHJhaW50IiAgLSA+ICAicmVzb3VyY2UtY29uc3RyYWluZWQi ICBpbiAgDQp0aGUgIHRpdGxlICBhbmQgIHRleHQNCg0KKDIxKSAgU2VjdGlvbiAgMy40ICAtICAi c2V0ICB0b3AgIGJveCIgIC0gPiAgInNldCAgdG9wICBib3hlcyAgKFNUQnMpIg0KDQooMjIpICBT ZWN0aW9uICAzLjQgIC0gIHRoaXMgIHNob3VsZCAgYmUgIGNsYXJpZmllZCAgdG8gIGRpc3Rpbmd1 aXNoICBiZXR3ZWVuICANCndoZXRoZXIgIHRoZSAgcmVzb3VyY2UgIHRoYXQncyAgY29uc3RyYWlu ZWQgIGlzICB0aGUgIHBlcnNpc3RlbnQgIHN0b3JhZ2UgIG9yICBSQU0gIA0Kb24gIHRoZSAgZGV2 aWNlcw0KDQooMjMpICBTZWN0aW9uICA0ICAtICAiYXJlICBiZWxvbmdpbmciICAtID4gICJiZWxv bmciDQoNCigyNCkgIFNlY3Rpb24gIDQgIC0gIEluICB0aGUgIGRlc2NyaXB0aW9uICBvZiAgcHVz aC1iYXNlZCAgYW5kICBoeWJyaWQgIG1vZGVzLCAgaXQncyAgDQp1bmNsZWFyICBob3cgIHBlZXJz ICBmaW5kICB0aGUgIGhlYWQgIG5vZGUgIG9yICBob3cgIHRoZXkgIGZpbmQgIGVhY2ggIG90aGVy ICANCmNvbXBhcmVkICB0byAgaG93ICB0aGV5ICBmaW5kICB0aGUgIHRyYWNrZXIgIGluICBhICBw dWxsLWJhc2VkICBtb2RlLiAgICBUaGlzICANCnByb2JhYmx5ICByZXF1aXJlcyAgYSAgYnJpZWYg IGRlc2NyaXB0aW9uLg0KDQooMjUpICBTZWN0aW9uICA0ICAtICBJbnN0ZWFkICBvZiAgc2F5aW5n Og0KICAgIlBQU1AgIGlzICB0YXJnZXRlZCAgdG8gIHN0YW5kYXJkaXplICB0aGUgIHNpZ25hbGlu ZyAgcHJvdG9jb2xzICBpbiAgdGhpcyAgDQp0cmFja2VyLWJhc2VkICBhcmNoaXRlY3R1cmVzICBm b3IgIHN1cHBvcnRpbmcgIGJvdGggIGxpdmUgIGFuZCAgVm9EICBzdHJlYW1pbmcuIg0KSSAgdGhp bmsgIGl0ICBiZSAgbW9yZSAgYWNjdXJhdGUgIHRvICBzYXk6DQogICAiUFBTUCAgaW5jbHVkZXMg IHN0YW5kYXJkICBzaWduYWxpbmcgIHByb3RvY29scyAgZm9yICB0cmFja2VyLWJhc2VkICANCmFy Y2hpdGVjdHVyZXMgIHRoYXQgIHN1cHBvcnQgIGVpdGhlciAgbGl2ZSAgb3IgIG9mZmxpbmUgIHN0 cmVhbWluZy4iDQoNCg0KKDI2KSAgU2VjdGlvbiAgNCAgLSAgIkluICBkZXRhaWwsICBQUFNQICBk ZXNpZ25zICAtID4gICJUaGUgIFBQU1AgIGRlc2lnbiAgaW5jbHVkZXMiIg0KDQooMjcpICBTZWN0 aW9uICA1LjEgIC0gIFRoZSAgZmlyc3QgIHBhcmFncmFwaCAgbmVlZHMgIHRvICBiZSAgcmV3cml0 dGVuLCAgc2luY2UgIGl0ICANCnNlZW1zICBtb3JlICBsaWtlbHkgIHRvICByZWZlciAgdG8gIGNv bnRlbnQgIHByb3ZpZGVycyAgKHNlbGxpbmcgIGJpdHMgIG9mICBtZWRpYSkgIA0KcmF0aGVyICB0 aGFuICAidmVuZG9ycyIgIHRoYXQgIHdlICB1c3VhbGx5ICByZWZlciAgdG8gIGFzICBwZW9wbGUg IHNlbGxpbmcgIGJveGVzLiAgDQogICBJICB0aGluayAgdGhlICBwaWN0dXJlICBpcyAgY2xlYXIs ICBidXQgIHRoZSAgdGV4dCAgaXMgIG5vdC4gICAgTm90ZSAgdGhhdCAgdGhlICANCnN1cGVyLW5v ZGUgIGNvbmNlcHQgIHdhcyAgYnJvdWdodCAgdXAgIGluICB0aGlzICBwYXJhZ3JhcGggIHdpdGhv dXQgIGFueSAgDQpleHBsYW5hdGlvbiAgb3IgIGRlZmluaXRpb24gIG9mICB3aGF0ICB3ZSAgbWVh biAgYnkgIGl0ICBpbiAgUFBTUC4NCg0KKDI4KSAgU2VjdGlvbiAgNS4zICAtICAiV2l0aCAgUFBT UCAgUGVlcnMiICAtID4gICJXaXRoICBQUFNQLCAgcGVlcnMiDQoNCigyOSkgIFNlY3Rpb24gIDUu NCAgLSAgQ0RTICBpcyAgbm90ICBkZWZpbmVkDQoNCigzMCkgIFNlY3Rpb24gIDUuNSAgLSAgSSAg dW5kZXJzdGFuZCAgdGhlICBpbnRlbnQsICBidXQgIHRoZSAgZmlyc3QgIHR3byAgcGFyYWdyYXBo cyAgDQpoZXJlICBuZWVkICB0byAgYmUgIGNsZWFuZWQgIHVwICBhbmQgIGNsYXJpZmllZC4gICAg VGhlICBmaWd1cmUgIGlzICB2ZXJ5ICBjbGVhcjsgIHRoZSAgDQp0ZXh0ICBpc24ndC4NCg0KKDMx KSAgVGhlICBkb2N1bWVudCAgc2hvdWxkICBjb25zaXN0ZW50bHkgIHVzZSAgZWl0aGVyICAiUDJQ IiAgb3IgICJwMnAiDQoNCigzMikgIE1hbnkgIG9mICB0aGUgIEluZm9ybWF0aXZlICBSZWZlcmVu Y2VzICBhcmUgIG9ubHkgIFVSTHMsICBhbmQgIEkgIHN1c3BlY3QgIA0KdGhpcyAgUkZDICB3aWxs ICBsaXZlICBvbiAgbXVjaCAgbG9uZ2VyICB0aGFuICBtb3N0ICBvZiAgdGhvc2UgIFVSTHMuICAg IEkgIHRoaW5rICB0aGF0ICANCndoZXJldmVyICBpdCdzICByZWFzb25hYmxlLCAgdGhvc2UgIFVS THMgIHNob3VsZCAgYmUgIHJlcGxhY2VkICB3aXRoICBtb3JlICBzdGFibGUgIA0KcmVmZXJlbmNl cy4gICAgSSAgdW5kZXJzdGFuZCAgdGhhdCAgdGhpcyAgd29uJ3QgIGJlICBwb3NzaWJsZSAgaW4g IGFsbCAgY2FzZXMuDQoNCg0KVGhhbmtzICBmb3IgIGJlYXJpbmcgIHdpdGggIHRoZXNlICBpbiAg b3JkZXIgIHRvICBwcm9ncmVzcyAgdGhpcyAgZG9jdW1lbnQuDQoNCi0tICANCldlcyAgRWRkeQ0K TVRJICBTeXN0ZW1zDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KcHBzcCAgbWFpbGluZyAgbGlzdA0KcHBzcEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNwDQo= --=====003_Dragon253423115650_===== Content-Transfer-Encoding: base64 Content-Type: text/html; charset="gb2312" PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBuYW1lPUdFTkVSQVRPUiBjb250 ZW50PSJNU0hUTUwgOS4wMC44MTEyLjE2NDM3Ij4NCjxTVFlMRT4NCjwhLS0NCiAvKiBGb250IERl ZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrLzszlOw0KCXBhbm9zZS0x OjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5h Ow0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlxAy87M5SI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQogLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246 anVzdGlmeTsNCgl0ZXh0LWp1c3RpZnk6aW50ZXItaWRlb2dyYXBoOw0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe2NvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6VmVyZGFuYTsNCgljb2xvcjp3aW5k b3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0 LWRlY29yYXRpb246bm9uZSBub25lO30NCiAvKiBQYWdlIERlZmluaXRpb25zICovDQogQHBhZ2Ug U2VjdGlvbjENCgl7c2l6ZTo1OTUuM3B0IDg0MS45cHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDsNCglsYXlvdXQtZ3JpZDoxNS42cHQ7fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KLS0+DQo8L1NUWUxFPg0KPC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGNvbG9yPSMwMDAwZmYgc2l6ZT0yIGZhY2U9VmVyZGFuYT5UaGFua3MgV2VzIGZvciB5b3VyIGNh cmVmdWwgcmV2aWV3LiANCkknbGwgdXBkYXRlIHRoZSBkb2N1bWVudCZuYnNwO3Nvb24gYWNjb3Jk aW5nIHRvIHlvdXIgc3VnZ2VzdGlvbnMuIFRoYW5rcyANCmFnYWluLjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTIgZmFjZT1WZXJkYW5hPkJSPC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIHNpemU9MiBmYWNlPVZlcmRhbmE+ WXVuZmVpPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJkYW5hPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVYgYWxpZ249bGVmdD4NCjxESVYgYWxpZ249bGVmdD48Rk9OVCBz aXplPTIgZmFjZT1WZXJkYW5hPg0KPEhSIHN0eWxlPSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4 IiBTSVpFPTI+DQo8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSNjMGMwYzA+PEZPTlQg c2l6ZT0yIGZhY2U9VmVyZGFuYT56aGFuZ3l1bmZlaTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yIGZhY2U9VmVyZGFuYT4yMDExLTEwLTE4PC9GT05UPjwvRk9OVD48L0RJVj48L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxIUj4NCjwvRk9OVD48L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPreivP7Iy6O6PC9TVFJP Tkc+IFdlc2xleSANCkVkZHk8L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZl cmRhbmE+PEZPTlQgc2l6ZT0yPjxTVFJPTkc+t6LLzcqxvOSjujwvU1RST05HPiANCjIwMTEtMTAt MTgmbmJzcDsxMjoyOTo0MzwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVy ZGFuYT48Rk9OVCBzaXplPTI+PFNUUk9ORz7K1bz+yMujujwvU1RST05HPiANCnBwc3BAaWV0Zi5v cmc8L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmE+PEZPTlQgc2l6 ZT0yPjxTVFJPTkc+s63LzaO6PC9TVFJPTkc+IA0KZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3Rh dGVtZW50QHRvb2xzLmlldGYub3JnPC9GT05UPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFj ZT1WZXJkYW5hPjxGT05UIHNpemU9Mj48U1RST05HPtb3zOKjujwvU1RST05HPiBbcHBzcF0gQUQg cmV2aWV3IG9mIA0KZHJhZnQtaWV0Zi1wcHNwLXByb2JsZW0tc3RhdGVtZW50LTA1PC9GT05UPjwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+DQo8RElWPkkndmUgJm5ic3A7 Y29tcGxldGVkICZuYnNwO0FEICZuYnNwO3JldmlldyAmbmJzcDtvZiAmbmJzcDt0aGlzIA0KJm5i c3A7ZG9jdW1lbnQsICZuYnNwO2FuZCAmbmJzcDt3aGlsZSAmbmJzcDt0aGUgJm5ic3A7Y29udGVu dCAmbmJzcDtpcyANCiZuYnNwOzwvRElWPg0KPERJVj5jb21wbGV0ZSwgJm5ic3A7SSAmbmJzcDtk b24ndCAmbmJzcDt0aGluayAmbmJzcDtpdCdzICZuYnNwO2VkaXRvcmlhbGx5IA0KJm5ic3A7cXVp dGUgJm5ic3A7cmVhZHkgJm5ic3A7Zm9yICZuYnNwO0lFVEYgJm5ic3A7TGFzdCAmbmJzcDtDYWxs ICZuYnNwOzwvRElWPg0KPERJVj5hbmQgJm5ic3A7SUVTRyAmbmJzcDtyZXZpZXcuICZuYnNwOyAm bmJzcDtNeSAmbmJzcDtjb21tZW50cyAmbmJzcDtiZWxvdyANCiZuYnNwO2FyZSAmbmJzcDtpbnRl bmRlZCAmbmJzcDt0byAmbmJzcDtoZWxwICZuYnNwO2dldCAmbmJzcDtpdCAmbmJzcDt0aGVyZS4g DQombmJzcDs8L0RJVj4NCjxESVY+SW4gJm5ic3A7c29tZSAmbmJzcDtjYXNlcywgJm5ic3A7SSAm bmJzcDtpbmRpY2F0ZWQgJm5ic3A7c3VnZ2VzdGVkIA0KJm5ic3A7Y2hhbmdlcyAmbmJzcDt3aXRo ICZuYnNwO2FuICZuYnNwO2Fycm93ICZuYnNwOyJmcm9tICZuYnNwOy0gJmd0OyAmbmJzcDt0byIg DQombmJzcDs8L0RJVj4NCjxESVY+YmV0d2VlbiAmbmJzcDt0aGUgJm5ic3A7b3JpZ2luYWwgJm5i c3A7ImZyb20iICZuYnNwO3RleHQgJm5ic3A7YW5kIA0KJm5ic3A7dGhlICZuYnNwO3N1Z2dlc3Rl ZCAmbmJzcDsidG8iICZuYnNwO3RleHQuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj5X aGlsZSAmbmJzcDtpdCAmbmJzcDtzZWVtcyAmbmJzcDtsaWtlICZuYnNwO2EgJm5ic3A7bG90LCAm bmJzcDttb3N0IA0KJm5ic3A7b2YgJm5ic3A7dGhlc2UgJm5ic3A7YXJlICZuYnNwO2FjdHVhbGx5 ICZuYnNwO3ByZXR0eSAmbmJzcDttaW5vciANCiZuYnNwO2NoYW5nZXMuPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj4oMSkgJm5ic3A7SW4gJm5ic3A7dGhlICZuYnNwO2Fic3RyYWN0ICZu YnNwOyhhbmQgJm5ic3A7cG9zc2libHkgJm5ic3A7dGhlIA0KJm5ic3A7dGl0bGUgJm5ic3A7dG9v KSwgJm5ic3A7UDJQICZuYnNwO3Nob3VsZCAmbmJzcDtiZSAmbmJzcDtzcGVsbGVkIA0KJm5ic3A7 PC9ESVY+DQo8RElWPm91dCAmbmJzcDthcyAmbmJzcDtwZWVyLXRvLXBlZXIuICZuYnNwOyAmbmJz cDtJbiAmbmJzcDt0aGUgJm5ic3A7YWJzdHJhY3QsIA0KJm5ic3A7IlBQU1AiICZuYnNwO3Nob3Vs ZCAmbmJzcDtiZSAmbmJzcDtkZWZpbmVkICZuYnNwO2JlZm9yZSAmbmJzcDs8L0RJVj4NCjxESVY+ dXNlICZuYnNwO3NpbmNlICZuYnNwO3RoaXMgJm5ic3A7cGFyYWdyYXBoICZuYnNwO3dpbGwgJm5i c3A7YXBwZWFyICZuYnNwO2luIA0KJm5ic3A7YW5ub3VuY2VtZW50cyAmbmJzcDsoZS5nLiAmbmJz cDtmb3IgJm5ic3A7SUVURiAmbmJzcDtMQykgJm5ic3A7PC9ESVY+DQo8RElWPmFuZCAmbmJzcDtv dGhlciAmbmJzcDtwbGFjZXMuICZuYnNwOyAmbmJzcDtOb3RlICZuYnNwO3RoYXQgJm5ic3A7UFBT UCANCiZuYnNwO2lzICZuYnNwO3Npbmd1bGFyICZuYnNwOygiUHJvdG9jb2wiLCAmbmJzcDtub3Qg Jm5ic3A7PC9ESVY+DQo8RElWPiJQcm90b2NvbHMiLCAmbmJzcDtidXQgJm5ic3A7dGhlICZuYnNw O2xhc3QgJm5ic3A7c2VudGVuY2UgJm5ic3A7b2YgDQombmJzcDt0aGUgJm5ic3A7YWJzdHJhY3Qg Jm5ic3A7YW5kICZuYnNwO3RoZSAmbmJzcDt0aXRsZSAmbmJzcDtvZiAmbmJzcDs8L0RJVj4NCjxE SVY+U2VjdGlvbiAmbmJzcDs0ICZuYnNwO3VzZSAmbmJzcDtwbHVyYWwpLiAmbmJzcDsgJm5ic3A7 SSAmbmJzcDt0aGluayANCiZuYnNwO2l0ICZuYnNwO3dvdWxkICZuYnNwO2JlICZuYnNwO2dvb2Qg Jm5ic3A7dG8gJm5ic3A7YmUgJm5ic3A7bW9yZSANCiZuYnNwO2NsZWFyICZuYnNwO2hlcmUgJm5i c3A7PC9ESVY+DQo8RElWPmFuZCAmbmJzcDtzYXkgJm5ic3A7c29tZXRoaW5nICZuYnNwO21vcmUg Jm5ic3A7bGlrZSAmbmJzcDsicHJvcG9zZXMgJm5ic3A7YSANCiZuYnNwO1BlZXIgJm5ic3A7dG8g Jm5ic3A7UGVlciAmbmJzcDtTdHJlYW1pbmcgJm5ic3A7UHJvdG9jb2wgJm5ic3A7PC9ESVY+DQo8 RElWPihQUFNQKSAmbmJzcDtpbmNsdWRpbmcgJm5ic3A7dHJhY2tlciAmbmJzcDthbmQgJm5ic3A7 cGVlciAmbmJzcDtzaWduYWxpbmcgDQombmJzcDtjb21wb25lbnRzLCAmbmJzcDthbmQgJm5ic3A7 ZGlzY3Vzc2VzICZuYnNwOzwvRElWPg0KPERJVj50aGUgJm5ic3A7c2NvcGUgJm5ic3A7YW5kICZu YnNwO3VzZXMgJm5ic3A7Y2FzZXMgJm5ic3A7b2YgDQombmJzcDtQUFNQLiI8L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4oMikgJm5ic3A7c2VjdGlvbiAm bmJzcDsxLCAmbmJzcDsybmQgJm5ic3A7cGFyYWdyYXBoICZuYnNwOy0gJm5ic3A7IlRoaXMgDQom bmJzcDtpcyAmbmJzcDtsZXNzICZuYnNwO2NoYWxsZW5naW5nICZuYnNwO2ZvciAmbmJzcDtoaWdo bHkgJm5ic3A7PC9ESVY+DQo8RElWPmluY3JlYXNpbmcgJm5ic3A7Y2FwYWJpbGl0eSAmbmJzcDtv biAmbmJzcDtoYXJkd2FyZS4iICZuYnNwOyAmbmJzcDsgJm5ic3A7SSANCiZuYnNwO3RoaW5rICZu YnNwO3RoaXMgJm5ic3A7c2VudGVuY2UgJm5ic3A7aXMgJm5ic3A7dmFndWUgJm5ic3A7YXQgJm5i c3A7PC9ESVY+DQo8RElWPmJlc3QgJm5ic3A7YW5kICZuYnNwO2xpa2VseSAmbmJzcDttaXNsZWFk aW5nLiAmbmJzcDsgJm5ic3A7VGhlIA0KJm5ic3A7c2VudGVuY2UgJm5ic3A7cHJpb3IgJm5ic3A7 dG8gJm5ic3A7aXQgJm5ic3A7dGFsa3MgJm5ic3A7YWJvdXQgDQombmJzcDs8L0RJVj4NCjxESVY+ bmV0d29yayAmbmJzcDtlZmZpY2llbmN5ICZuYnNwO3dpdGhvdXQgJm5ic3A7ZGVmaW5pbmcgJm5i c3A7aW4gJm5ic3A7d2hhdCANCiZuYnNwO3NlbnNlICZuYnNwO3RoaXMgJm5ic3A7aXMgJm5ic3A7 bWVhbnQgJm5ic3A7KGlzICZuYnNwO2l0ICZuYnNwOzwvRElWPg0KPERJVj5lZmZpY2llbnQgJm5i c3A7dXNlICZuYnNwO29mICZuYnNwO2JhbmR3aWR0aCwgJm5ic3A7bG93LWxhdGVuY3ksICZuYnNw O2xvdyANCiZuYnNwO2xvYWQgJm5ic3A7b24gJm5ic3A7c2VydmVycywgJm5ic3A7bG93ICZuYnNw O3Bvd2VyICZuYnNwOzwvRElWPg0KPERJVj51c2FnZSwgJm5ic3A7ZXRjLikuICZuYnNwOyAmbmJz cDtUaGUgJm5ic3A7dHlwZSAmbmJzcDtvZiAmbmJzcDtlZmZpY2llbmN5IA0KJm5ic3A7bWVhbnQg Jm5ic3A7aGVyZSAmbmJzcDtzaG91bGQgJm5ic3A7YmUgJm5ic3A7Y2xhcmlmaWVkLCAmbmJzcDs8 L0RJVj4NCjxESVY+YW5kICZuYnNwO2NvbnNpZGVyICZuYnNwO2VpdGhlciAmbmJzcDtyZW1vdmlu ZyAmbmJzcDtvciAmbmJzcDtmdXJ0aGVyIA0KJm5ic3A7Y2xhcmlmeWluZyAmbmJzcDt0aGUgJm5i c3A7c2VudGVuY2UgJm5ic3A7PC9ESVY+DQo8RElWPmZvbGxvd2luZyAmbmJzcDtpdCAmbmJzcDth Ym91dCAmbmJzcDtoYXJkd2FyZSAmbmJzcDtjYXBhYmlsaXRpZXMuPC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KDMpICZuYnNwO3NlY3Rpb24gJm5ic3A7 MSwgJm5ic3A7M3JkICZuYnNwO3BhcmFncmFwaCAmbmJzcDstICZuYnNwO0RvZXMgDQombmJzcDsi c291cmNlIiAmbmJzcDtoZXJlICZuYnNwO3JlZmVyICZuYnNwO3RvICZuYnNwO3RoZSAmbmJzcDtv cmlnaW5hbCANCiZuYnNwOzwvRElWPg0KPERJVj5zb3VyY2UgJm5ic3A7b2YgJm5ic3A7dGhlICZu YnNwO21lZGlhICZuYnNwO2JlaW5nICZuYnNwO3N0cmVhbWVkLCAmbmJzcDt0aGUgDQombmJzcDty b290ICZuYnNwO25vZGUgJm5ic3A7YWN0dWFsbHkgJm5ic3A7dHJhbnNtaXR0aW5nICZuYnNwOzwv RElWPg0KPERJVj5zdHJlYW0sICZuYnNwO29yICZuYnNwO3NvbWV0aGluZyAmbmJzcDtlbHNlPyAm bmJzcDsgJm5ic3A7SSAmbmJzcDt0aGluayANCiZuYnNwOyJoZXRlcm9nZW5lb3VzICZuYnNwO2tp bmRzICZuYnNwO29mICZuYnNwO3Rlcm1pbmFscyIgJm5ic3A7PC9ESVY+DQo8RElWPndvdWxkICZu YnNwO2JlICZuYnNwO21vcmUgJm5ic3A7Y2xlYXIgJm5ic3A7YXMgJm5ic3A7ImhldGVyb2dlbmVv dXMgDQombmJzcDt0eXBlcyAmbmJzcDtvZiAmbmJzcDtwZWVyICZuYnNwO29yICZuYnNwO2NsaWVu dCAmbmJzcDtkZXZpY2UgJm5ic3A7PC9ESVY+DQo8RElWPnBsYXRmb3Jtcy4iPzwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+KDQpICZuYnNwO3NlY3Rpb24gJm5ic3A7MSwgJm5ic3A7NHRo ICZuYnNwO3BhcmFncmFwaCAmbmJzcDstICZuYnNwOyJsYWNraW5nIA0KJm5ic3A7b2YgJm5ic3A7 YW4iICZuYnNwOy0gJmd0OyAmbmJzcDsibGFjayAmbmJzcDtvZiAmbmJzcDthbiI8L0RJVj4NCjxE SVY+Jm5ic3A7PC9ESVY+DQo8RElWPig1KSAmbmJzcDtzZWN0aW9uICZuYnNwOzEsICZuYnNwOzJu ZCAmbmJzcDt0byAmbmJzcDtsYXN0ICZuYnNwO3BhcmFncmFwaCANCiZuYnNwOy0gJm5ic3A7d2hl biAmbmJzcDsiUFBTUCIgJm5ic3A7aXMgJm5ic3A7Zmlyc3QgJm5ic3A7dXNlZCwgJm5ic3A7ZGVm aW5lIA0KJm5ic3A7aXQuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4oNikgJm5ic3A7 c2VjdGlvbiAmbmJzcDsyICZuYnNwOy0gJm5ic3A7VGhlICZuYnNwO2RlZmluaXRpb24gJm5ic3A7 b2YgDQombmJzcDtDaHVuayAmbmJzcDtpcyAmbmJzcDtwcmV0dHkgJm5ic3A7bm9uLXNwZWNpZmlj OyAmbmJzcDtmb3IgJm5ic3A7PC9ESVY+DQo8RElWPmluc3RhbmNlLCAmbmJzcDthcy11c2VkICZu YnNwO2luICZuYnNwO1BQU1AsICZuYnNwO2lzICZuYnNwO2EgJm5ic3A7Y2h1bmsgDQombmJzcDtp bnRlbmRlZCAmbmJzcDt0byAmbmJzcDtmaXQgJm5ic3A7aW4gJm5ic3A7YSAmbmJzcDtzaW5nbGUg Jm5ic3A7PC9ESVY+DQo8RElWPnRyYW5zbWl0dGVkICZuYnNwO3BhY2tldCAmbmJzcDtvciAmbmJz cDtpcyAmbmJzcDtpdCAmbmJzcDtnZW5lcmFsbHkgJm5ic3A7YSANCiZuYnNwO2xhcmdlciAmbmJz cDt1bml0ICZuYnNwO29mICZuYnNwO3NldmVyYWwgJm5ic3A7a0I/ICZuYnNwOyAmbmJzcDtJdCdz IA0KJm5ic3A7PC9ESVY+DQo8RElWPmFsc28gJm5ic3A7dW5jbGVhciAmbmJzcDt3aGF0J3MgJm5i c3A7bWVhbnQgJm5ic3A7YnkgJm5ic3A7InBhcnRpdGlvbmVkIA0KJm5ic3A7c3RyZWFtaW5nIiAm bmJzcDtoZXJlLCAmbmJzcDthcyAmbmJzcDt0aGF0ICZuYnNwO3Rlcm0gJm5ic3A7PC9ESVY+DQo8 RElWPmlzICZuYnNwO25vdCAmbmJzcDt1c2VkICZuYnNwO29yICZuYnNwO2RlZmluZWQgJm5ic3A7 ZWxzZXdoZXJlICZuYnNwO2luIA0KJm5ic3A7dGhlICZuYnNwO2RvY3VtZW50ICZuYnNwO2FzICZu YnNwO3RvICZuYnNwO2hvdyAmbmJzcDtpdCAmbmJzcDtkaWZmZXJzIA0KJm5ic3A7PC9ESVY+DQo8 RElWPmZyb20gJm5ic3A7anVzdCAmbmJzcDsic3RyZWFtaW5nIi48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPig3KSAmbmJzcDtzZWN0aW9uICZuYnNwOzIgJm5ic3A7LSAmbmJzcDtJbiAm bmJzcDt0aGUgJm5ic3A7c3dhcm0gDQombmJzcDtkZWZpbml0aW9uLCAmbmJzcDtJICZuYnNwO3Ro aW5rICZuYnNwO2l0ICZuYnNwO3dvdWxkICZuYnNwO2JlIA0KJm5ic3A7cmVhc29uYWJsZSAmbmJz cDs8L0RJVj4NCjxESVY+dG8gJm5ic3A7c2F5ICZuYnNwO3RoYXQgJm5ic3A7dGhleSAmbmJzcDsi ZGlzdHJpYnV0ZSAmbmJzcDtjaHVua3MgJm5ic3A7b2YgDQombmJzcDt0aGUgJm5ic3A7c2FtZSAm bmJzcDtjb250ZW50IiwgJm5ic3A7aW4gJm5ic3A7b3JkZXIgJm5ic3A7dG8gJm5ic3A7PC9ESVY+ DQo8RElWPnRpZSAmbmJzcDt0aGUgJm5ic3A7c3dhcm0gJm5ic3A7ZGVmaW5pdGlvbiAmbmJzcDtp bnRvICZuYnNwO3RoYXQgDQombmJzcDtvdGhlciAmbmJzcDtkZWZpbmVkICZuYnNwO3Rlcm0uPC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4oOCkgJm5ic3A7d2h5ICZuYnNwO2lzICZuYnNw O0FMVE8ncyAmbmJzcDtwcm9ibGVtICZuYnNwO3N0YXRlbWVudCANCiZuYnNwOyhSRkMgJm5ic3A7 NTY5MykgJm5ic3A7bGlzdGVkICZuYnNwO2FzICZuYnNwO25vcm1hdGl2ZT8gJm5ic3A7ICZuYnNw O0kgDQombmJzcDs8L0RJVj4NCjxESVY+ZG9uJ3QgJm5ic3A7YmVsaWV2ZSAmbmJzcDtpdCAmbmJz cDtyZWFsbHkgJm5ic3A7aXMgJm5ic3A7bm9ybWF0aXZlICZuYnNwO3RvIA0KJm5ic3A7dGhpcyAm bmJzcDtQUFNQICZuYnNwO2RvY3VtZW50LCAmbmJzcDt0aG91Z2ggJm5ic3A7aXQncyAmbmJzcDs8 L0RJVj4NCjxESVY+Y2VydGFpbmx5ICZuYnNwO2luZm9ybWF0aXZlLjwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+KDkpICZuYnNwO1NlY3Rpb24gJm5ic3A7My4xLCAmbmJzcDtsYXN0ICZu YnNwO3BhcmFncmFwaC4gJm5ic3A7ICZuYnNwO1dlIA0KJm5ic3A7dGFsayAmbmJzcDthYm91dCAm bmJzcDtQUFNQICZuYnNwO2hlcmUgJm5ic3A7YXMgJm5ic3A7aWYgJm5ic3A7aXQgDQombmJzcDs8 L0RJVj4NCjxESVY+YWxyZWFkeSAmbmJzcDtleGlzdHMgJm5ic3A7aW4gJm5ic3A7YSAmbmJzcDt1 c2FibGUgJm5ic3A7Zm9ybS4gJm5ic3A7IA0KJm5ic3A7SW5zdGVhZCAmbmJzcDtvZiAmbmJzcDsi Y2FuIiAmbmJzcDt3ZSAmbmJzcDtwcm9iYWJseSAmbmJzcDtuZWVkICZuYnNwO3RvIA0KJm5ic3A7 PC9ESVY+DQo8RElWPnNheSAmbmJzcDsic2hvdWxkICZuYnNwO2JlICZuYnNwO2FibGUgJm5ic3A7 dG8iLCAmbmJzcDtmb3IgJm5ic3A7aW5zdGFuY2UsIA0KJm5ic3A7YW5kICZuYnNwO3RoZXJlICZu YnNwO2FyZSAmbmJzcDtvdGhlciAmbmJzcDtzaW1pbGFyICZuYnNwOzwvRElWPg0KPERJVj5jaGFu Z2VzICZuYnNwO2luICZuYnNwO3RoaXMgJm5ic3A7cGFyYWdyYXBoICZuYnNwO3RoYXQgJm5ic3A7 c2hvdWxkIA0KJm5ic3A7bm90ICZuYnNwO21pc2xlYWQgJm5ic3A7c29tZW9uZSAmbmJzcDtpbnRv ICZuYnNwO3RoaW5raW5nICZuYnNwOzwvRElWPg0KPERJVj5hICZuYnNwO1BQU1AgJm5ic3A7cHJv ZHVjdCAmbmJzcDtpcyAmbmJzcDthbHJlYWR5ICZuYnNwO2luICZuYnNwO2V4aXN0ZW5jZSANCiZu YnNwO2FuZCAmbmJzcDtkb2VzICZuYnNwO3RoZXNlICZuYnNwO3RoaW5ncy48L0RJVj4NCjxESVY+ Jm5ic3A7PC9ESVY+DQo8RElWPigxMCkgJm5ic3A7U2VjdGlvbiAmbmJzcDszLjIgJm5ic3A7LSAm bmJzcDsiUDJQLXR5cGUgJm5ic3A7aXMgDQombmJzcDthY2NvdW50aW5nICZuYnNwO2ZvciAmbmJz cDthICZuYnNwO2xhcmdlICZuYnNwO3BvcnRpb24iICZuYnNwOy0gJmd0OyANCiZuYnNwOzwvRElW Pg0KPERJVj4ic3lzdGVtcyAmbmJzcDt1c2luZyAmbmJzcDtQMlAgJm5ic3A7YWNjb3VudCAmbmJz cDtmb3IgJm5ic3A7YSAmbmJzcDtsYXJnZSANCiZuYnNwO3BvcnRpb24iLjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+KDExKSAmbmJzcDtTZWN0aW9uICZuYnNwOzMuMiAmbmJzcDstICZu YnNwOyJ2YXN0ICZuYnNwO29mICZuYnNwO3NhbWUiIA0KJm5ic3A7LSAmZ3Q7ICZuYnNwOyJ2YXN0 bHkgJm5ic3A7dGhlICZuYnNwO3NhbWUiPzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ KDEyKSAmbmJzcDtTZWN0aW9uICZuYnNwOzMuMiAmbmJzcDstICZuYnNwOyJjb250ZW50cywgJm5i c3A7aW5jcmVhc2VzIiANCiZuYnNwOy0gJmd0OyAmbmJzcDsiY29udGVudHMsICZuYnNwO2FuZCAm bmJzcDtpbmNyZWFzZXMiPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4oMTMpICZuYnNw O1NlY3Rpb24gJm5ic3A7My4yICZuYnNwOy0gJm5ic3A7IkNETiAmbmJzcDtwcm92aWRlciIgJm5i c3A7LSANCiZndDsgJm5ic3A7IkNETiAmbmJzcDtwcm92aWRlcnMiPC9ESVY+DQo8RElWPiZuYnNw OzwvRElWPg0KPERJVj4oMTQpICZuYnNwO1NlY3Rpb24gJm5ic3A7My4yICZuYnNwOy0gJm5ic3A7 ImNhbiAmbmJzcDtiZSAmbmJzcDtlaXRoZXIgDQombmJzcDtIVFRQICZuYnNwO29yICZuYnNwO1BQ U1AiICZuYnNwOy0gJmd0OyAmbmJzcDsiY291bGQgJm5ic3A7YmUgJm5ic3A7dmlhIA0KJm5ic3A7 PC9ESVY+DQo8RElWPnNvbWV0aGluZyAmbmJzcDtsaWtlICZuYnNwO3RyYWRpdGlvbmFsICZuYnNw O0hUVFAgJm5ic3A7cmVxdWVzdHMsICZuYnNwO29yIA0KJm5ic3A7Y291bGQgJm5ic3A7dXNlICZu YnNwO3N0cmVhbWluZyAmbmJzcDtzZXR1cCAmbmJzcDs8L0RJVj4NCjxESVY+dmlhICZuYnNwO1BQ U1AuIj88L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPigxNSkgJm5ic3A7U2VjdGlvbiAm bmJzcDszLjMgJm5ic3A7LSAmbmJzcDsic2V2ZW50ZWVuICZuYnNwO21pbGxpb25zIiANCiZuYnNw Oy0gJmd0OyAmbmJzcDsic2V2ZW50ZWVuICZuYnNwO21pbGxpb24iLCAmbmJzcDthbmQgJm5ic3A7 PC9ESVY+DQo8RElWPiJtb3JlICZuYnNwO2FuZCAmbmJzcDttb3JlICZuYnNwO3N0dWRpZXMiICZu YnNwOy0gJmd0OyAmbmJzcDsibXVsdGlwbGUgDQombmJzcDtwcmlvciAmbmJzcDtzdHVkaWVzIjwv RElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KDE2KSAmbmJzcDtTZWN0aW9uICZuYnNwOzMu MyAmbmJzcDstICZuYnNwOyJsb3dlciAmbmJzcDthbmQgJm5ic3A7Y29zdGx5IiANCiZuYnNwOy0g Jmd0OyAmbmJzcDsibG93ZXIgJm5ic3A7cmF0ZSwgJm5ic3A7YW5kICZuYnNwO2Nvc3RseSAmbmJz cDtpbiANCiZuYnNwOzwvRElWPg0KPERJVj50ZXJtcyAmbmJzcDtvZiAmbmJzcDtlbmVyZ3kgJm5i c3A7Y29uc3VtcHRpb24iPzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KDE3KSAmbmJz cDtTZWN0aW9uICZuYnNwOzMuMyAmbmJzcDstICZuYnNwOyJyZWxhdGl2ZWx5ICZuYnNwO2ZyZXF1 ZXN0IA0KJm5ic3A7dG8gJm5ic3A7ZXhjaGFuZ2UiICZuYnNwOy0gJmd0OyAmbmJzcDsiZXhjaGFu Z2VkICZuYnNwOzwvRElWPg0KPERJVj5yZWxhdGl2ZWx5ICZuYnNwO2ZyZXF1ZW50bHkiPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4oMTgpICZuYnNwO1NlY3Rpb24gJm5ic3A7My4zICZu YnNwOy0gJm5ic3A7SSAmbmJzcDtkbyAmbmJzcDtub3QgDQombmJzcDt1bmRlcnN0YW5kICZuYnNw O3RoZSAmbmJzcDtzZW50ZW5jZSAmbmJzcDsiVGhlICZuYnNwO25ldy1hZGRlZCANCiZuYnNwOzwv RElWPg0KPERJVj5pbmZvcm1hdGlvbiAmbmJzcDtzaG91bGQgJm5ic3A7aGVscCAmbmJzcDt0aGUg Jm5ic3A7dHJhY2tlci9wZWVyICZuYnNwO3RvIA0KJm5ic3A7bWFrZSAmbmJzcDt0aGUgJm5ic3A7 ZGVjaXNpb24iLiAmbmJzcDs8L0RJVj4NCjxESVY+Q29uc2lkZXIgJm5ic3A7cmVtb3ZpbmcgJm5i c3A7dGhpcyAmbmJzcDtvciAmbmJzcDtmaW5kaW5nICZuYnNwO2EgJm5ic3A7d2F5IA0KJm5ic3A7 dG8gJm5ic3A7Y2xhcmlmeSAmbmJzcDt3aGF0ICZuYnNwO2l0ICZuYnNwO21lYW5zLCAmbmJzcDtp ZiAmbmJzcDs8L0RJVj4NCjxESVY+aXQncyAmbmJzcDtuZWNlc3NhcnkgJm5ic3A7dG8gJm5ic3A7 a2VlcC48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPigxOSkgJm5ic3A7U2VjdGlvbiAm bmJzcDszLjMgJm5ic3A7LSAmbmJzcDsibWF5YmUgJm5ic3A7cmVxdWlyZXMgJm5ic3A7YSANCiZu YnNwO25ldyAmbmJzcDtleHByZXNzaW9uICZuYnNwO29uICZuYnNwOyJiaXRtYXAiIiAmbmJzcDst ICZndDsgJm5ic3A7Im1heSANCiZuYnNwOzwvRElWPg0KPERJVj5yZXF1aXJlICZuYnNwO2FsdGVy bmF0aXZlICZuYnNwO21ldGhvZHMgJm5ic3A7Zm9yICZuYnNwO2Rpc3RyaWJ1dGluZyANCiZuYnNw O2JpdG1hcCAmbmJzcDtpbmZvcm1hdGlvbiI/PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj4mbmJzcDs8L0RJVj4NCjxESVY+KDIwKSAmbmJzcDtTZWN0aW9uICZuYnNwOzMuNCAmbmJzcDst ICZuYnNwOyJyZXNvdXJjZS1jb25zdHJhaW50IiAmbmJzcDstIA0KJmd0OyAmbmJzcDsicmVzb3Vy Y2UtY29uc3RyYWluZWQiICZuYnNwO2luICZuYnNwOzwvRElWPg0KPERJVj50aGUgJm5ic3A7dGl0 bGUgJm5ic3A7YW5kICZuYnNwO3RleHQ8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPigy MSkgJm5ic3A7U2VjdGlvbiAmbmJzcDszLjQgJm5ic3A7LSAmbmJzcDsic2V0ICZuYnNwO3RvcCAm bmJzcDtib3giIA0KJm5ic3A7LSAmZ3Q7ICZuYnNwOyJzZXQgJm5ic3A7dG9wICZuYnNwO2JveGVz ICZuYnNwOyhTVEJzKSI8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPigyMikgJm5ic3A7 U2VjdGlvbiAmbmJzcDszLjQgJm5ic3A7LSAmbmJzcDt0aGlzICZuYnNwO3Nob3VsZCAmbmJzcDti ZSANCiZuYnNwO2NsYXJpZmllZCAmbmJzcDt0byAmbmJzcDtkaXN0aW5ndWlzaCAmbmJzcDtiZXR3 ZWVuICZuYnNwOzwvRElWPg0KPERJVj53aGV0aGVyICZuYnNwO3RoZSAmbmJzcDtyZXNvdXJjZSAm bmJzcDt0aGF0J3MgJm5ic3A7Y29uc3RyYWluZWQgJm5ic3A7aXMgDQombmJzcDt0aGUgJm5ic3A7 cGVyc2lzdGVudCAmbmJzcDtzdG9yYWdlICZuYnNwO29yICZuYnNwO1JBTSAmbmJzcDs8L0RJVj4N CjxESVY+b24gJm5ic3A7dGhlICZuYnNwO2RldmljZXM8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+ DQo8RElWPigyMykgJm5ic3A7U2VjdGlvbiAmbmJzcDs0ICZuYnNwOy0gJm5ic3A7ImFyZSAmbmJz cDtiZWxvbmdpbmciICZuYnNwOy0gJmd0OyANCiZuYnNwOyJiZWxvbmciPC9ESVY+DQo8RElWPiZu YnNwOzwvRElWPg0KPERJVj4oMjQpICZuYnNwO1NlY3Rpb24gJm5ic3A7NCAmbmJzcDstICZuYnNw O0luICZuYnNwO3RoZSAmbmJzcDtkZXNjcmlwdGlvbiANCiZuYnNwO29mICZuYnNwO3B1c2gtYmFz ZWQgJm5ic3A7YW5kICZuYnNwO2h5YnJpZCAmbmJzcDttb2RlcywgJm5ic3A7aXQncyANCiZuYnNw OzwvRElWPg0KPERJVj51bmNsZWFyICZuYnNwO2hvdyAmbmJzcDtwZWVycyAmbmJzcDtmaW5kICZu YnNwO3RoZSAmbmJzcDtoZWFkICZuYnNwO25vZGUgDQombmJzcDtvciAmbmJzcDtob3cgJm5ic3A7 dGhleSAmbmJzcDtmaW5kICZuYnNwO2VhY2ggJm5ic3A7b3RoZXIgJm5ic3A7PC9ESVY+DQo8RElW PmNvbXBhcmVkICZuYnNwO3RvICZuYnNwO2hvdyAmbmJzcDt0aGV5ICZuYnNwO2ZpbmQgJm5ic3A7 dGhlICZuYnNwO3RyYWNrZXIgDQombmJzcDtpbiAmbmJzcDthICZuYnNwO3B1bGwtYmFzZWQgJm5i c3A7bW9kZS4gJm5ic3A7ICZuYnNwO1RoaXMgJm5ic3A7PC9ESVY+DQo8RElWPnByb2JhYmx5ICZu YnNwO3JlcXVpcmVzICZuYnNwO2EgJm5ic3A7YnJpZWYgJm5ic3A7ZGVzY3JpcHRpb24uPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4oMjUpICZuYnNwO1NlY3Rpb24gJm5ic3A7NCAmbmJz cDstICZuYnNwO0luc3RlYWQgJm5ic3A7b2YgDQombmJzcDtzYXlpbmc6PC9ESVY+DQo8RElWPiZu YnNwOyAmbmJzcDsiUFBTUCAmbmJzcDtpcyAmbmJzcDt0YXJnZXRlZCAmbmJzcDt0byAmbmJzcDtz dGFuZGFyZGl6ZSANCiZuYnNwO3RoZSAmbmJzcDtzaWduYWxpbmcgJm5ic3A7cHJvdG9jb2xzICZu YnNwO2luICZuYnNwO3RoaXMgJm5ic3A7PC9ESVY+DQo8RElWPnRyYWNrZXItYmFzZWQgJm5ic3A7 YXJjaGl0ZWN0dXJlcyAmbmJzcDtmb3IgJm5ic3A7c3VwcG9ydGluZyAmbmJzcDtib3RoIA0KJm5i c3A7bGl2ZSAmbmJzcDthbmQgJm5ic3A7Vm9EICZuYnNwO3N0cmVhbWluZy4iPC9ESVY+DQo8RElW PkkgJm5ic3A7dGhpbmsgJm5ic3A7aXQgJm5ic3A7YmUgJm5ic3A7bW9yZSAmbmJzcDthY2N1cmF0 ZSAmbmJzcDt0byANCiZuYnNwO3NheTo8L0RJVj4NCjxESVY+Jm5ic3A7ICZuYnNwOyJQUFNQICZu YnNwO2luY2x1ZGVzICZuYnNwO3N0YW5kYXJkICZuYnNwO3NpZ25hbGluZyANCiZuYnNwO3Byb3Rv Y29scyAmbmJzcDtmb3IgJm5ic3A7dHJhY2tlci1iYXNlZCAmbmJzcDs8L0RJVj4NCjxESVY+YXJj aGl0ZWN0dXJlcyAmbmJzcDt0aGF0ICZuYnNwO3N1cHBvcnQgJm5ic3A7ZWl0aGVyICZuYnNwO2xp dmUgJm5ic3A7b3IgDQombmJzcDtvZmZsaW5lICZuYnNwO3N0cmVhbWluZy4iPC9ESVY+DQo8RElW PiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KDI2KSAmbmJzcDtTZWN0aW9u ICZuYnNwOzQgJm5ic3A7LSAmbmJzcDsiSW4gJm5ic3A7ZGV0YWlsLCAmbmJzcDtQUFNQIA0KJm5i c3A7ZGVzaWducyAmbmJzcDstICZndDsgJm5ic3A7IlRoZSAmbmJzcDtQUFNQICZuYnNwO2Rlc2ln biANCiZuYnNwO2luY2x1ZGVzIiI8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPigyNykg Jm5ic3A7U2VjdGlvbiAmbmJzcDs1LjEgJm5ic3A7LSAmbmJzcDtUaGUgJm5ic3A7Zmlyc3QgJm5i c3A7cGFyYWdyYXBoIA0KJm5ic3A7bmVlZHMgJm5ic3A7dG8gJm5ic3A7YmUgJm5ic3A7cmV3cml0 dGVuLCAmbmJzcDtzaW5jZSAmbmJzcDtpdCAmbmJzcDs8L0RJVj4NCjxESVY+c2VlbXMgJm5ic3A7 bW9yZSAmbmJzcDtsaWtlbHkgJm5ic3A7dG8gJm5ic3A7cmVmZXIgJm5ic3A7dG8gJm5ic3A7Y29u dGVudCANCiZuYnNwO3Byb3ZpZGVycyAmbmJzcDsoc2VsbGluZyAmbmJzcDtiaXRzICZuYnNwO29m ICZuYnNwO21lZGlhKSAmbmJzcDs8L0RJVj4NCjxESVY+cmF0aGVyICZuYnNwO3RoYW4gJm5ic3A7 InZlbmRvcnMiICZuYnNwO3RoYXQgJm5ic3A7d2UgJm5ic3A7dXN1YWxseSANCiZuYnNwO3JlZmVy ICZuYnNwO3RvICZuYnNwO2FzICZuYnNwO3Blb3BsZSAmbmJzcDtzZWxsaW5nICZuYnNwO2JveGVz LiANCiZuYnNwOzwvRElWPg0KPERJVj4mbmJzcDsgJm5ic3A7SSAmbmJzcDt0aGluayAmbmJzcDt0 aGUgJm5ic3A7cGljdHVyZSAmbmJzcDtpcyAmbmJzcDtjbGVhciwgDQombmJzcDtidXQgJm5ic3A7 dGhlICZuYnNwO3RleHQgJm5ic3A7aXMgJm5ic3A7bm90LiAmbmJzcDsgJm5ic3A7Tm90ZSAmbmJz cDt0aGF0IA0KJm5ic3A7dGhlICZuYnNwOzwvRElWPg0KPERJVj5zdXBlci1ub2RlICZuYnNwO2Nv bmNlcHQgJm5ic3A7d2FzICZuYnNwO2Jyb3VnaHQgJm5ic3A7dXAgJm5ic3A7aW4gDQombmJzcDt0 aGlzICZuYnNwO3BhcmFncmFwaCAmbmJzcDt3aXRob3V0ICZuYnNwO2FueSAmbmJzcDs8L0RJVj4N CjxESVY+ZXhwbGFuYXRpb24gJm5ic3A7b3IgJm5ic3A7ZGVmaW5pdGlvbiAmbmJzcDtvZiAmbmJz cDt3aGF0ICZuYnNwO3dlIA0KJm5ic3A7bWVhbiAmbmJzcDtieSAmbmJzcDtpdCAmbmJzcDtpbiAm bmJzcDtQUFNQLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KDI4KSAmbmJzcDtTZWN0 aW9uICZuYnNwOzUuMyAmbmJzcDstICZuYnNwOyJXaXRoICZuYnNwO1BQU1AgJm5ic3A7UGVlcnMi IA0KJm5ic3A7LSAmZ3Q7ICZuYnNwOyJXaXRoICZuYnNwO1BQU1AsICZuYnNwO3BlZXJzIjwvRElW Pg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KDI5KSAmbmJzcDtTZWN0aW9uICZuYnNwOzUuNCAm bmJzcDstICZuYnNwO0NEUyAmbmJzcDtpcyAmbmJzcDtub3QgDQombmJzcDtkZWZpbmVkPC9ESVY+ DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4oMzApICZuYnNwO1NlY3Rpb24gJm5ic3A7NS41ICZu YnNwOy0gJm5ic3A7SSAmbmJzcDt1bmRlcnN0YW5kICZuYnNwO3RoZSANCiZuYnNwO2ludGVudCwg Jm5ic3A7YnV0ICZuYnNwO3RoZSAmbmJzcDtmaXJzdCAmbmJzcDt0d28gJm5ic3A7cGFyYWdyYXBo cyANCiZuYnNwOzwvRElWPg0KPERJVj5oZXJlICZuYnNwO25lZWQgJm5ic3A7dG8gJm5ic3A7YmUg Jm5ic3A7Y2xlYW5lZCAmbmJzcDt1cCAmbmJzcDthbmQgDQombmJzcDtjbGFyaWZpZWQuICZuYnNw OyAmbmJzcDtUaGUgJm5ic3A7ZmlndXJlICZuYnNwO2lzICZuYnNwO3ZlcnkgJm5ic3A7Y2xlYXI7 IA0KJm5ic3A7dGhlICZuYnNwOzwvRElWPg0KPERJVj50ZXh0ICZuYnNwO2lzbid0LjwvRElWPg0K PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+KDMxKSAmbmJzcDtUaGUgJm5ic3A7ZG9jdW1lbnQgJm5i c3A7c2hvdWxkICZuYnNwO2NvbnNpc3RlbnRseSAmbmJzcDt1c2UgDQombmJzcDtlaXRoZXIgJm5i c3A7IlAyUCIgJm5ic3A7b3IgJm5ic3A7InAycCI8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8 RElWPigzMikgJm5ic3A7TWFueSAmbmJzcDtvZiAmbmJzcDt0aGUgJm5ic3A7SW5mb3JtYXRpdmUg Jm5ic3A7UmVmZXJlbmNlcyANCiZuYnNwO2FyZSAmbmJzcDtvbmx5ICZuYnNwO1VSTHMsICZuYnNw O2FuZCAmbmJzcDtJICZuYnNwO3N1c3BlY3QgJm5ic3A7PC9ESVY+DQo8RElWPnRoaXMgJm5ic3A7 UkZDICZuYnNwO3dpbGwgJm5ic3A7bGl2ZSAmbmJzcDtvbiAmbmJzcDttdWNoICZuYnNwO2xvbmdl ciANCiZuYnNwO3RoYW4gJm5ic3A7bW9zdCAmbmJzcDtvZiAmbmJzcDt0aG9zZSAmbmJzcDtVUkxz LiAmbmJzcDsgJm5ic3A7SSANCiZuYnNwO3RoaW5rICZuYnNwO3RoYXQgJm5ic3A7PC9ESVY+DQo8 RElWPndoZXJldmVyICZuYnNwO2l0J3MgJm5ic3A7cmVhc29uYWJsZSwgJm5ic3A7dGhvc2UgJm5i c3A7VVJMcyAmbmJzcDtzaG91bGQgDQombmJzcDtiZSAmbmJzcDtyZXBsYWNlZCAmbmJzcDt3aXRo ICZuYnNwO21vcmUgJm5ic3A7c3RhYmxlICZuYnNwOzwvRElWPg0KPERJVj5yZWZlcmVuY2VzLiAm bmJzcDsgJm5ic3A7SSAmbmJzcDt1bmRlcnN0YW5kICZuYnNwO3RoYXQgJm5ic3A7dGhpcyANCiZu YnNwO3dvbid0ICZuYnNwO2JlICZuYnNwO3Bvc3NpYmxlICZuYnNwO2luICZuYnNwO2FsbCAmbmJz cDtjYXNlcy48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj5UaGFua3MgJm5ic3A7Zm9yICZuYnNwO2JlYXJpbmcgJm5ic3A7d2l0aCAmbmJzcDt0aGVzZSAm bmJzcDtpbiAmbmJzcDtvcmRlciANCiZuYnNwO3RvICZuYnNwO3Byb2dyZXNzICZuYnNwO3RoaXMg Jm5ic3A7ZG9jdW1lbnQuPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLSAmbmJzcDs8 L0RJVj4NCjxESVY+V2VzICZuYnNwO0VkZHk8L0RJVj4NCjxESVY+TVRJICZuYnNwO1N5c3RlbXM8 L0RJVj4NCjxESVY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L0RJVj4NCjxESVY+cHBzcCAmbmJzcDttYWlsaW5nICZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+ cHBzcEBpZXRmLm9yZzwvRElWPg0KPERJVj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Bwc3A8L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --=====003_Dragon253423115650_=====-- From lin.xiao@nsn.com Mon Oct 24 20:19:17 2011 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 46E6E1F0C62 for ; Mon, 24 Oct 2011 20:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GErSR0tqyM2H for ; Mon, 24 Oct 2011 20:19:16 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id F3C041F0C51 for ; Mon, 24 Oct 2011 20:19:12 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9P3JBXK028274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 25 Oct 2011 05:19:11 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9P3J5st011422 for ; Tue, 25 Oct 2011 05:19:11 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 05:19:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC92C4.C7608AEE" Date: Tue, 25 Oct 2011 11:18:31 +0800 Message-ID: <22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net> In-Reply-To: <201110181408148242523@chinamobile.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPSP distributed tracker Thread-Index: AcyNXF3B912o4HshR/CgU7TsDtpg8gFZ/Wyw References: <4E9D00AA.4060400@mti-systems.com> <201110181408148242523@chinamobile.com> From: "Xiao, Lin (NSN - CN/Beijing)" To: X-OriginalArrivalTime: 25 Oct 2011 03:19:07.0047 (UTC) FILETIME=[DAE33370:01CC92C4] Subject: [ppsp] PPSP distributed tracker 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: Tue, 25 Oct 2011 03:19:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC92C4.C7608AEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 I've updated the distributed tracker draft for a while. Could you please give your comment on it ? Thanks! =20 http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.t xt =20 =20 Abstract =20 This document defines PPSP tracker usages for REsource LOcation And Discovery (RELOAD). Although PPSP assumes a centralized tracker from peer's point of view, the logical centralized tracker could be realized by a cluster of geographically distributed trackers. In this draft, we design distributed trackers system, which are organized by RELOAD. It provides lookup service for file/channel indexes and Peer Status among the distributed trackers. =20 =20 =20 BR Xiao Lin ------_=_NextPart_001_01CC92C4.C7608AEE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

I’ve = updated the distributed tracker draft for a while. Could you please give = your comment on it ? Thanks!

 

http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tr= acker-02.txt

 

 

Abstract

 =

This document = defines PPSP tracker usages for REsource LOcation = And

Discovery = (RELOAD).  Although PPSP assumes a centralized tracker = from

peer's point of = view, the logical centralized tracker could be = realized

by a cluster of = geographically distributed trackers. In this draft, = we

design = distributed trackers system, which are organized by RELOAD. = It

provides lookup = service for file/channel indexes and Peer Status = among

the distributed = trackers.

 =

 

 

BR<= /span>

Xiao = Lin

------_=_NextPart_001_01CC92C4.C7608AEE-- From guyingjie@huawei.com Mon Oct 24 20:32:06 2011 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 E4EE521F8BA8 for ; Mon, 24 Oct 2011 20:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.733 X-Spam-Level: X-Spam-Status: No, score=-101.733 tagged_above=-999 required=5 tests=[AWL=-2.430, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, 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 4TGcmBvxBcG1 for ; Mon, 24 Oct 2011 20:32:06 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8E14A21F8B84 for ; Mon, 24 Oct 2011 20:32:05 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTL00BWFR5G5M@szxga04-in.huawei.com> for ppsp@ietf.org; Tue, 25 Oct 2011 11:32:04 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTL00430R5G8L@szxga04-in.huawei.com> for ppsp@ietf.org; Tue, 25 Oct 2011 11:32:04 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEK06170; Tue, 25 Oct 2011 11:32:03 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 11:32:00 +0800 Received: from g00107907 (10.138.41.134) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 11:31:53 +0800 Date: Tue, 25 Oct 2011 11:34:52 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net> X-Originating-IP: [10.138.41.134] To: "'Xiao, Lin (NSN - CN/Beijing)'" , ppsp@ietf.org Message-id: <00bf01cc92c7$0edbe120$2c93a360$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_81OG517xwOFvywxPVaJj7Q)" Content-language: zh-cn Thread-index: AcyNXF3B912o4HshR/CgU7TsDtpg8gFZ/WywAACjbFA= X-CFilter-Loop: Reflected References: <4E9D00AA.4060400@mti-systems.com> <201110181408148242523@chinamobile.com> <22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net> Subject: [ppsp] =?gb2312?b?tPC4tDogIFBQU1AgZGlzdHJpYnV0ZWQgdHJhY2tlcg==?= 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: Tue, 25 Oct 2011 03:32:07 -0000 --Boundary_(ID_81OG517xwOFvywxPVaJj7Q) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thanks lin for updating the draft. Maybe it=A1=AFs better to give a brief introduction of the updating from = -01 version to -02 version. =20 =20 _____ =20 Best Regards Gu Yingjie =20 =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED Xiao, Lin (NSN - CN/Beijing) =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D611:19 =CA=D5=BC=FE=C8=CB: ppsp@ietf.org =D6=F7=CC=E2: [ppsp] PPSP distributed tracker =20 Hi All, =20 I=A1=AFve updated the distributed tracker draft for a while. Could you = please give your comment on it ? Thanks! =20 http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.tx= t =20 =20 Abstract =20 This document defines PPSP tracker usages for REsource LOcation And Discovery (RELOAD). Although PPSP assumes a centralized tracker from peer's point of view, the logical centralized tracker could be realized by a cluster of geographically distributed trackers. In this draft, we design distributed trackers system, which are organized by RELOAD. It provides lookup service for file/channel indexes and Peer Status among the distributed trackers. =20 =20 =20 BR Xiao Lin --Boundary_(ID_81OG517xwOFvywxPVaJj7Q) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Th= anks lin for updating the draft.

Ma= ybe it=A1=AFs better to give a brief introduction of the updating from = -01 version to -02 version.

 

 

B= est Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED = Xiao, Lin (NSN - = CN/Beijing)
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 = =C0=D6=C0=D611:19
=CA=D5=BC=FE=C8=CB: = ppsp@ietf.org
=D6=F7=CC=E2: [ppsp] PPSP distributed = tracker

 

Hi = All,

 

I=A1=AFve = updated the distributed tracker draft for a while. Could you please give = your comment on it ? Thanks!

 

http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tr= acker-02.txt

 

 

Abstract<= /p>

 

This document = defines PPSP tracker usages for REsource LOcation = And

Discovery (RELOAD).  = Although PPSP assumes a centralized tracker from

peer's point = of view, the logical centralized tracker could be = realized

by a cluster of = geographically distributed trackers. In this draft, = we

design distributed = trackers system, which are organized by RELOAD. = It

provides lookup service = for file/channel indexes and Peer Status among

the = distributed trackers.

 

 

 

BR<= /span>

Xiao = Lin

= --Boundary_(ID_81OG517xwOFvywxPVaJj7Q)-- From lin.xiao@nsn.com Mon Oct 24 23:42:06 2011 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 A48AE21F8C12 for ; Mon, 24 Oct 2011 23:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] 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 OynIX5XAygsO for ; Mon, 24 Oct 2011 23:42:05 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4372F21F8C0E for ; Mon, 24 Oct 2011 23:42:04 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9P6g0od017453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Oct 2011 08:42:00 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9P6fxKS029732; Tue, 25 Oct 2011 08:42:00 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 08:41:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC92E1.172C0D45" Date: Tue, 25 Oct 2011 14:41:13 +0800 Message-ID: <22A3852D27EBD546A70413F89677CE33019BEE@CNBEEXC007.nsn-intra.net> In-Reply-To: <00bf01cc92c7$0edbe120$2c93a360$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppsp] PPSP distributed tracker Thread-Index: AcyNXF3B912o4HshR/CgU7TsDtpg8gFZ/WywAACjbFAABVv+UA== References: <4E9D00AA.4060400@mti-systems.com> <201110181408148242523@chinamobile.com> <22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net> <00bf01cc92c7$0edbe120$2c93a360$@com> From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Yingjie Gu(yingjie)" , X-OriginalArrivalTime: 25 Oct 2011 06:41:54.0736 (UTC) FILETIME=[2F653300:01CC92E1] Subject: Re: [ppsp] PPSP distributed tracker 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: Tue, 25 Oct 2011 06:42:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC92E1.172C0D45 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable The updating content in v02 includes : =20 l The local tracker can keep the content record of local peers, at the = same time when it forwards the content update/registration information = to tracker overlay. So, most content requests can be solved locally.=20 l Delete the open issues in chapter 5, and decide to use local = connection tracker to manage the status of the ppsp peers locally, as = most peer requests are from local peers according to the algorithm = mentioned above. If the peer status can not be found in local connection = tracker, the request is forwarded to the tracker overlay, as each local = tracker always registries its own address to a node on tracker overly, = whose ID has a DHT mapping with the PPSP peer. As the position of the = peer status , which is also the peer=A1=AFs connection node address, is = always registered to the tracker overlay according to RELOAD. l A data kind for peerStatusIndex is defined. =20 As still some editorial errors, I=A1=AFll give a new version soon. =20 =20 BR Xiao Lin=20 =20 From: ext Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]=20 Sent: Tuesday, October 25, 2011 11:35 AM To: Xiao, Lin (NSN - CN/Beijing); ppsp@ietf.org Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker =20 Thanks lin for updating the draft. Maybe it=A1=AFs better to give a brief introduction of the updating from = -01 version to -02 version. =20 =20 ________________________________ Best Regards Gu Yingjie =20 =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED Xiao, Lin (NSN - CN/Beijing) =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D611:19 =CA=D5=BC=FE=C8=CB: ppsp@ietf.org =D6=F7=CC=E2: [ppsp] PPSP distributed tracker =20 Hi All, =20 I=A1=AFve updated the distributed tracker draft for a while. Could you = please give your comment on it ? Thanks! =20 http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.tx= t =20 =20 Abstract =20 This document defines PPSP tracker usages for REsource LOcation And Discovery (RELOAD). Although PPSP assumes a centralized tracker from peer's point of view, the logical centralized tracker could be realized by a cluster of geographically distributed trackers. In this draft, we design distributed trackers system, which are organized by RELOAD. It provides lookup service for file/channel indexes and Peer Status among the distributed trackers. =20 =20 =20 BR Xiao Lin ------_=_NextPart_001_01CC92E1.172C0D45 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

The updating = content in v02 includes :

 

l  The local = tracker can keep the content record of  local peers, at the same = time when it forwards the  content update/registration information = to tracker overlay. So, most content requests can be solved locally. =

l  Delete =  the open issues in chapter 5, and decide to use local connection = tracker to manage the status of the ppsp peers locally, as most peer = requests are from local peers according to the algorithm mentioned = above. If the peer status can not be found in local connection tracker, = the request is forwarded to the tracker overlay, as each local tracker = always registries its own address to a node on tracker overly, whose ID = has a DHT mapping  with the PPSP peer. As the position of the peer = status , which is also the peer=A1=AFs connection node address, is = always registered to the tracker overlay according to = RELOAD.

l  A data kind = for peerStatusIndex is defined.

 

As still some = editorial errors, I=A1=AFll give a new version = soon.

 

 

BR<= /span>

Xiao Lin =

 

From:= ext = Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]
Sent: = Tuesday, October 25, 2011 11:35 AM
To: Xiao, Lin (NSN - = CN/Beijing); ppsp@ietf.org
Subject: =B4=F0=B8=B4: [ppsp] = PPSP distributed tracker

 

Th= anks lin for updating the draft.

Ma= ybe it=A1=AFs better to give a brief introduction of the updating from = -01 version to -02 version.

 

 

B= est Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB: = ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED = Xiao, Lin (NSN - = CN/Beijing)
=B7=A2=CB=CD=CA=B1=BC= =E4: 2011=C4=EA10=D4=C225=C8=D5 = =C0=D6=C0=D611:19
=CA=D5=BC=FE=C8=CB: = ppsp@ietf.org
=D6=F7=CC=E2: [ppsp] PPSP distributed = tracker

 

Hi = All,

 

I=A1=AFve = updated the distributed tracker draft for a while. Could you please give = your comment on it ? Thanks!

 

http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tr= acker-02.txt

 

 

Abstract

 

This = document defines PPSP tracker usages for REsource LOcation = And

Discovery = (RELOAD).  Although PPSP assumes a centralized tracker = from

peer's point of = view, the logical centralized tracker could be = realized

by a cluster of = geographically distributed trackers. In this draft, = we

design distributed = trackers system, which are organized by RELOAD. = It

provides lookup = service for file/channel indexes and Peer Status = among

the distributed = trackers.

 

 

 

BR<= /span>

Xiao = Lin

------_=_NextPart_001_01CC92E1.172C0D45-- From guyingjie@huawei.com Tue Oct 25 00:43:10 2011 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 861C221F8BAA for ; Tue, 25 Oct 2011 00:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.429 X-Spam-Level: X-Spam-Status: No, score=-101.429 tagged_above=-999 required=5 tests=[AWL=-2.126, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345, 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 9DAVvWdzK6p6 for ; Tue, 25 Oct 2011 00:43:09 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id B020B21F8B72 for ; Tue, 25 Oct 2011 00:43:07 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTM00EJI2IHR0@szxga04-in.huawei.com> for ppsp@ietf.org; Tue, 25 Oct 2011 15:37:29 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTM00IB12IHBT@szxga04-in.huawei.com> for ppsp@ietf.org; Tue, 25 Oct 2011 15:37:29 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEK22267; Tue, 25 Oct 2011 15:37:29 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 15:37:26 +0800 Received: from g00107907 (10.138.41.134) by szxeml410-hub.china.huawei.com (10.82.67.137) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 15:37:19 +0800 Date: Tue, 25 Oct 2011 15:40:39 +0800 From: "Yingjie Gu(yingjie)" In-reply-to: <22A3852D27EBD546A70413F89677CE33019BEE@CNBEEXC007.nsn-intra.net> X-Originating-IP: [10.138.41.134] To: "'Xiao, Lin (NSN - CN/Beijing)'" , ppsp@ietf.org Message-id: <00eb01cc92e9$64ec6130$2ec52390$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6YwUt4mkoh7K5IbWJ+/m8A)" Content-language: zh-cn Thread-index: AcyNXF3B912o4HshR/CgU7TsDtpg8gFZ/WywAACjbFAABVv+UAACoiMw X-CFilter-Loop: Reflected References: <4E9D00AA.4060400@mti-systems.com> <201110181408148242523@chinamobile.com> <22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net> <00bf01cc92c7$0edbe120$2c93a360$@com> <22A3852D27EBD546A70413F89677CE33019BEE@CNBEEXC007.nsn-intra.net> Subject: [ppsp] =?gb2312?b?tPC4tDogIFBQU1AgZGlzdHJpYnV0ZWQgdHJhY2tlcg==?= 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: Tue, 25 Oct 2011 07:43:10 -0000 --Boundary_(ID_6YwUt4mkoh7K5IbWJ+/m8A) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thanks to Lin again for doing all the work. I would apologize, as co-author, I failed to contribute to this version = of updating.=20 Here is my comments and hope it can help. =20 =20 _____ =20 Best Regards Gu Yingjie =20 =B7=A2=BC=FE=C8=CB: Xiao, Lin (NSN - CN/Beijing) = [mailto:lin.xiao@nsn.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D614:41 =CA=D5=BC=FE=C8=CB: ext Yingjie Gu(yingjie); ppsp@ietf.org =D6=F7=CC=E2: RE: [ppsp] PPSP distributed tracker =20 The updating content in v02 includes : =20 l The local tracker can keep the content record of local peers, at the same time when it forwards the content update/registration information = to tracker overlay. So, most content requests can be solved locally.=20 Y.J. Gu : How frequently the content record is shared among trackers? = I guess not real-time sharing, because the content record is updated quite often. It could be an implementation choice, but we can give some = advise in the draft.=20 l Delete the open issues in chapter 5, and decide to use local = connection tracker to manage the status of the ppsp peers locally, as most peer requests are from local peers according to the algorithm mentioned = above. If the peer status can not be found in local connection tracker, the = request is forwarded to the tracker overlay, as each local tracker always = registries its own address to a node on tracker overly, whose ID has a DHT mapping with the PPSP peer. As the position of the peer status , which is also = the peer=A1=AFs connection node address, is always registered to the tracker = overlay according to RELOAD. Y.J. Gu : Why not share peer status when you share content record? The reason that we share content record among trackers is to decrease the response time to a request for some content that is not locally stored. = If the content can be found locally, but the tracker still have to find the status through the overlay, it doesn=A1=AFt decrease the response time. = The status shared on tracker overlay might not be accurate, but neither do = the content record. It=A1=AFs only a way to improve the performance. The = peer, who get an inaccurate information from the tracker, can correct it by communicating with the peers in peerlist. Even the local connection = tracker can not promise an accurate content record and peer status. =20 l A data kind for peerStatusIndex is defined. =20 As still some editorial errors, I=A1=AFll give a new version soon. =20 =20 BR Xiao Lin=20 =20 From: ext Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]=20 Sent: Tuesday, October 25, 2011 11:35 AM To: Xiao, Lin (NSN - CN/Beijing); ppsp@ietf.org Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker =20 Thanks lin for updating the draft. Maybe it=A1=AFs better to give a brief introduction of the updating from = -01 version to -02 version. =20 =20 _____ =20 Best Regards Gu Yingjie =20 =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED Xiao, Lin (NSN - CN/Beijing) =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D611:19 =CA=D5=BC=FE=C8=CB: ppsp@ietf.org =D6=F7=CC=E2: [ppsp] PPSP distributed tracker =20 Hi All, =20 I=A1=AFve updated the distributed tracker draft for a while. Could you = please give your comment on it ? Thanks! =20 http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.tx= t =20 =20 Abstract =20 This document defines PPSP tracker usages for REsource LOcation And Discovery (RELOAD). Although PPSP assumes a centralized tracker from peer's point of view, the logical centralized tracker could be realized by a cluster of geographically distributed trackers. In this draft, we design distributed trackers system, which are organized by RELOAD. It provides lookup service for file/channel indexes and Peer Status among the distributed trackers. =20 =20 =20 BR Xiao Lin --Boundary_(ID_6YwUt4mkoh7K5IbWJ+/m8A) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Th= anks to Lin  again for doing all the work.

I = would apologize, as co-author, I failed to contribute to this version of = updating.

He= re is my comments and hope it can help.

 

 

B= est Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB: Xiao, Lin (NSN - = CN/Beijing) [mailto:lin.xiao@nsn.com]
=B7=A2=CB=CD=CA=B1=BC= =E4: 2011=C4=EA10=D4=C225=C8=D5 = =C0=D6=C0=D614:41
=CA=D5=BC=FE=C8=CB: ext Yingjie Gu(yingjie); = ppsp@ietf.org
=D6=F7=CC=E2: RE: [ppsp] PPSP distributed = tracker

 

The updating = content in v02 includes :

 

l  The local = tracker can keep the content record of  local peers, at the same = time when it forwards the  content update/registration information = to tracker overlay. So, most content requests can be solved locally. =

Y.J. Gu :  How frequently the = content record is shared among trackers?  I guess not real-time = sharing, because the content record is updated quite often.  It = could be an implementation choice, but we can give some advise in the = draft.

l  Delete =  the open issues in chapter 5, and decide to use local connection = tracker to manage the status of the ppsp peers locally, as most peer = requests are from local peers according to the algorithm mentioned = above. If the peer status can not be found in local connection tracker, = the request is forwarded to the tracker overlay, as each local tracker = always registries its own address to a node on tracker overly, whose ID = has a DHT mapping  with the PPSP peer. As the position of the peer = status , which is also the peer=A1=AFs connection node address, is = always registered to the tracker overlay according to = RELOAD.

Y.J. Gu : Why not share peer status = when you share content record? The reason that we share content record = among trackers is to decrease the response time to a request for some = content that is not locally stored. If the content can be found locally, = but the tracker still have to find the status through the overlay, it = doesn=A1=AFt decrease the response time. The status shared on tracker = overlay might not be accurate, but neither do the content record. = It=A1=AFs only a way to improve the performance. The peer, who get an = inaccurate information from the tracker, can correct it by communicating = with the peers in peerlist. Even the local connection tracker can not = promise an accurate content record and peer = status.

&n= bsp; 

l  A data kind = for peerStatusIndex is defined.

 

As still some = editorial errors, I=A1=AFll give a new version = soon.

 

 

BR<= /span>

Xiao Lin =

 

From:= ext = Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]
Sent: = Tuesday, October 25, 2011 11:35 AM
To: Xiao, Lin (NSN - = CN/Beijing); ppsp@ietf.org
Subject: =B4=F0=B8=B4: [ppsp] = PPSP distributed tracker

 

Th= anks lin for updating the draft.

Ma= ybe it=A1=AFs better to give a brief introduction of the updating from = -01 version to -02 version.

 

 

B= est Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB: = ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED = Xiao, Lin (NSN - = CN/Beijing)
=B7=A2=CB=CD=CA=B1=BC= =E4: 2011=C4=EA10=D4=C225=C8=D5 = =C0=D6=C0=D611:19
=CA=D5=BC=FE=C8=CB: = ppsp@ietf.org
=D6=F7=CC=E2: [ppsp] PPSP distributed = tracker

 

Hi = All,

 

I=A1=AFve = updated the distributed tracker draft for a while. Could you please give = your comment on it ? Thanks!

 

http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tr= acker-02.txt

 

 

Abstract

 

This = document defines PPSP tracker usages for REsource LOcation = And

Discovery = (RELOAD).  Although PPSP assumes a centralized tracker = from

peer's point of = view, the logical centralized tracker could be = realized

by a cluster of = geographically distributed trackers. In this draft, = we

design distributed = trackers system, which are organized by RELOAD. = It

provides lookup = service for file/channel indexes and Peer Status = among

the distributed = trackers.

 

 

 

BR<= /span>

Xiao = Lin

= --Boundary_(ID_6YwUt4mkoh7K5IbWJ+/m8A)-- From lin.xiao@nsn.com Tue Oct 25 01:13:38 2011 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 674EA21F8B19 for ; Tue, 25 Oct 2011 01:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.761 X-Spam-Level: X-Spam-Status: No, score=-4.761 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] 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 ORJ8yWhfik+w for ; Tue, 25 Oct 2011 01:13:36 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A84EB21F8AEC for ; Tue, 25 Oct 2011 01:13:35 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9P8DSFD017663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Oct 2011 10:13:28 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9P8DSgw020225; Tue, 25 Oct 2011 10:13:28 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 10:13:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC92ED.B567A929" Date: Tue, 25 Oct 2011 16:11:33 +0800 Message-ID: <22A3852D27EBD546A70413F89677CE33019C22@CNBEEXC007.nsn-intra.net> In-Reply-To: <00eb01cc92e9$64ec6130$2ec52390$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppsp] PPSP distributed tracker Thread-Index: AcyNXF3B912o4HshR/CgU7TsDtpg8gFZ/WywAACjbFAABVv+UAACoiMwAAEaUZA= References: <4E9D00AA.4060400@mti-systems.com> <201110181408148242523@chinamobile.com> <22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net> <00bf01cc92c7$0edbe120$2c93a360$@com> <22A3852D27EBD546A70413F89677CE33019BEE@CNBEEXC007.nsn-intra.net> <00eb01cc92e9$64ec6130$2ec52390$@com> From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Yingjie Gu(yingjie)" , X-OriginalArrivalTime: 25 Oct 2011 08:13:26.0283 (UTC) FILETIME=[F89CC5B0:01CC92ED] Subject: Re: [ppsp] PPSP distributed tracker 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: Tue, 25 Oct 2011 08:13:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC92ED.B567A929 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Yingjie, =20 I=A1=AFve answered your questions as followed. By the way, I=A1=AFm submitting a updated version 03, which may describe = the change more clearly.=20 =20 BR Xiao Lin =20 From: ext Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]=20 Sent: Tuesday, October 25, 2011 3:41 PM To: Xiao, Lin (NSN - CN/Beijing); ppsp@ietf.org Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker =20 Thanks to Lin again for doing all the work. I would apologize, as co-author, I failed to contribute to this version = of updating.=20 Here is my comments and hope it can help. =20 =20 ________________________________ Best Regards Gu Yingjie =20 =B7=A2=BC=FE=C8=CB: Xiao, Lin (NSN - CN/Beijing) = [mailto:lin.xiao@nsn.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D614:41 =CA=D5=BC=FE=C8=CB: ext Yingjie Gu(yingjie); ppsp@ietf.org =D6=F7=CC=E2: RE: [ppsp] PPSP distributed tracker =20 The updating content in v02 includes : =20 l The local tracker can keep the content record of local peers, at the = same time when it forwards the content update/registration information = to tracker overlay. So, most content requests can be solved locally.=20 Y.J. Gu : How frequently the content record is shared among trackers? = I guess not real-time sharing, because the content record is updated = quite often. It could be an implementation choice, but we can give some = advise in the draft.=20 [Lin]: content record is not shared among trackers, it only stored in = both local connection tracker (for traffic localization) and the = responsible swarm tracker located by RELOAD mechanism (maintains overall = peerlist for a swarm).=20 =20 l Delete the open issues in chapter 5, and decide to use local = connection tracker to manage the status of the ppsp peers locally, as = most peer requests are from local peers according to the algorithm = mentioned above. If the peer status can not be found in local connection = tracker, the request is forwarded to the tracker overlay, as each local = tracker always registries its own address to a node on tracker overly, = whose ID has a DHT mapping with the PPSP peer. As the position of the = peer status , which is also the peer=A1=AFs connection node address, is = always registered to the tracker overlay according to RELOAD. Y.J. Gu : Why not share peer status when you share content record? The = reason that we share content record among trackers is to decrease the = response time to a request for some content that is not locally stored. = If the content can be found locally, but the tracker still have to find = the status through the overlay, it doesn=A1=AFt decrease the response = time. The status shared on tracker overlay might not be accurate, but = neither do the content record. It=A1=AFs only a way to improve the = performance. The peer, who get an inaccurate information from the = tracker, can correct it by communicating with the peers in peerlist. = Even the local connection tracker can not promise an accurate content = record and peer status. [Lin]: No. I mean, node status always maintained by its local = connection tracker, but only put the information that how to find the = local connection tracker of the peer (the position of the peer status) = on the tracker overlay. So, the frequent status updates can be done = locally, but there must be a way (by RELOAD overlay ) to find the = position of the status information, and the position information do not = need frequent updates, which saves the traffic across overlay. =20 =20 l A data kind for peerStatusIndex is defined. =20 As still some editorial errors, I=A1=AFll give a new version soon. =20 =20 BR Xiao Lin=20 =20 From: ext Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]=20 Sent: Tuesday, October 25, 2011 11:35 AM To: Xiao, Lin (NSN - CN/Beijing); ppsp@ietf.org Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker =20 Thanks lin for updating the draft. Maybe it=A1=AFs better to give a brief introduction of the updating from = -01 version to -02 version. =20 =20 ________________________________ Best Regards Gu Yingjie =20 =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED Xiao, Lin (NSN - CN/Beijing) =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D611:19 =CA=D5=BC=FE=C8=CB: ppsp@ietf.org =D6=F7=CC=E2: [ppsp] PPSP distributed tracker =20 Hi All, =20 I=A1=AFve updated the distributed tracker draft for a while. Could you = please give your comment on it ? Thanks! =20 http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.tx= t =20 =20 Abstract =20 This document defines PPSP tracker usages for REsource LOcation And Discovery (RELOAD). Although PPSP assumes a centralized tracker from peer's point of view, the logical centralized tracker could be realized by a cluster of geographically distributed trackers. In this draft, we design distributed trackers system, which are organized by RELOAD. It provides lookup service for file/channel indexes and Peer Status among the distributed trackers. =20 =20 =20 BR Xiao Lin ------_=_NextPart_001_01CC92ED.B567A929 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi = Yingjie,

 

I=A1=AFve = answered your questions as followed.

By the way, = I=A1=AFm submitting a updated version 03, which may describe the change = more clearly.

 

BR<= /span>

Xiao = Lin

 

From:= ext = Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]
Sent: = Tuesday, October 25, 2011 3:41 PM
To: Xiao, Lin (NSN - = CN/Beijing); ppsp@ietf.org
Subject: =B4=F0=B8=B4: [ppsp] = PPSP distributed tracker

 

Th= anks to Lin  again for doing all the work.

I = would apologize, as co-author, I failed to contribute to this version of = updating.

He= re is my comments and hope it can help.

 

 

B= est Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB: Xiao, Lin (NSN - = CN/Beijing) [mailto:lin.xiao@nsn.com]
=B7=A2=CB=CD=CA=B1=BC= =E4: 2011=C4=EA10=D4=C225=C8=D5 = =C0=D6=C0=D614:41
=CA=D5=BC=FE=C8=CB: ext Yingjie Gu(yingjie); = ppsp@ietf.org
=D6=F7=CC=E2: RE: [ppsp] PPSP distributed = tracker

 

The updating = content in v02 includes :

 

l  The local = tracker can keep the content record of  local peers, at the same = time when it forwards the  content update/registration information = to tracker overlay. So, most content requests can be solved locally. =

Y.J. Gu :  How frequently the = content record is shared among trackers?  I guess not real-time = sharing, because the content record is updated quite often.  It = could be an implementation choice, but we can give some advise in the = draft.

[Lin]: content record is not shared = among trackers, it only stored in both local connection tracker (for = traffic localization) and the responsible swarm tracker located by = RELOAD mechanism (maintains overall peerlist for a swarm). =

 

l  Delete =  the open issues in chapter 5, and decide to use local connection = tracker to manage the status of the ppsp peers locally, as most peer = requests are from local peers according to the algorithm mentioned = above. If the peer status can not be found in local connection tracker, = the request is forwarded to the tracker overlay, as each local tracker = always registries its own address to a node on tracker overly, whose ID = has a DHT mapping  with the PPSP peer. As the position of the peer = status , which is also the peer=A1=AFs connection node address, is = always registered to the tracker overlay according to = RELOAD.

Y.J. Gu : Why not share peer status = when you share content record? The reason that we share content record = among trackers is to decrease the response time to a request for some = content that is not locally stored. If the content can be found locally, = but the tracker still have to find the status through the overlay, it = doesn=A1=AFt decrease the response time. The status shared on tracker = overlay might not be accurate, but neither do the content record. = It=A1=AFs only a way to improve the performance. The peer, who get an = inaccurate information from the tracker, can correct it by communicating = with the peers in peerlist. Even the local connection tracker can not = promise an accurate content record and peer = status.

[Lin]:   No. I mean, node status always maintained by its local = connection tracker, but only put the information that how to find the = local connection tracker of the peer (the position of the peer status) = on the tracker overlay.  So, the frequent status updates can be = done locally, but there must be a way (by RELOAD overlay ) to find the = position of the status information, and the position information do not = need frequent updates, which saves the traffic across overlay. =  

 

l  A data kind = for peerStatusIndex is defined.

 

As still some = editorial errors, I=A1=AFll give a new version = soon.

 

 

BR<= /span>

Xiao Lin =

 

From:= ext = Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]
Sent: = Tuesday, October 25, 2011 11:35 AM
To: Xiao, Lin (NSN - = CN/Beijing); ppsp@ietf.org
Subject: =B4=F0=B8=B4: [ppsp] = PPSP distributed tracker

 

Th= anks lin for updating the draft.

Ma= ybe it=A1=AFs better to give a brief introduction of the updating from = -01 version to -02 version.

 

 

B= est Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB: = ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED = Xiao, Lin (NSN - = CN/Beijing)
=B7=A2=CB=CD=CA=B1=BC= =E4: 2011=C4=EA10=D4=C225=C8=D5 = =C0=D6=C0=D611:19
=CA=D5=BC=FE=C8=CB: = ppsp@ietf.org
=D6=F7=CC=E2: [ppsp] PPSP distributed = tracker

 

Hi = All,

 

I=A1=AFve = updated the distributed tracker draft for a while. Could you please give = your comment on it ? Thanks!

 

http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tr= acker-02.txt

 

 

Abstract

 

This = document defines PPSP tracker usages for REsource LOcation = And

Discovery = (RELOAD).  Although PPSP assumes a centralized tracker = from

peer's point of = view, the logical centralized tracker could be = realized

by a cluster of = geographically distributed trackers. In this draft, = we

design distributed = trackers system, which are organized by RELOAD. = It

provides lookup = service for file/channel indexes and Peer Status = among

the distributed = trackers.

 

 

 

BR<= /span>

Xiao = Lin

------_=_NextPart_001_01CC92ED.B567A929-- From lin.xiao@nsn.com Tue Oct 25 02:02:21 2011 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 0229721F891D for ; Tue, 25 Oct 2011 02:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.556 X-Spam-Level: X-Spam-Status: No, score=-4.556 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] 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 9sr+9Q0nUAOB for ; Tue, 25 Oct 2011 02:02:19 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1923E21F89BA for ; Tue, 25 Oct 2011 02:02:18 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9P900t2005186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 Oct 2011 11:02:11 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9P8YWmB028867; Tue, 25 Oct 2011 10:34:53 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Oct 2011 10:33:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC92EF.9E8A028D" Date: Tue, 25 Oct 2011 16:25:13 +0800 Message-ID: <22A3852D27EBD546A70413F89677CE33019C32@CNBEEXC007.nsn-intra.net> In-Reply-To: <22A3852D27EBD546A70413F89677CE33019C22@CNBEEXC007.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppsp] PPSP distributed tracker Thread-Index: AcyNXF3B912o4HshR/CgU7TsDtpg8gFZ/WywAACjbFAABVv+UAACoiMwAAEaUZAAAQbwsA== References: <4E9D00AA.4060400@mti-systems.com><201110181408148242523@chinamobile.com><22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net><00bf01cc92c7$0edbe120$2c93a360$@com><22A3852D27EBD546A70413F89677CE33019BEE@CNBEEXC007.nsn-intra.net><00eb01cc92e9$64ec6130$2ec52390$@com> <22A3852D27EBD546A70413F89677CE33019C22@CNBEEXC007.nsn-intra.net> From: "Xiao, Lin (NSN - CN/Beijing)" To: "Xiao, Lin (NSN - CN/Beijing)" , "ext Yingjie Gu(yingjie)" , X-OriginalArrivalTime: 25 Oct 2011 08:33:53.0220 (UTC) FILETIME=[D3EC8040:01CC92F0] Subject: Re: [ppsp] PPSP distributed tracker 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: Tue, 25 Oct 2011 09:02:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC92EF.9E8A028D Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, =20 As I said, I made another version to give a clearer description. Also = the Figures and the flows are modified accordingly. =20 http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-03.tx= t =20 =20 BR Xiao Lin =20 From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of = Xiao, Lin (NSN - CN/Beijing) Sent: Tuesday, October 25, 2011 4:12 PM To: ext Yingjie Gu(yingjie); ppsp@ietf.org Subject: Re: [ppsp] PPSP distributed tracker =20 Hi Yingjie, =20 I=A1=AFve answered your questions as followed. By the way, I=A1=AFm submitting a updated version 03, which may describe = the change more clearly.=20 =20 BR Xiao Lin =20 From: ext Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]=20 Sent: Tuesday, October 25, 2011 3:41 PM To: Xiao, Lin (NSN - CN/Beijing); ppsp@ietf.org Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker =20 Thanks to Lin again for doing all the work. I would apologize, as co-author, I failed to contribute to this version = of updating.=20 Here is my comments and hope it can help. =20 =20 ________________________________ Best Regards Gu Yingjie =20 =B7=A2=BC=FE=C8=CB: Xiao, Lin (NSN - CN/Beijing) = [mailto:lin.xiao@nsn.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D614:41 =CA=D5=BC=FE=C8=CB: ext Yingjie Gu(yingjie); ppsp@ietf.org =D6=F7=CC=E2: RE: [ppsp] PPSP distributed tracker =20 The updating content in v02 includes : =20 l The local tracker can keep the content record of local peers, at the = same time when it forwards the content update/registration information = to tracker overlay. So, most content requests can be solved locally.=20 Y.J. Gu : How frequently the content record is shared among trackers? = I guess not real-time sharing, because the content record is updated = quite often. It could be an implementation choice, but we can give some = advise in the draft.=20 [Lin]: content record is not shared among trackers, it only stored in = both local connection tracker (for traffic localization) and the = responsible swarm tracker located by RELOAD mechanism (maintains overall = peerlist for a swarm).=20 =20 l Delete the open issues in chapter 5, and decide to use local = connection tracker to manage the status of the ppsp peers locally, as = most peer requests are from local peers according to the algorithm = mentioned above. If the peer status can not be found in local connection = tracker, the request is forwarded to the tracker overlay, as each local = tracker always registries its own address to a node on tracker overly, = whose ID has a DHT mapping with the PPSP peer. As the position of the = peer status , which is also the peer=A1=AFs connection node address, is = always registered to the tracker overlay according to RELOAD. Y.J. Gu : Why not share peer status when you share content record? The = reason that we share content record among trackers is to decrease the = response time to a request for some content that is not locally stored. = If the content can be found locally, but the tracker still have to find = the status through the overlay, it doesn=A1=AFt decrease the response = time. The status shared on tracker overlay might not be accurate, but = neither do the content record. It=A1=AFs only a way to improve the = performance. The peer, who get an inaccurate information from the = tracker, can correct it by communicating with the peers in peerlist. = Even the local connection tracker can not promise an accurate content = record and peer status. [Lin]: No. I mean, node status always maintained by its local = connection tracker, but only put the information that how to find the = local connection tracker of the peer (the position of the peer status) = on the tracker overlay. So, the frequent status updates can be done = locally, but there must be a way (by RELOAD overlay ) to find the = position of the status information, and the position information do not = need frequent updates, which saves the traffic across overlay. =20 =20 l A data kind for peerStatusIndex is defined. =20 As still some editorial errors, I=A1=AFll give a new version soon. =20 =20 BR Xiao Lin=20 =20 From: ext Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]=20 Sent: Tuesday, October 25, 2011 11:35 AM To: Xiao, Lin (NSN - CN/Beijing); ppsp@ietf.org Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker =20 Thanks lin for updating the draft. Maybe it=A1=AFs better to give a brief introduction of the updating from = -01 version to -02 version. =20 =20 ________________________________ Best Regards Gu Yingjie =20 =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED Xiao, Lin (NSN - CN/Beijing) =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D611:19 =CA=D5=BC=FE=C8=CB: ppsp@ietf.org =D6=F7=CC=E2: [ppsp] PPSP distributed tracker =20 Hi All, =20 I=A1=AFve updated the distributed tracker draft for a while. Could you = please give your comment on it ? Thanks! =20 http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.tx= t =20 =20 Abstract =20 This document defines PPSP tracker usages for REsource LOcation And Discovery (RELOAD). Although PPSP assumes a centralized tracker from peer's point of view, the logical centralized tracker could be realized by a cluster of geographically distributed trackers. In this draft, we design distributed trackers system, which are organized by RELOAD. It provides lookup service for file/channel indexes and Peer Status among the distributed trackers. =20 =20 =20 BR Xiao Lin ------_=_NextPart_001_01CC92EF.9E8A028D Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,=

 

As I said, I = made another version to give a clearer description. Also the Figures and = the flows are modified accordingly.

 

http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tr= acker-03.txt

 

 

BR<= /span>

Xiao = Lin

 

From:= = ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of = Xiao, Lin (NSN - CN/Beijing)
Sent: Tuesday, October 25, = 2011 4:12 PM
To: ext Yingjie Gu(yingjie); = ppsp@ietf.org
Subject: Re: [ppsp] PPSP distributed = tracker

 

Hi = Yingjie,

 

I=A1=AFve = answered your questions as followed.

By the way, = I=A1=AFm submitting a updated version 03, which may describe the change = more clearly.

 

BR<= /span>

Xiao = Lin

 

From:= ext = Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]
Sent: = Tuesday, October 25, 2011 3:41 PM
To: Xiao, Lin (NSN - = CN/Beijing); ppsp@ietf.org
Subject: =B4=F0=B8=B4: [ppsp] = PPSP distributed tracker

 

Th= anks to Lin  again for doing all the work.

I = would apologize, as co-author, I failed to contribute to this version of = updating.

He= re is my comments and hope it can help.

 

 

B= est Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB: Xiao, Lin (NSN - = CN/Beijing) [mailto:lin.xiao@nsn.com]
=B7=A2=CB=CD=CA=B1=BC= =E4: 2011=C4=EA10=D4=C225=C8=D5 = =C0=D6=C0=D614:41
=CA=D5=BC=FE=C8=CB: ext Yingjie Gu(yingjie); = ppsp@ietf.org
=D6=F7=CC=E2: RE: [ppsp] PPSP distributed = tracker

 

The updating = content in v02 includes :

 

l  The local = tracker can keep the content record of  local peers, at the same = time when it forwards the  content update/registration information = to tracker overlay. So, most content requests can be solved locally. =

Y.J. Gu :  How frequently the = content record is shared among trackers?  I guess not real-time = sharing, because the content record is updated quite often.  It = could be an implementation choice, but we can give some advise in the = draft.

[Lin]: content record is not shared = among trackers, it only stored in both local connection tracker (for = traffic localization) and the responsible swarm tracker located by = RELOAD mechanism (maintains overall peerlist for a swarm). =

 

l  Delete =  the open issues in chapter 5, and decide to use local connection = tracker to manage the status of the ppsp peers locally, as most peer = requests are from local peers according to the algorithm mentioned = above. If the peer status can not be found in local connection tracker, = the request is forwarded to the tracker overlay, as each local tracker = always registries its own address to a node on tracker overly, whose ID = has a DHT mapping  with the PPSP peer. As the position of the peer = status , which is also the peer=A1=AFs connection node address, is = always registered to the tracker overlay according to = RELOAD.

Y.J. Gu : Why not share peer status = when you share content record? The reason that we share content record = among trackers is to decrease the response time to a request for some = content that is not locally stored. If the content can be found locally, = but the tracker still have to find the status through the overlay, it = doesn=A1=AFt decrease the response time. The status shared on tracker = overlay might not be accurate, but neither do the content record. = It=A1=AFs only a way to improve the performance. The peer, who get an = inaccurate information from the tracker, can correct it by communicating = with the peers in peerlist. Even the local connection tracker can not = promise an accurate content record and peer = status.

[Lin]:   No. I mean, node status always maintained by its local = connection tracker, but only put the information that how to find the = local connection tracker of the peer (the position of the peer status) = on the tracker overlay.  So, the frequent status updates can be = done locally, but there must be a way (by RELOAD overlay ) to find the = position of the status information, and the position information do not = need frequent updates, which saves the traffic across overlay. =  

 

l  A data kind = for peerStatusIndex is defined.

 

As still some = editorial errors, I=A1=AFll give a new version = soon.

 

 

BR<= /span>

Xiao Lin =

 

From:= ext = Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com]
Sent: = Tuesday, October 25, 2011 11:35 AM
To: Xiao, Lin (NSN - = CN/Beijing); ppsp@ietf.org
Subject: =B4=F0=B8=B4: [ppsp] = PPSP distributed tracker

 

Th= anks lin for updating the draft.

Ma= ybe it=A1=AFs better to give a brief introduction of the updating from = -01 version to -02 version.

 

 

B= est Regards
Gu Yingjie

 

=B7=A2=BC=FE=C8=CB: = ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED = Xiao, Lin (NSN - = CN/Beijing)
=B7=A2=CB=CD=CA=B1=BC= =E4: 2011=C4=EA10=D4=C225=C8=D5 = =C0=D6=C0=D611:19
=CA=D5=BC=FE=C8=CB: = ppsp@ietf.org
=D6=F7=CC=E2: [ppsp] PPSP distributed = tracker

 

Hi = All,

 

I=A1=AFve = updated the distributed tracker draft for a while. Could you please give = your comment on it ? Thanks!

 

http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tr= acker-02.txt

 

 

Abstract

 

This = document defines PPSP tracker usages for REsource LOcation = And

Discovery = (RELOAD).  Although PPSP assumes a centralized tracker = from

peer's point of = view, the logical centralized tracker could be = realized

by a cluster of = geographically distributed trackers. In this draft, = we

design distributed = trackers system, which are organized by RELOAD. = It

provides lookup = service for file/channel indexes and Peer Status = among

the distributed = trackers.

 

 

 

BR<= /span>

Xiao = Lin

------_=_NextPart_001_01CC92EF.9E8A028D-- From a.bakker@vu.nl Wed Oct 26 07:36:26 2011 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 42A3521F84DA for ; Wed, 26 Oct 2011 07:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.575 X-Spam-Level: X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-4] 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 jpjIaJNw8p76 for ; Wed, 26 Oct 2011 07:36:25 -0700 (PDT) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4B83121F84DB for ; Wed, 26 Oct 2011 07:36:24 -0700 (PDT) Received: from PEXHB011B.vu.local (130.37.236.65) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 26 Oct 2011 16:36:20 +0200 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.65) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 26 Oct 2011 16:36:21 +0200 Message-ID: <4EA81B39.6050902@cs.vu.nl> Date: Wed, 26 Oct 2011 16:37:45 +0200 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: ppsp References: <20111026143342.19808.5534.idtracker@ietfa.amsl.com> In-Reply-To: <20111026143342.19808.5534.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20111026143342.19808.5534.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: [ppsp] New Version Notification for draft-grishchenko-ppsp-swift-03.txt X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: arno@cs.vu.nl 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, 26 Oct 2011 14:36:26 -0000 Hi folks we just uploaded a more RFC-like version of our swift proposal and request your comments ;o) Regards, Arno Bakker and the rest of the TU Delft team -------- Original Message -------- Subject: New Version Notification for draft-grishchenko-ppsp-swift-03.txt Date: Wed, 26 Oct 2011 07:33:42 -0700 From: To: CC: A new version of I-D, draft-grishchenko-ppsp-swift-03.txt has been successfully submitted by Arno Bakker and posted to the IETF repository. Filename: draft-grishchenko-ppsp-swift Revision: 03 Title: The Generic Multiparty Transport Protocol (swift) Creation date: 2011-10-26 WG ID: Individual Submission Number of pages: 39 Abstract: The Generic Multiparty Protocol (swift) is a peer-to-peer based transport protocol for content dissemination. It can be used for streaming on-demand and live video content, as well as conventional downloading. In swift, the clients consuming the content participate in the dissemination by forwarding the content to other clients via a mesh-like structure. It is a generic protocol which can run directly on top of UDP, TCP, HTTP or as a RTP profile. Features of swift are short time-till-playback and extensibility. Hence, it can use different mechanisms to prevent freeriding, and work with different peer discovery schemes (centralized trackers or Distributed Hash Tables). Depending on the underlying transport protocol, swift can also use different congestion control algorithms, such as LEDBAT, and offer transparent NAT traversal. Finally, swift maintains only a small amount of state per peer and detects malicious modification of content. This documents describes swift and how it satisfies the requirements for the IETF Peer-to-Peer Streaming Protocol (PPSP) Working Group's peer protocol. The IETF Secretariat From peer2peer@gmail.com Wed Oct 26 14:39:14 2011 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 7DAC821F869E for ; Wed, 26 Oct 2011 14:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-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 ijWTYk0BwiRf for ; Wed, 26 Oct 2011 14:39:13 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2244E21F84A5 for ; Wed, 26 Oct 2011 14:39:12 -0700 (PDT) Received: by wyh22 with SMTP id 22so2522340wyh.31 for ; Wed, 26 Oct 2011 14:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=No9V5eARGTVzzEo0pVg2IGoW0ZnM20zL1MHtf+KF58Y=; b=uyNOx6H2jJw3fIQWXQuxNauReYoEidzn2q6fNW5AC3dk4n0DPWbekNK+tgOV6jZ5qb T2FSpA/UfeU45T8l1CV9v3z6z7Qoo1suaND9Yc0Vx00lhGM5KY1JH0Szo5327IHSOWDK aBxlWicxH13OPBeeO0c+HlLcSSdkPyD0rOqV4= MIME-Version: 1.0 Received: by 10.227.206.146 with SMTP id fu18mr12447573wbb.7.1319665151945; Wed, 26 Oct 2011 14:39:11 -0700 (PDT) Received: by 10.180.86.33 with HTTP; Wed, 26 Oct 2011 14:39:11 -0700 (PDT) In-Reply-To: <22A3852D27EBD546A70413F89677CE33019C32@CNBEEXC007.nsn-intra.net> References: <4E9D00AA.4060400@mti-systems.com> <201110181408148242523@chinamobile.com> <22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net> <00bf01cc92c7$0edbe120$2c93a360$@com> <22A3852D27EBD546A70413F89677CE33019BEE@CNBEEXC007.nsn-intra.net> <00eb01cc92e9$64ec6130$2ec52390$@com> <22A3852D27EBD546A70413F89677CE33019C22@CNBEEXC007.nsn-intra.net> <22A3852D27EBD546A70413F89677CE33019C32@CNBEEXC007.nsn-intra.net> Date: Wed, 26 Oct 2011 23:39:11 +0200 Message-ID: From: Johan Pouwelse To: "Xiao, Lin (NSN - CN/Beijing)" Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: ppsp@ietf.org Subject: Re: [ppsp] PPSP distributed tracker 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, 26 Oct 2011 21:39:14 -0000 Dear PPSP, Just completed a review of V3 of your distributed tracker proposal. Main point: As indicated my me before within PPSP, light-weight solutions are not often proposed here. This proposal leans towards overengineering. This proposal does not make a distinction between tracker replication and distribution using PEX or DHT. By having multiple central trackers, reliability should improve. However, how many seconds does a peer wait when a query gets no reply? If a peer waits for 10 seconds before trying a secondairy peers the result is significant loss of user experienced performance and degradation of streaming service. Should a peer issue multiple request in parallel to ensure fast performance at the cost of server resources? From my viewpoint a PPSP standard should recommend policies here. You agree? Section 2 defines six different entities/roles, where 2 is the minimum. By expanding the tracker functionality to include network locality, piece availability registration and a tracker2tracker protocol we risk defining a standard which cannot be implemented, scale or compete with the performance of minimalistic solutions. Missing from this draft is the handling of NATed peers. Does the tracker do a simple dialback to check if a peer is connectable? Is connectability part of peer info? For over 10 years the Bittorrent tracker protocol seems to be doing well. This proposal is a radical departure from this deployed technology. An explanation why this is done would significantly improve this draft in my opinion. Is that possible? Greetings, johan. On 25/10/2011, Xiao, Lin (NSN - CN/Beijing) wrote: > Hi, > > > > As I said, I made another version to give a clearer description. Also the > Figures and the flows are modified accordingly. > > > > http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-03.tx= t > > > > > > BR > > Xiao Lin > > > > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of > Xiao, Lin (NSN - CN/Beijing) > Sent: Tuesday, October 25, 2011 4:12 PM > To: ext Yingjie Gu(yingjie); ppsp@ietf.org > Subject: Re: [ppsp] PPSP distributed tracker > > > > Hi Yingjie, > > > > I=A1=AFve answered your questions as followed. > > By the way, I=A1=AFm submitting a updated version 03, which may describe = the > change more clearly. > > > > BR > > Xiao Lin > > > > From: ext Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com] > Sent: Tuesday, October 25, 2011 3:41 PM > To: Xiao, Lin (NSN - CN/Beijing); ppsp@ietf.org > Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker > > > > Thanks to Lin again for doing all the work. > > I would apologize, as co-author, I failed to contribute to this version o= f > updating. > > Here is my comments and hope it can help. > > > > > > ________________________________ > > Best Regards > Gu Yingjie > > > > =B7=A2=BC=FE=C8=CB: Xiao, Lin (NSN - CN/Beijing) [mailto:lin.xiao@nsn.com= ] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D614:41 > =CA=D5=BC=FE=C8=CB: ext Yingjie Gu(yingjie); ppsp@ietf.org > =D6=F7=CC=E2: RE: [ppsp] PPSP distributed tracker > > > > The updating content in v02 includes : > > > > l The local tracker can keep the content record of local peers, at the > same time when it forwards the content update/registration information t= o > tracker overlay. So, most content requests can be solved locally. > > Y.J. Gu : How frequently the content record is shared among trackers? I > guess not real-time sharing, because the content record is updated quite > often. It could be an implementation choice, but we can give some advise= in > the draft. > > [Lin]: content record is not shared among trackers, it only stored in bot= h > local connection tracker (for traffic localization) and the responsible > swarm tracker located by RELOAD mechanism (maintains overall peerlist for= a > swarm). > > > > l Delete the open issues in chapter 5, and decide to use local connecti= on > tracker to manage the status of the ppsp peers locally, as most peer > requests are from local peers according to the algorithm mentioned above.= If > the peer status can not be found in local connection tracker, the request= is > forwarded to the tracker overlay, as each local tracker always registries > its own address to a node on tracker overly, whose ID has a DHT mapping > with the PPSP peer. As the position of the peer status , which is also th= e > peer=A1=AFs connection node address, is always registered to the tracker = overlay > according to RELOAD. > > Y.J. Gu : Why not share peer status when you share content record? The > reason that we share content record among trackers is to decrease the > response time to a request for some content that is not locally stored. I= f > the content can be found locally, but the tracker still have to find the > status through the overlay, it doesn=A1=AFt decrease the response time. T= he > status shared on tracker overlay might not be accurate, but neither do th= e > content record. It=A1=AFs only a way to improve the performance. The peer= , who > get an inaccurate information from the tracker, can correct it by > communicating with the peers in peerlist. Even the local connection track= er > can not promise an accurate content record and peer status. > > [Lin]: No. I mean, node status always maintained by its local connectio= n > tracker, but only put the information that how to find the local connecti= on > tracker of the peer (the position of the peer status) on the tracker > overlay. So, the frequent status updates can be done locally, but there > must be a way (by RELOAD overlay ) to find the position of the status > information, and the position information do not need frequent updates, > which saves the traffic across overlay. > > > > l A data kind for peerStatusIndex is defined. > > > > As still some editorial errors, I=A1=AFll give a new version soon. > > > > > > BR > > Xiao Lin > > > > From: ext Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com] > Sent: Tuesday, October 25, 2011 11:35 AM > To: Xiao, Lin (NSN - CN/Beijing); ppsp@ietf.org > Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker > > > > Thanks lin for updating the draft. > > Maybe it=A1=AFs better to give a brief introduction of the updating from = -01 > version to -02 version. > > > > > > ________________________________ > > Best Regards > Gu Yingjie > > > > =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED Xiao, Lin (NSN > - CN/Beijing) > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D611:19 > =CA=D5=BC=FE=C8=CB: ppsp@ietf.org > =D6=F7=CC=E2: [ppsp] PPSP distributed tracker > > > > Hi All, > > > > I=A1=AFve updated the distributed tracker draft for a while. Could you pl= ease > give your comment on it ? Thanks! > > > > http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.tx= t > > > > > > Abstract > > > > This document defines PPSP tracker usages for REsource LOcation And > > Discovery (RELOAD). Although PPSP assumes a centralized tracker from > > peer's point of view, the logical centralized tracker could be realized > > by a cluster of geographically distributed trackers. In this draft, we > > design distributed trackers system, which are organized by RELOAD. It > > provides lookup service for file/channel indexes and Peer Status among > > the distributed trackers. > > > > > > > > BR > > Xiao Lin > > From lin.xiao@nsn.com Wed Oct 26 19:54:17 2011 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 AFFCA21F8AD6 for ; Wed, 26 Oct 2011 19:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.454 X-Spam-Level: X-Spam-Status: No, score=-4.454 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] 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 wstvcEA1SBQn for ; Wed, 26 Oct 2011 19:54:16 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 01A8621F8AB8 for ; Wed, 26 Oct 2011 19:54:14 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p9R2s92i023547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Oct 2011 04:54:09 +0200 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p9R2s696002067; Thu, 27 Oct 2011 04:54:09 +0200 Received: from CNBEEXC007.nsn-intra.net ([10.159.192.12]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 Oct 2011 04:54:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9453.AEFDD76E" Date: Thu, 27 Oct 2011 10:54:02 +0800 Message-ID: <22A3852D27EBD546A70413F89677CE3303BF01@CNBEEXC007.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ppsp] PPSP distributed tracker Thread-Index: AcyUJ7WJNrf6amvtQdG+0SMhLzddZwAJOIMg References: <4E9D00AA.4060400@mti-systems.com><201110181408148242523@chinamobile.com><22A3852D27EBD546A70413F89677CE33019B92@CNBEEXC007.nsn-intra.net><00bf01cc92c7$0edbe120$2c93a360$@com><22A3852D27EBD546A70413F89677CE33019BEE@CNBEEXC007.nsn-intra.net><00eb01cc92e9$64ec6130$2ec52390$@com><22A3852D27EBD546A70413F89677CE33019C22@CNBEEXC007.nsn-intra.net><22A3852D27EBD546A70413F89677CE33019C32@CNBEEXC007.nsn-intra.net> From: "Xiao, Lin (NSN - CN/Beijing)" To: "ext Johan Pouwelse" X-OriginalArrivalTime: 27 Oct 2011 02:54:06.0743 (UTC) FILETIME=[B1767A70:01CC9453] Cc: ppsp@ietf.org Subject: Re: [ppsp] PPSP distributed tracker 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: Thu, 27 Oct 2011 02:54:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9453.AEFDD76E Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi Johan, =20 Thank you very much for your comments. I agree with you that the = proposal now is not that mature. Valuable suggestions are appreciated = and helpful to refine the solution. =20 Try to answer your questions in line as following: =20 BR Xiao Lin -----Original Message----- From: ext Johan Pouwelse [mailto:peer2peer@gmail.com]=20 Sent: Thursday, October 27, 2011 5:39 AM To: Xiao, Lin (NSN - CN/Beijing) Cc: ext Yingjie Gu(yingjie); ppsp@ietf.org Subject: Re: [ppsp] PPSP distributed tracker =20 Dear PPSP, Just completed a review of V3 of your distributed tracker proposal. =20 Main point: As indicated my me before within PPSP, light-weight solutions are not = often proposed here. This proposal leans towards overengineering. =20 This proposal does not make a distinction between tracker replication and distribution using PEX or DHT. By having multiple central trackers, reliability should improve. However, how many seconds does a peer wait when a query gets no reply? If a peer waits for 10 seconds before trying a secondairy peers the result is significant loss of user experienced performance and degradation of streaming service. Should a peer issue multiple request in parallel to ensure fast performance at the cost of server resources? From my viewpoint a PPSP standard should recommend policies here. You agree? [Lin]: Yes. I think parallel requests may necessary, but not from peer = directly. To keep the simplification, we need decouple the PPSP tracker = protocol with the distributed tracker deployment solution here. A = normative tracker request is sent to a local tracker (by tracker = protocol). This local tracker takes the responsibility for the = distributed searching, which needn=A1=AFt be aware by the requested = peer. As local swarms managed by the tracker, at most time it can reply = a list with local peers. Or the swarm tracker, which responsible for the = swarm globally, should be queried. The solution can reduce the cross = area traffic in both peer overlay and tracker overlay. But considering = the waiting time, as you suggested, the local tracker may send query the = tracker overlay at the same time when it searches the swarm locally. =20 =20 Section 2 defines six different entities/roles, where 2 is the minimum. By expanding the tracker functionality to include network locality, piece availability registration and a tracker2tracker protocol we risk defining a standard which cannot be implemented, scale or compete with the performance of minimalistic solutions. Missing from this draft is the handling of NATed peers. Does the tracker do a simple dialback to check if a peer is connectable? Is connectability part of peer info? [Lin]:Yes. We do need NAT traversal in PPSP, but it should be solved = from the level of PPSP tracker protocol. As the distributed tracker use = directly the PPSP tracker protocol for peer-tracker communication, = it=A1=AFll implement the NAT traversal mechanism adopted by tracker = protocol. PPSP WG had made a decision to take this part out from tracker = protocol as a individual draft for NAT traversal study: http://tools.ietf.org/html/draft-li-ppsp-nat-traversal-02 =20 =20 For over 10 years the Bittorrent tracker protocol seems to be doing well. This proposal is a radical departure from this deployed technology. An explanation why this is done would significantly improve this draft in my opinion. Is that possible? [Lin]: Good question. A single service provider may not require such = complex deployment. However, considering the purpose of the PPSP, which = is to setup a standardized platform for all P2P file/video sharing = applications. Multiple and distributed tracker deployment may required = in the future.=20 =20 =20 Greetings, johan. On 25/10/2011, Xiao, Lin (NSN - CN/Beijing) wrote: > Hi, >=20 >=20 >=20 > As I said, I made another version to give a clearer description. Also = the > Figures and the flows are modified accordingly. >=20 >=20 >=20 > = http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-03.tx= t >=20 >=20 >=20 >=20 >=20 > BR >=20 > Xiao Lin >=20 >=20 >=20 > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf = Of > Xiao, Lin (NSN - CN/Beijing) > Sent: Tuesday, October 25, 2011 4:12 PM > To: ext Yingjie Gu(yingjie); ppsp@ietf.org > Subject: Re: [ppsp] PPSP distributed tracker >=20 >=20 >=20 > Hi Yingjie, >=20 >=20 >=20 > I=A1=AFve answered your questions as followed. >=20 > By the way, I=A1=AFm submitting a updated version 03, which may = describe the > change more clearly. >=20 >=20 >=20 > BR >=20 > Xiao Lin >=20 >=20 >=20 > From: ext Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com] > Sent: Tuesday, October 25, 2011 3:41 PM > To: Xiao, Lin (NSN - CN/Beijing); ppsp@ietf.org > Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker >=20 >=20 >=20 > Thanks to Lin again for doing all the work. >=20 > I would apologize, as co-author, I failed to contribute to this = version of > updating. >=20 > Here is my comments and hope it can help. >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > Best Regards > Gu Yingjie >=20 >=20 >=20 > =B7=A2=BC=FE=C8=CB: Xiao, Lin (NSN - CN/Beijing) = [mailto:lin.xiao@nsn.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D614:41 > =CA=D5=BC=FE=C8=CB: ext Yingjie Gu(yingjie); ppsp@ietf.org > =D6=F7=CC=E2: RE: [ppsp] PPSP distributed tracker >=20 >=20 >=20 > The updating content in v02 includes : >=20 >=20 >=20 > l The local tracker can keep the content record of local peers, at = the > same time when it forwards the content update/registration = information to > tracker overlay. So, most content requests can be solved locally. >=20 > Y.J. Gu : How frequently the content record is shared among trackers? = I > guess not real-time sharing, because the content record is updated = quite > often. It could be an implementation choice, but we can give some = advise in > the draft. >=20 > [Lin]: content record is not shared among trackers, it only stored in = both > local connection tracker (for traffic localization) and the = responsible > swarm tracker located by RELOAD mechanism (maintains overall peerlist = for a > swarm). >=20 >=20 >=20 > l Delete the open issues in chapter 5, and decide to use local = connection > tracker to manage the status of the ppsp peers locally, as most peer > requests are from local peers according to the algorithm mentioned = above. If > the peer status can not be found in local connection tracker, the = request is > forwarded to the tracker overlay, as each local tracker always = registries > its own address to a node on tracker overly, whose ID has a DHT = mapping > with the PPSP peer. As the position of the peer status , which is also = the > peer=A1=AFs connection node address, is always registered to the = tracker overlay > according to RELOAD. >=20 > Y.J. Gu : Why not share peer status when you share content record? The > reason that we share content record among trackers is to decrease the > response time to a request for some content that is not locally = stored. If > the content can be found locally, but the tracker still have to find = the > status through the overlay, it doesn=A1=AFt decrease the response = time. The > status shared on tracker overlay might not be accurate, but neither do = the > content record. It=A1=AFs only a way to improve the performance. The = peer, who > get an inaccurate information from the tracker, can correct it by > communicating with the peers in peerlist. Even the local connection = tracker > can not promise an accurate content record and peer status. >=20 > [Lin]: No. I mean, node status always maintained by its local = connection > tracker, but only put the information that how to find the local = connection > tracker of the peer (the position of the peer status) on the tracker > overlay. So, the frequent status updates can be done locally, but = there > must be a way (by RELOAD overlay ) to find the position of the status > information, and the position information do not need frequent = updates, > which saves the traffic across overlay. >=20 >=20 >=20 > l A data kind for peerStatusIndex is defined. >=20 >=20 >=20 > As still some editorial errors, I=A1=AFll give a new version soon. >=20 >=20 >=20 >=20 >=20 > BR >=20 > Xiao Lin >=20 >=20 >=20 > From: ext Yingjie Gu(yingjie) [mailto:guyingjie@huawei.com] > Sent: Tuesday, October 25, 2011 11:35 AM > To: Xiao, Lin (NSN - CN/Beijing); ppsp@ietf.org > Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker >=20 >=20 >=20 > Thanks lin for updating the draft. >=20 > Maybe it=A1=AFs better to give a brief introduction of the updating = from -01 > version to -02 version. >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > Best Regards > Gu Yingjie >=20 >=20 >=20 > =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] =B4=FA=B1=ED Xiao, Lin (NSN > - CN/Beijing) > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D611:19 > =CA=D5=BC=FE=C8=CB: ppsp@ietf.org > =D6=F7=CC=E2: [ppsp] PPSP distributed tracker >=20 >=20 >=20 > Hi All, >=20 >=20 >=20 > I=A1=AFve updated the distributed tracker draft for a while. Could you = please > give your comment on it ? Thanks! >=20 >=20 >=20 > = http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.tx= t >=20 >=20 >=20 >=20 >=20 > Abstract >=20 >=20 >=20 > This document defines PPSP tracker usages for REsource LOcation And >=20 > Discovery (RELOAD). Although PPSP assumes a centralized tracker from >=20 > peer's point of view, the logical centralized tracker could be = realized >=20 > by a cluster of geographically distributed trackers. In this draft, we >=20 > design distributed trackers system, which are organized by RELOAD. It >=20 > provides lookup service for file/channel indexes and Peer Status among >=20 > the distributed trackers. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > BR >=20 > Xiao Lin >=20 >=20 ------_=_NextPart_001_01CC9453.AEFDD76E Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi = Johan,

 

Thank you very much for your = comments. I agree with you that the proposal now is not that mature. = Valuable suggestions are appreciated and helpful to refine the solution. =  

Try to answer your questions in = line as following:

 

BR

Xiao = Lin

-----Original Message-----
From: ext Johan Pouwelse = [mailto:peer2peer@gmail.com]
Sent: Thursday, October 27, 2011 5:39 = AM
To: Xiao, Lin (NSN - CN/Beijing)
Cc: ext Yingjie Gu(yingjie); = ppsp@ietf.org
Subject: Re: [ppsp] PPSP distributed = tracker

 

Dear PPSP,

Just completed a review of V3 of = your distributed tracker proposal.

 

Main = point:

As indicated my me before within PPSP, light-weight = solutions are not often

proposed here. This proposal = leans towards overengineering.

 

This proposal does not make a = distinction between tracker replication

and distribution using PEX or = DHT. By having multiple central

trackers, reliability should = improve. However, how many seconds does a

peer wait when a query gets no = reply? If a peer waits for 10 seconds

before trying a secondairy peers = the result is significant loss of

user experienced performance and = degradation of streaming service.

Should a peer issue multiple = request in parallel to ensure fast

performance at the cost of = server resources? From my viewpoint a PPSP

standard should recommend = policies here. You agree?

[Lin]: Yes. I think parallel = requests may necessary, but not from peer directly. To keep the = simplification, we need decouple the PPSP tracker protocol with the = distributed tracker deployment solution here. A normative tracker = request is sent to a local tracker (by tracker protocol). This local = tracker takes the responsibility for the distributed searching, which = needn=A1=AFt be aware by the requested = peer. As local swarms managed by the tracker, at most time it can reply = a list with local peers. Or the swarm tracker, which responsible for the = swarm globally, should be queried. The solution can reduce the cross = area traffic in both peer overlay and tracker overlay. But considering = the waiting time, as you suggested, the local tracker may send query the = tracker overlay at the same time when it searches the swarm = locally.

 

 

Section 2 defines six different = entities/roles, where 2 is the

minimum. By expanding the = tracker functionality to include network

locality, piece availability = registration and a tracker2tracker

protocol we risk defining a = standard which cannot be implemented,

scale or compete with the = performance of minimalistic solutions.

Missing from this draft is the = handling of NATed peers. Does the

tracker do a simple dialback to = check if a peer is connectable? Is

connectability part of peer = info?

[Lin]:Yes. We do need NAT = traversal in PPSP, but it should be solved from the level of PPSP = tracker protocol. As the distributed tracker use directly the PPSP = tracker protocol for peer-tracker communication, it=A1=AFll implement the NAT traversal = mechanism adopted by tracker protocol. PPSP WG had made a decision to = take this part out from tracker protocol as a individual draft for NAT = traversal study:

http:/= /tools.ietf.org/html/draft-li-ppsp-nat-traversal-02=

 

 

For over 10 years the Bittorrent = tracker protocol seems to be doing

well. This proposal is a radical = departure from this deployed

technology. An explanation why = this is done would significantly

improve this draft in my = opinion. Is that possible?

[Lin]: Good question. A single = service provider may not require such complex deployment. However, = considering the purpose of the PPSP, which is to setup a standardized = platform for all P2P file/video sharing applications. Multiple and = distributed tracker deployment may required in the future. =

 

 

Greetings, = johan.

On 25/10/2011, Xiao, Lin (NSN - CN/Beijing) = <lin.xiao@nsn.com> wrote:

> Hi,

> 

> 

> 

> As I said, I made another = version to give a clearer description. Also the

> Figures and the flows are = modified accordingly.

> 

> 

> 

> = http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-03.tx= t

> 

> 

> 

> 

> 

> BR

> 

> Xiao = Lin

> 

> 

> 

> From: ppsp-bounces@ietf.org = [mailto:ppsp-bounces@ietf.org] On Behalf Of

> Xiao, Lin (NSN - = CN/Beijing)

> Sent: Tuesday, October 25, 2011 4:12 = PM

> = To: ext Yingjie Gu(yingjie); ppsp@ietf.org

> Subject: Re: [ppsp] PPSP = distributed tracker

> 

> 

> 

> Hi = Yingjie,

> 

> 

> 

> I=A1=AFve = answered your questions as followed.

> 

> By the way, I=A1=AFm submitting a updated version 03, which may describe = the

> = change more clearly.

> 

> 

> 

> BR

> 

> Xiao = Lin

> 

> 

> 

> From: ext Yingjie = Gu(yingjie) [mailto:guyingjie@huawei.com]

> Sent: Tuesday, October 25, = 2011 3:41 PM

> To: Xiao, Lin (NSN - CN/Beijing); = ppsp@ietf.org

> Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker

> 

> 

> 

> Thanks to Lin  again = for doing all the work.

> 

> I would apologize, as = co-author, I failed to contribute to this version = of

> = updating.

> 

> Here is my comments and = hope it can help.

> 

> 

> 

> 

> 

> = ________________________________

> 

> Best = Regards

> Gu Yingjie

> 

> 

> 

> =B7=A2=BC=FE=C8=CB: Xiao, Lin (NSN - CN/Beijing) = [mailto:lin.xiao@nsn.com]

> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D614:41

> =CA=D5=BC=FE=C8=CB: ext Yingjie Gu(yingjie); = ppsp@ietf.org

> =D6=F7=CC=E2: RE: [ppsp] PPSP distributed = tracker

> 

> 

> 

> The updating content in v02 = includes :

> 

> 

> 

> l  The local tracker = can keep the content record of  local peers, at = the

> = same time when it forwards the  content update/registration = information to

> tracker overlay. So, most content requests can be = solved locally.

> 

> Y.J. Gu :  How = frequently the content record is shared among trackers?  = I

> = guess not real-time sharing, because the content record is updated = quite

> often.  It could be an implementation choice, but = we can give some advise in

> the = draft.

> 

> [Lin]: content record is = not shared among trackers, it only stored in = both

> local connection tracker (for traffic localization) = and the responsible

> swarm tracker located by RELOAD mechanism (maintains = overall peerlist for a

> = swarm).

> 

> 

> 

> l  Delete  the = open issues in chapter 5, and decide to use local = connection

> tracker to manage the status of the ppsp peers = locally, as most peer

> requests are from local peers according to the = algorithm mentioned above. If

> the peer status can not be = found in local connection tracker, the request = is

> = forwarded to the tracker overlay, as each local tracker always = registries

> its own address to a node on tracker overly, whose ID = has a DHT mapping

> with the PPSP peer. As the position of the peer status = , which is also the

> peer=A1=AFs = connection node address, is always registered to the tracker = overlay

> according to RELOAD.

> 

> Y.J. Gu : Why not share = peer status when you share content record? The

> reason that we share = content record among trackers is to decrease the

> response time to a request = for some content that is not locally stored. If

> the content can be found = locally, but the tracker still have to find the

> status through the overlay, = it doesn=A1=AFt decrease the response time. = The

> = status shared on tracker overlay might not be accurate, but neither do = the

> = content record. It=A1=AFs = only a way to improve the performance. The peer, = who

> = get an inaccurate information from the tracker, can correct it = by

> = communicating with the peers in peerlist. Even the local connection = tracker

> can not promise an accurate content record and peer = status.

> 

> [Lin]:   No. I = mean, node status always maintained by its local = connection

> tracker, but only put the information that how to find = the local connection

> tracker of the peer (the position of the peer status) = on the tracker

> overlay.  So, the frequent status updates can be = done locally, but there

> must be a way (by RELOAD = overlay ) to find the position of the status

> information, and the = position information do not need frequent = updates,

> which saves the traffic across = overlay.

> 

> 

> 

> l  A data kind for = peerStatusIndex is defined.

> 

> 

> 

> As still some editorial = errors, I=A1=AFll give a new version = soon.

> 

> 

> 

> 

> 

> BR

> 

> Xiao = Lin

> 

> 

> 

> From: ext Yingjie = Gu(yingjie) [mailto:guyingjie@huawei.com]

> Sent: Tuesday, October 25, = 2011 11:35 AM

> To: Xiao, Lin (NSN - CN/Beijing); = ppsp@ietf.org

> Subject: =B4=F0=B8=B4: [ppsp] PPSP distributed tracker

> 

> 

> 

> Thanks lin for updating the = draft.

> 

> Maybe it=A1=AFs better to give a brief introduction of the updating from = -01

> = version to -02 version.

> 

> 

> 

> 

> 

> = ________________________________

> 

> Best = Regards

> Gu Yingjie

> 

> 

> 

> =B7=A2=BC=FE=C8=CB: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] = =B4=FA=B1=ED Xiao, Lin (NSN

> - = CN/Beijing)

> =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 =C0=D6=C0=D611:19

> =CA=D5=BC=FE=C8=CB: ppsp@ietf.org

> =D6=F7=CC=E2: [ppsp] PPSP distributed tracker

> 

> 

> 

> Hi = All,

> 

> 

> 

> I=A1=AFve = updated the distributed tracker draft for a while. Could you = please

> give your comment on it ? = Thanks!

> 

> 

> 

> = http://tools.ietf.org/id/draft-xiao-ppsp-reload-distributed-tracker-02.tx= t

> 

> 

> 

> 

> 

> = Abstract

> 

> 

> 

> This document defines PPSP = tracker usages for REsource LOcation And

> 

> Discovery (RELOAD).  = Although PPSP assumes a centralized tracker from

> 

> peer's point of view, the = logical centralized tracker could be realized

> 

> by a cluster of = geographically distributed trackers. In this draft, = we

> 

> design distributed trackers = system, which are organized by RELOAD. It

> 

> provides lookup service for = file/channel indexes and Peer Status among

> 

> the distributed = trackers.

> 

> 

> 

> 

> 

> 

> 

> BR

> 

> Xiao = Lin

> 

> 

------_=_NextPart_001_01CC9453.AEFDD76E-- From zhangyunfei@chinamobile.com Sun Oct 30 06:13:56 2011 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 AEF1E21F8B33 for ; Sun, 30 Oct 2011 06:13:56 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -96.224 X-Spam-Level: X-Spam-Status: No, score=-96.224 tagged_above=-999 required=5 tests=[AWL=-1.265, BAYES_50=0.001, CN_BODY_35=0.339, CN_BODY_509=0.029, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, 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 Gg1UXmPnVCGW for ; Sun, 30 Oct 2011 06:13:56 -0700 (PDT) Received: from cmhqproxy1.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 19EAC21F8AAC for ; Sun, 30 Oct 2011 06:13:56 -0700 (PDT) Received: from cmhqproxy1.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 268E6E6CB; Sun, 30 Oct 2011 21:13:55 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by cmhqproxy1.chinamobile.com (Postfix) with ESMTP id 1DB75E6C7; Sun, 30 Oct 2011 21:13:55 +0800 (CST) MIME-Version: 1.0 To: ppsp@ietf.org From: zhangyunfei@chinamobile.com Date: Sun, 30 Oct 2011 21:13:54 +0800 Message-ID: X-Mailer: Lotus Domino Web Server Release 6.5.6 March 06, 2007 X-MIMETrack: Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2011-10-30 21:13:54 MIME-Version: 1.0 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18480.007 X-TM-AS-Result: No--16.284-7.0-31-10 X-imss-scan-details: No--16.284-7.0-31-10;No--16.284-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No Cc: stiemerling@netlab.nec.de Subject: [ppsp] Fw: New Version Notification for draft-ietf-ppsp-problem-statement-06.txt 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: Sun, 30 Oct 2011 13:13:56 -0000 Hi folks, We've updated the new version of PPSP problem statement draft replying all= the comments in Wes' AD review.The main changes besides editorial problems= are: 1)The definition update on chunk in section2; 2) Update of the description of how peers find the head node and how= they find each other in push and hybrid mode compared to how they = find the tracker in a pull-based mode in section 4; 3)Update of the description of section 5.1 and 5.5. Please let me know your comments and suggestions.Thanks. BR Yunfei ************=CF=C2=C3=E6=CA=C7=D7=AA=B7=A2=D3=CA=BC=FE************ =D4=AD=D3=CA=BC=FE=B7=A2=BC=FE=C8=CB=A3=BAinternet-drafts =D4=AD=D3=CA=BC=FE=B7=A2=BC=FE=C8=CB=B5=D8=D6=B7=A3=BAinternet-drafts@ietf.= org =D4=AD=D3=CA=BC=FE=CA=D5=BC=FE=C8=CB=A3=BAzhangyunfei@chinamobile.com =D4=AD=D3=CA=BC=FE=CA=D5=BC=FE=C8=CB=B5=D8=D6=B7 =A3=BAzhangyunfei@chinamob= ile.com =D4=AD=D3=CA=BC=FE=B3=AD=CB=CD=C8=CB=A3=BAyry@cs.yale.edu;gonzalo.camarillo= @ericsson.com;zhangyunfei@chinamobile.com =D4=AD=D3=CA=BC=FE=B3=AD=CB=CD=C8=CB=B5=D8=D6=B7=A3=BAyry@cs.yale.edu;gonza= lo.camarillo@ericsson.com;zhangyunfei@chinamobile.com =B7=A2=CB=CD=CA=B1=BC=E4=A3=BA2011-10-30 21:02:19 A new version of I-D, draft-ietf-ppsp-problem-statement-06.txt has been suc= cessfully submitted by Yunfei Zhang and posted to the IETF repository. Filename: draft-ietf-ppsp-problem-statement Revision: 06 Title: Problem Statement of Peer-to-Peer Streaming Protocol (PPSP) Creation date: 2011-10-29 WG ID: ppsp Number of pages: 25 Abstract: Peer-to-Peer(P2P for short) streaming systems show more and more popularity in current Internet with proprietary protocols. This document identifies problems of the proprietary protocols, proposes a Peer to Peer Streaming Protocol(PPSP) including tracker and peer signaling components, and discusses the scope and uses cases of PPSP. The IETF Secretariat From rui.cruz@ieee-pt.org Mon Oct 31 08:50:37 2011 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 CE8CE21F8D7B for ; Mon, 31 Oct 2011 08:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gmb4pCMWqgLA for ; Mon, 31 Oct 2011 08:50:37 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBF2A21F8D6B for ; Mon, 31 Oct 2011 08:50:29 -0700 (PDT) Received: by wwi36 with SMTP id 36so1088309wwi.13 for ; Mon, 31 Oct 2011 08:50:28 -0700 (PDT) Received: by 10.216.138.209 with SMTP id a59mr4459695wej.94.1320076228397; Mon, 31 Oct 2011 08:50:28 -0700 (PDT) Received: from [10.0.2.15] ([89.180.22.211]) by mx.google.com with ESMTPS id gd6sm33207930wbb.1.2011.10.31.08.50.26 (version=SSLv3 cipher=OTHER); Mon, 31 Oct 2011 08:50:27 -0700 (PDT) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_0A11F17F-ABF0-4872-9F6F-3791F01090F8" From: Rui Cruz In-Reply-To: <20111031112206.30317.90541.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 15:50:25 +0000 Message-Id: References: <20111031112206.30317.90541.idtracker@ietfa.amsl.com> To: ppsp X-Mailer: Apple Mail (2.1251.1) Cc: Rui Cruz Subject: Re: [ppsp] New Version Notification for draft-gu-ppsp-tracker-protocol-06.txt 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, 31 Oct 2011 15:50:37 -0000 --Apple-Mail=_0A11F17F-ABF0-4872-9F6F-3791F01090F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, We have updated the PPSP Tracker Protocol draft, corresponding to the = merge of the former drafts from Gu and Cruz.=20 The changes reflect the details and suggestions discussed in recent = meetings and in the mailing list. Please let us know your comments and suggestions. Thanks. --------------------------- Best Regards, Prof. Rui Santos Cruz Chairman IEEE Portugal Section Av. Prof. Dr. An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal +351 214 233 200 (ext 5044), +351.939 060 939 (mobile) rui.cruz@ieee.org=20 rui.s.cruz@ist.utl.pt sec.portugal@ieee.org www.ieee-pt.org Advancing technology for humanity. On 31/10/2011, at 11:22, internet-drafts@ietf.org wrote: > A new version of I-D, draft-gu-ppsp-tracker-protocol-06.txt has been = successfully submitted by Rui Cruz and posted to the IETF repository. >=20 > Filename: draft-gu-ppsp-tracker-protocol > Revision: 06 > Title: PPSP Tracker Protocol > Creation date: 2011-10-30 > WG ID: Individual Submission > Number of pages: 44 >=20 > Abstract: > This document outlines the functionality required for an HTTP-based > P2P Streaming Tracker Protocol, including requirements, functional > entities and architecture, components, message flows, with detailed > message processing instructions using an HTTP/XML encoding, the > respective parameters, methods, and message formats, formal syntax > and semantics. The PPSP Tracker Protocol proposed in this document > extends the capabilities of PPSP to support adaptive and scalable > video and 3D video, for Video On Demand (VoD) and Live video > services. The Tracker Protocol is an application-level protocol for > peers to publish/request content, provide peer lists to peers and > peer status to Trackers. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail=_0A11F17F-ABF0-4872-9F6F-3791F01090F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

---------------------------
Best = Regards,

Chairman
IEEE Portugal Section
Av. Prof. Dr. = An=EDbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 = Porto Salvo, Portugal
+351 214 233 200 (ext 5044), +351.939 060 = 939 (mobile)
rui.cruz@ieee.org 
rui.s.cruz@ist.utl.pt
sec.portugal@ieee.org
www.ieee-pt.org
Advancing = technology for humanity.

On 31/10/2011, at 11:22, internet-drafts@ietf.org = wrote:

A new version of I-D, = draft-gu-ppsp-tracker-protocol-06.txt has been successfully submitted by = Rui Cruz and posted to the IETF repository.

Filename: = draft-gu-ppsp-tracker-protocol
Revision: 06
Title: PPSP = Tracker Protocol
Creation date: 2011-10-30
WG ID: = Individual Submission
Number of pages: 44

Abstract:
=   This document outlines the functionality required for an = HTTP-based
  P2P Streaming Tracker Protocol, including = requirements, functional
  entities and architecture, = components, message flows, with detailed
  message = processing instructions using an HTTP/XML encoding, the
=   respective parameters, methods, and message formats, formal = syntax
  and semantics. The PPSP Tracker Protocol proposed = in this document
  extends the capabilities of PPSP to = support adaptive and scalable
  video and 3D video, for = Video On Demand (VoD) and Live video
  services. The = Tracker Protocol is an application-level protocol for
=   peers to publish/request content, provide peer lists to = peers and
  peer status to = Trackers.




The IETF = Secretariat

= --Apple-Mail=_0A11F17F-ABF0-4872-9F6F-3791F01090F8-- From xiajinwei@huawei.com Mon Oct 31 18:21:47 2011 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 58CA61F0C48 for ; Mon, 31 Oct 2011 18:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.685 X-Spam-Level: X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=0.462, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 LKahTO6a1B88 for ; Mon, 31 Oct 2011 18:21:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 399321F0C4F for ; Mon, 31 Oct 2011 18:21:46 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY003U2JS4O9@szxga04-in.huawei.com> for ppsp@ietf.org; Tue, 01 Nov 2011 09:21:40 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY0058WJRSXX@szxga04-in.huawei.com> for ppsp@ietf.org; Tue, 01 Nov 2011 09:21:40 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ71503; Tue, 01 Nov 2011 09:21:39 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 09:21:36 +0800 Received: from SZXEML511-MBX.china.huawei.com ([169.254.3.245]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Tue, 01 Nov 2011 09:21:29 +0800 Date: Tue, 01 Nov 2011 01:21:28 +0000 From: Xiajinwei X-Originating-IP: [10.138.41.52] To: "ppsp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-gu-ppsp-peer-protocol-03.txt Thread-index: AQHMl7z9aWtcBWdsOU2XbMUCzMs7GJWXOP8Q X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [ppsp] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-gu-ppsp-peer-protocol-03=2Etxt?= 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: Tue, 01 Nov 2011 01:21:47 -0000 SGksDQoNCldlIGhhdmUgdXBkYXRlZCB0aGUgUFBTUCBUcmFja2VyIFByb3RvY29sIGRyYWZ0LCBj b3JyZXNwb25kaW5nIHRvIHRoZSBtZXJnZSBvZiB0aGUgZm9ybWVyIGRyYWZ0cyBmcm9tIEd1IGFu ZCBDcnV6LiANCg0KVGhpcyB2ZXJzaW9uIG1haW5seSBmb2N1cyBvbiB0aGUgbWVzc2FnZXMgZXhj aGFuZ2VkIGJldHdlZW4gcGVlcnMsIGJ1dCBsZWF2ZSB0aGUgZW5jb2RpbmcgZm9ybWF0IGludG8g QXBwZW5kaXggc2luY2UgdXNpbmcgYmluYXJ5IG9yIEhUVFAvWE1MIGFzIGNvbnRhaW5lciBpcyBz dGlsbCB1bmRlciBkaXNwdXRlLg0KDQpQbGVhc2UgbGV0IHVzIGtub3cgeW91ciBjb21tZW50cyBh bmQgc3VnZ2VzdGlvbnMuDQoNClRoYW5rcy4NCg0KSmlud2VpDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2 LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaXtumXtDogMjAxMeW5tDEw5pyIMzHml6UgMTk6 MDQNCuaUtuS7tuS6ujogWGlhamlud2VpDQrmioTpgIE6IFhpYWppbndlaTsgWWluZ2ppZSBHdSh5 aW5namllKTsgbWFyaW8ubnVuZXNAaW5vdi5wdDsgam9hby5zaWx2YUBpbm92LnB0OyBydWkuY3J1 ekBpZWVlLm9yZzsgZGJyeWFuQGV0aGVybm90Lm9yZw0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWd1LXBwc3AtcGVlci1wcm90b2NvbC0wMy50eHQNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWd1LXBwc3AtcGVlci1wcm90b2NvbC0wMy50eHQgaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKaW53ZWkgWGlhIGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1ndS1wcHNwLXBlZXItcHJvdG9j b2wNClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIFBlZXIgUHJvdG9jb2wNCkNyZWF0aW9uIGRhdGU6 CSAyMDExLTEwLTMxDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBw YWdlczogMzENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHByZXNlbnRzIHRoZSBhcmNo aXRlY3R1cmUgb2YgdGhlIFBQU1AgUGVlciBwcm90b2NvbA0KICAgb3V0bGluaW5nIHRoZSBmdW5j dGlvbmFsIGVudGl0aWVzLCBtZXNzYWdlIGZsb3dzIGFuZCBtZXNzYWdlDQogICBwcm9jZXNzaW5n IGluc3RydWN0aW9ucywgd2l0aCB0aGUgcmVzcGVjdGl2ZSBwYXJhbWV0ZXJzLiAgVGhlIFBQU1AN CiAgIFBlZXIgUHJvdG9jb2wgcHJvcG9zZWQgaW4gdGhpcyBkb2N1bWVudCBleHRlbmRzIHRoZSBj YXBhYmlsaXRpZXMgb2YNCiAgIFBQU1AgdG8gc3VwcG9ydCBhZGFwdGl2ZSBhbmQgc2NhbGFibGUg dmlkZW8gYW5kIDNEIHZpZGVvLCBmb3IgVmlkZW8NCiAgIE9uIERlbWFuZCAoVm9EKSBhbmQgTGl2 ZSB2aWRlbyBzZXJ2aWNlcy4gIFRoZSBwcm90b2NvbCBtZXNzYWdlcw0KICAgZm9ybWFsIHN5bnRh eCBhbmQgc2VtYW50aWNzLCBtZXRob2RzLCBhbmQgZm9ybWF0cyBhcmUgcHJlc2VudGVkIGZvcg0K ICAgYm90aCBCaW5hcnkgYW5kIEhUVFAvWE1MIGVuY29kZWQgZm9ybWF0cy4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQo= From li.lichun1@zte.com.cn Mon Oct 31 18:56:19 2011 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 33B6A1F0D92; Mon, 31 Oct 2011 18:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.451 X-Spam-Level: X-Spam-Status: No, score=-92.451 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 5SN41SdvqKJR; Mon, 31 Oct 2011 18:56:18 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 706D61F0D76; Mon, 31 Oct 2011 18:56:16 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901821921442; Tue, 1 Nov 2011 09:47:22 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 16073.2106504928; Tue, 1 Nov 2011 09:55:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pA11twxM039147; Tue, 1 Nov 2011 09:55:58 +0800 (GMT-8) (envelope-from li.lichun1@zte.com.cn) In-Reply-To: To: Xiajinwei MIME-Version: 1.0 X-KeepSent: DF918261:0FDBB5BD-4825793B:000A0EB5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: li.lichun1@zte.com.cn Date: Tue, 1 Nov 2011 09:55:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-01 09:55:59, Serialize complete at 2011-11-01 09:55:59 Content-Type: multipart/alternative; boundary="=_alternative 000AECA74825793B_=" X-MAIL: mse01.zte.com.cn pA11twxM039147 Cc: "ppsp@ietf.org" , ppsp-bounces@ietf.org Subject: Re: [ppsp] =?gb2312?b?16q3ojogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?gb2312?b?ciBkcmFmdC1ndS1wcHNwLXBlZXItcHJvdG9jb2wtMDMudHh0?= 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: Tue, 01 Nov 2011 01:56:19 -0000 This is a multipart message in MIME format. --=_alternative 000AECA74825793B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSB0aGluayBYTUwgb3ZlciBVRFAgaXMgYWxzbyBhIGdvb2Qgb3B0aW9uLg0KDQpCUg0KTGljaHVu DQoNCg0KcHBzcC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMS0xMS0wMSAwOToyMToyODoNCg0K PiBIaSwNCj4gDQo+IFdlIGhhdmUgdXBkYXRlZCB0aGUgUFBTUCBUcmFja2VyIFByb3RvY29sIGRy YWZ0LCBjb3JyZXNwb25kaW5nIHRvIA0KPiB0aGUgbWVyZ2Ugb2YgdGhlIGZvcm1lciBkcmFmdHMg ZnJvbSBHdSBhbmQgQ3J1ei4gDQo+IA0KPiBUaGlzIHZlcnNpb24gbWFpbmx5IGZvY3VzIG9uIHRo ZSBtZXNzYWdlcyBleGNoYW5nZWQgYmV0d2VlbiBwZWVycywgDQo+IGJ1dCBsZWF2ZSB0aGUgZW5j b2RpbmcgZm9ybWF0IGludG8gQXBwZW5kaXggc2luY2UgdXNpbmcgYmluYXJ5IG9yIA0KPiBIVFRQ L1hNTCBhcyBjb250YWluZXIgaXMgc3RpbGwgdW5kZXIgZGlzcHV0ZS4NCj4gDQo+IFBsZWFzZSBs ZXQgdXMga25vdyB5b3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucy4NCj4gDQo+IFRoYW5rcy4N Cj4gDQo+IEppbndlaQ0KPiANCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCj4g t6LLzcqxvOQ6IDIwMTHE6jEw1MIzMcjVIDE5OjA0DQo+IMrVvP7IyzogWGlhamlud2VpDQo+ILOt y806IFhpYWppbndlaTsgWWluZ2ppZSBHdSh5aW5namllKTsgbWFyaW8ubnVuZXNAaW5vdi5wdDsg am9hby4NCj4gc2lsdmFAaW5vdi5wdDsgcnVpLmNydXpAaWVlZS5vcmc7IGRicnlhbkBldGhlcm5v dC5vcmcNCj4g1vfM4jogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1ndS1wcHNw LXBlZXItcHJvdG9jb2wtMDMudHh0DQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt Z3UtcHBzcC1wZWVyLXByb3RvY29sLTAzLnR4dCBoYXMgYmVlbiANCj4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBKaW53ZWkgWGlhIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4N Cj4gDQo+IEZpbGVuYW1lOiAgICBkcmFmdC1ndS1wcHNwLXBlZXItcHJvdG9jb2wNCj4gUmV2aXNp b246ICAgIDAzDQo+IFRpdGxlOiAgICAgICBQZWVyIFByb3RvY29sDQo+IENyZWF0aW9uIGRhdGU6 ICAgIDIwMTEtMTAtMzENCj4gV0cgSUQ6ICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBO dW1iZXIgb2YgcGFnZXM6IDMxDQo+IA0KPiBBYnN0cmFjdDoNCj4gICAgVGhpcyBkb2N1bWVudCBw cmVzZW50cyB0aGUgYXJjaGl0ZWN0dXJlIG9mIHRoZSBQUFNQIFBlZXIgcHJvdG9jb2wNCj4gICAg b3V0bGluaW5nIHRoZSBmdW5jdGlvbmFsIGVudGl0aWVzLCBtZXNzYWdlIGZsb3dzIGFuZCBtZXNz YWdlDQo+ICAgIHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb25zLCB3aXRoIHRoZSByZXNwZWN0aXZlIHBh cmFtZXRlcnMuICBUaGUgUFBTUA0KPiAgICBQZWVyIFByb3RvY29sIHByb3Bvc2VkIGluIHRoaXMg ZG9jdW1lbnQgZXh0ZW5kcyB0aGUgY2FwYWJpbGl0aWVzIG9mDQo+ICAgIFBQU1AgdG8gc3VwcG9y dCBhZGFwdGl2ZSBhbmQgc2NhbGFibGUgdmlkZW8gYW5kIDNEIHZpZGVvLCBmb3IgVmlkZW8NCj4g ICAgT24gRGVtYW5kIChWb0QpIGFuZCBMaXZlIHZpZGVvIHNlcnZpY2VzLiAgVGhlIHByb3RvY29s IG1lc3NhZ2VzDQo+ICAgIGZvcm1hbCBzeW50YXggYW5kIHNlbWFudGljcywgbWV0aG9kcywgYW5k IGZvcm1hdHMgYXJlIHByZXNlbnRlZCBmb3INCj4gICAgYm90aCBCaW5hcnkgYW5kIEhUVFAvWE1M IGVuY29kZWQgZm9ybWF0cy4NCj4gDQo+ICANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlh dA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBw cHNwIG1haWxpbmcgbGlzdA0KPiBwcHNwQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcHBzcA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 000AECA74825793B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgWE1MIG92ZXIgVURQ IGlzIGFsc28gYSBnb29kDQpvcHRpb24uPGJyPg0KPGJyPg0KQlI8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxpY2h1bjxicj4NCjwvZm9udD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPnBwc3AtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTEtMTEtMDEgMDk6 MjE6Mjg6PGJyPg0KPGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgV2UgaGF2ZSB1 cGRhdGVkIHRoZSBQUFNQIFRyYWNrZXIgUHJvdG9jb2wgZHJhZnQsIGNvcnJlc3BvbmRpbmcgdG8N Cjxicj4NCiZndDsgdGhlIG1lcmdlIG9mIHRoZSBmb3JtZXIgZHJhZnRzIGZyb20gR3UgYW5kIENy dXouIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIHZlcnNpb24gbWFpbmx5IGZvY3VzIG9uIHRo ZSBtZXNzYWdlcyBleGNoYW5nZWQgYmV0d2VlbiBwZWVycywNCjxicj4NCiZndDsgYnV0IGxlYXZl IHRoZSBlbmNvZGluZyBmb3JtYXQgaW50byBBcHBlbmRpeCBzaW5jZSB1c2luZyBiaW5hcnkgb3IN Cjxicj4NCiZndDsgSFRUUC9YTUwgYXMgY29udGFpbmVyIGlzIHN0aWxsIHVuZGVyIGRpc3B1dGUu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFBsZWFzZSBsZXQgdXMga25vdyB5b3VyIGNvbW1lbnRzIGFu ZCBzdWdnZXN0aW9ucy48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBKaW53ZWk8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS3Tyrz+1K28/i0tLS0tPGJy Pg0KJmd0OyC3orz+yMs6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZ10NCjxicj4NCiZndDsgt6LLzcqxvOQ6IDIwMTHE6jEw1MIzMcjVIDE5 OjA0PGJyPg0KJmd0OyDK1bz+yMs6IFhpYWppbndlaTxicj4NCiZndDsgs63LzTogWGlhamlud2Vp OyBZaW5namllIEd1KHlpbmdqaWUpOyBtYXJpby5udW5lc0Bpbm92LnB0OyBqb2FvLjxicj4NCiZn dDsgc2lsdmFAaW5vdi5wdDsgcnVpLmNydXpAaWVlZS5vcmc7IGRicnlhbkBldGhlcm5vdC5vcmc8 YnI+DQomZ3Q7INb3zOI6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ3UtcHBz cC1wZWVyLXByb3RvY29sLTAzLnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyBBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtZ3UtcHBzcC1wZWVyLXByb3RvY29sLTAzLnR4dCBoYXMgYmVlbg0KPGJy Pg0KJmd0OyBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEppbndlaSBYaWEgYW5kIHBvc3RlZCB0 byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBGaWxlbmFtZTogJm5i c3A7ICZuYnNwO2RyYWZ0LWd1LXBwc3AtcGVlci1wcm90b2NvbDxicj4NCiZndDsgUmV2aXNpb246 ICZuYnNwOyAmbmJzcDswMzxicj4NCiZndDsgVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBl ZXIgUHJvdG9jb2w8YnI+DQomZ3Q7IENyZWF0aW9uIGRhdGU6ICZuYnNwOyAmbmJzcDsyMDExLTEw LTMxPGJyPg0KJmd0OyBXRyBJRDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgSW5kaXZpZHVhbCBTdWJt aXNzaW9uPGJyPg0KJmd0OyBOdW1iZXIgb2YgcGFnZXM6IDMxPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEFic3RyYWN0Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgcHJlc2VudHMg dGhlIGFyY2hpdGVjdHVyZSBvZiB0aGUgUFBTUCBQZWVyDQpwcm90b2NvbDxicj4NCiZndDsgJm5i c3A7ICZuYnNwO291dGxpbmluZyB0aGUgZnVuY3Rpb25hbCBlbnRpdGllcywgbWVzc2FnZSBmbG93 cyBhbmQNCm1lc3NhZ2U8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtwcm9jZXNzaW5nIGluc3RydWN0 aW9ucywgd2l0aCB0aGUgcmVzcGVjdGl2ZSBwYXJhbWV0ZXJzLg0KJm5ic3A7VGhlIFBQU1A8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDtQZWVyIFByb3RvY29sIHByb3Bvc2VkIGluIHRoaXMgZG9jdW1l bnQgZXh0ZW5kcyB0aGUgY2FwYWJpbGl0aWVzDQpvZjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1BQ U1AgdG8gc3VwcG9ydCBhZGFwdGl2ZSBhbmQgc2NhbGFibGUgdmlkZW8gYW5kIDNEIHZpZGVvLA0K Zm9yIFZpZGVvPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7T24gRGVtYW5kIChWb0QpIGFuZCBMaXZl IHZpZGVvIHNlcnZpY2VzLiAmbmJzcDtUaGUgcHJvdG9jb2wNCm1lc3NhZ2VzPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7Zm9ybWFsIHN5bnRheCBhbmQgc2VtYW50aWNzLCBtZXRob2RzLCBhbmQgZm9y bWF0cyBhcmUNCnByZXNlbnRlZCBmb3I8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtib3RoIEJpbmFy eSBhbmQgSFRUUC9YTUwgZW5jb2RlZCBmb3JtYXRzLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgcHBzcCBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHBwc3BAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHBzcDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjxw cmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJz cDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZu YnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGll bnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3Rv Jm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5i c3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRz Jm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJz Lg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFu c21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNw O2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNl Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJz cDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lm Jm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5i c3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29y aWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmll d3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJl Jm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIu DQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7 Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNw O0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 000AECA74825793B_=-- From guyingjie@huawei.com Mon Oct 31 19:15:56 2011 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 7B8611F0C34 for ; Mon, 31 Oct 2011 19:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.84 X-Spam-Level: X-Spam-Status: No, score=-104.84 tagged_above=-999 required=5 tests=[AWL=1.758, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 jzGkrpsuEnX0 for ; Mon, 31 Oct 2011 19:15:56 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id AA91021F8E0F for ; Mon, 31 Oct 2011 19:15:55 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY0093DM779T@szxga05-in.huawei.com> for ppsp@ietf.org; Tue, 01 Nov 2011 10:13:55 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTY00LIVM75N3@szxga05-in.huawei.com> for ppsp@ietf.org; Tue, 01 Nov 2011 10:13:55 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV34813; Tue, 01 Nov 2011 10:13:54 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 10:13:52 +0800 Received: from g00107907 (10.138.41.134) by szxeml407-hub.china.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 01 Nov 2011 10:13:45 +0800 Date: Tue, 01 Nov 2011 10:16:34 +0800 From: "Yingjie Gu(yingjie)" X-Originating-IP: [10.138.41.134] To: ppsp@ietf.org Message-id: <005501cc983c$47a9ecc0$d6fdc640$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BC+wF1Ak2hMQSndLyYxf7g)" Content-language: zh-cn Thread-index: AcyYPEcfn9IlCn/lTeaJxar9xczoTA== X-CFilter-Loop: Reflected Cc: 'Rui Cruz' Subject: [ppsp] Merged Tracker Protocol has been submitted. 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: Tue, 01 Nov 2011 02:15:56 -0000 --Boundary_(ID_BC+wF1Ak2hMQSndLyYxf7g) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi all, A new Tracker protocol, which merge both draft-gu=A1=AD and = draft-cruz=A1=AD tracker protocol, is submitted.=20 We still use the name of draft-gu-ppsp-tracker-protocol.=20 =20 You can find it at http://tools.ietf.org/html/draft-gu-ppsp-tracker-protocol-06 =20 Any comments are appreciated. =20 _____ =20 Best Regards Gu Yingjie =20 --Boundary_(ID_BC+wF1Ak2hMQSndLyYxf7g) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi= all,

A = new Tracker protocol, which merge both draft-gu=A1=AD and = draft-cruz=A1=AD tracker protocol, is submitted. =

We= still use the name of draft-gu-ppsp-tracker-protocol. =

 

Yo= u can find it at htt= p://tools.ietf.org/html/draft-gu-ppsp-tracker-protocol-06

 

An= y comments are appreciated.

 

B= est Regards
Gu Yingjie

 

= --Boundary_(ID_BC+wF1Ak2hMQSndLyYxf7g)--