From trac+ppsp@trac.tools.ietf.org Mon Jan 30 00:08:35 2012 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 C9A4F21F8600 for ; Mon, 30 Jan 2012 00:08:35 -0800 (PST) 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 NRvcNYr+LaiB for ; Mon, 30 Jan 2012 00:08:35 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id EFF8021F85FC for ; Mon, 30 Jan 2012 00:08:34 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RrmHu-0006R7-Rs; Mon, 30 Jan 2012 03:08:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Mon, 30 Jan 2012 08:08:30 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/3#comment:1 Message-ID: <067.063c8fe80df3894c95c836740468203c@trac.tools.ietf.org> References: <052.4e42b5ce125df950a43947383b3d50af@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <052.4e42b5ce125df950a43947383b3d50af@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120130080834.EFF8021F85FC@ietfa.amsl.com> Resent-Date: Mon, 30 Jan 2012 00:08:34 -0800 (PST) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 01 Feb 2012 18:56:37 -0800 Cc: ppsp@ietf.org Subject: Re: [ppsp] #3: Need to clarify that peer selection is not random, but policy controlled. X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2012 08:08:35 -0000 #3: Need to clarify that peer selection is not random, but policy controlled. Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Text adjusted in -01. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Mon Jan 30 00:09:04 2012 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 C60E521F85FC for ; Mon, 30 Jan 2012 00:09:04 -0800 (PST) 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=[AWL=0.000, 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 H1vlKvF4qnZC for ; Mon, 30 Jan 2012 00:09:04 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 27E8D21F8600 for ; Mon, 30 Jan 2012 00:09:04 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RrmIR-0006Rl-Qz; Mon, 30 Jan 2012 03:09:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Mon, 30 Jan 2012 08:09:03 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/6#comment:1 Message-ID: <067.2a5669173e0fe7e98e26d4500b88847f@trac.tools.ietf.org> References: <052.503f12e0cfbb3cc52fcd0beb045cb177@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <052.503f12e0cfbb3cc52fcd0beb045cb177@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120130080904.27E8D21F8600@ietfa.amsl.com> Resent-Date: Mon, 30 Jan 2012 00:09:04 -0800 (PST) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 01 Feb 2012 18:56:37 -0800 Cc: ppsp@ietf.org Subject: Re: [ppsp] #6: Need to clarify how higher layers can control swift download process X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2012 08:09:04 -0000 #6: Need to clarify how higher layers can control swift download process Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Text adjusted in -01. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Mon Jan 30 00:09:36 2012 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 29FE521F8600 for ; Mon, 30 Jan 2012 00:09:36 -0800 (PST) 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=[AWL=0.000, 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 Kas9Aqq0-omY for ; Mon, 30 Jan 2012 00:09:35 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7D91621F85FC for ; Mon, 30 Jan 2012 00:09:35 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RrmIx-0006SL-6C; Mon, 30 Jan 2012 03:09:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Mon, 30 Jan 2012 08:09:35 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/11#comment:1 Message-ID: <067.b29a353ccb6925f61df73fa18f75c914@trac.tools.ietf.org> References: <052.98bb90912edac98de2605b38903f8d4c@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <052.98bb90912edac98de2605b38903f8d4c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120130080935.7D91621F85FC@ietfa.amsl.com> Resent-Date: Mon, 30 Jan 2012 00:09:35 -0800 (PST) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 01 Feb 2012 18:56:37 -0800 Cc: ppsp@ietf.org Subject: Re: [ppsp] #11: Need to clarify that swift doesn't specify how content is stored. X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2012 08:09:36 -0000 #11: Need to clarify that swift doesn't specify how content is stored. Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Text adjusted in -01. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Mon Jan 30 00:10:20 2012 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 AD2DC21F8600 for ; Mon, 30 Jan 2012 00:10:20 -0800 (PST) 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 q+Z-EVx8EG8x for ; Mon, 30 Jan 2012 00:10:20 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3A50621F85FC for ; Mon, 30 Jan 2012 00:10:20 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RrmJf-0006U1-Sg; Mon, 30 Jan 2012 03:10:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Mon, 30 Jan 2012 08:10:19 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/14#comment:1 Message-ID: <067.6142534bdab64e849771db9c286e996c@trac.tools.ietf.org> References: <052.afbef901ea0ec393ab9e663d9c32c593@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <052.afbef901ea0ec393ab9e663d9c32c593@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120130081020.3A50621F85FC@ietfa.amsl.com> Resent-Date: Mon, 30 Jan 2012 00:10:20 -0800 (PST) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 01 Feb 2012 18:56:37 -0800 Cc: ppsp@ietf.org Subject: Re: [ppsp] #14: Need to clarify which features of swift depend on fixed-sized chunks X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2012 08:10:20 -0000 #14: Need to clarify which features of swift depend on fixed-sized chunks Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Text adjusted in -01. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Mon Jan 30 00:14:10 2012 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 140CC21F85AD for ; Mon, 30 Jan 2012 00:14:10 -0800 (PST) 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 vAOxzsWZWDkk for ; Mon, 30 Jan 2012 00:14:09 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8A221F85A0 for ; Mon, 30 Jan 2012 00:14:09 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RrmNL-0007PU-8U; Mon, 30 Jan 2012 03:14:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Mon, 30 Jan 2012 08:14:07 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/15#comment:1 Message-ID: <067.782f5f10e3d97cfbd439de4669d1a46a@trac.tools.ietf.org> References: <052.a74cf2388202c48c3b9f4b3d306df584@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <052.a74cf2388202c48c3b9f4b3d306df584@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120130081409.4F8A221F85A0@ietfa.amsl.com> Resent-Date: Mon, 30 Jan 2012 00:14:09 -0800 (PST) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 01 Feb 2012 18:56:37 -0800 Cc: ppsp@ietf.org Subject: Re: [ppsp] #15: Need to add explanation to section 2 that this is an example behaviour X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2012 08:14:10 -0000 #15: Need to add explanation to section 2 that this is an example behaviour Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Text adjusted in -01. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Mon Jan 30 00:14:35 2012 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 6088221F85AD for ; Mon, 30 Jan 2012 00:14:35 -0800 (PST) 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=[AWL=0.000, 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 AR-n2BjtrjpW for ; Mon, 30 Jan 2012 00:14:35 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DC65E21F85A0 for ; Mon, 30 Jan 2012 00:14:34 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RrmNm-0007QD-IX; Mon, 30 Jan 2012 03:14:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Mon, 30 Jan 2012 08:14:34 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/30#comment:1 Message-ID: <067.aac51ded68ab10f4b95233c876494660@trac.tools.ietf.org> References: <052.89df026bc79987631665f667cf742faa@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 In-Reply-To: <052.89df026bc79987631665f667cf742faa@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120130081434.DC65E21F85A0@ietfa.amsl.com> Resent-Date: Mon, 30 Jan 2012 00:14:34 -0800 (PST) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 01 Feb 2012 18:56:37 -0800 Cc: ppsp@ietf.org Subject: Re: [ppsp] #30: Need to clarify why multiple HINTs in datagram. X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2012 08:14:35 -0000 #30: Need to clarify why multiple HINTs in datagram. Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Text adjusted in -01. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Mon Jan 30 00:47:18 2012 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 72D0921F84CD for ; Mon, 30 Jan 2012 00:47:18 -0800 (PST) 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=[AWL=0.000, 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 onYS7x+xvgjs for ; Mon, 30 Jan 2012 00:47:17 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4B97421F8473 for ; Mon, 30 Jan 2012 00:47:16 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RrmP0-0007Te-QO; Mon, 30 Jan 2012 03:15:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Mon, 30 Jan 2012 08:15:50 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/33#comment:1 Message-ID: <067.19e33fde7f6a6e482a5b89c95886a09b@trac.tools.ietf.org> References: <052.884addd15ffeb3ae16aaade3aad68809@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <052.884addd15ffeb3ae16aaade3aad68809@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-To: Resent-Message-Id: <20120130084717.4B97421F8473@ietfa.amsl.com> Resent-Date: Mon, 30 Jan 2012 00:47:16 -0800 (PST) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 01 Feb 2012 18:56:37 -0800 Cc: ppsp@ietf.org Subject: Re: [ppsp] #33: Need to clarify built-in NAT hole punching. X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2012 08:47:18 -0000 #33: Need to clarify built-in NAT hole punching. Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Text adjusted in -01. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Mon Jan 30 00:47:18 2012 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 8A4F121F8473 for ; Mon, 30 Jan 2012 00:47:18 -0800 (PST) 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 OKPPbOJtImEi for ; Mon, 30 Jan 2012 00:47:17 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 909DB21F8476 for ; Mon, 30 Jan 2012 00:47:17 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RrmPZ-0007Uh-LG; Mon, 30 Jan 2012 03:16:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Mon, 30 Jan 2012 08:16:25 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/34#comment:1 Message-ID: <067.d93566af110329cd480ff897f2dbee7a@trac.tools.ietf.org> References: <052.07ec78d35389079fddaa8e839d0e983e@trac.tools.ietf.org> X-Trac-Ticket-ID: 34 In-Reply-To: <052.07ec78d35389079fddaa8e839d0e983e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-To: Resent-Message-Id: <20120130084717.909DB21F8476@ietfa.amsl.com> Resent-Date: Mon, 30 Jan 2012 00:47:17 -0800 (PST) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 01 Feb 2012 18:56:37 -0800 Cc: ppsp@ietf.org Subject: Re: [ppsp] #34: Need to clarify resource usage of Merkle hash trees X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2012 08:47:18 -0000 #34: Need to clarify resource usage of Merkle hash trees Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Text adjusted in -01. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Mon Jan 30 00:47:18 2012 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 AD1F721F8476 for ; Mon, 30 Jan 2012 00:47:18 -0800 (PST) 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 DYlEvg6XVe2e for ; Mon, 30 Jan 2012 00:47:18 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C061721F847F for ; Mon, 30 Jan 2012 00:47:17 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RrmOb-0007Sc-25; Mon, 30 Jan 2012 03:15:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Mon, 30 Jan 2012 08:15:25 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/32#comment:1 Message-ID: <067.0dc68d97c7c6c402ad70c7c6a5c451ef@trac.tools.ietf.org> References: <052.6920c175ebb92d9173c11cde86fcf6ed@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <052.6920c175ebb92d9173c11cde86fcf6ed@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-To: Resent-Message-Id: <20120130084717.C061721F847F@ietfa.amsl.com> Resent-Date: Mon, 30 Jan 2012 00:47:17 -0800 (PST) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 01 Feb 2012 18:56:37 -0800 Cc: ppsp@ietf.org Subject: Re: [ppsp] #32: Need to clarify keep-alive mechanism. X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2012 08:47:18 -0000 #32: Need to clarify keep-alive mechanism. Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Text adjusted in -01. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From trac+ppsp@trac.tools.ietf.org Mon Jan 30 00:47:18 2012 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 D2FE321F84CD for ; Mon, 30 Jan 2012 00:47:18 -0800 (PST) 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=[AWL=0.000, 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 vgm17PetzoOY for ; Mon, 30 Jan 2012 00:47:18 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 21ABC21F84AA for ; Mon, 30 Jan 2012 00:47:18 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RrmO9-0007R6-AE; Mon, 30 Jan 2012 03:14:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ppsp issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl X-Trac-Project: ppsp Date: Mon, 30 Jan 2012 08:14:57 -0000 X-URL: http://tools.ietf.org/ppsp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ppsp/trac/ticket/31#comment:1 Message-ID: <067.2f84d5da9179061f07dc316470594324@trac.tools.ietf.org> References: <052.01c9a40500f4fd39ea82c9cdde327156@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <052.01c9a40500f4fd39ea82c9cdde327156@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-ppsp-peer-protocol@tools.ietf.org, arno@cs.vu.nl, ppsp@ietf.org X-SA-Exim-Mail-From: trac+ppsp@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-To: Resent-Message-Id: <20120130084718.21ABC21F84AA@ietfa.amsl.com> Resent-Date: Mon, 30 Jan 2012 00:47:18 -0800 (PST) Resent-From: trac+ppsp@trac.tools.ietf.org X-Mailman-Approved-At: Wed, 01 Feb 2012 18:56:37 -0800 Cc: ppsp@ietf.org Subject: Re: [ppsp] #31: Rename PEX_ADD to PEX_RES. X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 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, 30 Jan 2012 08:47:19 -0000 #31: Rename PEX_ADD to PEX_RES. Changes (by arno@…): * status: new => closed * resolution: => fixed Comment: Text adjusted in -01. -- ---------------------------+---------------------------------------------- Reporter: arno@… | Owner: draft-ietf-ppsp-peer-protocol@… Type: enhancement | Status: closed Priority: major | Milestone: Component: peer-protocol | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------+---------------------------------------------- Ticket URL: ppsp From a.bakker@vu.nl Mon Feb 13 23:31:25 2012 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 3A04C21E8046 for ; Mon, 13 Feb 2012 23:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.084 X-Spam-Level: * X-Spam-Status: No, score=1.084 tagged_above=-999 required=5 tests=[AWL=-2.026, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_24=0.6, J_CHICKENPOX_35=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 JmY5lnjQenHV for ; Mon, 13 Feb 2012 23:31:24 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id AD55E21E803C for ; Mon, 13 Feb 2012 23:31:22 -0800 (PST) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 14 Feb 2012 08:31:17 +0100 Received: from [192.168.0.105] (130.37.238.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 14 Feb 2012 08:31:20 +0100 Message-ID: <4F3A0DE0.5050408@cs.vu.nl> Date: Tue, 14 Feb 2012 08:31:44 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: ppsp Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: [ppsp] Proposal to resolve Issue 17+20... 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, 14 Feb 2012 07:31:25 -0000 Hi all in this mail I propose a solution to the following issues: 17. How to formulate behaviour of Peer-Exchange messages? What is recent? [Kiraly] 20. Evaluate security implications of PEX. [Bakker] And also the use of Distributed Hash Tables (DHTs) with PPSPP. This discussion has implications for the tracker as well. Description =========== In the current protocol a peer A can send a Peer-Exchange message PEX_RES to a peer B, which currently contains the IP address and port of other peers that are supposedly also in the current swarm. The strength of this mechanism is that it allows decentralized tracking, after an initial bootstrap no central tracker is needed anymore. The vulnerability of this mechanism (and DHTs) is that malicious peers can use it for an Amplification attack. In particular, a malicious peer T could send a PEX_RES to well-behaved peer A containing a list of address B1,B2,...,BN and on receipt, peer A could send a HANDSHAKE to all these peers. So in the worst case, a single datagram results in N datagrams. The actual damage depends on A's behaviour. E.g. when A already has sufficient connections it may not connect to the offered ones at all, but if it is a fresh peer it may connect to all directly. Note the impact of the attack is reduced by the secure handshake (see my proposal to resolve Issue 26). Peer A only sends a small HANDSHAKE to the peers Bx. In addition, PEX can be used in Eclipse attacks where malicious peers try to isolate a particular peer such that it only interacts with malicious peers. Let us distinguish two specific attacks: E1. Malicious peers try to eclipse the single injector in live streaming E2. Malicious peers try to eclipse a specific consumer peer. Attack E1 has the most impact on the system as it would disrupt all peers. Protection against Amplification Attack ======================================= The Amplification attack can partly be fended off by policies. For example, a peer could only select a few addresses (randomly) from each PEX_RES message. Or only use PEX when it needs new peers and has not been able to contact the tracker for a while, so just as a fallback. Certification ------------- A stronger protection can be provided by using public key cryptography and certification. The idea is a PEX message will carry membership certificates rather than IP+port. A membership certificate for peer B states that peer B at address ipB+portB is part of swarm S at time T and is cryptographically signed. The receiver A can check the cert for a valid signature, the right swarm and liveliness and only then consider contacting B. Several designs are possible for the security environment for these membership certificates. I'll describe two. 1. "Generic" Certification Authority ------------------------------------ First, we can assume there is a Certification Authority (CA) that hands out what I'll call a basic public key certificate to a peer A wanting to use PPSPP. The basic certificate just says that A is a valid user and protects against Sybil attacks. Now, when peer A wants to join swarm S, it creates a membership certificate mA containing its basic certificate from the CA, its external IP and port, swarm ID S and a time stamp, which it signs with A's private key. Note this assumes A actually knows its external IP and port. When peer A establishes a connection with peer B, it will send mA as part of the handshake procedure, for example, in the third datagram (cert mA is not essential and takes up bytes, so sending it in the first is not required). B then verifies the signature on the cert mA against the included basic certificate, and verifies the basic certificate against the root certificate of the Certification Authority. Subsequently, peer B can send cert mA to other peers in PEX_RES messages. The timestamp in the membership certificate protects against replays, and peer A should regularly create new membership certs. Question is how regularly? The main goal of the membership certs is to prevent that malicious peer T can cause good peer A to contact *random* hosts. The freshness of the timestamp just adds extra protection in addition to achieving that goal. It protects against malicious hosts causing a good peer A to contact hosts that *previously participated in the swarm*. So the attack amplification factor is considerably smaller. So slow refreshes may be acceptable. 2. Tracker as Certification Authority ------------------------------------- Another approach is to let the tracker act as certification authority. A peer A wanting to join swarm S sends a registration message to a tracker X. Upon receipt, the tracker creates a membership certificate from the request with swarm ID S, a timestamp T and the external IP + port it received the message from, signed with the tracker's private key. This certificate is returned to A, along with the peer addresses in the tracker response. Peer A then includes this cert in the handshake, as above, and receiver B verifies it against the tracker public key. This tracker public key should be part of the swarm's metadata, which B received from a trusted source. The registration procedure may have to be changed to a three-way handshake to disable the attack where malicious peers sends lots of registeration messages to the tracker, causing it to do a lot of crypto. Presently, the procedure is already safe against Sybil attacks, if we assume the attackers can spoof but not eavesdrop. In those conditions, malicious peers may send registration messages with spoofed IP addresses, but they won't be able to receive the tracker's responses with the membership certificates. Note that this procedure can also be delayed as it is not essential for operation and may add latency (especially with a 3-way handshake). So a peer could contact the tracker to get some initial peers and try to get content as soon as possible. After prebuffering is over, the peer could contact the tracker again to obtain the membership cert and be able to participate in PEX. The tracker could play the role of bootstrap service. New attack: Amplication attack via membership certs --------------------------------------------------- The membership certificate mechanism itself can be used for a kind of amplication attack. Malicious peer T can cause peer A to spend some CPU to verify the signatures on the membership certificates that T sends. To counter this, A could just check a few of the certs sent and discard the rest. Distributed Hash Tables ----------------------- The same membership certificates described above can be registered in a DHT that has been secured against the well-known DHT specific attacks. In the IETF RELOAD base protocol (http://datatracker.ietf.org/doc/draft-ietf-p2psip-base) all data in stored in the DHT overlay is also signed by the peer. I can't find specifics on peer address storage. Protection Against Eclipse Attacks ================================== Before we can discuss Eclipse attacks we first need to establish the security properties of the central tracker. A tracker is vulnerable to Amplification attacks too. A malicious peer T could register a victim B with the tracker, and many peers joining the swarm will contact B. Trackers can also be used in Eclipse attacks. If many malicious peers register themselves at the tracker, the percentage of bad peers in the returned address list may become high. Leaving the protection of the tracker to the tracker protocol spec, we assume for the following discussion that it returns a true random sample of the actual swarm membership (achieved via Sybil attack protection). This means that if 50% of the peers is bad, you'll still get 50% good addresses from the tracker. Attack E1 on PEX can be fended off by letting live injectors disable PEX. Or at least ensure that part of their connections are to peers whose addresses came from the trusted tracker. The same measures defend against attack E2 on PEX. They can also be employed dynamically. When the current set of peers B that peer A is connected to doesn't provide good quality of service, A can contact the tracker to find new candidates. PuppetCast ========== Even stronger protection mechanisms exists. In PuppetCast [PUPPETCAST] a trusted bootstrap service assigns each peer a set of peers in the swarm that it can advertise to others. Cryptography prevents peers from sending a different set. PuppetCast ensures freshness of the peers in the set (i.e., deals with churn, the leaving and joining of peers) with just a light load on the bootstrap service. PuppetCast protects against Amplification attacks and Eclipse attacks against PEX because the set of peers sent in PEX_RES messages consists of peers that are part of the swarm, and because the set cannot be changed by malicious peers. Proposed Solution Issue 17 ========================== The current draft says about the addresses used in the PEX_RES message. "The addresses MUST be of peers it has recently exchanged messages with to guarantee liveliness." I propose to rewrite this to: "exchanged messages with in the last 60 seconds". Note this value is largely independent of the expiry of membership certificates. A peer may be in a swarm longer than that it is connected to a single peer. Proposed Solution Issue 20 ========================== In sum, there are four approaches to PEX and its potential for amplification attacks. 1. Do not allow the use of PEX. 2. Limit PEX use via policies. E.g. just use as a fallback. 3. Introduce membership certificates + true random sample from tracker. 4. Employ PuppetCast. I propose solution 1 or 3 (with tracker as CA). References ---------- [PUPPETCAST] A. Bakker and M. van Steen. "PuppetCast: A Secure Peer Sampling Protocol". Proceedings 4th Annual European Conference on Computer Network Defense (EC2ND'08), pp. 3-10, Dublin, Ireland, 11-12 December 2008. From a.bakker@vu.nl Tue Feb 14 05:24:39 2012 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 EAF5E21F872B for ; Tue, 14 Feb 2012 05:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_50=0.001, 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 mOcCf673ivMw for ; Tue, 14 Feb 2012 05:24:35 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F71E21F8717 for ; Tue, 14 Feb 2012 05:24:34 -0800 (PST) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 14 Feb 2012 14:24:32 +0100 Received: from [192.168.0.105] (130.37.238.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 14 Feb 2012 14:24:32 +0100 Message-ID: <4F3A60A8.6080800@cs.vu.nl> Date: Tue, 14 Feb 2012 14:24:56 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: ppsp Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [130.37.238.20] Subject: [ppsp] New issues derived from PPSP requirements... 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, 14 Feb 2012 13:24:39 -0000 Hi I've gone over the requirements list in draft-ietf-ppsp-reqs-05 and identified some issues (mostly security related) that need to be discussed in the WG: > * "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 > 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." The current protocol has been designed for short-time-till-playback, unless limited by security considerations (cf. Issue #26 security of handshakes). Otherwise it operates in a best effort mode. But perhaps more is needed, as indicated in the description. Also relevant is issue 12 (=Support for UNHINT), as that helps in making requesting chunks from multiple peers at the same time efficient, as you can cancel the duplicates when you receive an answer. You may need double requests when some peers are slow and strong QoS is needed. I'd like to raise this as Issue #35. > * PPSP.PP.REQ-3: The streaming content availability request message > SHOULD allow the peer to solicit an additional list of peers to that > 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. The draft uses PEX_* messages for this, hence I propose to rephrase this requirement, or declare PEX as sufficient to satisfy this requirement. > * 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. > With this information, a peer can select more appropriate peers for > streaming. I'd like to raise this as Issue #36. > * 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. I'd like to raise this as Issue #37. In addition, I propose the following solution: The Closed Swarms [CLOSED] and Enchanced Closed Swarms [ENHCLOSED] mechanisms developed in the P2P-Next project provide swarm-level access control. The basic idea is that a peer cannot download from another peer unless it shows a Proof-of-Access. Enhanced Closed Swarms improve on the original Closed Swarms by adding on-the-wire encryption against man-in-the-middle attacks and more flexible access control rules. I propose to describe Enhanced Closed Swarms as one of the mechanisms (please put forward others if you know about them) to satisfy the requirement and include it as a Section in the WG draft. > * 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. > No extra mechanism is needed in to support confidentiality in PPSPP. A content publisher wishing confidentiality should just distribute content in cyphertext / DRM-ed format. I assume a higher layer handles key management out-of-band. Alternatively, the swarm access control will point-to-point encrypt content. I'd like to raise this as Issue #38, and propose to add a paragraph to Section 7 of the draft with the explanation I just gave. > * PPSP.SEC.REQ-3: PPSP MUST provide an option to encrypt the data > exchange among the PPSP entities. > If this requirement means that all PPSPP messages should be encrypted (as opposed to just content in SEC.REQ-2), IPsec or DTLS is the obvious solution. I'd like to raise this as Issue #39, and propose to add a paragraph to Section 7 of the draft with the explanation I just gave. Furthermore, a key distribution scheme would have to be added. > * 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. Content integrity protection helps here. I'd like to raise this as Issue #40 and will provide a per-message analysis of issues later. > * PPSP.SEC.REQ-5: PPSP SHOULD support identifying badly behaving peers, > and exclude or reject them from the P2P streaming system. Quoting WG draft 6.3.2.3: "The Merkle tree hashing scheme allows a receiving peer to detect a malicious or faulty sender, which it can subsequently ignore. Spreading this knowledge to other peers such that they know about this bad behavior is hearsay." So we can provide protection, but to actually oust bad peers permanently from the system, access control and a reliable accusation system is needed that is itself protected against malicious peers reporting about good peers. Such a system is complex. I'd like to raise this as Issue #41, and propose to add a paragraph to Section 7 of the draft with the explanation I just gave. > * 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 > streaming system where attackers are capable of consuming a lot of > resources with just a small amount of effort. Quoting WG draft 6.3.2.3: "A risk in peer-to-peer streaming systems is that malicious peers launch an Eclipse [ECLIPSE] attack on the initial injectors of the content (in particular in live streaming). The attack tries to let the injector upload to just malicious peers which then do not forward the content to others, thus stopping the distribution. An Eclipse attack could also be launched on an individual peer. Letting these injectors only use trusted trackers that provide true random samples of the population or using a secure peer sampling service [PUPPETCAST] can help negate such an attack." So we need PEX protection as discussed in the mail "Proposal to resolve Issue 17+20..." of Feb 14th. In addition, a peer A must not let other peers T1..TN fill all its available connection slots, i.e., A must initiate connections itself too, to prevent isolation. Furthermore, to prevent malicious peers consuming all upload bandwidth of a peer, there should be a limit on the upload capacity a single peer can consume, e.g. via a limit on the number of requests as in SecureStream [SECSTREAM]. A natural upper limit of this upload quotum is the bitrate of the content. Protection against amplifcation attacks such as mentioned in the mail "Proposal to solve Issue #26" of Jan 25th also help to satisfy this requirement. If you know any other resource exhaustion attacks possible, please submit them with proposals on how to solve them. I'd like to raise this as Issue #42, and propose to add paragraphs to Section 7 of the draft with the explanation I just gave. > * 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. We need PEX protection as discussed in the mail "Proposal to resolve Issue 17+20..." of Feb 14th. I propose to update Issue 20 to indicate that this requirement is related. > * 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. The Merkle hash trees mechanism provides content integrity protection and is already explained in the draft. Merkle hash trees can also be used for live streaming. In that context we should quote [DIGSIGFLOW], the signature amortization scheme that also uses Merkle trees. I'd like to raise adding the reference as Issue #43. Support for multiple content integrity schemes will be added when we reach concensus on Issue #10+13 (see my mail dd. Jan 18th). What do you think? CU, Arno References ---------- [CLOSED] N. Borch, K. Michell, I. Arntzen, and D. Gabrijelcic: "Access control to BitTorrent swarms using closed swarms". In Proceedings of the 2010 ACM workshop on Advanced video streaming techniques for peer-to-peer networks and social networking (AVSTP2P '10). ACM, New York, NY, USA, 25-30. http://doi.acm.org/10.1145/1877891.1877898 [ENHCLOSED] V. Jovanovikj, D. Gabrijelčič and T. Klobučar. "Access Control in BitTorrent P2P Networks Using the Enhanced Closed Swarms Protocol". In Proceedings of the Fifth International Conference on Emerging Security Information, Systems and Technologies (SECURWARE 2011), pp. 97-102, Nice, France, August 2011. [SECSTREAM] Maya Haridasan and Robbert van Renesse. "SecureStream: An Intrusion-Tolerant Protocol for Live-Streaming Dissemination". The Journal of Computer Communication's Special issue on Foundation of Peer-to-Peer Computing. Volume 31 Number 2, Elsevier, 2008. [DIGSIGFLOW] Chung Kei Wong and Simon S. Lam. "Digital Signatures for Flows and Multicasts". IEEE/ACM Transactions on Networking, Volume 7, Issue 4, pp. 502-513, Aug 1999. http://dx.doi.org/10.1109/90.793005 From a.bakker@vu.nl Wed Feb 15 01:09:19 2012 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 0DF8A21F85FD for ; Wed, 15 Feb 2012 01:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.939 X-Spam-Level: X-Spam-Status: No, score=0.939 tagged_above=-999 required=5 tests=[AWL=-1.571, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_45=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 TwpG3tSO1zDs for ; Wed, 15 Feb 2012 01:09:18 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9257121F85E7 for ; Wed, 15 Feb 2012 01:09:16 -0800 (PST) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 15 Feb 2012 10:09:14 +0100 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 15 Feb 2012 10:09:14 +0100 Message-ID: <4F3B7654.8010706@cs.vu.nl> Date: Wed, 15 Feb 2012 10:09:40 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: ppsp Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Subject: [ppsp] SEC.REQ-4 Analysis 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, 15 Feb 2012 09:09:19 -0000 Hi please find below an analysis of threats of malicious peers. I'll go over each of the message types currently defined and describe how they could be exploited by malicious peers and how to stop that. Please add to the analysis if you identified new threats. > * 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. HANDSHAKE ========= - Secured against DoS amplification attacks as proposed in mail dd. Jan 25th. - Threat 1.1: Eclipse attack where peers T1..TN fill all connection slots of A by initiating the connection to A. Solution: Don't accept all incoming connections, initiate e.g. 50% yourself (see also SEC.REQ-6 discussion in previous mail). HAVE ==== - Threat 2.1: Malicious peer T can claim to have content which it hasn't. Subsequently T won't correspond to requests. Solution: peer A will consider T to be a slow peer and not ask it again. - Threat 2.2: Malicious peer T can claim not to have content. Hence it won't contribute. Solution: Peer+chunk selection policies external to the protocol will implement fairness and provide sharing incentives. Perhaps we should add CHOKE/UNCHOKE messages (Issue #4) as an extra mechanism for these policies to use. ACK === - Threat 3.1: peer T acks wrong chunks. Solution: peer A will detect inconsistencies with what it sent. - Threat 3.2: peer T modifies timestamp in ACK to peer A used for time-based congestion control. Solution: TODO. Could peer T use it to fake there is no congestion when in fact there is, causing A to send more data than it should? DATA ==== - Threat 4.1: peer T sending bogus chunks. Solution: The content integrity protection scheme defends against this. - Threat 4.2: peer T sends peer A unrequested chunks. To protect against this threat we would need network-level DoS prevention. HASH ==== - Threat 5.1: Amplifcation attack: peer T sends HASHes, peer A checks hashes, spending CPU. Solution: If the hashes don't check out A will stop asking T because of the atomic datagram principle and the content integrity protection. HINT ==== - Threat 6.1: peer T could request lots from A, leaving A without resources for others. Solution: Limit upload bandwidth per peer (see also SEC.REQ-6 discussion in previous mail). PEX_RES ======= - See mail dd. Feb 14th on how we can defend against amplication and Eclipse attacks. VERSION ======= - No threats identified. Unsollicited requests in general ================================ - Threat: peer T could send a spoofed PEX_REQ or HINT from peer B to peer A, causing A to send a PEX_RES/DATA to B. Solution: the message from peer T won't be accepted unless T does a handshake first (see mail dd. Jan 25th.), in which case the reply goes to T, not victim B. CU, Arno From zhangyunfei@chinamobile.com Sun Feb 19 07:58:53 2012 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 2D66121F8489 for ; Sun, 19 Feb 2012 07:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.386 X-Spam-Level: X-Spam-Status: No, score=-95.386 tagged_above=-999 required=5 tests=[AWL=-1.029, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RELAY_IS_221=2.222, SARE_HTML_USL_OBFU=1.666, 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 WylNzfluHrN1 for ; Sun, 19 Feb 2012 07:58:51 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2A46621F841A for ; Sun, 19 Feb 2012 07:58:51 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 59763E4B7; Sun, 19 Feb 2012 23:58:49 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 3F8E0E4B1; Sun, 19 Feb 2012 23:58:49 +0800 (CST) Received: from pc917 ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012021923584640-4594 ; Sun, 19 Feb 2012 23:58:46 +0800 Date: Sun, 19 Feb 2012 23:58:44 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012021923584463860669@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-19 23:58:47, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-19 23:58:48 Content-Type: multipart/alternative; boundary="----=_001_NextPart143161021156_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18720.000 X-TM-AS-Result: No--27.205-7.0-31-10 X-imss-scan-details: No--27.205-7.0-31-10;No--27.205-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] PPSP Re-charter discussion X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei 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, 19 Feb 2012 15:58:53 -0000 ------=_001_NextPart143161021156_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgYWxsLA0KICAgQmFzZWQgb24gdGhlIGRpc2N1c3Npb25zIGluIFRhaXBlaSBtZWV0aW5nLCBN YXJ0aW4gYW5kIEkgaGF2ZSBkcmFmdGVkIHRoZSBmb2xsb3dpbmcgcmUtY2hhcnRlciB0ZXh0IHdp dGggdGhlIHRyYWNrIGNoYW5nZSBtb2RlLiBUaGUgYmFzaWMgY2hhbmdlcyBpbmNsdWRlOg0KMSkg SW5jbHVzaW9uIG9mIG1lZGlhIHRyYW5zcG9ydCBtZWNoYW5pc20gaW50byBQUFNQIFdHIHRhc2su DQoyKSBTaWduYWxpbmcgcHJvdG9jb2wgYW5kIG1lZGlhIHByb3RvY29sIGNhbmRpZGF0ZXMgZGVz Y3JpcHRpb24gY2hhbmdlOw0KMykgRG9jdW1lbnQgbWVyZ2VyLCBzdWJtaXNzaW9uIGRlYWRsaW5l IGFzIHdlbGwgYXMgbmV3IFdHIGRyYWZ0IHVwZGF0ZSBpbiBHb2FscyBhbmQgbWlsZXN0b25lcy4N CiAgICBQbGVhc2UgcmV2aWV3IGl0IGFuZCBwb3N0IHlvdXIgY29tbWVudHMgaW4gdGhlIG1haWxp bmcgbGlzdC4gV2Ugd2lzaCB0byBnZXQgY29uc2Vuc3VzIGluIHRoZSBtYWlsaW5nIGxpc3QgYmVm b3JlIHN1Ym1pdHRpbmcgdG8gdGFsayB3aXRoIHRoZSBBRC4NClAuUy46IFdlIGFyZSBleHBsb3Jp bmcgdGhlIHBvc3NpYmlsaXR5IG9mIGhhdmluZyBhbiBpbnRlcmltIG1lZXRpbmcgaW4gdGhlIGVh cmx5IG9mIE1hcmNoLCBiZWZvcmUgbmV4dCBJRVRGLiBXZSdsbCBzdGFydCB0aGUgcG9sbCBvZiB0 aGUgdGltZSBzb29uIGlmIHdlIGdldCBwb3NpdGl2ZSBmZWVkYmFjayBvbiB0aGUgcHJvZ3Jlc3Mg ZnJvbSB0aGUgcHJvcG9zZWQgcGVlciBhbmQgdHJhY2tlciBwcm90b2NvbCBhdXRob3JzLg0KDQpC Ug0KWXVuZmVpDQogICANCiAgICANCg0KRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cA0KVGhl IFBlZXItdG8tUGVlciBTdHJlYW1pbmcgUHJvdG9jb2wgKFBQU1ApIHdvcmtpbmcgZ3JvdXAgZGV2 ZWxvcHMgdHdvDQpzaWduYWxpbmcgYW5kIGNvbnRyb2wgcHJvdG9jb2xzIGZvciBhIHBlZXItdG8t cGVlciAoUDJQKSBzdHJlYW1pbmcNCnN5c3RlbSBmb3IgdHJhbnNtaXR0aW5nIGxpdmUgYW5kIHRp bWUtc2hpZnRlZCBtZWRpYSBjb250ZW50IHdpdGggbmVhcg0KcmVhbC10aW1lIGRlbGl2ZXJ5IHJl cXVpcmVtZW50cy4NClR3byBraW5kcyBvZiBub2RlcyBleGlzdCBpbiB0aGUgdGFyZ2V0ZWQgUDJQ IHN0cmVhbWluZyBzeXN0ZW0sIGkuZS4sDQoicGVlcnMiIGFuZCAidHJhY2tlcnMiLiBQZWVycyBh cmUgbm9kZXMgdGhhdCBhcmUgYWN0aXZlbHkgc2VuZGluZyBhbmQNCnJlY2VpdmluZyBzdHJlYW1l ZCBtZWRpYSBjb250ZW50LCBhbmQgaW5jbHVkZSBib3RoIHN0YXRpY2FsbHkgY29ubmVjdGVkDQpo b3N0cyBhcyB3ZWxsIGFzIG1vYmlsZSBkZXZpY2VzIHdpdGggY29ubmVjdGl2aXR5IGFuZCBJUCBh ZGRyZXNzZXMgdGhhdA0KY2hhbmdlIG92ZXIgdGltZSwgYXMgd2VsbCBhcyBjaGFuZ2VkIGxpbmsg Y2hhcmFjdGVyaXN0aWNzIGZvciBtb2JpbGUgbm9kZXMuDQpUaGUgc2V0IG9mIHBlZXJzIHRoYXQg YXJlIHBhcnRpY2lwYXRpbmcgaW4gYSBzdHJlYW1pbmcNCnNlc3Npb24gd2lsbCBkeW5hbWljYWxs eSBjaGFuZ2Ugb3ZlciB0aW1lLiBUcmFja2VycyBhcmUgd2VsbC1rbm93biBub2Rlcw0Kd2l0aCBz dGFibGUgY29ubmVjdGl2aXR5IHRoYXQgbWFpbnRhaW4gbWV0YSBpbmZvcm1hdGlvbiBhYm91dCB0 aGUNCnN0cmVhbWVkIGNvbnRlbnQgYW5kIHRoZSBkeW5hbWljIHBlZXIgc2V0IGludm9sdmVkIGlu IHRoZSBzdHJlYW1pbmcuIFRyYWNrZXJzIGNhbiBiZSBvcmdhbml6ZWQgaW4NCmNlbnRyYWxpemVk IG9yIGRpc3RyaWJ1dGVkIHdheXMuDQpUaGUgUFBTUCBXRyBkZXNpZ25zIGEgcHJvdG9jb2wgZm9y IHNpZ25hbGluZyBhbmQgY29udHJvbCBiZXR3ZWVuDQp0cmFja2VycyBhbmQgcGVlcnMgKHRoZSBQ UFNQICJ0cmFja2VyIHByb3RvY29sIikgYW5kIGEgc2lnbmFsaW5nIGFuZA0KY29udHJvbCBwcm90 b2NvbCBmb3IgY29tbXVuaWNhdGlvbiBhbW9uZyB0aGUgcGVlcnMgKHRoZSBQUFNQICJwZWVyDQpw cm90b2NvbCIpLiBUaGUgdHdvIHByb3RvY29scyBlbmFibGUgcGVlcnMgdG8gcmVjZWl2ZSBzdHJl YW1pbmcgZGF0YQ0Kd2l0aGluIHRoZSB0aW1lIGNvbnN0cmFpbnRzIHJlcXVpcmVkIGJ5IHNwZWNp ZmljIGNvbnRlbnQgaXRlbXMuIFRoZQ0KdHJhY2tlciBwcm90b2NvbCBoYW5kbGVzIHRoZSBpbml0 aWFsIGFuZCBwZXJpb2RpYyBleGNoYW5nZSBvZiBtZXRhDQppbmZvcm1hdGlvbiBiZXR3ZWVuIHRy YWNrZXJzIGFuZCBwZWVycywgc3VjaCBhcyBwZWVyIGxpc3RzIGFuZCBjb250ZW50DQppbmZvcm1h dGlvbi4gVGhlIHBlZXIgcHJvdG9jb2wgY29udHJvbHMgdGhlIGFkdmVydGlzaW5nIGFuZCBleGNo YW5nZSBvZg0KbWVkaWEgZGF0YSBhdmFpbGFiaWxpdHkgYmV0d2VlbiB0aGUgcGVlcnMsIGFzIHdl bGwgYXMgdGhlIGV4Y2hhbmdlIG9mIHN0cmVhbWluZyBtZWRpYS4NCkl0IGlzIGVudmlzaW9uZWQg dGhhdCB0aGUgdHJhY2tlciBwcm90b2NvbCB3aWxsIGJlIG1vZGVsZWQgYXMgYQ0KcmVxdWVzdC9y ZXNwb25zZSBwcm90b2NvbCBiZXR3ZWVuIHBlZXJzIGFuZCB0cmFja2VycywgYW5kIHdpbGwgY2Fy cnkNCmluZm9ybWF0aW9uIG5lZWRlZCBmb3IgdGhlIHNlbGVjdGlvbiBvZiBwZWVycyBzdWl0YWJs ZSBmb3IgcmVhbC10aW1lDQpzdHJlYW1pbmcuIFRoZSBwZWVyIHByb3RvY29sIGlzIGVudmlzaW9u ZWQgdG8gYmUgbW9kZWxlZCBhcyBhDQpnb3NzaXAtbGlrZSBwcm90b2NvbCB3aXRoIHBlcmlvZGlj LCBwYWlyd2lzZSBleGNoYW5nZXMgb2YgbmVpZ2hib3IgYW5kDQptZWRpYSBjaHVuayBhdmFpbGFi aWxpdHkgaW5mb3JtYXRpb24uIEJvdGggcHJvdG9jb2xzIHdpbGwgYmUgY2FycmllZA0Kb3ZlciBU Q1AgKG9yIFVEUCwgd2hlbiBkZWxpdmVyeSByZXF1aXJlbWVudHMgY2Fubm90IGJlIG1ldCBieSBU Q1ApLA0KbGlrZWx5IGluIGNvbWJpbmF0aW9uIHdpdGggSUNFIGZvciBOQVQgdHJhdmVyc2FsIHN1 cHBvcnQuIFBlcmZlY3QNCnByaXZhY3kgcHJvdGVjdGlvbiBpcyBhIGdvb2QgZmVhdHVyZSB0byBo YXZlIGJ1dCBub3QgYSBtYW5kYXRvcnkNCnJlcXVpcmVtZW50IGZvciB0aGUgcGVlciBhbmQgdHJh Y2tlciBwcm90b2NvbHMuIFRoZSBXRyB3aWxsIGNvbnNpZGVyIHRvDQp1c2UgZXhpc3RpbmcgcHJv dG9jb2xzIGFzIGRlc2lnbiBiYXNlIGZvciB0aGUgdHJhY2tlciBhbmQgcGVlcg0KcHJvdG9jb2xz Lg0KRGV2ZWxvcGluZyBtZWNoYW5pc21zIGZvciBzZWFyY2hpbmcgdHJhY2tlcnMgdGhhdCBjb250 YWluIGEgc3BlY2lmaWMNCm1lZGlhIGl0ZW0gaXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIFdH LiBBZGRpdGlvbmFsbHksIHRoZSBXRyB3aWxsDQp3b3JrIHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRo YXQgdHJhY2tlcnMgYXJlIGxvZ2ljYWxseSBjZW50cmFsaXplZA0KZW50aXRpZXMgKGUuZy4sIGEg c2luZ2xlIHNlcnZlciBvciBhIHNlcnZlciBmYXJtIHBlcmZvcm1pbmcgRE5TLWJhc2VkDQpsb2Nh bCBiYWxhbmNpbmcpLiBIb3dldmVyLCBhcyBmYXIgYXMgaXQgaXMgcG9zc2libGUsIHRoZSBXRyB3 aWxsIG5vdA0KbWFrZSBkZXNpZ24gZGVjaXNpb25zIHRoYXQgY291bGQgcHJlY2x1ZGUgdGhlIHVz ZSBvZiBkaXN0cmlidXRlZA0KdHJhY2tlcnMgaW4gdGhlIGZ1dHVyZSAoZS5nLiwgREhULWJhc2Vk IHRyYWNrZXJzKS4NCkEgcGVlciBsb29raW5nIGZvciBhIHBhcnRpY3VsYXIgbWVkaWEgc3RyZWFt IG1lZGlhIGNodW5rU3VjaCBhIG1lZGlhIHN0cmVhbSBpcyB0cmFuc3BvcnRlZCBpbiBzby1jYWxs ZWQgY2h1bmtzLCB3aGVyZSBhIGNodW5rIGNvbnRhaW5zIHRoZSBwaWVjZXMgb2YgdGhlIG1lZGlh Lg0KT2J0YWluaW5nIHRoZSBtZWRpYSBjaHVuayBmcm9tIHRoZSByZW1vdGUgcGVlciB3aWxsIGlu dm9sdmUgc29tZQ0KdHlwZSBvZiBzaWduYWxpbmcgZXhjaGFuZ2UsIGkuZS4sIHRoZSB0cmFja2Vy IGFuZCBwZWVyIHByb3RvY29scyB0bw0KbG9jYXRlIGEgcmVtb3RlIHBlZXIgKG9yIHBlZXJzKSBw bHVzIHRoZSBhY3R1YWwgbWVkaWEgdHJhbnNmZXIgb2YgdGhlIGNodW5rcy4gVGhlIGZpcnN0LCBt ZWRpYSBzdHJlYW1tZWRpYQ0KY2h1bmsuIA0KdGFzayBmb3IgdGhpcyBXRyB3aWxsIGJlIHRvIGRl Y2lkZSB3aGljaCBzaWduYWxpbmcgYW5kIG1lZGlhIHRyYW5zZmVyDQpwcm90b2NvbHMgd2lsbCBi ZSB1c2VkVGhlIFdHIHdpbGwgd29yayBvbiB0aGUgcGVlciBhbmQgdHJhY2tlciBwcm90b2NvbCBh bmQgLiBUaGUgV0cgd2lsbCBjb25zaWRlciBleGlzdGluZyBwcm90b2NvbHMgYW5kLCBpZg0KbmVl ZGVkLCBpZGVudGlmeSBwb3RlbnRpYWwgZXh0ZW5zaW9ucyB0byB0aGVzZSBwcm90b2NvbHMuIFRo ZSBXRyB3aWxsDQpjb25zaWRlciB0aGUgaW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlc2UgcHJvdG9j b2xzIGFuZCB0aGUgcGVlciBwcm90b2NvbA0KKGUuZy4sIGF2b2lkaW5nIGR1cGxpY2F0ZSBOQVQg dHJhdmVyc2FsIHByb2NlZHVyZXMpLiBBbiBFZXhhbXBsZXMgb2YgYQ0Kc2lnbmFsaW5nIHByb3Rv Y29scyB0byBiZSBjb25zaWRlcmVkIGFyZSBpc1NJUCwgUlRTUCwgYW5kIEhUVFAuIEV4YW1wbGVz DQpvZiBtZWRpYSB0cmFuc2ZlciBwcm90b2NvbHMgbWVjaGFuaXNtc3RvIGJlIGNvbnNpZGVyZWQg YXJlIFVEUCwgYW5kVENQUlRQIGFuZCBIVFRQLg0KYW5kIHBvc3NpYmxlIGV4dGVuc2lvbiBvbiB0 b3Agb2YgdGhlbS4NClBQU1AgaXMgbm90IGNoYXJ0ZXJlZCB0byB3b3JrIG9uIG1lZGlhIHRyYW5z bWlzc2lvbiBwcm90b2NvbHMsIG1lZGlhDQplbmNvZGluZyB0ZWNobmlxdWVzIG9yIG90aGVyIGNv bXBvbmVudHMgb2YgYSBQMlAgc3RyZWFtaW5nIHN5c3RlbSBzdWNoDQphcyBwbGF5b3V0IGNvbnRy b2wgb3IsIHNjaGVkdWxpbmcgYW5kIGNvbnRyb2wsIGV0Yy4NClBQU1Agd2lsbCBleHBsb3JlIHRo ZSByZWxhdGlvbnNoaXAgdG8gREVDQURFIGFuZCBBTFRPIHdvcmtpbmcgZ3JvdXBzLg0KVGhlIHdv cmsgaXRlbXMgb2YgdGhlIFBQU1AgV0cgYXJlOg0KKDEpIEEgInByb2JsZW0gc3RhdGVtZW50IiBh bmQgInJlcXVpcmVtZW50cyIgZG9jdW1lbnQuIFRoaXMgZG9jdW1lbnQgdGhhdCBnaXZlcyBhbiBv dmVydmlldyBvZiB0aGUNCnByb3Bvc2VkIFAyUCBzdHJlYW1pbmcgc3lzdGVtLCBtb3RpdmF0ZXMg dGhlIGRlc2lyZSBmb3INCnN0YW5kYXJkaXplZCBwcm90b2NvbHMsIGRlZmluZXMgdGhlIGVudmlz aW9uZWQgc2NvcGUgb2YgdGhvc2UNCnN0YW5kYXJkaXplZCBjb21wb25lbnRzIGFuZCBkaXNjdXNz ZXMgY29tbW9uIHRlcm1pbm9sb2dpZXMgYW5kDQpjb25jZXB0cy4gSXQgYWxzbyB0aGF0IGRldGFp bHMgdGhlIHNwZWNpZmljIGZ1bmN0aW9uYWwsDQpvcGVyYXRpb25hbCBhbmQgcGVyZm9ybWFuY2Ug cmVxdWlyZW1lbnRzIG9mIHRoZSB0d28gUFBTUA0KcHJvdG9jb2xzLg0KKDIpIEEgInJlcXVpcmVt ZW50cyIgZG9jdW1lbnQgdGhhdCBkZXRhaWxzIHRoZSBzcGVjaWZpYyBmdW5jdGlvbmFsLA0Kb3Bl cmF0aW9uYWwgYW5kIHBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBvZiB0aGUgdHdvIFBQU1ANCnBy b3RvY29scy4NCigzKSBBbiAiYXJjaGl0ZWN0dXJhbCBzdXJ2ZXkiIGRvY3VtZW50IHRoYXQgc3Vt bWFyaXplcyBjdXJyZW50IFAyUA0Kc3RyZWFtaW5nIGFyY2hpdGVjdHVyZXMsIGluIHBhcnRpY3Vs YXIgdHJhY2tlci1iYXNlZCBQMlANCnN0cmVhbWluZyBzeXN0ZW1zLCBhbmQgaGlnaGxpZ2h0cyBi ZXN0IGN1cnJlbnQgcHJhY3RpY2VzLCBhcyBpbnB1dCB0byB0aGUgZGVzaWduIG9mIHRoZSBwZWVy IGFuZCB0cmFja2VyIHByb3RvY29scy4uDQooNCkgQSBkZXRhaWxlZCBzcGVjaWZpY2F0aW9uIG9m IHRoZSBQUFNQIHBlZXIgcHJvdG9jb2wuDQooNSkgQSBkZXRhaWxlZCBzcGVjaWZpY2F0aW9uIG9m IHRoZSBQUFNQIHRyYWNrZXIgcHJvdG9jb2wuDQooNikgQSBkZXRhaWxlZCBzcGVjaWZpY2F0aW9u IG9mIHRoZSBQUFNQIG1lZGlhIHRyYW5zcG9ydCBtZWNoYW5pc20uDQooNykgQSAidXNhZ2UgZ3Vp ZGUiIHRoYXQgZGVzY3JpYmVzIGhvdyB0aGUgdGhld28gUFBTUCBwcm90b2NvbHMgYW5kDQpleGlz dGluZyBJRVRGIHByb3RvY29scywgc3VjaCBhcyBQMlBTSVAsREVDQURFb3IgQUxUTywgY2FuIGJl IGNvbWJpbmVkDQp0byBjcmVhdGUgYSBkZXBsb3lhYmxlIG9wZXJhdGlvbmFsIFAyUCBzdHJlYW1p bmcgc3lzdGVtLiBUaGlzDQpkb2N1bWVudCBtYXkgYWxzbyBkaXNjdXNzIHZhcmlhbnRzIG9mIHN1 Y2ggYSBzeXN0ZW0gdGhhdCwgZm9yDQpleGFtcGxlLCB1c2UgbGF5ZXJlZCBtZWRpYSBlbmNvZGlu ZyBhbmQgcmVsYXRlZCBtZWRpYSBjaHVuaw0KZGVzY3JpcHRpb25zIGluIHRoZSBwZWVyIHByb3Rv Y29sIGZvciBtb3JlIHJvYnVzdCBzdHJlYW1pbmcuDQooOCkgQSBpbXBsZW1lbnRhdGlvbiBhbmQg b3BlcmF0aW9uYWwgZXhwZXJpZW5jZSBndWlkZSBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyB0aGUg cGVyZm9ybWFuY2Ugb2YgdGhlIHByb3Bvc2VkIHByb3RvY29scyBhbmQgdXNhYmxlIHN5c3RlbXMu DQpUaGUgd29yayBpdGVtcyBvZiB0aGUgUFBTUCBXRyBpbnRlcmFjdHMgd2l0aCB0aGUgd29yayBw ZXJmb3JtZWQgaW4gb3RoZXINCklFVEYgV0dzLCBpbmNsdWRpbmcgUDJQU0lQLCBTSVBDT1JFLCBB VlQsIEFMVE8sIExFREJBVCwgYW5kIERFQ0FERSBhbmQgTU1VU0lDLg0KV2hlbmV2ZXIgZXh0ZW5z aW9ucyBvciBtb2RpZmljYXRpb24gdG8gdGhlIHByb3RvY29scyBkZXZlbG9wZWQgaW4gb3RoZXIN CldHcyBhcmUgZGVlbWVkIG5lY2Vzc2FyeSwgUFBTUCBzaGFsbCBjb21tdW5pY2F0ZSBhbmQgZGlz Y3VzcyB0aGUNCnJlcXVpcmVtZW50cyBmb3Igc3VjaCBleHRlbnNpb25zIHdpdGggdGhlIHJlbGV2 YW50IFdHcy4gUFBTUCBpcyBub3QNCmNoYXJ0ZXJlZCB0byBkZXNpZ24gYW5kIHNwZWNpZnkgc3Vj aCBjaGFuZ2VzLg0KR29hbHMgYW5kIE1pbGVzdG9uZXMNCkRlYyAyMDExMFN1Ym1pdCBwcm9ibGVt IHN0YXRlbWVudCB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwgDQpBcHIgMjAxMSAyMDEyU3VibWl0 IHByb2JsZW0gc3RhdGVtZW50IGFuZCByZXF1aXJlbWVudHNhcmNoaXRlY3R1cmFsIHN1cnZleSBk b2N1bWVudHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbCANCkFwciAyMDExIDIwMTJTdWJtaXQgYXJj aGl0ZWN0dXJhbCBzdXJ2ZXkgcmVxdWlyZW1lbnRzIGRvY3VtZW50IHRvIElFU0cgYXMgSW5mb3Jt YXRpb25hbCANCkF1ZyBTZXAyMDEyMSBKYW4gMjAxM1N1Ym1pdCBQUFNQIHRyYWNrZXIgcGVlciBw cm90b2NvbCB0byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJkIA0KQXVnIERlYzIwMTIxIEphbiAy MDEzU3VibWl0IFBQU1AgdHJhY2tlciBwZWVyIHByb3RvY29sIHRvIElFU0cgYXMgUHJvcG9zZWQg U3RhbmRhcmQgDQpEZWMyMDExIFN1Ym1pdCB1c2FnZSBndWlkZSB0byBJRVNHIHRvIElFU0cgYXMg SW5mb3JtYXRpb25hbCANCg0KRGVjIDIwMTJKYW4gMjAxMyAgICBTdWJtaXQgUFBTUCBtZWRpYSB0 cmFuc3BvcnQgbWVjaGFuaXNtIHRvIElFU0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQNCiANCkFwciAy MDEzICAgIFN1Ym1pdCB1c2FnZSBndWlkZSB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwNCiANCkFw ciAyMDEzICAgIFN1Ym1pdCBmaWVsZCB0ZXN0IHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbA0KIA0K DQoNCg0KDQp6aGFuZ3l1bmZlaQ== ------=_001_NextPart143161021156_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi=20 all,

  =20 Based on the discussions in Taipei meeting, Martin and I have drafted the=20 following re-charter text with the track change mode. The basic changes=20 include:

1) Inclusion=20 of media transport mechanism into PPSP WG task.

2)=20 Signaling protocol and media protocol candidates description=20 change;

3)=20 Document merger, submission deadline as well as new WG draft update in Goal= s and=20 milestones.

   =20 Please review it and post your comments in the mailing list. We wish to get= =20 consensus in the mailing list before submitting to talk with the=20 AD.

P.S.:=20 We are exploring the possibility of having an interim meeting in the e= arly=20 of March, before next IETF. We'll start the poll of the time soon if we get= =20 positive feedback on the progress from the proposed peer and tracker protoc= ol=20 authors.

 

BR

Yunfei

  =20

   =20

 

Description=20 of Working Group

The=20 Peer-to-Peer Streaming Protocol (PPSP) working group develops two
signal= ing=20 and control protocols for a peer-to-peer (P2P) streaming
system for=20 transmitting live and time-shifted media content with near
real-time del= ivery=20 requirements.

Two=20 kinds of nodes exist in the targeted P2P streaming system, i.e.,
"peers"= and=20 "trackers". Peers are nodes that are actively sending and
receiving stre= amed=20 media content, and include both statically connected
hosts as well as mo= bile=20 devices with connectivity and=20 IP addresses that
change over time, as well as changed link characteristics=20 for mobile nodes.
The set of peers that are=20 participating in a streaming
session will dynamically change over time. = Trackers are well-known nodes
with stable connectivity that maintain met= a=20 information about the
streamed content and the dynamic peer set involved in the=20 streaming. Trackers can be organized in
centralized = or=20 distributed ways.

The=20 PPSP WG designs a protocol for signaling and control between
trackers an= d=20 peers (the PPSP "tracker protocol") and a signaling and
control protocol= for=20 communication among the peers (the PPSP "peer
protocol"). The two protoc= ols=20 enable peers to receive streaming data
within the time constraints requi= red=20 by specific content items. The
tracker protocol handles the initial and = periodic exchange of meta
information between trackers and peers, such a= s=20 peer lists and content
information. The peer protocol controls the=20 advertising and exchange of
media data availability between the peers, as well as the exchange= of=20 streaming media.

It=20 is envisioned that the tracker protocol will be modeled as a
request/res= ponse=20 protocol between peers and trackers, and will carry
information needed f= or=20 the selection of peers suitable for real-time
streaming. The peer protoc= ol is=20 envisioned to be modeled as a
gossip-like protocol with periodic, pairwi= se=20 exchanges of neighbor and
media chunk availability information. Both=20 protocols will be carried
over TCP (or UDP, when delivery requirements c= annot=20 be met by TCP),
likely in combination with ICE for NAT traversal support= .=20 Perfect
privacy protection is a good feature to have but not a=20 mandatory
requirement for the peer and tracker protocols. The WG will=20 consider to
use existing protocols as design base for the tracker and=20 peer
protocols.

Developing=20 mechanisms for searching trackers that contain a specific
media item is = out=20 of the scope of this WG. Additionally, the WG will
work under the assump= tion=20 that trackers are logically centralized
entities (e.g., a single server = or a=20 server farm performing DNS-based
local balancing). However, as far as it= is=20 possible, the WG will not
make design decisions that could preclude the = use=20 of distributed
trackers in the future (e.g., DHT-based=20 trackers).

A=20 peer looking for a particular media stream media chunk= Such a media stream is transported in so-called= =20 chunks, where a chunk contains the pieces of the=20 media.

Obtaining the media chunk=20 from the remote peer will involve some
type of signaling exchange, i.e.,=20 the tracker and peer protocols to
locate a remote peer (or peers)=20 plus the actual media transfer=20 of the chunks. The first, media=20 streammedia
chunk. task for=20 this WG will be to decide which signaling and media transfer
protocols w= ill=20 be usedThe WG will work on the peer and tracker protocol and=20 . The WG will=20 consider existing protocols and, if
needed, identify potential extension= s to=20 these protocols. The WG will
consider t= he=20 interactions between these protocols and the peer protocol
(e.g., avoidi= ng=20 duplicate NAT traversal procedures). An Eexamples of=20 a
signaling protocols to be considered are <= SPAN=20 class=3DmsoIns>isSIP, RTSP, and HTTP. Examples
of med= ia=20 transfer protocols mechanismsto be considered are UDP,=20 andTCPRTP and=20 HTTP.

and=20 <= FONT=20 color=3D#008080>possible extension on top of them.

PPSP=20 is not chartered to work on media transmission protoc= ols,=20 media
encoding techniques or other components of a P= 2P=20 streaming system such
as playout control=20 or,=20 scheduling and control= ,=20 etc.

PPSP will explore the relationship to DECADE an= d ALTO=20 working groups.

The=20 work items of the PPSP WG are:

(1)=20 A "problem statement" and "requirements"=20 document. This=20 document=20 that gives an overview of the
proposed P2P streaming system,= =20 motivates the desire for
standardized protocols, defines the envisioned = scope=20 of those
standardized components and discusses common terminologies=20 and
concepts. It also tha= t details=20 the specific functional,
operational and performance requirements of the= two=20 PPSP
protocols.

(2) A "requirements" docu= ment that=20 details the specific functional,
operational and performance requirement= s of=20 the two PPSP
protocols.

(3)=20 An "architectural survey" document that summarizes current P2P
streaming= =20 architectures, in particular tracker-based P2P
streaming systems, and=20 highlights best current practices,=20 as input to the design of the peer and tracker=20 protocols..

(4)=20 A detailed specification of the PPSP peer protocol.

(5)=20 A detailed specification of the PPSP tracker protocol.

(6)=20 A detailed specification of the PPSP media=20 transport=20 mechanism.

(7) A "usage guide" that describes how = the=20 thewo PP= SP=20 protocols and
existing IETF protocols, such as P2PSIP,DECADEor ALTO,=20 can be combined
to create a deployable operational P2P streaming system.= =20 This
document may also discuss variants of such a system that,=20 for
example, use layered media encoding and related media=20 chunk
descriptions in the peer protocol for more robust streaming.

(8) A=20 implementation and operational experience guide=20 document that describes the performance of the proposed pro= tocols=20 and usable systems.

The=20 work items of the PPSP WG interacts with the work performed in other
IET= F=20 WGs, including P2PSIP, SIPCORE, AVT,=20 ALTO, LEDBAT= , and DECADE=20 and MMUSIC.
Whenever extensions or modification to t= he=20 protocols developed in other
WGs are deemed necessary, PPSP shall commun= icate=20 and discuss the
requirements for such extensions with the relevant WGs. = PPSP=20 is not
chartered to design and specify such changes.

Goals=20 and Milestones

Dec 20110

Submit problem statement to IESG as=20 Informational

Apr=20 2011 2012

Submit problem statement and requirementsarchitectural survey documentto IESG as Informational =

Apr=20 2011 2012

Submit=20 architectural survey requirements document to IESG as = Informational

Aug Sep20121=20 Jan=20 2013

Submit=20 PPSP tracker=20 peer=20 protocol to IESG as Proposed Standard=20

Aug Dec20121=20 Jan=20 2013

Submit=20 PPSP=20 tracker peer<= /SPAN>=20 protocol to IESG as Proposed Standard

Dec2011=20

Submit usage guide to IESG to IESG as=20 Informational=20

Dec=20 2012Jan=20 2013  &= nbsp;=20 Submit PPSP media transport mechanism to IESG as Proposed=20 Standard

 

Apr 2013    Submit usage guide to= IESG=20 as Informational

 

Apr 2013   = ;=20 Submit field test to IESG as=20 Informational

=  

 
zhangyunfei
------=_001_NextPart143161021156_=------ From zhangyunfei@chinamobile.com Sun Feb 19 18:35:02 2012 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 3D17921F8601 for ; Sun, 19 Feb 2012 18:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.014 X-Spam-Level: X-Spam-Status: No, score=-94.014 tagged_above=-999 required=5 tests=[AWL=-2.107, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_HTML_USL_OBFU=1.666, 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 0R41oqOBDeVo for ; Sun, 19 Feb 2012 18:35:00 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8054521F85F1 for ; Sun, 19 Feb 2012 18:34:59 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 85887E510; Mon, 20 Feb 2012 10:34:57 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 6DE3DE4BD; Mon, 20 Feb 2012 10:34:57 +0800 (CST) Received: from pc917 ([10.2.43.7]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012022010345580-5266 ; Mon, 20 Feb 2012 10:34:55 +0800 Date: Mon, 20 Feb 2012 10:34:54 +0800 From: zhangyunfei To: ppsp References: <2012021923584463860669@chinamobile.com> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012022010345434384023@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-20 10:34:55, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-20 10:34:57 Content-Type: multipart/alternative; boundary="----=_001_NextPart081857738750_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18720.004 X-TM-AS-Result: No--35.737-7.0-31-10 X-imss-scan-details: No--35.737-7.0-31-10;No--35.737-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] Planning of a virtual interim meeting for PPSP for early of March X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei 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, 20 Feb 2012 02:35:02 -0000 ------=_001_NextPart081857738750_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" RGVhciBhbGwsDQoNCiAgICAgIEFzIGRpc2N1c3NlZCB3aXRoIHRoZSBhdXRob3JzIG9mIHRoZSBw ZWVyIGFuZCB0cmFja2VyIHByb3RvY29sLCBNYXJ0aW4gYW5kIEkgZGlzY3Vzc2VkIA0KdGhlIG5l ZWQgb2YgaGF2aW5nIGEgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgZm9yIHRoZSBQUFNQIFdHIGJl Zm9yZSBuZXh0IElFVEYuIA0KDQogICAgICBUaGUgcHVycG9zZSBvZiB0aGlzIHZpcnR1YWwgaW50 ZXJpbSBtZWV0aW5nIGlzIHRvIHByb2dyZXNzIHRoZSB3b3JrcyBvbiB0aGUNCnBlZXIgYW5kIHRy YWNrZXIgcHJvdG9jb2xzLiANCg0KICAgICAgTWFydGluIGFuZCBJIGhhdmUgcGxhbm5lZCB0byBo YXZlIHRoZSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyBpbiB0aGUgZWFybHkgd2VlayBvZiBNYXJj aCAoNHRoIHRvIDl0aCBvZiBNYXJjaCkuDQpUaGlzIHNob3VsZCBnaXZlIHN1ZmZpY2llbnQgdGlt ZSB0byB0byBhbm5vdW5jZSBpdCwgYW5kIG1vcmUgaW1wb3J0YW50bHkgdG8gZ2V0IHVwZGF0ZWQg ZHJhZnRzIChhbmQNCnRlY2huaWNhbCBwcm9ncmVzcykgb2YgdGhlIHBlZXIgcHJvdG9jb2wgcHJv cG9zYWxzIGFuZCBhbHNvIHRoZSB0cmFja2VyDQpwcm90b2NvbCBwcm9wb3NhbHMuIA0KDQogICAg ICAgRm9yIHBpY2tpbmcgYSBnb29kIGRhdGUgd2UgcmVxdWVzdCB0aGF0IGFsbCBpbnRlcmVzdGVk IFdHIG1lbWJlcnMgZmlsbCBpbg0KdGhlaXIgYXZhaWxhYmlsaXR5IGluIHRoZSBkb29kbGUgcG9s bCBoZXJlOg0KaHR0cDovL3d3dy5kb29kbGUuY29tL2JpY25zdGh0ZWhod3pwN2kNCiAgICAgV2Ug d2lsbCBzZXQgdGhlIG1lZXRpbmcgYXQgYSBkYXkgdGltZSBzbyB0aGF0IGFsbCBwYXJ0aWNpcGFu dHMgZnJvbSBhcm91bmQNCnRoZSB3b3JsZCBjYW4gcGFydGljaXBhdGUuIA0KDQoqKlBsZWFzZSBm aWxsIGluIHlvdXIgYXZhaWxhYmlsaXR5IGluIHRoZSBkb29kbGUgcG9sbCB1bnRpbCBGZWIgMjIu ICoqDQogICAgIFRoYW5rcy4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQoNCnpoYW5neXVuZmVpDQoN CreivP7Iy6O6IHpoYW5neXVuZmVpDQq3osvNyrG85KO6IDIwMTItMDItMTkgMjM6NTgNCsrVvP7I y6O6IHBwc3ANCrOty82juiBNYXJ0aW4gU3RpZW1lcmxpbmc7IFdlc2xleSBFZGR5DQrW98zio7og UFBTUCBSZS1jaGFydGVyIGRpc2N1c3Npb24NCkhpIGFsbCwNCiAgIEJhc2VkIG9uIHRoZSBkaXNj dXNzaW9ucyBpbiBUYWlwZWkgbWVldGluZywgTWFydGluIGFuZCBJIGhhdmUgZHJhZnRlZCB0aGUg Zm9sbG93aW5nIHJlLWNoYXJ0ZXIgdGV4dCB3aXRoIHRoZSB0cmFjayBjaGFuZ2UgbW9kZS4gVGhl IGJhc2ljIGNoYW5nZXMgaW5jbHVkZToNCjEpIEluY2x1c2lvbiBvZiBtZWRpYSB0cmFuc3BvcnQg bWVjaGFuaXNtIGludG8gUFBTUCBXRyB0YXNrLg0KMikgU2lnbmFsaW5nIHByb3RvY29sIGFuZCBt ZWRpYSBwcm90b2NvbCBjYW5kaWRhdGVzIGRlc2NyaXB0aW9uIGNoYW5nZTsNCjMpIERvY3VtZW50 IG1lcmdlciwgc3VibWlzc2lvbiBkZWFkbGluZSBhcyB3ZWxsIGFzIG5ldyBXRyBkcmFmdCB1cGRh dGUgaW4gR29hbHMgYW5kIG1pbGVzdG9uZXMuDQogICAgUGxlYXNlIHJldmlldyBpdCBhbmQgcG9z dCB5b3VyIGNvbW1lbnRzIGluIHRoZSBtYWlsaW5nIGxpc3QuIFdlIHdpc2ggdG8gZ2V0IGNvbnNl bnN1cyBpbiB0aGUgbWFpbGluZyBsaXN0IGJlZm9yZSBzdWJtaXR0aW5nIHRvIHRhbGsgd2l0aCB0 aGUgQUQuDQpQLlMuOiBXZSBhcmUgZXhwbG9yaW5nIHRoZSBwb3NzaWJpbGl0eSBvZiBoYXZpbmcg YW4gaW50ZXJpbSBtZWV0aW5nIGluIHRoZSBlYXJseSBvZiBNYXJjaCwgYmVmb3JlIG5leHQgSUVU Ri4gV2UnbGwgc3RhcnQgdGhlIHBvbGwgb2YgdGhlIHRpbWUgc29vbiBpZiB3ZSBnZXQgcG9zaXRp dmUgZmVlZGJhY2sgb24gdGhlIHByb2dyZXNzIGZyb20gdGhlIHByb3Bvc2VkIHBlZXIgYW5kIHRy YWNrZXIgcHJvdG9jb2wgYXV0aG9ycy4NCg0KQlINCll1bmZlaQ0KICAgDQogICAgDQoNCkRlc2Ny aXB0aW9uIG9mIFdvcmtpbmcgR3JvdXANClRoZSBQZWVyLXRvLVBlZXIgU3RyZWFtaW5nIFByb3Rv Y29sIChQUFNQKSB3b3JraW5nIGdyb3VwIGRldmVsb3BzIHR3bw0Kc2lnbmFsaW5nIGFuZCBjb250 cm9sIHByb3RvY29scyBmb3IgYSBwZWVyLXRvLXBlZXIgKFAyUCkgc3RyZWFtaW5nDQpzeXN0ZW0g Zm9yIHRyYW5zbWl0dGluZyBsaXZlIGFuZCB0aW1lLXNoaWZ0ZWQgbWVkaWEgY29udGVudCB3aXRo IG5lYXINCnJlYWwtdGltZSBkZWxpdmVyeSByZXF1aXJlbWVudHMuDQpUd28ga2luZHMgb2Ygbm9k ZXMgZXhpc3QgaW4gdGhlIHRhcmdldGVkIFAyUCBzdHJlYW1pbmcgc3lzdGVtLCBpLmUuLA0KInBl ZXJzIiBhbmQgInRyYWNrZXJzIi4gUGVlcnMgYXJlIG5vZGVzIHRoYXQgYXJlIGFjdGl2ZWx5IHNl bmRpbmcgYW5kDQpyZWNlaXZpbmcgc3RyZWFtZWQgbWVkaWEgY29udGVudCwgYW5kIGluY2x1ZGUg Ym90aCBzdGF0aWNhbGx5IGNvbm5lY3RlZA0KaG9zdHMgYXMgd2VsbCBhcyBtb2JpbGUgZGV2aWNl cyB3aXRoIGNvbm5lY3Rpdml0eSBhbmQgSVAgYWRkcmVzc2VzIHRoYXQNCmNoYW5nZSBvdmVyIHRp bWUsIGFzIHdlbGwgYXMgY2hhbmdlZCBsaW5rIGNoYXJhY3RlcmlzdGljcyBmb3IgbW9iaWxlIG5v ZGVzLg0KVGhlIHNldCBvZiBwZWVycyB0aGF0IGFyZSBwYXJ0aWNpcGF0aW5nIGluIGEgc3RyZWFt aW5nDQpzZXNzaW9uIHdpbGwgZHluYW1pY2FsbHkgY2hhbmdlIG92ZXIgdGltZS4gVHJhY2tlcnMg YXJlIHdlbGwta25vd24gbm9kZXMNCndpdGggc3RhYmxlIGNvbm5lY3Rpdml0eSB0aGF0IG1haW50 YWluIG1ldGEgaW5mb3JtYXRpb24gYWJvdXQgdGhlDQpzdHJlYW1lZCBjb250ZW50IGFuZCB0aGUg ZHluYW1pYyBwZWVyIHNldCBpbnZvbHZlZCBpbiB0aGUgc3RyZWFtaW5nLiBUcmFja2VycyBjYW4g YmUgb3JnYW5pemVkIGluDQpjZW50cmFsaXplZCBvciBkaXN0cmlidXRlZCB3YXlzLg0KVGhlIFBQ U1AgV0cgZGVzaWducyBhIHByb3RvY29sIGZvciBzaWduYWxpbmcgYW5kIGNvbnRyb2wgYmV0d2Vl bg0KdHJhY2tlcnMgYW5kIHBlZXJzICh0aGUgUFBTUCAidHJhY2tlciBwcm90b2NvbCIpIGFuZCBh IHNpZ25hbGluZyBhbmQNCmNvbnRyb2wgcHJvdG9jb2wgZm9yIGNvbW11bmljYXRpb24gYW1vbmcg dGhlIHBlZXJzICh0aGUgUFBTUCAicGVlcg0KcHJvdG9jb2wiKS4gVGhlIHR3byBwcm90b2NvbHMg ZW5hYmxlIHBlZXJzIHRvIHJlY2VpdmUgc3RyZWFtaW5nIGRhdGENCndpdGhpbiB0aGUgdGltZSBj b25zdHJhaW50cyByZXF1aXJlZCBieSBzcGVjaWZpYyBjb250ZW50IGl0ZW1zLiBUaGUNCnRyYWNr ZXIgcHJvdG9jb2wgaGFuZGxlcyB0aGUgaW5pdGlhbCBhbmQgcGVyaW9kaWMgZXhjaGFuZ2Ugb2Yg bWV0YQ0KaW5mb3JtYXRpb24gYmV0d2VlbiB0cmFja2VycyBhbmQgcGVlcnMsIHN1Y2ggYXMgcGVl ciBsaXN0cyBhbmQgY29udGVudA0KaW5mb3JtYXRpb24uIFRoZSBwZWVyIHByb3RvY29sIGNvbnRy b2xzIHRoZSBhZHZlcnRpc2luZyBhbmQgZXhjaGFuZ2Ugb2YNCm1lZGlhIGRhdGEgYXZhaWxhYmls aXR5IGJldHdlZW4gdGhlIHBlZXJzLCBhcyB3ZWxsIGFzIHRoZSBleGNoYW5nZSBvZiBzdHJlYW1p bmcgbWVkaWEuDQpJdCBpcyBlbnZpc2lvbmVkIHRoYXQgdGhlIHRyYWNrZXIgcHJvdG9jb2wgd2ls bCBiZSBtb2RlbGVkIGFzIGENCnJlcXVlc3QvcmVzcG9uc2UgcHJvdG9jb2wgYmV0d2VlbiBwZWVy cyBhbmQgdHJhY2tlcnMsIGFuZCB3aWxsIGNhcnJ5DQppbmZvcm1hdGlvbiBuZWVkZWQgZm9yIHRo ZSBzZWxlY3Rpb24gb2YgcGVlcnMgc3VpdGFibGUgZm9yIHJlYWwtdGltZQ0Kc3RyZWFtaW5nLiBU aGUgcGVlciBwcm90b2NvbCBpcyBlbnZpc2lvbmVkIHRvIGJlIG1vZGVsZWQgYXMgYQ0KZ29zc2lw LWxpa2UgcHJvdG9jb2wgd2l0aCBwZXJpb2RpYywgcGFpcndpc2UgZXhjaGFuZ2VzIG9mIG5laWdo Ym9yIGFuZA0KbWVkaWEgY2h1bmsgYXZhaWxhYmlsaXR5IGluZm9ybWF0aW9uLiBCb3RoIHByb3Rv Y29scyB3aWxsIGJlIGNhcnJpZWQNCm92ZXIgVENQIChvciBVRFAsIHdoZW4gZGVsaXZlcnkgcmVx dWlyZW1lbnRzIGNhbm5vdCBiZSBtZXQgYnkgVENQKSwNCmxpa2VseSBpbiBjb21iaW5hdGlvbiB3 aXRoIElDRSBmb3IgTkFUIHRyYXZlcnNhbCBzdXBwb3J0LiBQZXJmZWN0DQpwcml2YWN5IHByb3Rl Y3Rpb24gaXMgYSBnb29kIGZlYXR1cmUgdG8gaGF2ZSBidXQgbm90IGEgbWFuZGF0b3J5DQpyZXF1 aXJlbWVudCBmb3IgdGhlIHBlZXIgYW5kIHRyYWNrZXIgcHJvdG9jb2xzLiBUaGUgV0cgd2lsbCBj b25zaWRlciB0bw0KdXNlIGV4aXN0aW5nIHByb3RvY29scyBhcyBkZXNpZ24gYmFzZSBmb3IgdGhl IHRyYWNrZXIgYW5kIHBlZXINCnByb3RvY29scy4NCkRldmVsb3BpbmcgbWVjaGFuaXNtcyBmb3Ig c2VhcmNoaW5nIHRyYWNrZXJzIHRoYXQgY29udGFpbiBhIHNwZWNpZmljDQptZWRpYSBpdGVtIGlz IG91dCBvZiB0aGUgc2NvcGUgb2YgdGhpcyBXRy4gQWRkaXRpb25hbGx5LCB0aGUgV0cgd2lsbA0K d29yayB1bmRlciB0aGUgYXNzdW1wdGlvbiB0aGF0IHRyYWNrZXJzIGFyZSBsb2dpY2FsbHkgY2Vu dHJhbGl6ZWQNCmVudGl0aWVzIChlLmcuLCBhIHNpbmdsZSBzZXJ2ZXIgb3IgYSBzZXJ2ZXIgZmFy bSBwZXJmb3JtaW5nIEROUy1iYXNlZA0KbG9jYWwgYmFsYW5jaW5nKS4gSG93ZXZlciwgYXMgZmFy IGFzIGl0IGlzIHBvc3NpYmxlLCB0aGUgV0cgd2lsbCBub3QNCm1ha2UgZGVzaWduIGRlY2lzaW9u cyB0aGF0IGNvdWxkIHByZWNsdWRlIHRoZSB1c2Ugb2YgZGlzdHJpYnV0ZWQNCnRyYWNrZXJzIGlu IHRoZSBmdXR1cmUgKGUuZy4sIERIVC1iYXNlZCB0cmFja2VycykuDQpBIHBlZXIgbG9va2luZyBm b3IgYSBwYXJ0aWN1bGFyIG1lZGlhIHN0cmVhbSBtZWRpYSBjaHVua1N1Y2ggYSBtZWRpYSBzdHJl YW0gaXMgdHJhbnNwb3J0ZWQgaW4gc28tY2FsbGVkIGNodW5rcywgd2hlcmUgYSBjaHVuayBjb250 YWlucyB0aGUgcGllY2VzIG9mIHRoZSBtZWRpYS4NCk9idGFpbmluZyB0aGUgbWVkaWEgY2h1bmsg ZnJvbSB0aGUgcmVtb3RlIHBlZXIgd2lsbCBpbnZvbHZlIHNvbWUNCnR5cGUgb2Ygc2lnbmFsaW5n IGV4Y2hhbmdlLCBpLmUuLCB0aGUgdHJhY2tlciBhbmQgcGVlciBwcm90b2NvbHMgdG8NCmxvY2F0 ZSBhIHJlbW90ZSBwZWVyIChvciBwZWVycykgcGx1cyB0aGUgYWN0dWFsIG1lZGlhIHRyYW5zZmVy IG9mIHRoZSBjaHVua3MuIFRoZSBmaXJzdCwgbWVkaWEgc3RyZWFtbWVkaWENCmNodW5rLiANCnRh c2sgZm9yIHRoaXMgV0cgd2lsbCBiZSB0byBkZWNpZGUgd2hpY2ggc2lnbmFsaW5nIGFuZCBtZWRp YSB0cmFuc2Zlcg0KcHJvdG9jb2xzIHdpbGwgYmUgdXNlZFRoZSBXRyB3aWxsIHdvcmsgb24gdGhl IHBlZXIgYW5kIHRyYWNrZXIgcHJvdG9jb2wgYW5kIC4gVGhlIFdHIHdpbGwgY29uc2lkZXIgZXhp c3RpbmcgcHJvdG9jb2xzIGFuZCwgaWYNCm5lZWRlZCwgaWRlbnRpZnkgcG90ZW50aWFsIGV4dGVu c2lvbnMgdG8gdGhlc2UgcHJvdG9jb2xzLiBUaGUgV0cgd2lsbA0KY29uc2lkZXIgdGhlIGludGVy YWN0aW9ucyBiZXR3ZWVuIHRoZXNlIHByb3RvY29scyBhbmQgdGhlIHBlZXIgcHJvdG9jb2wNCihl LmcuLCBhdm9pZGluZyBkdXBsaWNhdGUgTkFUIHRyYXZlcnNhbCBwcm9jZWR1cmVzKS4gQW4gRWV4 YW1wbGVzIG9mIGENCnNpZ25hbGluZyBwcm90b2NvbHMgdG8gYmUgY29uc2lkZXJlZCBhcmUgaXNT SVAsIFJUU1AsIGFuZCBIVFRQLiBFeGFtcGxlcw0Kb2YgbWVkaWEgdHJhbnNmZXIgcHJvdG9jb2xz IG1lY2hhbmlzbXN0byBiZSBjb25zaWRlcmVkIGFyZSBVRFAsIGFuZFRDUFJUUCBhbmQgSFRUUC4N CmFuZCBwb3NzaWJsZSBleHRlbnNpb24gb24gdG9wIG9mIHRoZW0uDQpQUFNQIGlzIG5vdCBjaGFy dGVyZWQgdG8gd29yayBvbiBtZWRpYSB0cmFuc21pc3Npb24gcHJvdG9jb2xzLCBtZWRpYQ0KZW5j b2RpbmcgdGVjaG5pcXVlcyBvciBvdGhlciBjb21wb25lbnRzIG9mIGEgUDJQIHN0cmVhbWluZyBz eXN0ZW0gc3VjaA0KYXMgcGxheW91dCBjb250cm9sIG9yLCBzY2hlZHVsaW5nIGFuZCBjb250cm9s LCBldGMuDQpQUFNQIHdpbGwgZXhwbG9yZSB0aGUgcmVsYXRpb25zaGlwIHRvIERFQ0FERSBhbmQg QUxUTyB3b3JraW5nIGdyb3Vwcy4NClRoZSB3b3JrIGl0ZW1zIG9mIHRoZSBQUFNQIFdHIGFyZToN CigxKSBBICJwcm9ibGVtIHN0YXRlbWVudCIgYW5kICJyZXF1aXJlbWVudHMiIGRvY3VtZW50LiBU aGlzIGRvY3VtZW50IHRoYXQgZ2l2ZXMgYW4gb3ZlcnZpZXcgb2YgdGhlDQpwcm9wb3NlZCBQMlAg c3RyZWFtaW5nIHN5c3RlbSwgbW90aXZhdGVzIHRoZSBkZXNpcmUgZm9yDQpzdGFuZGFyZGl6ZWQg cHJvdG9jb2xzLCBkZWZpbmVzIHRoZSBlbnZpc2lvbmVkIHNjb3BlIG9mIHRob3NlDQpzdGFuZGFy ZGl6ZWQgY29tcG9uZW50cyBhbmQgZGlzY3Vzc2VzIGNvbW1vbiB0ZXJtaW5vbG9naWVzIGFuZA0K Y29uY2VwdHMuIEl0IGFsc28gdGhhdCBkZXRhaWxzIHRoZSBzcGVjaWZpYyBmdW5jdGlvbmFsLA0K b3BlcmF0aW9uYWwgYW5kIHBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBvZiB0aGUgdHdvIFBQU1AN CnByb3RvY29scy4NCigyKSBBICJyZXF1aXJlbWVudHMiIGRvY3VtZW50IHRoYXQgZGV0YWlscyB0 aGUgc3BlY2lmaWMgZnVuY3Rpb25hbCwNCm9wZXJhdGlvbmFsIGFuZCBwZXJmb3JtYW5jZSByZXF1 aXJlbWVudHMgb2YgdGhlIHR3byBQUFNQDQpwcm90b2NvbHMuDQooMykgQW4gImFyY2hpdGVjdHVy YWwgc3VydmV5IiBkb2N1bWVudCB0aGF0IHN1bW1hcml6ZXMgY3VycmVudCBQMlANCnN0cmVhbWlu ZyBhcmNoaXRlY3R1cmVzLCBpbiBwYXJ0aWN1bGFyIHRyYWNrZXItYmFzZWQgUDJQDQpzdHJlYW1p bmcgc3lzdGVtcywgYW5kIGhpZ2hsaWdodHMgYmVzdCBjdXJyZW50IHByYWN0aWNlcywgYXMgaW5w dXQgdG8gdGhlIGRlc2lnbiBvZiB0aGUgcGVlciBhbmQgdHJhY2tlciBwcm90b2NvbHMuLg0KKDQp IEEgZGV0YWlsZWQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgUFBTUCBwZWVyIHByb3RvY29sLg0KKDUp IEEgZGV0YWlsZWQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgUFBTUCB0cmFja2VyIHByb3RvY29sLg0K KDYpIEEgZGV0YWlsZWQgc3BlY2lmaWNhdGlvbiBvZiB0aGUgUFBTUCBtZWRpYSB0cmFuc3BvcnQg bWVjaGFuaXNtLg0KKDcpIEEgInVzYWdlIGd1aWRlIiB0aGF0IGRlc2NyaWJlcyBob3cgdGhlIHRo ZXdvIFBQU1AgcHJvdG9jb2xzIGFuZA0KZXhpc3RpbmcgSUVURiBwcm90b2NvbHMsIHN1Y2ggYXMg UDJQU0lQLERFQ0FERW9yIEFMVE8sIGNhbiBiZSBjb21iaW5lZA0KdG8gY3JlYXRlIGEgZGVwbG95 YWJsZSBvcGVyYXRpb25hbCBQMlAgc3RyZWFtaW5nIHN5c3RlbS4gVGhpcw0KZG9jdW1lbnQgbWF5 IGFsc28gZGlzY3VzcyB2YXJpYW50cyBvZiBzdWNoIGEgc3lzdGVtIHRoYXQsIGZvcg0KZXhhbXBs ZSwgdXNlIGxheWVyZWQgbWVkaWEgZW5jb2RpbmcgYW5kIHJlbGF0ZWQgbWVkaWEgY2h1bmsNCmRl c2NyaXB0aW9ucyBpbiB0aGUgcGVlciBwcm90b2NvbCBmb3IgbW9yZSByb2J1c3Qgc3RyZWFtaW5n Lg0KKDgpIEEgaW1wbGVtZW50YXRpb24gYW5kIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgZ3VpZGUg ZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBwcm9wb3NlZCBw cm90b2NvbHMgYW5kIHVzYWJsZSBzeXN0ZW1zLg0KVGhlIHdvcmsgaXRlbXMgb2YgdGhlIFBQU1Ag V0cgaW50ZXJhY3RzIHdpdGggdGhlIHdvcmsgcGVyZm9ybWVkIGluIG90aGVyDQpJRVRGIFdHcywg aW5jbHVkaW5nIFAyUFNJUCwgU0lQQ09SRSwgQVZULCBBTFRPLCBMRURCQVQsIGFuZCBERUNBREUg YW5kIE1NVVNJQy4NCldoZW5ldmVyIGV4dGVuc2lvbnMgb3IgbW9kaWZpY2F0aW9uIHRvIHRoZSBw cm90b2NvbHMgZGV2ZWxvcGVkIGluIG90aGVyDQpXR3MgYXJlIGRlZW1lZCBuZWNlc3NhcnksIFBQ U1Agc2hhbGwgY29tbXVuaWNhdGUgYW5kIGRpc2N1c3MgdGhlDQpyZXF1aXJlbWVudHMgZm9yIHN1 Y2ggZXh0ZW5zaW9ucyB3aXRoIHRoZSByZWxldmFudCBXR3MuIFBQU1AgaXMgbm90DQpjaGFydGVy ZWQgdG8gZGVzaWduIGFuZCBzcGVjaWZ5IHN1Y2ggY2hhbmdlcy4NCkdvYWxzIGFuZCBNaWxlc3Rv bmVzDQpEZWMgMjAxMTBTdWJtaXQgcHJvYmxlbSBzdGF0ZW1lbnQgdG8gSUVTRyBhcyBJbmZvcm1h dGlvbmFsIA0KQXByIDIwMTEgMjAxMlN1Ym1pdCBwcm9ibGVtIHN0YXRlbWVudCBhbmQgcmVxdWly ZW1lbnRzYXJjaGl0ZWN0dXJhbCBzdXJ2ZXkgZG9jdW1lbnR0byBJRVNHIGFzIEluZm9ybWF0aW9u YWwgDQpBcHIgMjAxMSAyMDEyU3VibWl0IGFyY2hpdGVjdHVyYWwgc3VydmV5IHJlcXVpcmVtZW50 cyBkb2N1bWVudCB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwgDQpBdWcgU2VwMjAxMjEgSmFuIDIw MTNTdWJtaXQgUFBTUCB0cmFja2VyIHBlZXIgcHJvdG9jb2wgdG8gSUVTRyBhcyBQcm9wb3NlZCBT dGFuZGFyZCANCkF1ZyBEZWMyMDEyMSBKYW4gMjAxM1N1Ym1pdCBQUFNQIHRyYWNrZXIgcGVlciBw cm90b2NvbCB0byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJkIA0KRGVjMjAxMSBTdWJtaXQgdXNh Z2UgZ3VpZGUgdG8gSUVTRyB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwgDQoNCkRlYyAyMDEySmFu IDIwMTMgICAgU3VibWl0IFBQU1AgbWVkaWEgdHJhbnNwb3J0IG1lY2hhbmlzbSB0byBJRVNHIGFz IFByb3Bvc2VkIFN0YW5kYXJkDQogDQpBcHIgMjAxMyAgICBTdWJtaXQgdXNhZ2UgZ3VpZGUgdG8g SUVTRyBhcyBJbmZvcm1hdGlvbmFsDQogDQpBcHIgMjAxMyAgICBTdWJtaXQgZmllbGQgdGVzdCB0 byBJRVNHIGFzIEluZm9ybWF0aW9uYWwNCiANCg0KDQoNCg0Kemhhbmd5dW5mZWk= ------=_001_NextPart081857738750_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear all,

      As discussed with the = authors of the peer and tracker protocol, Martin and I discussed
the need of having a virtual interim meeting for the PPSP WG before ne= xt=20 IETF.

      The purpose of this virtual in= terim=20 meeting is to progress the works on the
peer and tracker=20 protocols. 

      Martin and I have pl= anned=20 to have the virtual interim meeting in the early week of March (4th to= 9th=20 of March).
This should give sufficient time to to announce it, and more = importantly to get updated drafts (and
technical progress) of the peer=20 protocol proposals and also the tracker
protocol proposals.=20

       For picking a good date we req= uest=20 that all interested WG members fill in
their availability in the doodle = poll=20 here:
http://www.doodle.com/bicns= thtehhwzp7i
    =20 We will set the meeting at a day time so that all participants from=20 around
the world can participate.

**Please fill in your availabi= lity=20 in the doodle poll until Feb 22. **
     Thanks.
 
BR
Yunfei

zhangyunfei
 
=B7=A2=BC=FE=C8=CB=A3=BA zhangyunfei
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-02-19 23:58
=CA=D5=BC=FE=C8=CB=A3=BA = ppsp
=B3=AD=CB=CD=A3=BA Martin=20 Stiemerling; Wesley Eddy
=D6=F7=CC=E2=A3=BA PPSP Re-charter discussion
<= /DIV>

Hi=20 all,

  =20 Based on the discussions in Taipei meeting, Martin and I have drafted the=20 following re-charter text with the track change mode. The basic changes=20 include:

1) Inclusion=20 of media transport mechanism into PPSP WG task.

2)=20 Signaling protocol and media protocol candidates description=20 change;

3)=20 Document merger, submission deadline as well as new WG draft update in Goal= s and=20 milestones.

   =20 Please review it and post your comments in the mailing list. We wish to get= =20 consensus in the mailing list before submitting to talk with the=20 AD.

P.S.:=20 We are exploring the possibility of having an interim meeting in the e= arly=20 of March, before next IETF. We'll start the poll of the time soon if we get= =20 positive feedback on the progress from the proposed peer and tracker protoc= ol=20 authors.

 

BR

Yunfei

  =20

   =20

 

Description=20 of Working Group

The=20 Peer-to-Peer Streaming Protocol (PPSP) working group develops two
signal= ing=20 and control protocols for a peer-to-peer (P2P) streaming
system for=20 transmitting live and time-shifted media content with near
real-time del= ivery=20 requirements.

Two=20 kinds of nodes exist in the targeted P2P streaming system, i.e.,
"peers"= and=20 "trackers". Peers are nodes that are actively sending and
receiving stre= amed=20 media content, and include both statically connected
hosts as well as mo= bile=20 devices with connectivity and=20 IP addresses that
change over time, as well as changed link characteristics=20 for mobile nodes.
The set of peers that are=20 participating in a streaming
session will dynamically change over time. = Trackers are well-known nodes
with stable connectivity that maintain met= a=20 information about the
streamed content and the dynamic peer set involved in the=20 streaming. Trackers can be organized in
centralized = or=20 distributed ways.

The=20 PPSP WG designs a protocol for signaling and control between
trackers an= d=20 peers (the PPSP "tracker protocol") and a signaling and
control protocol= for=20 communication among the peers (the PPSP "peer
protocol"). The two protoc= ols=20 enable peers to receive streaming data
within the time constraints requi= red=20 by specific content items. The
tracker protocol handles the initial and = periodic exchange of meta
information between trackers and peers, such a= s=20 peer lists and content
information. The peer protocol controls the=20 advertising and exchange of
media data availability between the peers, as well as the exchange= of=20 streaming media.

It=20 is envisioned that the tracker protocol will be modeled as a
request/res= ponse=20 protocol between peers and trackers, and will carry
information needed f= or=20 the selection of peers suitable for real-time
streaming. The peer protoc= ol is=20 envisioned to be modeled as a
gossip-like protocol with periodic, pairwi= se=20 exchanges of neighbor and
media chunk availability information. Both=20 protocols will be carried
over TCP (or UDP, when delivery requirements c= annot=20 be met by TCP),
likely in combination with ICE for NAT traversal support= .=20 Perfect
privacy protection is a good feature to have but not a=20 mandatory
requirement for the peer and tracker protocols. The WG will=20 consider to
use existing protocols as design base for the tracker and=20 peer
protocols.

Developing=20 mechanisms for searching trackers that contain a specific
media item is = out=20 of the scope of this WG. Additionally, the WG will
work under the assump= tion=20 that trackers are logically centralized
entities (e.g., a single server = or a=20 server farm performing DNS-based
local balancing). However, as far as it= is=20 possible, the WG will not
make design decisions that could preclude the = use=20 of distributed
trackers in the future (e.g., DHT-based=20 trackers).

A=20 peer looking for a particular media stream media chunk= Such a media stream is transported in so-called= =20 chunks, where a chunk contains the pieces of the=20 media.

Obtaining the media chunk=20 from the remote peer will involve some
type of signaling exchange, i.e.,=20 the tracker and peer protocols to
locate a remote peer (or peers)=20 plus the actual media transfer=20 of the chunks. The first, media=20 streammedia
chunk. task for=20 this WG will be to decide which signaling and media transfer
protocols w= ill=20 be usedThe WG will work on the peer and tracker protocol and=20 . The WG will=20 consider existing protocols and, if
needed, identify potential extension= s to=20 these protocols. The WG will
consider t= he=20 interactions between these protocols and the peer protocol
(e.g., avoidi= ng=20 duplicate NAT traversal procedures). An Eexamples of=20 a
signaling protocols to be considered are <= SPAN=20 class=3DmsoIns>isSIP, RTSP, and HTTP. Examples
of med= ia=20 transfer protocols mechanismsto be considered are UDP,=20 andTCPRTP and=20 HTTP.

and=20 <= FONT=20 color=3D#008080>possible extension on top of them.

PPSP=20 is not chartered to work on media transmission protoc= ols,=20 media
encoding techniques or other components of a P= 2P=20 streaming system such
as playout control=20 or,=20 scheduling and control= ,=20 etc.

PPSP will explore the relationship to DECADE an= d ALTO=20 working groups.

The=20 work items of the PPSP WG are:

(1)=20 A "problem statement" and "requirements"=20 document. This=20 document=20 that gives an overview of the
proposed P2P streaming system,= =20 motivates the desire for
standardized protocols, defines the envisioned = scope=20 of those
standardized components and discusses common terminologies=20 and
concepts. It also tha= t details=20 the specific functional,
operational and performance requirements of the= two=20 PPSP
protocols.

(2) A "requirements" docu= ment that=20 details the specific functional,
operational and performance requirement= s of=20 the two PPSP
protocols.

(3)=20 An "architectural survey" document that summarizes current P2P
streaming= =20 architectures, in particular tracker-based P2P
streaming systems, and=20 highlights best current practices,=20 as input to the design of the peer and tracker=20 protocols..

(4)=20 A detailed specification of the PPSP peer protocol.

(5)=20 A detailed specification of the PPSP tracker protocol.

(6)=20 A detailed specification of the PPSP media=20 transport=20 mechanism.

(7) A "usage guide" that describes how = the=20 thewo PP= SP=20 protocols and
existing IETF protocols, such as P2PSIP,DECADEor ALTO,=20 can be combined
to create a deployable operational P2P streaming system.= =20 This
document may also discuss variants of such a system that,=20 for
example, use layered media encoding and related media=20 chunk
descriptions in the peer protocol for more robust streaming.

(8) A=20 implementation and operational experience guide=20 document that describes the performance of the proposed pro= tocols=20 and usable systems.

The=20 work items of the PPSP WG interacts with the work performed in other
IET= F=20 WGs, including P2PSIP, SIPCORE, AVT,=20 ALTO, LEDBAT= , and DECADE=20 and MMUSIC.
Whenever extensions or modification to t= he=20 protocols developed in other
WGs are deemed necessary, PPSP shall commun= icate=20 and discuss the
requirements for such extensions with the relevant WGs. = PPSP=20 is not
chartered to design and specify such changes.

Goals=20 and Milestones

Dec 20110

Submit problem statement to IESG as=20 Informational

Apr=20 2011 2012

Submit problem statement and requirementsarchitectural survey documentto IESG as Informational =

Apr=20 2011 2012

Submit=20 architectural survey requirements document to IESG as = Informational

Aug Sep20121=20 Jan=20 2013

Submit=20 PPSP tracker=20 peer=20 protocol to IESG as Proposed Standard=20

Aug Dec20121=20 Jan=20 2013

Submit=20 PPSP=20 tracker peer<= /SPAN>=20 protocol to IESG as Proposed Standard

Dec2011=20

Submit usage guide to IESG to IESG as=20 Informational=20

Dec=20 2012Jan=20 2013  &= nbsp;=20 Submit PPSP media transport mechanism to IESG as Proposed=20 Standard

 

Apr 2013    Submit usage guide to= IESG=20 as Informational

 

Apr 2013   = ;=20 Submit field test to IESG as=20 Informational

=  

 
zhangyunfei
------=_001_NextPart081857738750_=------ From a.bakker@vu.nl Mon Feb 20 01:04:14 2012 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 9B98221F8572 for ; Mon, 20 Feb 2012 01:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.125 X-Spam-Level: X-Spam-Status: No, score=-1.125 tagged_above=-999 required=5 tests=[AWL=0.779, BAYES_50=0.001, 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 fViA6qGMq+Zn for ; Mon, 20 Feb 2012 01:04:14 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.17]) by ietfa.amsl.com (Postfix) with ESMTP id 83BF521F84D4 for ; Mon, 20 Feb 2012 01:04:11 -0800 (PST) Received: from PEXHB011A.vu.local (130.37.236.64) by mailin.vu.nl (130.37.164.17) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 20 Feb 2012 10:04:10 +0100 Received: from [130.37.244.178] (130.37.238.20) by mails.vu.nl (130.37.236.64) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 20 Feb 2012 10:04:09 +0100 Message-ID: <4F420CA8.8090701@cs.vu.nl> Date: Mon, 20 Feb 2012 10:04:40 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: References: <2012021923584463860669@chinamobile.com> In-Reply-To: <2012021923584463860669@chinamobile.com> 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 Re-charter discussion 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: Mon, 20 Feb 2012 09:04:14 -0000 On 19/02/2012 16:58, zhangyunfei wrote: > > *Please review it and post your comments in the mailing list. We wish to > get consensus in the mailing list before submitting to talk with the AD.* > Hi can you elaborate on what the "the PPSP media transportmechanism." is for which we need to create a specification? Small typos below: > The set of peers that are participating in a streaming Typo: "that is" > > and possible extension on top of them. Typo: "possible extensions" CU, Arno From zongning@huawei.com Tue Feb 21 00:34:18 2012 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 416AA21F8540 for ; Tue, 21 Feb 2012 00:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.898 X-Spam-Level: X-Spam-Status: No, score=-105.898 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_OEM_S_DOL=1.2, 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 v55zoFsx2-8B for ; Tue, 21 Feb 2012 00:34:13 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5E721F8512 for ; Tue, 21 Feb 2012 00:34:07 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZQ002MRIGR71@szxga03-in.huawei.com> for ppsp@ietf.org; Tue, 21 Feb 2012 16:34:04 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZQ00BXVIGRW2@szxga03-in.huawei.com> for ppsp@ietf.org; Tue, 21 Feb 2012 16:34:03 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGZ01815; Tue, 21 Feb 2012 16:34:03 +0800 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 21 Feb 2012 16:33:45 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.8]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Tue, 21 Feb 2012 16:33:59 +0800 Date: Tue, 21 Feb 2012 08:33:57 +0000 From: ZongNing In-reply-to: <2012021923584463860669@chinamobile.com> X-Originating-IP: [10.138.41.33] To: zhangyunfei , ppsp Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ML7t4iuckOfrOqb8MjuVaw)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [ppsp] PPSP Re-charter discussion Thread-index: AQHM7x937BNyL3jVD0C+5ylSz/90ppZHBu5A X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2012021923584463860669@chinamobile.com> Subject: Re: [ppsp] PPSP Re-charter discussion 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, 21 Feb 2012 08:34:18 -0000 --Boundary_(ID_ML7t4iuckOfrOqb8MjuVaw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Regarding " Inclusion of media transport mechanism into PPSP WG task", because we haven't got consensus on mandatory data transport mechanism yet, how do you intend to progress this item? I can see two ways, thus different milestone layout: 1) still selecting at least one mandatory data transport mechanism and document it in peer protocol draft. 2) produce a list of best practice data transport mechanisms for PPSP usage and document these in separate drafts (to peer protocol draft). BR, Ning Zong From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of zhangyunfei Sent: Sunday, February 19, 2012 11:59 PM To: ppsp Subject: [ppsp] PPSP Re-charter discussion Hi all, Based on the discussions in Taipei meeting, Martin and I have drafted the following re-charter text with the track change mode. The basic changes include: 1) Inclusion of media transport mechanism into PPSP WG task. 2) Signaling protocol and media protocol candidates description change; 3) Document merger, submission deadline as well as new WG draft update in Goals and milestones. Please review it and post your comments in the mailing list. We wish to get consensus in the mailing list before submitting to talk with the AD. P.S.: We are exploring the possibility of having an interim meeting in the early of March, before next IETF. We'll start the poll of the time soon if we get positive feedback on the progress from the proposed peer and tracker protocol authors. BR Yunfei Description of Working Group The Peer-to-Peer Streaming Protocol (PPSP) working group develops two signaling and control protocols for a peer-to-peer (P2P) streaming system for transmitting live and time-shifted media content with near real-time delivery requirements. Two kinds of nodes exist in the targeted P2P streaming system, i.e., "peers" and "trackers". Peers are nodes that are actively sending and receiving streamed media content, and include both statically connected hosts as well as mobile devices with connectivity and IP addresses that change over time, as well as changed link characteristics for mobile nodes. The set of peers that are participating in a streaming session will dynamically change over time. Trackers are well-known nodes with stable connectivity that maintain meta information about the streamed content and the dynamic peer set involved in the streaming. Trackers can be organized in centralized or distributed ways. The PPSP WG designs a protocol for signaling and control between trackers and peers (the PPSP "tracker protocol") and a signaling and control protocol for communication among the peers (the PPSP "peer protocol"). The two protocols enable peers to receive streaming data within the time constraints required by specific content items. The tracker protocol handles the initial and periodic exchange of meta information between trackers and peers, such as peer lists and content information. The peer protocol controls the advertising and exchange of media data availability between the peers, as well as the exchange of streaming media. It is envisioned that the tracker protocol will be modeled as a request/response protocol between peers and trackers, and will carry information needed for the selection of peers suitable for real-time streaming. The peer protocol is envisioned to be modeled as a gossip-like protocol with periodic, pairwise exchanges of neighbor and media chunk availability information. Both protocols will be carried over TCP (or UDP, when delivery requirements cannot be met by TCP), likely in combination with ICE for NAT traversal support. Perfect privacy protection is a good feature to have but not a mandatory requirement for the peer and tracker protocols. The WG will consider to use existing protocols as design base for the tracker and peer protocols. Developing mechanisms for searching trackers that contain a specific media item is out of the scope of this WG. Additionally, the WG will work under the assumption that trackers are logically centralized entities (e.g., a single server or a server farm performing DNS-based local balancing). However, as far as it is possible, the WG will not make design decisions that could preclude the use of distributed trackers in the future (e.g., DHT-based trackers). A peer looking for a particular media stream media chunkSuch a media stream is transported in so-called chunks, where a chunk contains the pieces of the media. Obtaining the media chunk from the remote peer will involve some type of signaling exchange, i.e., the tracker and peer protocols to locate a remote peer (or peers) plus the actual media transfer of the chunks. The first, media streammedia chunk. task for this WG will be to decide which signaling and media transfer protocols will be usedThe WG will work on the peer and tracker protocol and . The WG will consider existing protocols and, if needed, identify potential extensions to these protocols. The WG will consider the interactions between these protocols and the peer protocol (e.g., avoiding duplicate NAT traversal procedures). An Eexamples of a signaling protocols to be considered are isSIP, RTSP, and HTTP. Examples of media transfer protocols mechanismsto be considered are UDP, andTCPRTP and HTTP. and possible extension on top of them. PPSP is not chartered to work on media transmission protocols, media encoding techniques or other components of a P2P streaming system such as playout control or, scheduling and control, etc. PPSP will explore the relationship to DECADE and ALTO working groups. The work items of the PPSP WG are: (1) A "problem statement" and "requirements" document. This document that gives an overview of the proposed P2P streaming system, motivates the desire for standardized protocols, defines the envisioned scope of those standardized components and discusses common terminologies and concepts. It also that details the specific functional, operational and performance requirements of the two PPSP protocols. (2) A "requirements" document that details the specific functional, operational and performance requirements of the two PPSP protocols. (3) An "architectural survey" document that summarizes current P2P streaming architectures, in particular tracker-based P2P streaming systems, and highlights best current practices, as input to the design of the peer and tracker protocols.. (4) A detailed specification of the PPSP peer protocol. (5) A detailed specification of the PPSP tracker protocol. (6) A detailed specification of the PPSP media transport mechanism. (7) A "usage guide" that describes how the thewo PPSP protocols and existing IETF protocols, such as P2PSIP,DECADEor ALTO, can be combined to create a deployable operational P2P streaming system. This document may also discuss variants of such a system that, for example, use layered media encoding and related media chunk descriptions in the peer protocol for more robust streaming. (8) A implementation and operational experience guide document that describes the performance of the proposed protocols and usable systems. The work items of the PPSP WG interacts with the work performed in other IETF WGs, including P2PSIP, SIPCORE, AVT, ALTO, LEDBAT, and DECADE and MMUSIC. Whenever extensions or modification to the protocols developed in other WGs are deemed necessary, PPSP shall communicate and discuss the requirements for such extensions with the relevant WGs. PPSP is not chartered to design and specify such changes. Goals and Milestones Dec 20110 Submit problem statement to IESG as Informational Apr 2011 2012 Submit problem statement and requirementsarchitectural survey documentto IESG as Informational Apr 2011 2012 Submit architectural survey requirements document to IESG as Informational Aug Sep20121 Jan 2013 Submit PPSP tracker peer protocol to IESG as Proposed Standard Aug Dec20121 Jan 2013 Submit PPSP tracker peer protocol to IESG as Proposed Standard Dec2011 Submit usage guide to IESG to IESG as Informational Dec 2012Jan 2013 Submit PPSP media transport mechanism to IESG as Proposed Standard Apr 2013 Submit usage guide to IESG as Informational Apr 2013 Submit field test to IESG as Informational ________________________________ zhangyunfei --Boundary_(ID_ML7t4iuckOfrOqb8MjuVaw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

 

Regarding “ Inclusion of media transport mechanis= m into PPSP WG task”, because we haven’t got consensus on manda= tory data transport mechanism yet, how do you intend to progress this item?

I can see two ways, thus different milestone layout:

1)       st= ill selecting at least one mandatory data transport mechanism and document = it in peer protocol draft.

2)       pr= oduce a list of best practice data transport mechanisms for PPSP usage and = document these in separate drafts (to peer protocol draft).

 = ;

BR,

Ning Zong<= o:p>

From: ppsp-bounc= es@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of zhangyunfei
Sent: Sunday, February 19, 2012 11:59 PM
To: ppsp
Subject: [ppsp] PPSP Re-charter discussion

 

Hi all,

  = ; Based on the discussions in Taipei meeting, Martin and I have drafted the= following re-charter text with the track change mode. The basic changes include:<= /span>

1) Inc= lusion of media transport mechanism into PPSP WG task.

2) Signalin= g protocol and media protocol candidates description change;

3) Document= merger, submission deadline as well as new WG draft update in Goals and mi= lestones.<= /span>

  = ;  Please review it and post your comments in the mailing list. We wis= h to get consensus in the mailing list before submitting to talk with the AD.

P.S.: We ar= e exploring the possibility of having an interim meeting in the early = of March, before next IETF. We'll start the poll of the time soon if we get positive feedback on the progress from the proposed peer and tra= cker protocol authors.

 

BR

Yunfei

  = ;

  = ; 

 

Description= of Working Group

The Peer-to-Pe= er Streaming Protocol (PPSP) working group develops two
signaling and control protocols for a peer-to-peer (P2P) streaming
system for transmitting live and time-shifted media content with near
real-time delivery requirements.

Two kinds of n= odes exist in the targeted P2P streaming system, i.e.,
"peers" and "trackers". Peers are nodes that are active= ly sending and
receiving streamed media content, and include both statically connected
hosts as well as mobile devices with connectivity and IP address= es that
change over time, as well as changed link characteristics for mobile nodes.
The set of peers that are participating in a streaming
session will dynamically change over time. Trackers are well-known nodes with stable connectivity that maintain meta information about the
streamed content and the dynamic peer set involved in the streaming. Trackers can be organized in
centralized or distributed ways.

The PPSP WG de= signs a protocol for signaling and control between
trackers and peers (the PPSP "tracker protocol") and a signaling = and
control protocol for communication among the peers (the PPSP "peer
protocol"). The two protocols enable peers to receive streaming data within the time constraints required by specific content items. The
tracker protocol handles the initial and periodic exchange of meta
information between trackers and peers, such as peer lists and content
information. The peer protocol controls the advertising and exchange of
media data availability between the peers, as well as the exchange of streaming media.

It is envision= ed that the tracker protocol will be modeled as a
request/response protocol between peers and trackers, and will carry
information needed for the selection of peers suitable for real-time
streaming. The peer protocol is envisioned to be modeled as a
gossip-like protocol with periodic, pairwise exchanges of neighbor and
media chunk availability information. Both protocols will be carried
over TCP (or UDP, when delivery requirements cannot be met by TCP),
likely in combination with ICE for NAT traversal support. Perfect
privacy protection is a good feature to have but not a mandatory
requirement for the peer and tracker protocols. The WG will consider to
use existing protocols as design base for the tracker and peer
protocols.

Developing mec= hanisms for searching trackers that contain a specific
media item is out of the scope of this WG. Additionally, the WG will
work under the assumption that trackers are logically centralized
entities (e.g., a single server or a server farm performing DNS-based
local balancing). However, as far as it is possible, the WG will not
make design decisions that could preclude the use of distributed
trackers in the future (e.g., DHT-based trackers).

A peer looking= for a particular media stream media chunk<= ins cite=3D"mailto:Martin%20Stiemerling" datetime=3D"2012-02-15T15:02">Such a media stream is transported in so-called chunks, where a chunk contains the pieces of the media.= <= /o:p>

Obtaining= the media chunk= from the remote peer will involve some
type of signaling exchange, i.e., the = tracker and peer protocols to
locate a remote peer (or peers) plus the actual media trans= fer of the chunks. The first,<= span lang=3D"EN-US" style=3D"color:black"> media streammedia= chunk.
task for this WG will be to decide which signaling = and media transfer
protocols will be usedThe WG will work on the peer and tracker protocol and . The WG will consider existing protocols and, if
needed, identify potential extensions to these protocols. The WG will
consider the interactions between these protocols a= nd the peer protocol
(e.g., avoiding duplicate NAT traversal procedures)= . An Eexamples= of a
= s= ignaling protocols to be considered are = is<= /del>SIP, RTSP, and HTTP. Examples
of media transfer <= span lang=3D"EN-US" style=3D"color:red">protocols mechanismsto be considered are = UDP<= /span><= span class=3D"msoDel"><= del cite=3D"mailto:ady" datetime=3D"2011-12-05T22:16">, andTCP<= /span><= del cite=3D"mailto:Martin%20Stiemerling" datetime=3D"2012-02-15T15:07">RTP and HTTP.

and possible extension on top of them.

PPSP is not chartered to work on media transmission protocols, media
encoding techniques or other components of a P2P streaming system such
as playout control or, scheduling and control, etc.=

PPSP will explore the relationship to DECADE and ALTO working groups.

The work items of the PPSP WG are:<= /p>

(1) A "problem statement" <= ins cite=3D"mailto:Martin%20Stiemerling" datetime=3D"2012-01-11T11:32"><= del cite=3D"mailto:ady" datetime=3D"2011-12-05T22:18">and "requirements" document= . This document that gives an overview of the
proposed P2P streaming system, motivates the desire for
standardized protocols, defines the envisioned scope of those
standardized components and discusses common terminologies and
concepts. It also that details the specific functional,
operational and performance requirements of the two= PPSP
protocols.

(2) A "requirements" document that details the specific functional,<= /del><= span class=3D"msoDel">
operational and performance requirements of the two= PPSP
protocols.

= (3) An "architectural survey" document that summarizes current P2P streaming architectures, in particular tracker-based P2P
streaming systems, and highlights best current practices<= /span><= span class=3D"msoIns">, as input to the design of the peer and tracker protocols..<= span lang=3D"EN-US">

= (4) A detailed specification of the PPSP peer protocol.=

= (5) A detailed specification of the PPSP tracker protocol.

= (6) A detailed specification of the PPSP media tran= sport mechanism.

(7) A "usage guide" that describes how the t<= /span>hewo PPSP protocols and
existing IETF protocols, such as P2PSIP,= DECADEor ALTO, can be combined
to create a deployable operational P2P streaming system. This
document may also discuss variants of such a system that, for
example, use layered media encoding and related media chunk
descriptions in the peer protocol for more robust streaming.=

(8) A implementation and operational experience guide = = doc= ument that describes the performance of the proposed protocols and usable system= s.

The work items of the PPSP WG interacts with the work performed in other
IETF WGs, including P2PSIP, SIPCORE, AVT, ALTO,<= span class=3D"msoDel"> LEDBAT, and DECADE and MMUSIC.
Whenever extensions or modification to the protocols developed in other
WGs are deemed necessary, PPSP shall communicate and discuss the
requirements for such extensions with the relevant WGs. PPSP is not
chartered to design and specify such changes.<= /span>

Goals and Milestones

Dec 20110

Submit problem statement to IESG as Informati= onal

Apr 2011 2012

Submit problem statement and requirementsarchitec= tural survey documentto IESG as Informational

Apr 2011 2012

Submit arch= itectural survey requirements document t= o IESG as Informational

<= del cite=3D"mailto:ady" datetime=3D"2011-12-05T22:35">Aug Sep20121 Jan 2013

Submit PPSP trac= ker peer protocol t= o IESG as Proposed Standard

<= del cite=3D"mailto:ady" datetime=3D"2011-12-05T22:35">Aug Dec20121 Jan 2013

Submit PPSP tracker peer protocol to IESG as Proposed Standard

<= del cite=3D"mailto:ady" datetime=3D"2011-12-05T22:36">Dec2011 <= /span>

<= del cite=3D"mailto:ady" datetime=3D"2011-12-05T22:49">Submit usage guide to IESG to IESG as Informational

<= ins cite=3D"mailto:ady" datetime=3D"2011-12-05T22:48"><= del cite=3D"mailto:ady" datetime=3D"2011-12-05T22:31">Dec 2012Jan 2013    Submit PPSP media transport mechanism to IESG as Proposed Standard

 

= = Apr 2013    Submit usage guide to IESG as Informational

 

= = Apr 2013    Submit field test to IESG as Informational

 

 

zhangyunfei

--Boundary_(ID_ML7t4iuckOfrOqb8MjuVaw)-- From riccardo.bernardini@uniud.it Tue Feb 21 01:26:01 2012 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 D230D21F85C5 for ; Tue, 21 Feb 2012 01:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 Z1uW9v+DbEjK for ; Tue, 21 Feb 2012 01:26:00 -0800 (PST) Received: from delivery.uniud.it (mail.uniud.it [158.110.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id 3501A21F8548 for ; Tue, 21 Feb 2012 01:25:58 -0800 (PST) Received: from nospam.uniud.it (nospam.uniud.it [158.110.1.213]) by delivery.uniud.it (Postfix) with ESMTP id 85D40B723A5 for ; Tue, 21 Feb 2012 10:25:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at talitha2.cc.uniud.it Received: from smtp.uniud.it ([158.110.1.136]) by nospam.uniud.it (nospam.uniud.it [158.110.1.213]) (amavisd-new, port 10028) with ESMTP id 7XTS8FzFCDRK for ; Tue, 21 Feb 2012 10:25:50 +0100 (CET) Received: from webmail.uniud.it (webmail2.cc.uniud.it [158.110.1.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uniud.it (Postfix) with ESMTPSA id 91717B0036 for ; Tue, 21 Feb 2012 10:25:50 +0100 (CET) Received: from 158.110.27.77 ([158.110.27.77]) by webmail.uniud.it (Horde Framework) with HTTP; Tue, 21 Feb 2012 10:25:50 +0100 Message-ID: <20120221102550.13522kalk6qvny1q@webmail.uniud.it> Date: Tue, 21 Feb 2012 10:25:50 +0100 From: Riccardo Bernardini To: ppsp@ietf.org References: <2012021923584463860669@chinamobile.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.7) Subject: Re: [ppsp] PPSP Re-charter discussion 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, 21 Feb 2012 09:26:02 -0000 ZongNing ha scritto: > Hi, > > Regarding " Inclusion of media transport mechanism into PPSP WG > task", because we haven't got consensus on mandatory data transport > mechanism yet, how do you intend to progress this item? > I can see two ways, thus different milestone layout: > > 1) still selecting at least one mandatory data transport > mechanism and document it in peer protocol draft. > > 2) produce a list of best practice data transport mechanisms > for PPSP usage and document these in separate drafts (to peer > protocol draft). I like this approach, but I would reverse the order of milestones, that is, first fix what we need from the media transport protocol and the interface that the transport protocol must expose, then on the top of that specification define one (or more) "default" (and mandatory to implement) transport protocol(s). (Actually, I expect the development of the two specs to proceed in parallel, with interactions). BTW, minor typo: maybe in "A peer looking for a particular media stream" is an "is" missing? Regards, Riccardo > > BR, > Ning Zong > From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf > Of zhangyunfei > Sent: Sunday, February 19, 2012 11:59 PM > To: ppsp > Subject: [ppsp] PPSP Re-charter discussion > > Hi all, > Based on the discussions in Taipei meeting, Martin and I have > drafted the following re-charter text with the track change mode. > The basic changes include: > 1) Inclusion of media transport mechanism into PPSP WG task. > 2) Signaling protocol and media protocol candidates description change; > 3) Document merger, submission deadline as well as new WG draft > update in Goals and milestones. > Please review it and post your comments in the mailing list. We > wish to get consensus in the mailing list before submitting to talk > with the AD. > P.S.: We are exploring the possibility of having an interim meeting > in the early of March, before next IETF. We'll start the poll of the > time soon if we get positive feedback on the progress from the > proposed peer and tracker protocol authors. > > BR > Yunfei > > > > Description of Working Group > The Peer-to-Peer Streaming Protocol (PPSP) working group develops two > signaling and control protocols for a peer-to-peer (P2P) streaming > system for transmitting live and time-shifted media content with near > real-time delivery requirements. > Two kinds of nodes exist in the targeted P2P streaming system, i.e., > "peers" and "trackers". Peers are nodes that are actively sending and > receiving streamed media content, and include both statically connected > hosts as well as mobile devices with connectivity and IP addresses that > change over time, as well as changed link characteristics for mobile nodes. > The set of peers that are participating in a streaming > session will dynamically change over time. Trackers are well-known nodes > with stable connectivity that maintain meta information about the > streamed content and the dynamic peer set involved in the streaming. > Trackers can be organized in > centralized or distributed ways. > The PPSP WG designs a protocol for signaling and control between > trackers and peers (the PPSP "tracker protocol") and a signaling and > control protocol for communication among the peers (the PPSP "peer > protocol"). The two protocols enable peers to receive streaming data > within the time constraints required by specific content items. The > tracker protocol handles the initial and periodic exchange of meta > information between trackers and peers, such as peer lists and content > information. The peer protocol controls the advertising and exchange of > media data availability between the peers, as well as the exchange > of streaming media. > It is envisioned that the tracker protocol will be modeled as a > request/response protocol between peers and trackers, and will carry > information needed for the selection of peers suitable for real-time > streaming. The peer protocol is envisioned to be modeled as a > gossip-like protocol with periodic, pairwise exchanges of neighbor and > media chunk availability information. Both protocols will be carried > over TCP (or UDP, when delivery requirements cannot be met by TCP), > likely in combination with ICE for NAT traversal support. Perfect > privacy protection is a good feature to have but not a mandatory > requirement for the peer and tracker protocols. The WG will consider to > use existing protocols as design base for the tracker and peer > protocols. > Developing mechanisms for searching trackers that contain a specific > media item is out of the scope of this WG. Additionally, the WG will > work under the assumption that trackers are logically centralized > entities (e.g., a single server or a server farm performing DNS-based > local balancing). However, as far as it is possible, the WG will not > make design decisions that could preclude the use of distributed > trackers in the future (e.g., DHT-based trackers). > A peer looking for a particular media stream media chunkSuch a media > stream is transported in so-called chunks, where a chunk contains > the pieces of the media. > Obtaining the media chunk from the remote peer will involve some > type of signaling exchange, i.e., the tracker and peer protocols to > locate a remote peer (or peers) plus the actual media transfer of > the chunks. The first, media streammedia > chunk. > task for this WG will be to decide which signaling and media transfer > protocols will be usedThe WG will work on the peer and tracker > protocol and . The WG will consider existing protocols and, if > needed, identify potential extensions to these protocols. The WG will > consider the interactions between these protocols and the peer protocol > (e.g., avoiding duplicate NAT traversal procedures). An Eexamples of a > signaling protocols to be considered are isSIP, RTSP, and HTTP. Examples > of media transfer protocols mechanismsto be considered are UDP, > andTCPRTP and HTTP. > and possible extension on top of them. > PPSP is not chartered to work on media transmission protocols, media > encoding techniques or other components of a P2P streaming system such > as playout control or, scheduling and control, etc. > PPSP will explore the relationship to DECADE and ALTO working groups. > The work items of the PPSP WG are: > (1) A "problem statement" and "requirements" document. This document > that gives an overview of the > proposed P2P streaming system, motivates the desire for > standardized protocols, defines the envisioned scope of those > standardized components and discusses common terminologies and > concepts. It also that details the specific functional, > operational and performance requirements of the two PPSP > protocols. > (2) A "requirements" document that details the specific functional, > operational and performance requirements of the two PPSP > protocols. > (3) An "architectural survey" document that summarizes current P2P > streaming architectures, in particular tracker-based P2P > streaming systems, and highlights best current practices, as input > to the design of the peer and tracker protocols.. > (4) A detailed specification of the PPSP peer protocol. > (5) A detailed specification of the PPSP tracker protocol. > (6) A detailed specification of the PPSP media transport mechanism. > (7) A "usage guide" that describes how the thewo PPSP protocols and > existing IETF protocols, such as P2PSIP,DECADEor ALTO, can be combined > to create a deployable operational P2P streaming system. This > document may also discuss variants of such a system that, for > example, use layered media encoding and related media chunk > descriptions in the peer protocol for more robust streaming. > (8) A implementation and operational experience guide document that > describes the performance of the proposed protocols and usable > systems. > The work items of the PPSP WG interacts with the work performed in other > IETF WGs, including P2PSIP, SIPCORE, AVT, ALTO, LEDBAT, and DECADE > and MMUSIC. > Whenever extensions or modification to the protocols developed in other > WGs are deemed necessary, PPSP shall communicate and discuss the > requirements for such extensions with the relevant WGs. PPSP is not > chartered to design and specify such changes. > Goals and Milestones > Dec 20110 > > Submit problem statement to IESG as Informational > > Apr 2011 2012 > > Submit problem statement and requirementsarchitectural survey > documentto IESG as Informational > > Apr 2011 2012 > > Submit architectural survey requirements document to IESG as Informational > > Aug Sep20121 Jan 2013 > > Submit PPSP tracker peer protocol to IESG as Proposed Standard > > Aug Dec20121 Jan 2013 > > Submit PPSP tracker peer protocol to IESG as Proposed Standard > > Dec2011 > > Submit usage guide to IESG to IESG as Informational > > Dec 2012Jan 2013 Submit PPSP media transport mechanism to IESG as > Proposed Standard > > Apr 2013 Submit usage guide to IESG as Informational > > Apr 2013 Submit field test to IESG as Informational > > > ________________________________ > zhangyunfei > -- Riccardo Bernardini DIEGM -- University of Udine via delle Scienze 208 33100 Udine Tel: +39-0432-55-8271 Fax: +39-0432-55-8251 ---------------------------------------------------------------------- SEMEL (SErvizio di Messaging ELettronico) - AINF, Universita' di Udine From zhangyunfei@chinamobile.com Tue Feb 21 19:15:47 2012 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 0479221E800F for ; Tue, 21 Feb 2012 19:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.109 X-Spam-Level: X-Spam-Status: No, score=-97.109 tagged_above=-999 required=5 tests=[AWL=1.514, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 duqYEutV81eA for ; Tue, 21 Feb 2012 19:15:43 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9C01721F8912 for ; Tue, 21 Feb 2012 19:15:42 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id EAA87E513; Wed, 22 Feb 2012 11:15:40 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id DD415E504; Wed, 22 Feb 2012 11:15:40 +0800 (CST) Received: from pc917 ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012022211153531-8071 ; Wed, 22 Feb 2012 11:15:35 +0800 Date: Wed, 22 Feb 2012 11:15:28 +0800 From: zhangyunfei To: "arno@cs.vu.nl" , ppsp References: <2012021923584463860669@chinamobile.com>, <4F420CA8.8090701@cs.vu.nl> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012022211013534382619@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-22 11:15:38, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-22 11:15:40, Serialize complete at 2012-02-22 11:15:40 Content-Type: multipart/alternative; boundary="----=_001_NextPart445517472723_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18724.004 X-TM-AS-Result: No--16.231-7.0-31-10 X-imss-scan-details: No--16.231-7.0-31-10;No--16.231-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] PPSP Re-charter discussion X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei 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, 22 Feb 2012 03:15:47 -0000 This is a multi-part message in MIME format. ------=_001_NextPart445517472723_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgQXJubywgIA0KICAgICBQbGVhc2Ugc2VlIGlubGluZS4NCg0KQlINCll1bmZlaQ0KDQoNCg0K DQp6aGFuZ3l1bmZlaQ0KDQpGcm9tOiBBcm5vIEJha2tlcg0KRGF0ZTogMjAxMi0wMi0yMCAxNzow NA0KVG86IHBwc3BAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcHBzcF0gUFBTUCBSZS1jaGFydGVy IGRpc2N1c3Npb24NCk9uIDE5LzAyLzIwMTIgMTY6NTgsIHpoYW5neXVuZmVpIHdyb3RlOg0KPg0K PiAqUGxlYXNlIHJldmlldyBpdCBhbmQgcG9zdCB5b3VyIGNvbW1lbnRzIGluIHRoZSBtYWlsaW5n IGxpc3QuIFdlIHdpc2ggdG8NCj4gZ2V0IGNvbnNlbnN1cyBpbiB0aGUgbWFpbGluZyBsaXN0IGJl Zm9yZSBzdWJtaXR0aW5nIHRvIHRhbGsgd2l0aCB0aGUgQUQuKg0KPg0KDQpIaQ0KDQpjYW4geW91 IGVsYWJvcmF0ZSBvbiB3aGF0IHRoZSAidGhlIFBQU1AgbWVkaWEgdHJhbnNwb3J0bWVjaGFuaXNt LiIgaXMgDQpmb3Igd2hpY2ggd2UgbmVlZCB0byBjcmVhdGUgYSBzcGVjaWZpY2F0aW9uPw0KDQpU aGUgcGljdHVyZSBJIGltYWdpbmUgaXMgdGhhdCB3ZSBoYXZlIGEgbWFuZGF0b3J5IG1lZGlhIHRy YW5zcG9ydCBtZWNoYW5pbSBpbiBQUFNQLiBJIGRvbid0IG1lYW4gdG8gZGVzaWduIA0KYSBuZXcg cHJvdG9jb2wgcGFyYWxsZWwgdG8gVURQIG9yIFRDUC4gUmF0aGVyIHRoZSBzcGVjIHNob3VsZCBt YWtlIGl0IGNsZWFyIGhvdyB0byB1c2UgVURQIG9yIFRDUCBpbiBQUFNQIGVudmlyb25tZW50LiBN YXliZSBpdCBhbHNvIA0KaW52b2x2ZXMgc29tZSBleHRlbnNpb25zIGFib3ZlIFVEUCBvciBUQ1Au DQoNCg0KU21hbGwgdHlwb3MgYmVsb3c6DQoNCj4gVGhlIHNldCBvZiBwZWVycyB0aGF0IGFyZSBw YXJ0aWNpcGF0aW5nIGluIGEgc3RyZWFtaW5nDQoNClR5cG86ICJ0aGF0IGlzIg0KDQo+DQo+IGFu ZCBwb3NzaWJsZSBleHRlbnNpb24gb24gdG9wIG9mIHRoZW0uDQoNClR5cG86ICJwb3NzaWJsZSBl eHRlbnNpb25zIg0KDQpUaGFua3MgZm9yIHRoZSBjYXJlZnVsIHJldmlldy4NCg0KQ1UsDQogICAg IEFybm8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpw cHNwIG1haWxpbmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wcHNw ------=_001_NextPart445517472723_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Arno, 
     Please see inline.
 
BR
Yunfei
 
zhangyunfei
 
From: Arno Bakker
Date: 2012-02-20 17:04
To: ppsp@ietf.org
Subject: Re: [ppsp] PPSP Re-charter=20 discussion
On 19/02/2012 16:58, zhangyunfei wrote:
>
> *Please review it and post your&nb= sp;comments in the mailing list. We wish&nbs= p;to
> get consensus in the mailing list&= nbsp;before submitting to talk with the AD.*=
>
 
Hi
 
can you elaborate on what the "the = ;PPSP media transportmechanism." is 
for which we need to create a spec= ification?
 
The picture I imagine is that we have a mand= atory=20 media transport mechanim in PPSP. I don't mean to design
a new protocol parallel to UDP or TCP. Rathe= r the=20 spec should make it clear how to use UDP or TCP in PPSP environment. Maybe= it=20 also
involves some extensions above UDP or TCP.
 
 
Small typos below:
 
> The set of peers that are par= ticipating in a streaming
 
Typo: "that is"
 
>
> and possible extension on top of&n= bsp;them.
 
Typo: "possible extensions"
 
Thanks for the careful review.
 
CU,
     Arno
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart445517472723_=------ From zhangyunfei@chinamobile.com Tue Feb 21 19:16:22 2012 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 CF92421E8038 for ; Tue, 21 Feb 2012 19:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.277 X-Spam-Level: X-Spam-Status: No, score=-97.277 tagged_above=-999 required=5 tests=[AWL=1.346, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 k7MBD8cR6cL8 for ; Tue, 21 Feb 2012 19:16:21 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1303621F8912 for ; Tue, 21 Feb 2012 19:16:20 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id BBCB5E504; Wed, 22 Feb 2012 11:16:18 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 94229E4D8; Wed, 22 Feb 2012 11:16:18 +0800 (CST) Received: from pc917 ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012022211153641-8072 ; Wed, 22 Feb 2012 11:15:36 +0800 Date: Wed, 22 Feb 2012 11:15:28 +0800 From: zhangyunfei To: ZongNing , ppsp References: <2012021923584463860669@chinamobile.com>, X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012022211100575063629@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-22 11:16:16, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-22 11:16:18 Content-Type: multipart/alternative; boundary="----=_001_NextPart411514585705_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18724.004 X-TM-AS-Result: No--28.365-7.0-31-10 X-imss-scan-details: No--28.365-7.0-31-10;No--28.365-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] PPSP Re-charter discussion X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei 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, 22 Feb 2012 03:16:22 -0000 ------=_001_NextPart411514585705_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgTmluZywNCiAgICBQbGVhc2Ugc2VlIGlubGluZS4NCg0KQlINCll1bmZlaQ0KDQoNCg0KDQp6 aGFuZ3l1bmZlaQ0KDQpGcm9tOiBab25nTmluZw0KRGF0ZTogMjAxMi0wMi0yMSAxNjozMw0KVG86 IHpoYW5neXVuZmVpOyBwcHNwDQpTdWJqZWN0OiBSRTogW3Bwc3BdIFBQU1AgUmUtY2hhcnRlciBk aXNjdXNzaW9uDQpIaSwNCiANClJlZ2FyZGluZyChsCBJbmNsdXNpb24gb2YgbWVkaWEgdHJhbnNw b3J0IG1lY2hhbmlzbSBpbnRvIFBQU1AgV0cgdGFza6GxLCBiZWNhdXNlIHdlIGhhdmVuoa90IGdv dCBjb25zZW5zdXMgb24gbWFuZGF0b3J5IGRhdGEgdHJhbnNwb3J0IG1lY2hhbmlzbSB5ZXQsIGhv dyBkbyB5b3UgaW50ZW5kIHRvIHByb2dyZXNzIHRoaXMgaXRlbT8NCkkgY2FuIHNlZSB0d28gd2F5 cywgdGh1cyBkaWZmZXJlbnQgbWlsZXN0b25lIGxheW91dDoNCjEpICAgICAgIHN0aWxsIHNlbGVj dGluZyBhdCBsZWFzdCBvbmUgbWFuZGF0b3J5IGRhdGEgdHJhbnNwb3J0IG1lY2hhbmlzbSBhbmQg ZG9jdW1lbnQgaXQgaW4gcGVlciBwcm90b2NvbCBkcmFmdC4NCjIpICAgICAgIHByb2R1Y2UgYSBs aXN0IG9mIGJlc3QgcHJhY3RpY2UgZGF0YSB0cmFuc3BvcnQgbWVjaGFuaXNtcyBmb3IgUFBTUCB1 c2FnZSBhbmQgZG9jdW1lbnQgdGhlc2UgaW4gc2VwYXJhdGUgZHJhZnRzICh0byBwZWVyIHByb3Rv Y29sIGRyYWZ0KS4NCltZdW5mZWldIEkgd291bGQgcHJlZmVyIHRoZSBzZWNvbmQgb3B0aW9uLCB3 aGljaCBtYWtlcyBldmVyeSBwYXJ0IG9mIFBQU1AgcHJvdG9jb2wgc3VpdGUgY2xlYXIuIEJ1dCB3 ZSBtYXkgbmVlZCBzb21lIGRpc2N1c3Npb24gaW4gdGhlIFBQU1AgdXNhZ2UgZG9jdW1lbnQgdG8g bWFrZSB0aGUgc2lnbmFsaW5nIGFuZCBtZWRpYSB0cmFuc2ZlciBtb3N0IGVmZmljaWVudCBpbiB0 aGUgY29tYmluZWQgdXNhZ2UuDQogDQpCUiwNCk5pbmcgWm9uZw0KRnJvbTogcHBzcC1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86cHBzcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Ygemhh bmd5dW5mZWkNClNlbnQ6IFN1bmRheSwgRmVicnVhcnkgMTksIDIwMTIgMTE6NTkgUE0NClRvOiBw cHNwDQpTdWJqZWN0OiBbcHBzcF0gUFBTUCBSZS1jaGFydGVyIGRpc2N1c3Npb24NCiANCkhpIGFs bCwNCiAgIEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyBpbiBUYWlwZWkgbWVldGluZywgTWFydGlu IGFuZCBJIGhhdmUgZHJhZnRlZCB0aGUgZm9sbG93aW5nIHJlLWNoYXJ0ZXIgdGV4dCB3aXRoIHRo ZSB0cmFjayBjaGFuZ2UgbW9kZS4gVGhlIGJhc2ljIGNoYW5nZXMgaW5jbHVkZToNCjEpIEluY2x1 c2lvbiBvZiBtZWRpYSB0cmFuc3BvcnQgbWVjaGFuaXNtIGludG8gUFBTUCBXRyB0YXNrLg0KMikg U2lnbmFsaW5nIHByb3RvY29sIGFuZCBtZWRpYSBwcm90b2NvbCBjYW5kaWRhdGVzIGRlc2NyaXB0 aW9uIGNoYW5nZTsNCjMpIERvY3VtZW50IG1lcmdlciwgc3VibWlzc2lvbiBkZWFkbGluZSBhcyB3 ZWxsIGFzIG5ldyBXRyBkcmFmdCB1cGRhdGUgaW4gR29hbHMgYW5kIG1pbGVzdG9uZXMuDQogICAg UGxlYXNlIHJldmlldyBpdCBhbmQgcG9zdCB5b3VyIGNvbW1lbnRzIGluIHRoZSBtYWlsaW5nIGxp c3QuIFdlIHdpc2ggdG8gZ2V0IGNvbnNlbnN1cyBpbiB0aGUgbWFpbGluZyBsaXN0IGJlZm9yZSBz dWJtaXR0aW5nIHRvIHRhbGsgd2l0aCB0aGUgQUQuDQpQLlMuOiBXZSBhcmUgZXhwbG9yaW5nIHRo ZSBwb3NzaWJpbGl0eSBvZiBoYXZpbmcgYW4gaW50ZXJpbSBtZWV0aW5nIGluIHRoZSBlYXJseSBv ZiBNYXJjaCwgYmVmb3JlIG5leHQgSUVURi4gV2UnbGwgc3RhcnQgdGhlIHBvbGwgb2YgdGhlIHRp bWUgc29vbiBpZiB3ZSBnZXQgcG9zaXRpdmUgZmVlZGJhY2sgb24gdGhlIHByb2dyZXNzIGZyb20g dGhlIHByb3Bvc2VkIHBlZXIgYW5kIHRyYWNrZXIgcHJvdG9jb2wgYXV0aG9ycy4NCiANCkJSDQpZ dW5mZWkNCiAgIA0KICAgIA0KIA0KRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cA0KVGhlIFBl ZXItdG8tUGVlciBTdHJlYW1pbmcgUHJvdG9jb2wgKFBQU1ApIHdvcmtpbmcgZ3JvdXAgZGV2ZWxv cHMgdHdvDQpzaWduYWxpbmcgYW5kIGNvbnRyb2wgcHJvdG9jb2xzIGZvciBhIHBlZXItdG8tcGVl ciAoUDJQKSBzdHJlYW1pbmcNCnN5c3RlbSBmb3IgdHJhbnNtaXR0aW5nIGxpdmUgYW5kIHRpbWUt c2hpZnRlZCBtZWRpYSBjb250ZW50IHdpdGggbmVhcg0KcmVhbC10aW1lIGRlbGl2ZXJ5IHJlcXVp cmVtZW50cy4NClR3byBraW5kcyBvZiBub2RlcyBleGlzdCBpbiB0aGUgdGFyZ2V0ZWQgUDJQIHN0 cmVhbWluZyBzeXN0ZW0sIGkuZS4sDQoicGVlcnMiIGFuZCAidHJhY2tlcnMiLiBQZWVycyBhcmUg bm9kZXMgdGhhdCBhcmUgYWN0aXZlbHkgc2VuZGluZyBhbmQNCnJlY2VpdmluZyBzdHJlYW1lZCBt ZWRpYSBjb250ZW50LCBhbmQgaW5jbHVkZSBib3RoIHN0YXRpY2FsbHkgY29ubmVjdGVkDQpob3N0 cyBhcyB3ZWxsIGFzIG1vYmlsZSBkZXZpY2VzIHdpdGggY29ubmVjdGl2aXR5IGFuZCBJUCBhZGRy ZXNzZXMgdGhhdA0KY2hhbmdlIG92ZXIgdGltZSwgYXMgd2VsbCBhcyBjaGFuZ2VkIGxpbmsgY2hh cmFjdGVyaXN0aWNzIGZvciBtb2JpbGUgbm9kZXMuDQpUaGUgc2V0IG9mIHBlZXJzIHRoYXQgYXJl IHBhcnRpY2lwYXRpbmcgaW4gYSBzdHJlYW1pbmcNCnNlc3Npb24gd2lsbCBkeW5hbWljYWxseSBj aGFuZ2Ugb3ZlciB0aW1lLiBUcmFja2VycyBhcmUgd2VsbC1rbm93biBub2Rlcw0Kd2l0aCBzdGFi bGUgY29ubmVjdGl2aXR5IHRoYXQgbWFpbnRhaW4gbWV0YSBpbmZvcm1hdGlvbiBhYm91dCB0aGUN CnN0cmVhbWVkIGNvbnRlbnQgYW5kIHRoZSBkeW5hbWljIHBlZXIgc2V0IGludm9sdmVkIGluIHRo ZSBzdHJlYW1pbmcuIFRyYWNrZXJzIGNhbiBiZSBvcmdhbml6ZWQgaW4NCmNlbnRyYWxpemVkIG9y IGRpc3RyaWJ1dGVkIHdheXMuDQpUaGUgUFBTUCBXRyBkZXNpZ25zIGEgcHJvdG9jb2wgZm9yIHNp Z25hbGluZyBhbmQgY29udHJvbCBiZXR3ZWVuDQp0cmFja2VycyBhbmQgcGVlcnMgKHRoZSBQUFNQ ICJ0cmFja2VyIHByb3RvY29sIikgYW5kIGEgc2lnbmFsaW5nIGFuZA0KY29udHJvbCBwcm90b2Nv bCBmb3IgY29tbXVuaWNhdGlvbiBhbW9uZyB0aGUgcGVlcnMgKHRoZSBQUFNQICJwZWVyDQpwcm90 b2NvbCIpLiBUaGUgdHdvIHByb3RvY29scyBlbmFibGUgcGVlcnMgdG8gcmVjZWl2ZSBzdHJlYW1p bmcgZGF0YQ0Kd2l0aGluIHRoZSB0aW1lIGNvbnN0cmFpbnRzIHJlcXVpcmVkIGJ5IHNwZWNpZmlj IGNvbnRlbnQgaXRlbXMuIFRoZQ0KdHJhY2tlciBwcm90b2NvbCBoYW5kbGVzIHRoZSBpbml0aWFs IGFuZCBwZXJpb2RpYyBleGNoYW5nZSBvZiBtZXRhDQppbmZvcm1hdGlvbiBiZXR3ZWVuIHRyYWNr ZXJzIGFuZCBwZWVycywgc3VjaCBhcyBwZWVyIGxpc3RzIGFuZCBjb250ZW50DQppbmZvcm1hdGlv bi4gVGhlIHBlZXIgcHJvdG9jb2wgY29udHJvbHMgdGhlIGFkdmVydGlzaW5nIGFuZCBleGNoYW5n ZSBvZg0KbWVkaWEgZGF0YSBhdmFpbGFiaWxpdHkgYmV0d2VlbiB0aGUgcGVlcnMsIGFzIHdlbGwg YXMgdGhlIGV4Y2hhbmdlIG9mIHN0cmVhbWluZyBtZWRpYS4NCkl0IGlzIGVudmlzaW9uZWQgdGhh dCB0aGUgdHJhY2tlciBwcm90b2NvbCB3aWxsIGJlIG1vZGVsZWQgYXMgYQ0KcmVxdWVzdC9yZXNw b25zZSBwcm90b2NvbCBiZXR3ZWVuIHBlZXJzIGFuZCB0cmFja2VycywgYW5kIHdpbGwgY2FycnkN CmluZm9ybWF0aW9uIG5lZWRlZCBmb3IgdGhlIHNlbGVjdGlvbiBvZiBwZWVycyBzdWl0YWJsZSBm b3IgcmVhbC10aW1lDQpzdHJlYW1pbmcuIFRoZSBwZWVyIHByb3RvY29sIGlzIGVudmlzaW9uZWQg dG8gYmUgbW9kZWxlZCBhcyBhDQpnb3NzaXAtbGlrZSBwcm90b2NvbCB3aXRoIHBlcmlvZGljLCBw YWlyd2lzZSBleGNoYW5nZXMgb2YgbmVpZ2hib3IgYW5kDQptZWRpYSBjaHVuayBhdmFpbGFiaWxp dHkgaW5mb3JtYXRpb24uIEJvdGggcHJvdG9jb2xzIHdpbGwgYmUgY2FycmllZA0Kb3ZlciBUQ1Ag KG9yIFVEUCwgd2hlbiBkZWxpdmVyeSByZXF1aXJlbWVudHMgY2Fubm90IGJlIG1ldCBieSBUQ1Ap LA0KbGlrZWx5IGluIGNvbWJpbmF0aW9uIHdpdGggSUNFIGZvciBOQVQgdHJhdmVyc2FsIHN1cHBv cnQuIFBlcmZlY3QNCnByaXZhY3kgcHJvdGVjdGlvbiBpcyBhIGdvb2QgZmVhdHVyZSB0byBoYXZl IGJ1dCBub3QgYSBtYW5kYXRvcnkNCnJlcXVpcmVtZW50IGZvciB0aGUgcGVlciBhbmQgdHJhY2tl ciBwcm90b2NvbHMuIFRoZSBXRyB3aWxsIGNvbnNpZGVyIHRvDQp1c2UgZXhpc3RpbmcgcHJvdG9j b2xzIGFzIGRlc2lnbiBiYXNlIGZvciB0aGUgdHJhY2tlciBhbmQgcGVlcg0KcHJvdG9jb2xzLg0K RGV2ZWxvcGluZyBtZWNoYW5pc21zIGZvciBzZWFyY2hpbmcgdHJhY2tlcnMgdGhhdCBjb250YWlu IGEgc3BlY2lmaWMNCm1lZGlhIGl0ZW0gaXMgb3V0IG9mIHRoZSBzY29wZSBvZiB0aGlzIFdHLiBB ZGRpdGlvbmFsbHksIHRoZSBXRyB3aWxsDQp3b3JrIHVuZGVyIHRoZSBhc3N1bXB0aW9uIHRoYXQg dHJhY2tlcnMgYXJlIGxvZ2ljYWxseSBjZW50cmFsaXplZA0KZW50aXRpZXMgKGUuZy4sIGEgc2lu Z2xlIHNlcnZlciBvciBhIHNlcnZlciBmYXJtIHBlcmZvcm1pbmcgRE5TLWJhc2VkDQpsb2NhbCBi YWxhbmNpbmcpLiBIb3dldmVyLCBhcyBmYXIgYXMgaXQgaXMgcG9zc2libGUsIHRoZSBXRyB3aWxs IG5vdA0KbWFrZSBkZXNpZ24gZGVjaXNpb25zIHRoYXQgY291bGQgcHJlY2x1ZGUgdGhlIHVzZSBv ZiBkaXN0cmlidXRlZA0KdHJhY2tlcnMgaW4gdGhlIGZ1dHVyZSAoZS5nLiwgREhULWJhc2VkIHRy YWNrZXJzKS4NCkEgcGVlciBsb29raW5nIGZvciBhIHBhcnRpY3VsYXIgbWVkaWEgc3RyZWFtIG1l ZGlhIGNodW5rU3VjaCBhIG1lZGlhIHN0cmVhbSBpcyB0cmFuc3BvcnRlZCBpbiBzby1jYWxsZWQg Y2h1bmtzLCB3aGVyZSBhIGNodW5rIGNvbnRhaW5zIHRoZSBwaWVjZXMgb2YgdGhlIG1lZGlhLg0K T2J0YWluaW5nIHRoZSBtZWRpYSBjaHVuayBmcm9tIHRoZSByZW1vdGUgcGVlciB3aWxsIGludm9s dmUgc29tZQ0KdHlwZSBvZiBzaWduYWxpbmcgZXhjaGFuZ2UsIGkuZS4sIHRoZSB0cmFja2VyIGFu ZCBwZWVyIHByb3RvY29scyB0bw0KbG9jYXRlIGEgcmVtb3RlIHBlZXIgKG9yIHBlZXJzKSBwbHVz IHRoZSBhY3R1YWwgbWVkaWEgdHJhbnNmZXIgb2YgdGhlIGNodW5rcy4gVGhlIGZpcnN0LCBtZWRp YSBzdHJlYW1tZWRpYQ0KY2h1bmsuIA0KdGFzayBmb3IgdGhpcyBXRyB3aWxsIGJlIHRvIGRlY2lk ZSB3aGljaCBzaWduYWxpbmcgYW5kIG1lZGlhIHRyYW5zZmVyDQpwcm90b2NvbHMgd2lsbCBiZSB1 c2VkVGhlIFdHIHdpbGwgd29yayBvbiB0aGUgcGVlciBhbmQgdHJhY2tlciBwcm90b2NvbCBhbmQg LiBUaGUgV0cgd2lsbCBjb25zaWRlciBleGlzdGluZyBwcm90b2NvbHMgYW5kLCBpZg0KbmVlZGVk LCBpZGVudGlmeSBwb3RlbnRpYWwgZXh0ZW5zaW9ucyB0byB0aGVzZSBwcm90b2NvbHMuIFRoZSBX RyB3aWxsDQpjb25zaWRlciB0aGUgaW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlc2UgcHJvdG9jb2xz IGFuZCB0aGUgcGVlciBwcm90b2NvbA0KKGUuZy4sIGF2b2lkaW5nIGR1cGxpY2F0ZSBOQVQgdHJh dmVyc2FsIHByb2NlZHVyZXMpLiBBbiBFZXhhbXBsZXMgb2YgYQ0Kc2lnbmFsaW5nIHByb3RvY29s cyB0byBiZSBjb25zaWRlcmVkIGFyZSBpc1NJUCwgUlRTUCwgYW5kIEhUVFAuIEV4YW1wbGVzDQpv ZiBtZWRpYSB0cmFuc2ZlciBwcm90b2NvbHMgbWVjaGFuaXNtc3RvIGJlIGNvbnNpZGVyZWQgYXJl IFVEUCwgYW5kVENQUlRQIGFuZCBIVFRQLg0KYW5kIHBvc3NpYmxlIGV4dGVuc2lvbiBvbiB0b3Ag b2YgdGhlbS4NClBQU1AgaXMgbm90IGNoYXJ0ZXJlZCB0byB3b3JrIG9uIG1lZGlhIHRyYW5zbWlz c2lvbiBwcm90b2NvbHMsIG1lZGlhDQplbmNvZGluZyB0ZWNobmlxdWVzIG9yIG90aGVyIGNvbXBv bmVudHMgb2YgYSBQMlAgc3RyZWFtaW5nIHN5c3RlbSBzdWNoDQphcyBwbGF5b3V0IGNvbnRyb2wg b3IsIHNjaGVkdWxpbmcgYW5kIGNvbnRyb2wsIGV0Yy4NClBQU1Agd2lsbCBleHBsb3JlIHRoZSBy ZWxhdGlvbnNoaXAgdG8gREVDQURFIGFuZCBBTFRPIHdvcmtpbmcgZ3JvdXBzLg0KVGhlIHdvcmsg aXRlbXMgb2YgdGhlIFBQU1AgV0cgYXJlOg0KKDEpIEEgInByb2JsZW0gc3RhdGVtZW50IiBhbmQg InJlcXVpcmVtZW50cyIgZG9jdW1lbnQuIFRoaXMgZG9jdW1lbnQgdGhhdCBnaXZlcyBhbiBvdmVy dmlldyBvZiB0aGUNCnByb3Bvc2VkIFAyUCBzdHJlYW1pbmcgc3lzdGVtLCBtb3RpdmF0ZXMgdGhl IGRlc2lyZSBmb3INCnN0YW5kYXJkaXplZCBwcm90b2NvbHMsIGRlZmluZXMgdGhlIGVudmlzaW9u ZWQgc2NvcGUgb2YgdGhvc2UNCnN0YW5kYXJkaXplZCBjb21wb25lbnRzIGFuZCBkaXNjdXNzZXMg Y29tbW9uIHRlcm1pbm9sb2dpZXMgYW5kDQpjb25jZXB0cy4gSXQgYWxzbyB0aGF0IGRldGFpbHMg dGhlIHNwZWNpZmljIGZ1bmN0aW9uYWwsDQpvcGVyYXRpb25hbCBhbmQgcGVyZm9ybWFuY2UgcmVx dWlyZW1lbnRzIG9mIHRoZSB0d28gUFBTUA0KcHJvdG9jb2xzLg0KKDIpIEEgInJlcXVpcmVtZW50 cyIgZG9jdW1lbnQgdGhhdCBkZXRhaWxzIHRoZSBzcGVjaWZpYyBmdW5jdGlvbmFsLA0Kb3BlcmF0 aW9uYWwgYW5kIHBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBvZiB0aGUgdHdvIFBQU1ANCnByb3Rv Y29scy4NCigzKSBBbiAiYXJjaGl0ZWN0dXJhbCBzdXJ2ZXkiIGRvY3VtZW50IHRoYXQgc3VtbWFy aXplcyBjdXJyZW50IFAyUA0Kc3RyZWFtaW5nIGFyY2hpdGVjdHVyZXMsIGluIHBhcnRpY3VsYXIg dHJhY2tlci1iYXNlZCBQMlANCnN0cmVhbWluZyBzeXN0ZW1zLCBhbmQgaGlnaGxpZ2h0cyBiZXN0 IGN1cnJlbnQgcHJhY3RpY2VzLCBhcyBpbnB1dCB0byB0aGUgZGVzaWduIG9mIHRoZSBwZWVyIGFu ZCB0cmFja2VyIHByb3RvY29scy4uDQooNCkgQSBkZXRhaWxlZCBzcGVjaWZpY2F0aW9uIG9mIHRo ZSBQUFNQIHBlZXIgcHJvdG9jb2wuDQooNSkgQSBkZXRhaWxlZCBzcGVjaWZpY2F0aW9uIG9mIHRo ZSBQUFNQIHRyYWNrZXIgcHJvdG9jb2wuDQooNikgQSBkZXRhaWxlZCBzcGVjaWZpY2F0aW9uIG9m IHRoZSBQUFNQIG1lZGlhIHRyYW5zcG9ydCBtZWNoYW5pc20uDQooNykgQSAidXNhZ2UgZ3VpZGUi IHRoYXQgZGVzY3JpYmVzIGhvdyB0aGUgdGhld28gUFBTUCBwcm90b2NvbHMgYW5kDQpleGlzdGlu ZyBJRVRGIHByb3RvY29scywgc3VjaCBhcyBQMlBTSVAsREVDQURFb3IgQUxUTywgY2FuIGJlIGNv bWJpbmVkDQp0byBjcmVhdGUgYSBkZXBsb3lhYmxlIG9wZXJhdGlvbmFsIFAyUCBzdHJlYW1pbmcg c3lzdGVtLiBUaGlzDQpkb2N1bWVudCBtYXkgYWxzbyBkaXNjdXNzIHZhcmlhbnRzIG9mIHN1Y2gg YSBzeXN0ZW0gdGhhdCwgZm9yDQpleGFtcGxlLCB1c2UgbGF5ZXJlZCBtZWRpYSBlbmNvZGluZyBh bmQgcmVsYXRlZCBtZWRpYSBjaHVuaw0KZGVzY3JpcHRpb25zIGluIHRoZSBwZWVyIHByb3RvY29s IGZvciBtb3JlIHJvYnVzdCBzdHJlYW1pbmcuDQooOCkgQSBpbXBsZW1lbnRhdGlvbiBhbmQgb3Bl cmF0aW9uYWwgZXhwZXJpZW5jZSBndWlkZSBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyB0aGUgcGVy Zm9ybWFuY2Ugb2YgdGhlIHByb3Bvc2VkIHByb3RvY29scyBhbmQgdXNhYmxlIHN5c3RlbXMuDQpU aGUgd29yayBpdGVtcyBvZiB0aGUgUFBTUCBXRyBpbnRlcmFjdHMgd2l0aCB0aGUgd29yayBwZXJm b3JtZWQgaW4gb3RoZXINCklFVEYgV0dzLCBpbmNsdWRpbmcgUDJQU0lQLCBTSVBDT1JFLCBBVlQs IEFMVE8sIExFREJBVCwgYW5kIERFQ0FERSBhbmQgTU1VU0lDLg0KV2hlbmV2ZXIgZXh0ZW5zaW9u cyBvciBtb2RpZmljYXRpb24gdG8gdGhlIHByb3RvY29scyBkZXZlbG9wZWQgaW4gb3RoZXINCldH cyBhcmUgZGVlbWVkIG5lY2Vzc2FyeSwgUFBTUCBzaGFsbCBjb21tdW5pY2F0ZSBhbmQgZGlzY3Vz cyB0aGUNCnJlcXVpcmVtZW50cyBmb3Igc3VjaCBleHRlbnNpb25zIHdpdGggdGhlIHJlbGV2YW50 IFdHcy4gUFBTUCBpcyBub3QNCmNoYXJ0ZXJlZCB0byBkZXNpZ24gYW5kIHNwZWNpZnkgc3VjaCBj aGFuZ2VzLg0KR29hbHMgYW5kIE1pbGVzdG9uZXMNCkRlYyAyMDExMFN1Ym1pdCBwcm9ibGVtIHN0 YXRlbWVudCB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwgDQpBcHIgMjAxMSAyMDEyU3VibWl0IHBy b2JsZW0gc3RhdGVtZW50IGFuZCByZXF1aXJlbWVudHNhcmNoaXRlY3R1cmFsIHN1cnZleSBkb2N1 bWVudHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbCANCkFwciAyMDExIDIwMTJTdWJtaXQgYXJjaGl0 ZWN0dXJhbCBzdXJ2ZXkgcmVxdWlyZW1lbnRzIGRvY3VtZW50IHRvIElFU0cgYXMgSW5mb3JtYXRp b25hbCANCkF1ZyBTZXAyMDEyMSBKYW4gMjAxM1N1Ym1pdCBQUFNQIHRyYWNrZXIgcGVlciBwcm90 b2NvbCB0byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJkIA0KQXVnIERlYzIwMTIxIEphbiAyMDEz U3VibWl0IFBQU1AgdHJhY2tlciBwZWVyIHByb3RvY29sIHRvIElFU0cgYXMgUHJvcG9zZWQgU3Rh bmRhcmQgDQpEZWMyMDExIFN1Ym1pdCB1c2FnZSBndWlkZSB0byBJRVNHIHRvIElFU0cgYXMgSW5m b3JtYXRpb25hbCANCg0KRGVjIDIwMTJKYW4gMjAxMyAgICBTdWJtaXQgUFBTUCBtZWRpYSB0cmFu c3BvcnQgbWVjaGFuaXNtIHRvIElFU0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQNCiANCkFwciAyMDEz ICAgIFN1Ym1pdCB1c2FnZSBndWlkZSB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwNCiANCkFwciAy MDEzICAgIFN1Ym1pdCBmaWVsZCB0ZXN0IHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbA0KIA0KIA0K DQoNCg0Kemhhbmd5dW5mZWk= ------=_001_NextPart411514585705_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Ning,
    Please see inline.
 
BR
Yunfei
 
zhangyunfei
 
From: ZongNing<= /DIV>
Date: 2012-02-21 16:33
To: zhangyunfei; ppsp
Subject: RE: [ppsp] PPSP Re-charter=20 discussion

Hi,

 

Regarding=20 =A1=B0 Inclusion of media transport mechanism into PPSP WG task=A1=B1, beca= use we haven=A1=AFt=20 got consensus on mandatory data transport mechanism yet, how do you intend = to=20 progress this item?

I=20 can see two ways, thus different milestone layout:

1)       = still=20 selecting at least one mandatory data transport mechanism and document it i= n=20 peer protocol draft.

2)       = produce=20 a list of best practice data transport mechanisms for PPSP usage and docume= nt=20 these in separate drafts (to peer protocol draft).
[Yunfei] I= would=20 prefer the second option, which makes every part of PPSP protocol suit= e=20 clear. But we may need some discussion in the PPSP usage document to make t= he=20 signaling and media transfer most efficient in the combined=20 usage.

 

BR,

Ning=20 Zong

From:<= /B>= =20 ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of=20 zhangyunfei
Sent: Sunday, February 19, 2012 11:59 PM
To= :=20 ppsp
Subject: [ppsp] PPSP Re-charter=20 discussion

 

= Hi=20 all,=

=   =20 Based on the discussions in Taipei meeting, Martin and I have drafted the=20 following re-charter text with the track change mode. The basic changes=20 include:

= 1) Inclusion=20 of media transport mechanism into PPSP WG task.

= 2)=20 Signaling protocol and media protocol candidates description=20 change;

= 3)=20 Document merger, submission deadline as well as new WG draft update in Goal= s and=20 milestones.

=    =20 Please review it and post your comments in the mailing list. We wish to get= =20 consensus in the mailing list before submitting to talk with the=20 AD.<= /P>

= P.S.:=20 We are exploring the possibility of having an interim meeting in the e= arly=20 of March, before next IETF. We'll start the poll of the time soon if we get= =20 positive feedback on the progress from the proposed peer and tracker protoc= ol=20 authors.

 

= BR

= Yunfei

=   =20

=    =20

 

= Description=20 of Working Group

= The=20 Peer-to-Peer Streaming Protocol (PPSP) working group develops two
signal= ing=20 and control protocols for a peer-to-peer (P2P) streaming
system for=20 transmitting live and time-shifted media content with near
real-time del= ivery=20 requirements.

= Two=20 kinds of nodes exist in the targeted P2P streaming system, i.e.,
"peers"= and=20 "trackers". Peers are nodes that are actively sending and
receiving stre= amed=20 media content, and include both statically connected
hosts as well as mo= bile=20 devices with connectivity and = IP=20 addresses that
change over time<= SPAN=20 class=3DmsoIns>,=20 as well as changed link characteristics <= INS=20 cite=3Dmailto:Martin%20Stiemerling dateTime=3D2012-01-11T11:29>for mobile=20 nodes= .
The set of peers that are=20 participating in a streaming
session will dynamically change over time. = Trackers are well-known nodes
with stable connectivity that maintain met= a=20 information about the
streamed content and the dynamic peer set<= SPAN=20 class=3DmsoIns>=20 involved in the streaming= .=20 Trackers can be organized in
centralized or distributed=20 ways.

= The=20 PPSP WG designs a protocol for signaling and control between
trackers an= d=20 peers (the PPSP "tracker protocol") and a signaling and
control protocol= for=20 communication among the peers (the PPSP "peer
protocol"). The two protoc= ols=20 enable peers to receive streaming data
within the time constraints requi= red=20 by specific content items. The
tracker protocol handles the initial and = periodic exchange of meta
information between trackers and peers, such a= s=20 peer lists and content
information. The peer protocol controls the=20 advertising and exchange of
media data availability between the=20 peers<= SPAN=20 class=3DmsoIns>,=20 as well as the exchange of streaming media= .

= It is=20 envisioned that the tracker protocol will be modeled as a
request/respon= se=20 protocol between peers and trackers, and will carry
information needed f= or=20 the selection of peers suitable for real-time
streaming. The peer protoc= ol is=20 envisioned to be modeled as a
gossip-like protocol with periodic, pairwi= se=20 exchanges of neighbor and
media chunk availability information. Both=20 protocols will be carried
over TCP (or UDP, when delivery requirements c= annot=20 be met by TCP),
likely in combination with ICE for NAT traversal support= .=20 Perfect
privacy protection is a good feature to have but not a=20 mandatory
requirement for the peer and tracker protocols. The WG will=20 consider to
use existing protocols as design base for the tracker and=20 peer
protocols.

= Developing=20 mechanisms for searching trackers that contain a specific
media item is = out=20 of the scope of this WG. Additionally, the WG will
work under the assump= tion=20 that trackers are logically centralized
entities (e.g., a single server = or a=20 server farm performing DNS-based
local balancing). However, as far as it= is=20 possible, the WG will not
make design decisions that could preclude the = use=20 of distributed
trackers in the future (e.g., DHT-based=20 trackers).

= A peer=20 looking for a <= SPAN=20 class=3DmsoIns>particular media stream=20 media chunk<= SPAN=20 class=3DmsoIns>Such a media stream is transported in so-called= =20 chunks, where a chunk contains the pieces of the=20 media.

Obtaining th= e=20 media chunk from the remote peer will involve some
type= of=20 signaling exchange, i.e., the tracker and peer protocols to
locate = a=20 remote peer (or peers) plus the=20 actual media transfer of the chunks. The first,=20 media=20 streammedia
chunk.=20
task for this WG will= be to=20 decide which signaling and media transfer
protocols will be usedThe WG will work on the peer and tracker protoc= ol and=20 . The WG=20 will consider existing protocols and, if
needed,= =20 identify potential extensions to these protocols.=20 The WG=20 will
consider the interact= ions=20 between these protocols and the peer protocol
(e.g., avoiding duplicate NAT traversal procedures).=20 An=20 <= SPAN=20 lang=3DEN-US style=3D"COLOR: red">Ee<= /SPAN>xamples of=20 a
signaling protocols to be considered=20 are is= SIP, RTSP, and=20 HTTP. Examples
of media transfer=20 protocols=20 mechanismsto be consid= ered are=20 UDP,<= /SPAN>=20 andTCPRTP and=20 HTTP.

= and <= SPAN=20 class=3DmsoIns>possible extension on top of=20 them.<= SPAN=20 class=3DmsoDel>

= PPSP is not chartered to work on=20 media=20 transmission protocols, = media
encoding techniques or other component= s of a=20 P2P streaming system such
as playout<= SPAN=20 class=3DmsoIns>=20 control or,= =20 scheduling and=20 control= ,=20 etc.

<= SPAN=20 class=3DmsoIns>PPSP will explore the relatio= nship to=20 DECADE and ALTO working=20 groups.

= The=20 work items of the PPSP WG are:

= (1) A=20 "problem statement" <= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: teal; FONT-FAMILY: 'Arial','sans-serif'"><= SPAN=20 class=3DmsoIns>and "requirements"=20 = document<= SPAN=20 class=3DmsoIns>.=20 This=20 document that=20 = gives an overview of the
p= roposed=20 P2P streaming system, motivates the desire for
standardized protocols,=20 defines the envisioned scope of those
standardized components and discus= ses=20 common terminologies and
concepts.<= SPAN=20 class=3DmsoIns> It also that details the specific=20 functional,<= SPAN=20 class=3DmsoIns>
operational and perfo= rmance=20 requirements of the two PPSP
protocols.

(2) A "requirements" document that details the = specific functional,
operational and perfo= rmance=20 requirements of the two PPSP
protocols.

= (3) An "architectural survey" document that sum= marizes=20 current P2P
streaming architectures, in particular tracker-based=20 P2P
streaming systems, and highlights best current=20 practices<= SPAN=20 class=3DmsoIns>, as input t= o the=20 design of the peer and tracker=20 protocols..

= (4) A detailed specification of the PPSP peer=20 protocol.

= (5) A detailed specification of the PPSP tracke= r=20 protocol.

= (6) <= SPAN=20 class=3DmsoIns>A detailed specification of the PPSP media=20 transport mechanism= .<= SPAN=20 lang=3DEN-US style=3D"COLOR: teal">

<= SPAN=20 class=3DmsoIns>(7)=20 = A "usage guide" that describes how the=20 t<= SPAN=20 class=3DmsoIns>he= wo= PPSP protoc= ols=20 and
existing IETF protocols, such as=20 P2PSIP,<= SPAN=20 class=3DmsoIns>DECADE= or ALTO, can= be=20 combined
to create a deployable operational P2P streaming system.=20 This
document may also discuss variants of such a system that,=20 for
example, use layered media encoding and related media=20 chunk
descriptions in the peer protocol for more robust streaming.

<= SPAN=20 class=3DmsoIns>(8) A=20 <= SPAN=20 lang=3DEN-US style=3D"COLOR: teal; FONT-FAMILY: 'Calibri','sans-serif'">implementation and operational experience guide= =20 <= SPAN=20 lang=3DEN-US=20 style=3D"FONT-SIZE: 10pt; COLOR: teal; FONT-FAMILY: 'Arial','sans-serif'"><= SPAN=20 class=3DmsoIns>document tha= t=20 describes the performance of the proposed protocols and usable=20 systems.=

= The work ite= ms of the=20 PPSP WG interacts with the work performed in other
IETF WGs, including=20 P2PSIP, SIPCORE,=20 AVT= , ALTO, LEDBAT<= SPAN=20 class=3Dmsoins0><= SPAN=20 class=3DmsoIns>,<= /S><= SPAN=20 class=3DmsoIns> and=20 DECADE and=20 MMUSIC= .
Whenever extensions or modification to the= =20 protocols developed in other
WGs are deemed necessary, PPSP shall commun= icate=20 and discuss the
requirements for such extensions with the relevant WGs. = PPSP=20 is not
chartered to design and specify such=20 changes.

= Goals=20 and Milestones

Dec=20 20110

Submit=20 problem statement to IESG as Informational=20

Apr=20 201= 1=20 2012

Submit problem statement and requirementsarc= hitectural=20 survey documentto=20 IESG as Informational

Apr=20 201= 1=20 2012

Submit=20 arc= hitectural=20 survey req= uirements=20 document=20 to IESG as Informational

Aug= =20 Sep2012= 1 Jan 2013

Submit=20 PPSP tra= cker=20 pee= r=20 protocol=20 to IESG as Proposed Standard

Aug= =20 Dec2012= 1 Jan 2013

Submit=20 PPSP=20 tracker=20 peer=20 protocol to IESG as Proposed Standard

Dec= 2011=20

Sub= mit usage=20 guide to IESG to IESG as Informational

Dec=20 2012<= SPAN=20 class=3DmsoIns>Jan=20 2013    Submit PPSP media transport = mechanism to IESG as Proposed=20 Standard

=  

<= SPAN=20 class=3DmsoIns>Apr 2013    Submi= t usage=20 guide to IESG as=20 Informational

=  

<= SPAN=20 class=3DmsoIns>Apr 2013    Su= bmit=20 field test to IESG as=20 Informational

 

 

zhangyunfei=

------=_001_NextPart411514585705_=------ From zhangyunfei@chinamobile.com Tue Feb 21 19:30:21 2012 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 D4DD521E8024 for ; Tue, 21 Feb 2012 19:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.412 X-Spam-Level: X-Spam-Status: No, score=-97.412 tagged_above=-999 required=5 tests=[AWL=1.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 JcerwNCu+Q0a for ; Tue, 21 Feb 2012 19:30:20 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AAAD721E800F for ; Tue, 21 Feb 2012 19:30:09 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 90705E51E; Wed, 22 Feb 2012 11:30:08 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 7162BE51C; Wed, 22 Feb 2012 11:30:08 +0800 (CST) Received: from pc917 ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012022211295591-8632 ; Wed, 22 Feb 2012 11:29:55 +0800 Date: Wed, 22 Feb 2012 11:29:47 +0800 From: zhangyunfei To: "Riccardo Bernardini" , ppsp References: <2012021923584463860669@chinamobile.com> , <20120221102550.13522kalk6qvny1q@webmail.uniud.it> X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <2012022211294770344911@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-22 11:30:05, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-22 11:30:07, Serialize complete at 2012-02-22 11:30:07 Content-Type: multipart/alternative; boundary="----=_001_NextPart855258147441_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18724.004 X-TM-AS-Result: No--30.898-7.0-31-10 X-imss-scan-details: No--30.898-7.0-31-10;No--30.898-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: Re: [ppsp] PPSP Re-charter discussion X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei 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, 22 Feb 2012 03:30:21 -0000 This is a multi-part message in MIME format. ------=_001_NextPart855258147441_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312" SGkgUmljY2FyZG8sDQogICAgUGxlYXNlIHNlZSBpbmxpbmUuDQoNCkJSDQpZdW5mZWkNCg0KDQoN Cg0Kemhhbmd5dW5mZWkNCg0KRnJvbTogUmljY2FyZG8gQmVybmFyZGluaQ0KRGF0ZTogMjAxMi0w Mi0yMSAxNzoyNQ0KVG86IHBwc3ANClN1YmplY3Q6IFJlOiBbcHBzcF0gUFBTUCBSZS1jaGFydGVy IGRpc2N1c3Npb24NClpvbmdOaW5nIDx6b25nbmluZ0BodWF3ZWkuY29tPiBoYSBzY3JpdHRvOg0K DQo+IEhpLA0KPg0KPiBSZWdhcmRpbmcgIiBJbmNsdXNpb24gb2YgbWVkaWEgdHJhbnNwb3J0IG1l Y2hhbmlzbSBpbnRvIFBQU1AgV0cgIA0KPiB0YXNrIiwgYmVjYXVzZSB3ZSBoYXZlbid0IGdvdCBj b25zZW5zdXMgb24gbWFuZGF0b3J5IGRhdGEgdHJhbnNwb3J0ICANCj4gbWVjaGFuaXNtIHlldCwg aG93IGRvIHlvdSBpbnRlbmQgdG8gcHJvZ3Jlc3MgdGhpcyBpdGVtPw0KPiBJIGNhbiBzZWUgdHdv IHdheXMsIHRodXMgZGlmZmVyZW50IG1pbGVzdG9uZSBsYXlvdXQ6DQo+DQo+IDEpICAgICAgIHN0 aWxsIHNlbGVjdGluZyBhdCBsZWFzdCBvbmUgbWFuZGF0b3J5IGRhdGEgdHJhbnNwb3J0ICANCj4g bWVjaGFuaXNtIGFuZCBkb2N1bWVudCBpdCBpbiBwZWVyIHByb3RvY29sIGRyYWZ0Lg0KPg0KPiAy KSAgICAgICBwcm9kdWNlIGEgbGlzdCBvZiBiZXN0IHByYWN0aWNlIGRhdGEgdHJhbnNwb3J0IG1l Y2hhbmlzbXMgIA0KPiBmb3IgUFBTUCB1c2FnZSBhbmQgZG9jdW1lbnQgdGhlc2UgaW4gc2VwYXJh dGUgZHJhZnRzICh0byBwZWVyICANCj4gcHJvdG9jb2wgZHJhZnQpLg0KDQoNCkkgbGlrZSB0aGlz IGFwcHJvYWNoLCBidXQgSSB3b3VsZCByZXZlcnNlIHRoZSBvcmRlciBvZiBtaWxlc3RvbmVzLCAg DQp0aGF0IGlzLCBmaXJzdCBmaXggd2hhdCB3ZSBuZWVkIGZyb20gdGhlIG1lZGlhIHRyYW5zcG9y dCBwcm90b2NvbCBhbmQgIA0KdGhlIGludGVyZmFjZSB0aGF0IHRoZSB0cmFuc3BvcnQgcHJvdG9j b2wgbXVzdCBleHBvc2UsIHRoZW4gb24gdGhlIHRvcCAgDQpvZiB0aGF0IHNwZWNpZmljYXRpb24g ZGVmaW5lIG9uZSAob3IgbW9yZSkgImRlZmF1bHQiIChhbmQgbWFuZGF0b3J5IHRvICANCmltcGxl bWVudCkgdHJhbnNwb3J0IHByb3RvY29sKHMpLiAgKEFjdHVhbGx5LCBJIGV4cGVjdCB0aGUgZGV2 ZWxvcG1lbnQgIA0Kb2YgdGhlIHR3byBzcGVjcyB0byBwcm9jZWVkIGluIHBhcmFsbGVsLCB3aXRo IGludGVyYWN0aW9ucykuDQoNCltZdW5mZWldIEdvb2QgcHJvcG9zYWwuIEkgdGhpbmsgdGhpcyBp cyBhIGZlYXNpYmxlIGFwcHJvYWNoIHRvIHN0YXJ0IHRoZSB3b3JrLg0KDQpCVFcsIG1pbm9yIHR5 cG86ICBtYXliZSBpbg0KDQogICAiQSBwZWVyIGxvb2tpbmcgZm9yIGEgcGFydGljdWxhciBtZWRp YSBzdHJlYW0iDQoNCmlzIGFuICJpcyIgbWlzc2luZz8NCiAgW1l1bmZlaV0gSXQgc2hvdWxkIGJl ICJBIHBlZXIgbG9va3MgZm9yIGEgcGFydGljdWxhciBtZWRpYSBzdHJlYW0gZmlyc3QgaW4gdmll d2luZyB0aGUgcHJvZ3JhbSIuIA0KDQpSZWdhcmRzLA0KUmljY2FyZG8NCg0KPg0KPiBCUiwNCj4g TmluZyBab25nDQo+IEZyb206IHBwc3AtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBwc3AtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmICANCj4gT2Ygemhhbmd5dW5mZWkNCj4gU2VudDogU3Vu ZGF5LCBGZWJydWFyeSAxOSwgMjAxMiAxMTo1OSBQTQ0KPiBUbzogcHBzcA0KPiBTdWJqZWN0OiBb cHBzcF0gUFBTUCBSZS1jaGFydGVyIGRpc2N1c3Npb24NCj4NCj4gSGkgYWxsLA0KPiAgICBCYXNl ZCBvbiB0aGUgZGlzY3Vzc2lvbnMgaW4gVGFpcGVpIG1lZXRpbmcsIE1hcnRpbiBhbmQgSSBoYXZl ICANCj4gZHJhZnRlZCB0aGUgZm9sbG93aW5nIHJlLWNoYXJ0ZXIgdGV4dCB3aXRoIHRoZSB0cmFj ayBjaGFuZ2UgbW9kZS4gIA0KPiBUaGUgYmFzaWMgY2hhbmdlcyBpbmNsdWRlOg0KPiAxKSBJbmNs dXNpb24gb2YgbWVkaWEgdHJhbnNwb3J0IG1lY2hhbmlzbSBpbnRvIFBQU1AgV0cgdGFzay4NCj4g MikgU2lnbmFsaW5nIHByb3RvY29sIGFuZCBtZWRpYSBwcm90b2NvbCBjYW5kaWRhdGVzIGRlc2Ny aXB0aW9uIGNoYW5nZTsNCj4gMykgRG9jdW1lbnQgbWVyZ2VyLCBzdWJtaXNzaW9uIGRlYWRsaW5l IGFzIHdlbGwgYXMgbmV3IFdHIGRyYWZ0ICANCj4gdXBkYXRlIGluIEdvYWxzIGFuZCBtaWxlc3Rv bmVzLg0KPiAgICAgUGxlYXNlIHJldmlldyBpdCBhbmQgcG9zdCB5b3VyIGNvbW1lbnRzIGluIHRo ZSBtYWlsaW5nIGxpc3QuIFdlICANCj4gd2lzaCB0byBnZXQgY29uc2Vuc3VzIGluIHRoZSBtYWls aW5nIGxpc3QgYmVmb3JlIHN1Ym1pdHRpbmcgdG8gdGFsayAgDQo+IHdpdGggdGhlIEFELg0KPiBQ LlMuOiBXZSBhcmUgZXhwbG9yaW5nIHRoZSBwb3NzaWJpbGl0eSBvZiBoYXZpbmcgYW4gaW50ZXJp bSBtZWV0aW5nICANCj4gaW4gdGhlIGVhcmx5IG9mIE1hcmNoLCBiZWZvcmUgbmV4dCBJRVRGLiBX ZSdsbCBzdGFydCB0aGUgcG9sbCBvZiB0aGUgIA0KPiB0aW1lIHNvb24gaWYgd2UgZ2V0IHBvc2l0 aXZlIGZlZWRiYWNrIG9uIHRoZSBwcm9ncmVzcyBmcm9tIHRoZSAgDQo+IHByb3Bvc2VkIHBlZXIg YW5kIHRyYWNrZXIgcHJvdG9jb2wgYXV0aG9ycy4NCj4NCj4gQlINCj4gWXVuZmVpDQo+DQo+DQo+ DQo+IERlc2NyaXB0aW9uIG9mIFdvcmtpbmcgR3JvdXANCj4gVGhlIFBlZXItdG8tUGVlciBTdHJl YW1pbmcgUHJvdG9jb2wgKFBQU1ApIHdvcmtpbmcgZ3JvdXAgZGV2ZWxvcHMgdHdvDQo+IHNpZ25h bGluZyBhbmQgY29udHJvbCBwcm90b2NvbHMgZm9yIGEgcGVlci10by1wZWVyIChQMlApIHN0cmVh bWluZw0KPiBzeXN0ZW0gZm9yIHRyYW5zbWl0dGluZyBsaXZlIGFuZCB0aW1lLXNoaWZ0ZWQgbWVk aWEgY29udGVudCB3aXRoIG5lYXINCj4gcmVhbC10aW1lIGRlbGl2ZXJ5IHJlcXVpcmVtZW50cy4N Cj4gVHdvIGtpbmRzIG9mIG5vZGVzIGV4aXN0IGluIHRoZSB0YXJnZXRlZCBQMlAgc3RyZWFtaW5n IHN5c3RlbSwgaS5lLiwNCj4gInBlZXJzIiBhbmQgInRyYWNrZXJzIi4gUGVlcnMgYXJlIG5vZGVz IHRoYXQgYXJlIGFjdGl2ZWx5IHNlbmRpbmcgYW5kDQo+IHJlY2VpdmluZyBzdHJlYW1lZCBtZWRp YSBjb250ZW50LCBhbmQgaW5jbHVkZSBib3RoIHN0YXRpY2FsbHkgY29ubmVjdGVkDQo+IGhvc3Rz IGFzIHdlbGwgYXMgbW9iaWxlIGRldmljZXMgd2l0aCBjb25uZWN0aXZpdHkgYW5kIElQIGFkZHJl c3NlcyB0aGF0DQo+IGNoYW5nZSBvdmVyIHRpbWUsIGFzIHdlbGwgYXMgY2hhbmdlZCBsaW5rIGNo YXJhY3RlcmlzdGljcyBmb3IgbW9iaWxlIG5vZGVzLg0KPiBUaGUgc2V0IG9mIHBlZXJzIHRoYXQg YXJlIHBhcnRpY2lwYXRpbmcgaW4gYSBzdHJlYW1pbmcNCj4gc2Vzc2lvbiB3aWxsIGR5bmFtaWNh bGx5IGNoYW5nZSBvdmVyIHRpbWUuIFRyYWNrZXJzIGFyZSB3ZWxsLWtub3duIG5vZGVzDQo+IHdp dGggc3RhYmxlIGNvbm5lY3Rpdml0eSB0aGF0IG1haW50YWluIG1ldGEgaW5mb3JtYXRpb24gYWJv dXQgdGhlDQo+IHN0cmVhbWVkIGNvbnRlbnQgYW5kIHRoZSBkeW5hbWljIHBlZXIgc2V0IGludm9s dmVkIGluIHRoZSBzdHJlYW1pbmcuICANCj4gVHJhY2tlcnMgY2FuIGJlIG9yZ2FuaXplZCBpbg0K PiBjZW50cmFsaXplZCBvciBkaXN0cmlidXRlZCB3YXlzLg0KPiBUaGUgUFBTUCBXRyBkZXNpZ25z IGEgcHJvdG9jb2wgZm9yIHNpZ25hbGluZyBhbmQgY29udHJvbCBiZXR3ZWVuDQo+IHRyYWNrZXJz IGFuZCBwZWVycyAodGhlIFBQU1AgInRyYWNrZXIgcHJvdG9jb2wiKSBhbmQgYSBzaWduYWxpbmcg YW5kDQo+IGNvbnRyb2wgcHJvdG9jb2wgZm9yIGNvbW11bmljYXRpb24gYW1vbmcgdGhlIHBlZXJz ICh0aGUgUFBTUCAicGVlcg0KPiBwcm90b2NvbCIpLiBUaGUgdHdvIHByb3RvY29scyBlbmFibGUg cGVlcnMgdG8gcmVjZWl2ZSBzdHJlYW1pbmcgZGF0YQ0KPiB3aXRoaW4gdGhlIHRpbWUgY29uc3Ry YWludHMgcmVxdWlyZWQgYnkgc3BlY2lmaWMgY29udGVudCBpdGVtcy4gVGhlDQo+IHRyYWNrZXIg cHJvdG9jb2wgaGFuZGxlcyB0aGUgaW5pdGlhbCBhbmQgcGVyaW9kaWMgZXhjaGFuZ2Ugb2YgbWV0 YQ0KPiBpbmZvcm1hdGlvbiBiZXR3ZWVuIHRyYWNrZXJzIGFuZCBwZWVycywgc3VjaCBhcyBwZWVy IGxpc3RzIGFuZCBjb250ZW50DQo+IGluZm9ybWF0aW9uLiBUaGUgcGVlciBwcm90b2NvbCBjb250 cm9scyB0aGUgYWR2ZXJ0aXNpbmcgYW5kIGV4Y2hhbmdlIG9mDQo+IG1lZGlhIGRhdGEgYXZhaWxh YmlsaXR5IGJldHdlZW4gdGhlIHBlZXJzLCBhcyB3ZWxsIGFzIHRoZSBleGNoYW5nZSAgDQo+IG9m IHN0cmVhbWluZyBtZWRpYS4NCj4gSXQgaXMgZW52aXNpb25lZCB0aGF0IHRoZSB0cmFja2VyIHBy b3RvY29sIHdpbGwgYmUgbW9kZWxlZCBhcyBhDQo+IHJlcXVlc3QvcmVzcG9uc2UgcHJvdG9jb2wg YmV0d2VlbiBwZWVycyBhbmQgdHJhY2tlcnMsIGFuZCB3aWxsIGNhcnJ5DQo+IGluZm9ybWF0aW9u IG5lZWRlZCBmb3IgdGhlIHNlbGVjdGlvbiBvZiBwZWVycyBzdWl0YWJsZSBmb3IgcmVhbC10aW1l DQo+IHN0cmVhbWluZy4gVGhlIHBlZXIgcHJvdG9jb2wgaXMgZW52aXNpb25lZCB0byBiZSBtb2Rl bGVkIGFzIGENCj4gZ29zc2lwLWxpa2UgcHJvdG9jb2wgd2l0aCBwZXJpb2RpYywgcGFpcndpc2Ug ZXhjaGFuZ2VzIG9mIG5laWdoYm9yIGFuZA0KPiBtZWRpYSBjaHVuayBhdmFpbGFiaWxpdHkgaW5m b3JtYXRpb24uIEJvdGggcHJvdG9jb2xzIHdpbGwgYmUgY2FycmllZA0KPiBvdmVyIFRDUCAob3Ig VURQLCB3aGVuIGRlbGl2ZXJ5IHJlcXVpcmVtZW50cyBjYW5ub3QgYmUgbWV0IGJ5IFRDUCksDQo+ IGxpa2VseSBpbiBjb21iaW5hdGlvbiB3aXRoIElDRSBmb3IgTkFUIHRyYXZlcnNhbCBzdXBwb3J0 LiBQZXJmZWN0DQo+IHByaXZhY3kgcHJvdGVjdGlvbiBpcyBhIGdvb2QgZmVhdHVyZSB0byBoYXZl IGJ1dCBub3QgYSBtYW5kYXRvcnkNCj4gcmVxdWlyZW1lbnQgZm9yIHRoZSBwZWVyIGFuZCB0cmFj a2VyIHByb3RvY29scy4gVGhlIFdHIHdpbGwgY29uc2lkZXIgdG8NCj4gdXNlIGV4aXN0aW5nIHBy b3RvY29scyBhcyBkZXNpZ24gYmFzZSBmb3IgdGhlIHRyYWNrZXIgYW5kIHBlZXINCj4gcHJvdG9j b2xzLg0KPiBEZXZlbG9waW5nIG1lY2hhbmlzbXMgZm9yIHNlYXJjaGluZyB0cmFja2VycyB0aGF0 IGNvbnRhaW4gYSBzcGVjaWZpYw0KPiBtZWRpYSBpdGVtIGlzIG91dCBvZiB0aGUgc2NvcGUgb2Yg dGhpcyBXRy4gQWRkaXRpb25hbGx5LCB0aGUgV0cgd2lsbA0KPiB3b3JrIHVuZGVyIHRoZSBhc3N1 bXB0aW9uIHRoYXQgdHJhY2tlcnMgYXJlIGxvZ2ljYWxseSBjZW50cmFsaXplZA0KPiBlbnRpdGll cyAoZS5nLiwgYSBzaW5nbGUgc2VydmVyIG9yIGEgc2VydmVyIGZhcm0gcGVyZm9ybWluZyBETlMt YmFzZWQNCj4gbG9jYWwgYmFsYW5jaW5nKS4gSG93ZXZlciwgYXMgZmFyIGFzIGl0IGlzIHBvc3Np YmxlLCB0aGUgV0cgd2lsbCBub3QNCj4gbWFrZSBkZXNpZ24gZGVjaXNpb25zIHRoYXQgY291bGQg cHJlY2x1ZGUgdGhlIHVzZSBvZiBkaXN0cmlidXRlZA0KPiB0cmFja2VycyBpbiB0aGUgZnV0dXJl IChlLmcuLCBESFQtYmFzZWQgdHJhY2tlcnMpLg0KPiBBIHBlZXIgbG9va2luZyBmb3IgYSBwYXJ0 aWN1bGFyIG1lZGlhIHN0cmVhbSBtZWRpYSBjaHVua1N1Y2ggYSBtZWRpYSAgDQo+IHN0cmVhbSBp cyB0cmFuc3BvcnRlZCBpbiBzby1jYWxsZWQgY2h1bmtzLCB3aGVyZSBhIGNodW5rIGNvbnRhaW5z ICANCj4gdGhlIHBpZWNlcyBvZiB0aGUgbWVkaWEuDQo+IE9idGFpbmluZyB0aGUgbWVkaWEgY2h1 bmsgZnJvbSB0aGUgcmVtb3RlIHBlZXIgd2lsbCBpbnZvbHZlIHNvbWUNCj4gdHlwZSBvZiBzaWdu YWxpbmcgZXhjaGFuZ2UsIGkuZS4sIHRoZSB0cmFja2VyIGFuZCBwZWVyIHByb3RvY29scyB0bw0K PiBsb2NhdGUgYSByZW1vdGUgcGVlciAob3IgcGVlcnMpIHBsdXMgdGhlIGFjdHVhbCBtZWRpYSB0 cmFuc2ZlciBvZiAgDQo+IHRoZSBjaHVua3MuIFRoZSBmaXJzdCwgbWVkaWEgc3RyZWFtbWVkaWEN Cj4gY2h1bmsuDQo+IHRhc2sgZm9yIHRoaXMgV0cgd2lsbCBiZSB0byBkZWNpZGUgd2hpY2ggc2ln bmFsaW5nIGFuZCBtZWRpYSB0cmFuc2Zlcg0KPiBwcm90b2NvbHMgd2lsbCBiZSB1c2VkVGhlIFdH IHdpbGwgd29yayBvbiB0aGUgcGVlciBhbmQgdHJhY2tlciAgDQo+IHByb3RvY29sIGFuZCAuIFRo ZSBXRyB3aWxsIGNvbnNpZGVyIGV4aXN0aW5nIHByb3RvY29scyBhbmQsIGlmDQo+IG5lZWRlZCwg aWRlbnRpZnkgcG90ZW50aWFsIGV4dGVuc2lvbnMgdG8gdGhlc2UgcHJvdG9jb2xzLiBUaGUgV0cg d2lsbA0KPiBjb25zaWRlciB0aGUgaW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlc2UgcHJvdG9jb2xz IGFuZCB0aGUgcGVlciBwcm90b2NvbA0KPiAoZS5nLiwgYXZvaWRpbmcgZHVwbGljYXRlIE5BVCB0 cmF2ZXJzYWwgcHJvY2VkdXJlcykuIEFuIEVleGFtcGxlcyBvZiBhDQo+IHNpZ25hbGluZyBwcm90 b2NvbHMgdG8gYmUgY29uc2lkZXJlZCBhcmUgaXNTSVAsIFJUU1AsIGFuZCBIVFRQLiBFeGFtcGxl cw0KPiBvZiBtZWRpYSB0cmFuc2ZlciBwcm90b2NvbHMgbWVjaGFuaXNtc3RvIGJlIGNvbnNpZGVy ZWQgYXJlIFVEUCwgIA0KPiBhbmRUQ1BSVFAgYW5kIEhUVFAuDQo+IGFuZCBwb3NzaWJsZSBleHRl bnNpb24gb24gdG9wIG9mIHRoZW0uDQo+IFBQU1AgaXMgbm90IGNoYXJ0ZXJlZCB0byB3b3JrIG9u IG1lZGlhIHRyYW5zbWlzc2lvbiBwcm90b2NvbHMsIG1lZGlhDQo+IGVuY29kaW5nIHRlY2huaXF1 ZXMgb3Igb3RoZXIgY29tcG9uZW50cyBvZiBhIFAyUCBzdHJlYW1pbmcgc3lzdGVtIHN1Y2gNCj4g YXMgcGxheW91dCBjb250cm9sIG9yLCBzY2hlZHVsaW5nIGFuZCBjb250cm9sLCBldGMuDQo+IFBQ U1Agd2lsbCBleHBsb3JlIHRoZSByZWxhdGlvbnNoaXAgdG8gREVDQURFIGFuZCBBTFRPIHdvcmtp bmcgZ3JvdXBzLg0KPiBUaGUgd29yayBpdGVtcyBvZiB0aGUgUFBTUCBXRyBhcmU6DQo+ICgxKSBB ICJwcm9ibGVtIHN0YXRlbWVudCIgYW5kICJyZXF1aXJlbWVudHMiIGRvY3VtZW50LiBUaGlzIGRv Y3VtZW50ICANCj4gdGhhdCBnaXZlcyBhbiBvdmVydmlldyBvZiB0aGUNCj4gcHJvcG9zZWQgUDJQ IHN0cmVhbWluZyBzeXN0ZW0sIG1vdGl2YXRlcyB0aGUgZGVzaXJlIGZvcg0KPiBzdGFuZGFyZGl6 ZWQgcHJvdG9jb2xzLCBkZWZpbmVzIHRoZSBlbnZpc2lvbmVkIHNjb3BlIG9mIHRob3NlDQo+IHN0 YW5kYXJkaXplZCBjb21wb25lbnRzIGFuZCBkaXNjdXNzZXMgY29tbW9uIHRlcm1pbm9sb2dpZXMg YW5kDQo+IGNvbmNlcHRzLiBJdCBhbHNvIHRoYXQgZGV0YWlscyB0aGUgc3BlY2lmaWMgZnVuY3Rp b25hbCwNCj4gb3BlcmF0aW9uYWwgYW5kIHBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBvZiB0aGUg dHdvIFBQU1ANCj4gcHJvdG9jb2xzLg0KPiAoMikgQSAicmVxdWlyZW1lbnRzIiBkb2N1bWVudCB0 aGF0IGRldGFpbHMgdGhlIHNwZWNpZmljIGZ1bmN0aW9uYWwsDQo+IG9wZXJhdGlvbmFsIGFuZCBw ZXJmb3JtYW5jZSByZXF1aXJlbWVudHMgb2YgdGhlIHR3byBQUFNQDQo+IHByb3RvY29scy4NCj4g KDMpIEFuICJhcmNoaXRlY3R1cmFsIHN1cnZleSIgZG9jdW1lbnQgdGhhdCBzdW1tYXJpemVzIGN1 cnJlbnQgUDJQDQo+IHN0cmVhbWluZyBhcmNoaXRlY3R1cmVzLCBpbiBwYXJ0aWN1bGFyIHRyYWNr ZXItYmFzZWQgUDJQDQo+IHN0cmVhbWluZyBzeXN0ZW1zLCBhbmQgaGlnaGxpZ2h0cyBiZXN0IGN1 cnJlbnQgcHJhY3RpY2VzLCBhcyBpbnB1dCAgDQo+IHRvIHRoZSBkZXNpZ24gb2YgdGhlIHBlZXIg YW5kIHRyYWNrZXIgcHJvdG9jb2xzLi4NCj4gKDQpIEEgZGV0YWlsZWQgc3BlY2lmaWNhdGlvbiBv ZiB0aGUgUFBTUCBwZWVyIHByb3RvY29sLg0KPiAoNSkgQSBkZXRhaWxlZCBzcGVjaWZpY2F0aW9u IG9mIHRoZSBQUFNQIHRyYWNrZXIgcHJvdG9jb2wuDQo+ICg2KSBBIGRldGFpbGVkIHNwZWNpZmlj YXRpb24gb2YgdGhlIFBQU1AgbWVkaWEgdHJhbnNwb3J0IG1lY2hhbmlzbS4NCj4gKDcpIEEgInVz YWdlIGd1aWRlIiB0aGF0IGRlc2NyaWJlcyBob3cgdGhlIHRoZXdvIFBQU1AgcHJvdG9jb2xzIGFu ZA0KPiBleGlzdGluZyBJRVRGIHByb3RvY29scywgc3VjaCBhcyBQMlBTSVAsREVDQURFb3IgQUxU TywgY2FuIGJlIGNvbWJpbmVkDQo+IHRvIGNyZWF0ZSBhIGRlcGxveWFibGUgb3BlcmF0aW9uYWwg UDJQIHN0cmVhbWluZyBzeXN0ZW0uIFRoaXMNCj4gZG9jdW1lbnQgbWF5IGFsc28gZGlzY3VzcyB2 YXJpYW50cyBvZiBzdWNoIGEgc3lzdGVtIHRoYXQsIGZvcg0KPiBleGFtcGxlLCB1c2UgbGF5ZXJl ZCBtZWRpYSBlbmNvZGluZyBhbmQgcmVsYXRlZCBtZWRpYSBjaHVuaw0KPiBkZXNjcmlwdGlvbnMg aW4gdGhlIHBlZXIgcHJvdG9jb2wgZm9yIG1vcmUgcm9idXN0IHN0cmVhbWluZy4NCj4gKDgpIEEg aW1wbGVtZW50YXRpb24gYW5kIG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UgZ3VpZGUgZG9jdW1lbnQg dGhhdCAgDQo+IGRlc2NyaWJlcyB0aGUgcGVyZm9ybWFuY2Ugb2YgdGhlIHByb3Bvc2VkIHByb3Rv Y29scyBhbmQgdXNhYmxlICANCj4gc3lzdGVtcy4NCj4gVGhlIHdvcmsgaXRlbXMgb2YgdGhlIFBQ U1AgV0cgaW50ZXJhY3RzIHdpdGggdGhlIHdvcmsgcGVyZm9ybWVkIGluIG90aGVyDQo+IElFVEYg V0dzLCBpbmNsdWRpbmcgUDJQU0lQLCBTSVBDT1JFLCBBVlQsIEFMVE8sIExFREJBVCwgYW5kIERF Q0FERSAgDQo+IGFuZCBNTVVTSUMuDQo+IFdoZW5ldmVyIGV4dGVuc2lvbnMgb3IgbW9kaWZpY2F0 aW9uIHRvIHRoZSBwcm90b2NvbHMgZGV2ZWxvcGVkIGluIG90aGVyDQo+IFdHcyBhcmUgZGVlbWVk IG5lY2Vzc2FyeSwgUFBTUCBzaGFsbCBjb21tdW5pY2F0ZSBhbmQgZGlzY3VzcyB0aGUNCj4gcmVx dWlyZW1lbnRzIGZvciBzdWNoIGV4dGVuc2lvbnMgd2l0aCB0aGUgcmVsZXZhbnQgV0dzLiBQUFNQ IGlzIG5vdA0KPiBjaGFydGVyZWQgdG8gZGVzaWduIGFuZCBzcGVjaWZ5IHN1Y2ggY2hhbmdlcy4N Cj4gR29hbHMgYW5kIE1pbGVzdG9uZXMNCj4gRGVjIDIwMTEwDQo+DQo+IFN1Ym1pdCBwcm9ibGVt IHN0YXRlbWVudCB0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwNCj4NCj4gQXByIDIwMTEgMjAxMg0K Pg0KPiBTdWJtaXQgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHJlcXVpcmVtZW50c2FyY2hpdGVjdHVy YWwgc3VydmV5ICANCj4gZG9jdW1lbnR0byBJRVNHIGFzIEluZm9ybWF0aW9uYWwNCj4NCj4gQXBy IDIwMTEgMjAxMg0KPg0KPiBTdWJtaXQgYXJjaGl0ZWN0dXJhbCBzdXJ2ZXkgcmVxdWlyZW1lbnRz IGRvY3VtZW50IHRvIElFU0cgYXMgSW5mb3JtYXRpb25hbA0KPg0KPiBBdWcgU2VwMjAxMjEgSmFu IDIwMTMNCj4NCj4gU3VibWl0IFBQU1AgdHJhY2tlciBwZWVyIHByb3RvY29sIHRvIElFU0cgYXMg UHJvcG9zZWQgU3RhbmRhcmQNCj4NCj4gQXVnIERlYzIwMTIxIEphbiAyMDEzDQo+DQo+IFN1Ym1p dCBQUFNQIHRyYWNrZXIgcGVlciBwcm90b2NvbCB0byBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJk DQo+DQo+IERlYzIwMTENCj4NCj4gU3VibWl0IHVzYWdlIGd1aWRlIHRvIElFU0cgdG8gSUVTRyBh cyBJbmZvcm1hdGlvbmFsDQo+DQo+IERlYyAyMDEySmFuIDIwMTMgICAgU3VibWl0IFBQU1AgbWVk aWEgdHJhbnNwb3J0IG1lY2hhbmlzbSB0byBJRVNHIGFzICANCj4gUHJvcG9zZWQgU3RhbmRhcmQN Cj4NCj4gQXByIDIwMTMgICAgU3VibWl0IHVzYWdlIGd1aWRlIHRvIElFU0cgYXMgSW5mb3JtYXRp b25hbA0KPg0KPiBBcHIgMjAxMyAgICBTdWJtaXQgZmllbGQgdGVzdCB0byBJRVNHIGFzIEluZm9y bWF0aW9uYWwNCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gemhh bmd5dW5mZWkNCj4NCg0KDQoNCi0tIA0KUmljY2FyZG8gQmVybmFyZGluaQ0KRElFR00gLS0gVW5p dmVyc2l0eSBvZiBVZGluZQ0KdmlhIGRlbGxlIFNjaWVuemUgMjA4DQozMzEwMCBVZGluZQ0KVGVs OiArMzktMDQzMi01NS04MjcxDQpGYXg6ICszOS0wNDMyLTU1LTgyNTENCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KU0VNRUwgKFNFcnZpemlvIGRpIE1lc3NhZ2luZyBFTGV0dHJvbmljbykgLSBBSU5GLCBVbml2 ZXJzaXRhJyBkaSBVZGluZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpwcHNwIG1haWxpbmcgbGlzdA0KcHBzcEBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wcHNw ------=_001_NextPart855258147441_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"
Hi Riccardo,
    Please see inline.
 
BR
Yunfei
 
zhangyunfei
 
Date: 2012-02-21 17:25
To: ppsp
Subject: Re: [ppsp] PPSP Re-charter=20 discussion
ZongNing <zongning@huawei.com> ha scritto:
 
> Hi,
>
> Regarding " Inclusion of media tra= nsport mechanism into PPSP WG  
> task", because we haven't got cons= ensus on mandatory data transport  
> mechanism yet, how do you intend&n= bsp;to progress this item?
> I can see two ways, thus diff= erent milestone layout:
>
> 1)       still sele= cting at least one mandatory data transport&= nbsp; 
> mechanism and document it in peer&= nbsp;protocol draft.
>
> 2)       produce a&= nbsp;list of best practice data transport me= chanisms  
> for PPSP usage and document these&= nbsp;in separate drafts (to peer  
> protocol draft).
 
 
I like this approach, but I would = reverse the order of milestones,  
that is, first fix what we need fr= om the media transport protocol and  
the interface that the transport protocol&nb= sp;must expose, then on the top  
of that specification define one (or mo= re) "default" (and mandatory to  
implement) transport protocol(s).  (Actually,&nbs= p;I expect the development  
of the two specs to proceed in par= allel, with interactions).
 
[Yunfei] Good proposal. I think this is=20 a feasible approach to start the work.
 
BTW, minor typo:  maybe in
 
   "A peer looking for a part= icular media stream"
 
is an "is" missing?
  [Yunfei] It should be "A p= eer=20 looks for a particular media stream first in viewing the program". =
 
Regards,
Riccardo
 
>
> BR,
> Ning Zong
> From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@= ietf.org] On Behalf  
> Of zhangyunfei
> Sent: Sunday, February 19, 2012 11= :59 PM
> To: ppsp
> Subject: [ppsp] PPSP Re-charter discuss= ion
>
> Hi all,
>    Based on the discussions&n= bsp;in Taipei meeting, Martin and I have&nbs= p; 
> drafted the following re-charter text&n= bsp;with the track change mode.  
> The basic changes include:
> 1) Inclusion of media transport me= chanism into PPSP WG task.
> 2) Signaling protocol and media pr= otocol candidates description change;
> 3) Document merger, submission deadline=  as well as new WG draft  
> update in Goals and milestones.
>     Please review it and=  post your comments in the mailing list= . We  
> wish to get consensus in the = mailing list before submitting to talk  = ;
> with the AD.
> P.S.: We are exploring the possibi= lity of having an interim meeting  
> in the early of March, before = ;next IETF. We'll start the poll of the=   
> time soon if we get positive = feedback on the progress from the  
> proposed peer and tracker protocol = ;authors.
>
> BR
> Yunfei
>
>
>
> Description of Working Group
> The Peer-to-Peer Streaming Protocol (PP= SP) working group develops two
> signaling and control protocols for&nbs= p;a peer-to-peer (P2P) streaming
> system for transmitting live and t= ime-shifted media content with near
> real-time delivery requirements.
> Two kinds of nodes exist in t= he targeted P2P streaming system, i.e.,
> "peers" and "trackers". Peers are = nodes that are actively sending and
> receiving streamed media content, and&n= bsp;include both statically connected
> hosts as well as mobile devices&nb= sp;with connectivity and IP addresses that
> change over time, as well as = changed link characteristics for mobile nodes.
> The set of peers that are par= ticipating in a streaming
> session will dynamically change over&nb= sp;time. Trackers are well-known nodes
> with stable connectivity that maintain&= nbsp;meta information about the
> streamed content and the dynamic p= eer set involved in the streaming.  
> Trackers can be organized in
> centralized or distributed ways.
> The PPSP WG designs a protocol&nbs= p;for signaling and control between
> trackers and peers (the PPSP "trac= ker protocol") and a signaling and
> control protocol for communication amon= g the peers (the PPSP "peer
> protocol"). The two protocols enable&nb= sp;peers to receive streaming data
> within the time constraints required&nb= sp;by specific content items. The
> tracker protocol handles the initial&nb= sp;and periodic exchange of meta
> information between trackers and peers,=  such as peer lists and content
> information. The peer protocol controls=  the advertising and exchange of
> media data availability between the&nbs= p;peers, as well as the exchange  
> of streaming media.
> It is envisioned that the tracker&= nbsp;protocol will be modeled as a
> request/response protocol between peers = ;and trackers, and will carry
> information needed for the selection&nb= sp;of peers suitable for real-time
> streaming. The peer protocol is en= visioned to be modeled as a
> gossip-like protocol with periodic, pai= rwise exchanges of neighbor and
> media chunk availability information. B= oth protocols will be carried
> over TCP (or UDP, when delivery&nb= sp;requirements cannot be met by TCP),
> likely in combination with ICE for=  NAT traversal support. Perfect
> privacy protection is a good featu= re to have but not a mandatory
> requirement for the peer and track= er protocols. The WG will consider to
> use existing protocols as design b= ase for the tracker and peer
> protocols.
> Developing mechanisms for searching tra= ckers that contain a specific
> media item is out of the scop= e of this WG. Additionally, the WG will=
> work under the assumption that tra= ckers are logically centralized
> entities (e.g., a single server or=  a server farm performing DNS-based
> local balancing). However, as far = as it is possible, the WG will not
> make design decisions that could p= reclude the use of distributed
> trackers in the future (e.g., DHT-= based trackers).
> A peer looking for a particular&nb= sp;media stream media chunkSuch a media &nbs= p;
> stream is transported in so-called = ;chunks, where a chunk contains  
> the pieces of the media.
> Obtaining the media chunk from the=  remote peer will involve some
> type of signaling exchange, i.e., = the tracker and peer protocols to
> locate a remote peer (or peers)&nb= sp;plus the actual media transfer of  <= /DIV>
> the chunks. The first, media strea= mmedia
> chunk.
> task for this WG will be to&n= bsp;decide which signaling and media transfer
> protocols will be usedThe WG will&= nbsp;work on the peer and tracker  
> protocol and . The WG will co= nsider existing protocols and, if
> needed, identify potential extensions t= o these protocols. The WG will
> consider the interactions between these=  protocols and the peer protocol
> (e.g., avoiding duplicate NAT traversal=  procedures). An Eexamples of a
> signaling protocols to be considered&nb= sp;are isSIP, RTSP, and HTTP. Examples
> of media transfer protocols mechanismst= o be considered are UDP,  
> andTCPRTP and HTTP.
> and possible extension on top of&n= bsp;them.
> PPSP is not chartered to work = ;on media transmission protocols, media
> encoding techniques or other components=  of a P2P streaming system such
> as playout control or, scheduling = and control, etc.
> PPSP will explore the relationship = ;to DECADE and ALTO working groups.
> The work items of the PPSP WG=  are:
> (1) A "problem statement" and "req= uirements" document. This document  
> that gives an overview of the
> proposed P2P streaming system, motivate= s the desire for
> standardized protocols, defines the env= isioned scope of those
> standardized components and discusses c= ommon terminologies and
> concepts. It also that details the=  specific functional,
> operational and performance requirements&nbs= p;of the two PPSP
> protocols.
> (2) A "requirements" document that = ;details the specific functional,
> operational and performance requirements&nbs= p;of the two PPSP
> protocols.
> (3) An "architectural survey" document&= nbsp;that summarizes current P2P
> streaming architectures, in particular = tracker-based P2P
> streaming systems, and highlights best&= nbsp;current practices, as input  
> to the design of the peer and=  tracker protocols..
> (4) A detailed specification of th= e PPSP peer protocol.
> (5) A detailed specification of th= e PPSP tracker protocol.
> (6) A detailed specification of th= e PPSP media transport mechanism.
> (7) A "usage guide" that describes=  how the thewo PPSP protocols and
> existing IETF protocols, such as P= 2PSIP,DECADEor ALTO, can be combined
> to create a deployable operational = ;P2P streaming system. This
> document may also discuss variants = ;of such a system that, for
> example, use layered media encoding&nbs= p;and related media chunk
> descriptions in the peer protocol = for more robust streaming.
> (8) A implementation and operational&nb= sp;experience guide document that  
> describes the performance of the p= roposed protocols and usable  
> systems.
> The work items of the PPSP WG=  interacts with the work performed in o= ther
> IETF WGs, including P2PSIP, SIPCORE,&nb= sp;AVT, ALTO, LEDBAT, and DECADE  
> and MMUSIC.
> Whenever extensions or modification to&= nbsp;the protocols developed in other
> WGs are deemed necessary, PPSP sha= ll communicate and discuss the
> requirements for such extensions with&n= bsp;the relevant WGs. PPSP is not
> chartered to design and specify su= ch changes.
> Goals and Milestones
> Dec 20110
>
> Submit problem statement to IESG a= s Informational
>
> Apr 2011 2012
>
> Submit problem statement and requiremen= tsarchitectural survey  
> documentto IESG as Informational
>
> Apr 2011 2012
>
> Submit architectural survey requirements&nbs= p;document to IESG as Informational
>
> Aug Sep20121 Jan 2013
>
> Submit PPSP tracker peer protocol = to IESG as Proposed Standard
>
> Aug Dec20121 Jan 2013
>
> Submit PPSP tracker peer protocol = to IESG as Proposed Standard
>
> Dec2011
>
> Submit usage guide to IESG to = ;IESG as Informational
>
> Dec 2012Jan 2013    Submit&nb= sp;PPSP media transport mechanism to IESG as=   
> Proposed Standard
>
> Apr 2013    Submit usage = ;guide to IESG as Informational
>
> Apr 2013    Submit field = ;test to IESG as Informational
>
>
> ________________________________
> zhangyunfei
>
 
 
 
-- 
Riccardo Bernardini
DIEGM -- University of Udine
via delle Scienze 208
33100 Udine
Tel: +39-0432-55-8271
Fax: +39-0432-55-8251
 
---------------------------------------------------------------------= -
SEMEL (SErvizio di Messaging ELettronico) -&= nbsp;AINF, Universita' di Udine
 
 
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
------=_001_NextPart855258147441_=------ From a.bakker@vu.nl Wed Feb 22 06:55:51 2012 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 4F86521F87BA for ; Wed, 22 Feb 2012 06:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.439 X-Spam-Level: X-Spam-Status: No, score=0.439 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 YR7+FT4yf4M8 for ; Wed, 22 Feb 2012 06:55:50 -0800 (PST) Received: from mailin.vu.nl (mailin.vu.nl [130.37.164.18]) by ietfa.amsl.com (Postfix) with ESMTP id 88FE921F87B9 for ; Wed, 22 Feb 2012 06:55:50 -0800 (PST) Received: from PEXHB012B.vu.local (130.37.236.67) by mailin.vu.nl (130.37.164.18) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 22 Feb 2012 15:55:47 +0100 Received: from [130.161.211.249] (130.37.238.20) by mails.vu.nl (130.37.236.67) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 22 Feb 2012 15:55:48 +0100 Message-ID: <4F4501F4.80704@cs.vu.nl> Date: Wed, 22 Feb 2012 15:55:48 +0100 From: Arno Bakker User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: zhangyunfei References: <2012021923584463860669@chinamobile.com>, <4F420CA8.8090701@cs.vu.nl> <2012022211013534382619@chinamobile.com> In-Reply-To: <2012022211013534382619@chinamobile.com> Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit X-Originating-IP: [130.37.238.20] Cc: ppsp Subject: Re: [ppsp] PPSP Re-charter discussion 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, 22 Feb 2012 14:55:51 -0000 On 22/02/2012 04:15, zhangyunfei wrote: > The picture I imagine is that we have a mandatory media transport > mechanim in PPSP. I don't mean to design > a new protocol parallel to UDP or TCP. Rather the spec should make it > clear how to use UDP or TCP in PPSP environment. Maybe it also > involves some extensions above UDP or TCP. Hi what is the reason for describing media transport in a separate specification and not keeping it in the peer protocol spec where it is now (Section 6. Transport Protocols and Encapsulation)? I'm afraid the PPSP specification will be fragmented over too many documents: 3 specs for the P2P part (peer proto spec, media transport spec and usage guide). Not nice for reading, not nice for authoring. Regards, Arno From wes@mti-systems.com Wed Feb 22 07:44:49 2012 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 9C53221F8748 for ; Wed, 22 Feb 2012 07:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 t9FZUNjpj-6U for ; Wed, 22 Feb 2012 07:44:48 -0800 (PST) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 927BF21F8746 for ; Wed, 22 Feb 2012 07:44:48 -0800 (PST) Received: from cm-omr14 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q1MFiknh025284 for ; Wed, 22 Feb 2012 10:44:47 -0500 Authentication-Results: cm-omr14 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.46.41.98] ([107.46.41.98:9576] helo=[68.245.171.115]) by cm-omr14 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id D6/E8-02762-D6D054F4; Wed, 22 Feb 2012 10:44:46 -0500 Message-ID: <4F450D72.9010504@mti-systems.com> Date: Wed, 22 Feb 2012 10:44:50 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: arno@cs.vu.nl References: <2012021923584463860669@chinamobile.com>, <4F420CA8.8090701@cs.vu.nl> <2012022211013534382619@chinamobile.com> <4F4501F4.80704@cs.vu.nl> In-Reply-To: <4F4501F4.80704@cs.vu.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ppsp Subject: Re: [ppsp] PPSP Re-charter discussion 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, 22 Feb 2012 15:44:49 -0000 On 2/22/2012 9:55 AM, Arno Bakker wrote: > On 22/02/2012 04:15, zhangyunfei wrote: >> The picture I imagine is that we have a mandatory media transport >> mechanim in PPSP. I don't mean to design >> a new protocol parallel to UDP or TCP. Rather the spec should make it >> clear how to use UDP or TCP in PPSP environment. Maybe it also >> involves some extensions above UDP or TCP. > > Hi > > what is the reason for describing media transport in a separate > specification and not keeping it in the peer protocol spec where it is > now (Section 6. Transport Protocols and Encapsulation)? > > I'm afraid the PPSP specification will be fragmented over too many > documents: 3 specs for the P2P part (peer proto spec, media transport > spec and usage guide). Not nice for reading, not nice for authoring. As an individual, I agree with Arno on this. -- Wes Eddy MTI Systems From zhangyunfei@chinamobile.com Thu Feb 23 08:01:50 2012 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 F274721F87E8; Thu, 23 Feb 2012 08:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.222 X-Spam-Level: X-Spam-Status: No, score=-96.222 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 wJeEcg9WGuZi; Thu, 23 Feb 2012 08:01:48 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D647621F87E2; Thu, 23 Feb 2012 08:01:47 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id C664BE5D9; Fri, 24 Feb 2012 00:01:45 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id BE48CE4BC; Fri, 24 Feb 2012 00:01:45 +0800 (CST) Received: from pc917 ([10.1.5.3]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012022400014387-22755 ; Fri, 24 Feb 2012 00:01:43 +0800 Date: Thu, 23 Feb 2012 23:59:30 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <20120224000001656830144@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-24 00:01:44, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-24 00:01:45, Serialize complete at 2012-02-24 00:01:45 Content-Type: multipart/alternative; boundary="----=_001_NextPart373300870422_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18730.000 X-TM-AS-Result: No--18.426-7.0-31-10 X-imss-scan-details: No--18.426-7.0-31-10;No--18.426-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Cc: iesg-secretary Subject: [ppsp] PPSP WG Virtual Interim Meeting Announcement X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei 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, 23 Feb 2012 16:01:50 -0000 This is a multi-part message in MIME format. ------=_001_NextPart373300870422_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGkgYWxsLA0KICAgICBBY2NvcmRpbmcgdG8gdGhlIHBvbGwgYW5kIGZ1cnRoZXIgZGlzY3Vzc2lv biB3aXRoIHRoZSBhdXRob3JzLCB3ZSBwbGFuIHRvIGhhdmUgYSBQUFNQIHZpcnR1YWwgaW50ZXJp bSBtZWV0aW5nIGFzIGZvbGxvd3M6DQogICAgICAgICAgRGF0ZTogIE1hcmNoIDd0aChXZXMpICwg MjAxMi4gDQogICAgICAgICAgVGltZTogR01UIDEwOjAwLTEyOjAwIA0KICAgIA0KICAgIFRoZSAg dmlydHVhbCAgaW50ZXJpbSAgbWVldGluZyAgd2lsbCAgYmUgIHVzZWQgIHRvICBkaXNjdXNzICB0 aGVzZSAgbWFpbiAgdG9waWNzOg0KICAgICAgICAgICAgLSAgUFBTUCBUcmFja2VyICBwcm90b2Nv bDogIHJldmlldyAgb2YgIGN1cnJlbnQgIHByb3Bvc2FscyAgZm9yICB0aGUgIHRyYWNrZXIgcHJv dG9jb2wuICANCiAgICAgICAgICAgICAgICAgICBUZWNobmljYWwgIGRpc2N1c3Npb24gIG9uICBo b3cgIHRvICBwcm9ncmVzcyAgdGhlICBwcm9wb3NhbHMgIHRvIGNvbWUgIHRvICBhICBXRyAgaXRl bSAgZm9yICB0aGUgIHRyYWNrZXIgIHByb3RvY29sLg0KICAgICAgICAgICAgLSAgUFBTUCAgUGVl ciAgcHJvdG9jb2w6ICByZXZpZXcgIG9mICBjdXJyZW50ICBwcm9wb3NhbHMgIGZvciAgdGhlICBw ZWVyICBwcm90b2NvbC4gDQogICAgICAgICAgICAgICAgICAgVGVjaG5pY2FsICBkaXNjdXNzaW9u ICBvbiAgaG93ICB0byAgcHJvZ3Jlc3MgIHRoZSAgcHJvcG9zYWxzLg0KICAgDQogICAgV2UgcGxh biB0byBmb2N1cyBvdXIgZGlzY3Vzc2lvbiBvbiB0aGUgdHdvIHByb3Bvc2VkIHByb3RvY29sIGRy YWZ0cyBpbiB0aGlzIG1lZXRpbmcgYW5kIGxlYXZlIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQg cmVxdWlyZW1lbnRzICAgICBtZXJnZXIgZHJhZnQgYW5kIGNoYXJ0ZXIgZGlzY3Vzc2lvbiBpbiBu ZXh0IElFVEYgbWVldGluZyBjb25zaWRlcmluZyB0aGV5IGFyZSBqdXN0IHN0YXJ0aW5nIGJlaW5n L3RvIGJlIGRpc2N1c3NlZCBpbiB0aGUgbWFpbGluZyBsaXN0LiAgDQoNCg0KDQpCUg0KWXVuZmVp DQoNCg0KDQoNCg0Kemhhbmd5dW5mZWk= ------=_001_NextPart373300870422_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Hi all,
     According to the poll and further discussion= with=20 the authors, we plan to have a PPSP virtual interim meeting as follows:
         =20 Date:  March 7th(Wes) , 2012. 
          Time: GMT=20 10:00-12:00
   
    The  virtual  interim  meeting &nbs= p;will=20  be  used  to  discuss  these  main=20  topics:
           =20 -  PPSP Tracker  protocol:  review  of  curr= ent=20  proposals  for  the  tracker protocol. &nbs= p;
           &nb= sp;      =20 Technical  discussion  on  how  to  progress &nbs= p;the=20  proposals  to come  to  a  WG  item=20  for  the  tracker=20  protocol.
         = ;   -  PPSP  Peer=20  protocol:  review  of  current  proposals  = for=20  the  peer  protocol.
           &nb= sp;      =20 Technical  discussion  on  how  to  progress &nbs= p;the=20  proposals.
  
    We plan to focus our discussion on the two propose= d=20 protocol drafts in this meeting and leave the problem statement and=20 requirements     merger draft and charter discussion i= n next=20 IETF meeting considering they are just starting being/to be discussed= in=20 the mailing list.  
 
 
 
BR
Yunfei
 
zhangyunfei
------=_001_NextPart373300870422_=------ From zhangyunfei@chinamobile.com Thu Feb 23 23:53:59 2012 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 53D0921F870B for ; Thu, 23 Feb 2012 23:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.205 X-Spam-Level: X-Spam-Status: No, score=-96.205 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 D8aS00qz1s6h for ; Thu, 23 Feb 2012 23:53:58 -0800 (PST) Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA6521F8707 for ; Thu, 23 Feb 2012 23:53:58 -0800 (PST) Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id 3EAAEE405; Fri, 24 Feb 2012 15:53:55 +0800 (CST) Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id 34585E385; Fri, 24 Feb 2012 15:53:55 +0800 (CST) Received: from zyf-PC ([10.2.52.179]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012022415535337-13199 ; Fri, 24 Feb 2012 15:53:53 +0800 Date: Fri, 24 Feb 2012 15:53:37 +0800 From: zhangyunfei To: ppsp X-Priority: 3 (Normal) X-Mailer: Foxmail 7.0.1.85[cn] Mime-Version: 1.0 Message-ID: <201202241553104487033@chinamobile.com> X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-24 15:53:53, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-02-24 15:53:54, Serialize complete at 2012-02-24 15:53:54 Content-Type: multipart/alternative; boundary="----=_001_NextPart843254106034_=----" X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-18730.005 X-TM-AS-Result: No--10.425-7.0-31-10 X-imss-scan-details: No--10.425-7.0-31-10;No--10.425-7.0-31-10 X-TM-AS-User-Approved-Sender: No;No X-TM-AS-User-Blocked-Sender: No;No Subject: [ppsp] Tentative PPSP sessions schedule for IETF-83 X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zhangyunfei 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, 24 Feb 2012 07:53:59 -0000 This is a multi-part message in MIME format. ------=_001_NextPart843254106034_=---- Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="us-ascii" SGVsbG8sDQoNCkZvciBpbmZvcm1hdGlvbiwgdGhlIFBQU1Agc2Vzc2lvbnMgaGF2ZSBiZWVuIHRl bnRhdGl2ZWx5IHNjaGVkdWxlZCB0byBXZWRuZXNkYXkgbW9ybmluZy4NCk5vdGUgdGhhdCB0aGlz IG1heSBiZSBtb2RpZmllZCB1bnRpbCB0aGUgSUVURi04MyBhZ2VuZGEgaXMgZmluYWxlcyAob24g MiBNYXJjaCAyMDEyKS4NCg0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpCZWxvdyBpcyB0aGUgc2NoZWR1bGVkIHNlc3Npb24gaW5mb3JtYXRpb24gZm9s bG93ZWQgYnkNCnRoZSBvcmlnaW5hbCByZXF1ZXN0LiANCg0KcHBzcCBTZXNzaW9uIDEgKDIuNSBo b3VycykNCiAgICBXZWRuZXNkYXksIE1vcm5pbmcgU2Vzc2lvbiBJIDA5MzAtMTEzMA0KICAgIFJv b20gTmFtZTogMjUyQQ0KICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQpCUg0KTWFydGluIGFuZCBZdW5mZWkNCg0KDQoNCnpoYW5neXVuZmVp ------=_001_NextPart843254106034_=---- Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Hello,
 
For information, the PPSP=20 sessions have been tentatively scheduled to = Wednesday=20 morning.
Note that this may be modified until&nb= sp;the IETF-83 agenda is finales (on 2 = March 2012).
 
   ---------------------------------------------
= Below is the scheduled session information f= ollowed by
the original request. 
 
ppsp Session 1 (2.5 hours)
    Wednesday, Morning Session I&n= bsp;0930-1130
    Room Name: 252A
    ---------------------------------------------=
 
BR
Martin and Yunfei
zhangyunfei
------=_001_NextPart843254106034_=------ From rui.cruz@ieee-pt.org Fri Feb 24 14:15:57 2012 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 D0BA621F860B for ; Fri, 24 Feb 2012 14:15:57 -0800 (PST) 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 bs2rubfwlFkl for ; Fri, 24 Feb 2012 14:15:56 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F20C21F8605 for ; Fri, 24 Feb 2012 14:15:55 -0800 (PST) Received: by werg1 with SMTP id g1so2283030wer.31 for ; Fri, 24 Feb 2012 14:15:54 -0800 (PST) Received-SPF: pass (google.com: domain of rui.cruz@ieee-pt.org designates 10.216.132.28 as permitted sender) client-ip=10.216.132.28; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rui.cruz@ieee-pt.org designates 10.216.132.28 as permitted sender) smtp.mail=rui.cruz@ieee-pt.org Received: from mr.google.com ([10.216.132.28]) by 10.216.132.28 with SMTP id n28mr2188048wei.35.1330121754911 (num_hops = 1); Fri, 24 Feb 2012 14:15:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=EW1skRbEuJ1nKdt3ZH2iWSx/2Z+91L4nlSuwgBp3BYc=; b=1haEXNRC1BI4DUFyQULxFi2doCJb2WTq9OMnlVQxIU9zxiltL/Uk2oAORCirJrIJB+ 13fi1JrEOneTBpeVd3o46UGb8bd1FN1qfg+0+HnC3nI+s42Ekt8yzOxKN7zsI7WpIXCP 74/s2YJAw6Xf3Ofly0BJgCz5PX1FPPmPEXOX0= Received: by 10.216.132.28 with SMTP id n28mr1771226wei.35.1330121754484; Fri, 24 Feb 2012 14:15:54 -0800 (PST) Received: from airia.casa (89-180-19-179.net.novis.pt. [89.180.19.179]) by mx.google.com with ESMTPS id ft8sm6198712wib.11.2012.02.24.14.15.52 (version=SSLv3 cipher=OTHER); Fri, 24 Feb 2012 14:15:53 -0800 (PST) Sender: Rui Cruz Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_1822ABB3-C174-4FDD-AFFC-3BDBD1531DEE" From: Rui Cruz In-Reply-To: <20120224220117.31836.3757.idtracker@ietfa.amsl.com> Date: Fri, 24 Feb 2012 22:15:50 +0000 Message-Id: References: <20120224220117.31836.3757.idtracker@ietfa.amsl.com> To: ppsp@ietf.org X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkPTLsIjFzQLwevKo43WTbFy4qRoqOSjONHaiV/IIXWsRASCnefKEo67HAo4Q7BcaVko7Sd Cc: Rui Cruz Subject: [ppsp] New Version for draft-gu-ppsp-tracker-protocol X-BeenThere: ppsp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: discussing to draw up peer to peer streaming protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 22:15:58 -0000 --Apple-Mail=_1822ABB3-C174-4FDD-AFFC-3BDBD1531DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, A new version of the Tracker Protocol draft was just submitted. This new version addresses all the issues discussed so far. Please review the draft and send your comments to the PPSP list. Any = type of review is highly appreciated. Regards, Rui Cruz rui.cruz@ieee.org IST/INESC-ID/INOV - Lisbon, Portugal __________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp On 24/02/2012, at 22:01, internet-drafts@ietf.org wrote: > A new version of I-D, draft-gu-ppsp-tracker-protocol-07.txt has been = successfully submitted by Rui Cruz and posted to the IETF repository. >=20 > Filename: draft-gu-ppsp-tracker-protocol > Revision: 07 > Title: PPSP Tracker Protocol (PPSP-TP) > Creation date: 2012-02-24 > WG ID: Individual Submission > Number of pages: 52 >=20 > Abstract: > This document specifies the Peer-to-Peer Streaming Protocol--Tracker > Protocol (PPSP-TP), an application-layer control (signaling) = protocol > for the exchange of meta information between trackers and peers, = such > as initial offer/request of participation in multimedia content > streaming, content information, peer lists and reports of activity > and status. The specification outlines the architecture of the > protocol and its functionality, and describes message flows, message > processing instructions, message formats, formal syntax and > semantics. The PPSP Tracker Protocol enables cooperating peers to > form content streaming overlay networks to support near real-time > Structured Media content (audio, video, associated text/metadata) > delivery, such as adaptive multi-rate, layered (scalable) and multi- > view (3D), in live, time-shifted and on-demand modes. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail=_1822ABB3-C174-4FDD-AFFC-3BDBD1531DEE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Regards,

Rui = Cruz
<= font class=3D"Apple-style-span" = color=3D"#1555cb">
IST/INESC-ID/INOV - Lisbon, = Portugal
__________________________________________
<= div>ppsp mailing = list

On 24/02/2012, at 22:01, internet-drafts@ietf.org = wrote:

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

Filename: = draft-gu-ppsp-tracker-protocol
Revision: 07
Title: PPSP = Tracker Protocol (PPSP-TP)
Creation date: 2012-02-24
WG ID: = Individual Submission
Number of pages: 52

Abstract:
=   This document specifies the Peer-to-Peer Streaming = Protocol--Tracker
  Protocol (PPSP-TP), an = application-layer control (signaling) protocol
  for the = exchange of meta information between trackers and peers, such
=   as initial offer/request of participation in multimedia = content
  streaming, content information, peer lists and = reports of activity
  and status.  The specification = outlines the architecture of the
  protocol and its = functionality, and describes message flows, message
=   processing instructions, message formats, formal syntax = and
  semantics.  The PPSP Tracker Protocol enables = cooperating peers to
  form content streaming overlay = networks to support near real-time
  Structured Media = content (audio, video, associated text/metadata)
=   delivery, such as adaptive multi-rate, layered (scalable) = and multi-
  view (3D), in live, time-shifted and = on-demand modes.




The IETF = Secretariat

= --Apple-Mail=_1822ABB3-C174-4FDD-AFFC-3BDBD1531DEE-- From hishigh@gmail.com Mon Feb 27 22:12:27 2012 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 2066521F86E8 for ; Mon, 27 Feb 2012 22:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, 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 L84xcn4rLApw for ; Mon, 27 Feb 2012 22:12:26 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1761421F86E5 for ; Mon, 27 Feb 2012 22:12:26 -0800 (PST) Received: by ggnp2 with SMTP id p2so777422ggn.31 for ; Mon, 27 Feb 2012 22:12:25 -0800 (PST) Received-SPF: pass (google.com: domain of hishigh@gmail.com designates 10.236.37.132 as permitted sender) client-ip=10.236.37.132; Authentication-Results: mr.google.com; spf=pass (google.com: domain of hishigh@gmail.com designates 10.236.37.132 as permitted sender) smtp.mail=hishigh@gmail.com; dkim=pass header.i=hishigh@gmail.com Received: from mr.google.com ([10.236.37.132]) by 10.236.37.132 with SMTP id y4mr2359862yha.10.1330409545675 (num_hops = 1); Mon, 27 Feb 2012 22:12:25 -0800 (PST) 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; bh=EibLgaGa5kurkitfauyADQIr1lRT7Oz8SntN8r/PiEc=; b=GcWTBciwMIE52r1vyy0XLgYndLasktRlvX3rgmdHbhpLhnvcMtC8GqcR+OGqt+FQks WQZ/DM8LhannC0BNciZFSqqKK+QOXIiCCv5dspsNMeeA3dux8n/IirRcoNbCBp0x8L23 FAcT58gVjYrY+wr2gttP2yARiF3pyKMpHZ1sQ= MIME-Version: 1.0 Received: by 10.236.37.132 with SMTP id y4mr1790357yha.10.1330409545608; Mon, 27 Feb 2012 22:12:25 -0800 (PST) Received: by 10.147.133.17 with HTTP; Mon, 27 Feb 2012 22:12:25 -0800 (PST) In-Reply-To: <20120228060011.19477.2480.idtracker@ietfa.amsl.com> References: <20120228060011.19477.2480.idtracker@ietfa.amsl.com> Date: Tue, 28 Feb 2012 14:12:25 +0800 Message-ID: From: yunfei zhang To: ppsp@ietf.org Content-Type: multipart/alternative; boundary=20cf302d48825f2e6f04ba001c4b Subject: [ppsp] Fwd: New Version Notification for draft-ietf-ppsp-problem-statement-08.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: Tue, 28 Feb 2012 06:12:27 -0000 --20cf302d48825f2e6f04ba001c4b Content-Type: text/plain; charset=ISO-8859-1 Hi all, As the reply to the IESG review, we have merged the problem statement and requirement draft into a new one,as we promised. We also update the ambiguous texts and delete the texts which may cause commmercial understanding of the draft. We also cut down the pages of the problem statement and use case, to delete the possible redundancy and make the scope more clear. Please review the draft and any suggestions and comments are highly appreciated. BR Yunfei ---------- Forwarded message ---------- From: Date: 2012/2/28 Subject: New Version Notification for draft-ietf-ppsp-problem-statement-08.txt To: hishigh@gmail.com Cc: vpascual@acmepacket.com, yry@cs.yale.edu, gonzalo.camarillo@ericsson.com, zhangyunfei@chinamobile.com A new version of I-D, draft-ietf-ppsp-problem-statement-08.txt has been successfully submitted by Yunfei Zhang and posted to the IETF repository. Filename: draft-ietf-ppsp-problem-statement Revision: 08 Title: Problem Statement and Requirements of Peer-to-Peer Streaming Protocol (PPSP) Creation date: 2012-02-27 WG ID: ppsp Number of pages: 27 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, uses cases and requirements of PPSP. The IETF Secretariat --20cf302d48825f2e6f04ba001c4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0=A0=A0 As the reply to the IESG review, we have merged the problem = statement and requirement draft into a new one,as we promised.
=A0=A0 =A0We also update the ambiguous texts and delete the texts whic= h may cause commmercial understanding of the draft. We also cut down the pa= ges of the problem statement and use case, to delete the possible redundanc= y and make the scope more clear.
=A0=A0=A0 Please review=A0the draft and any suggestions and comments a= re highly appreciated.
=A0
BR
Yunfei=A0
=A0
=A0
=A0
---------- Forwarded message ----------
From:= <internet-drafts@ietf.org>
Date: = 2012/2/28
Subject: New Version Notification for draft-ietf-ppsp-problem-statement-08.= txt
To: hishigh@gmail.com
Cc= : vpascual@acmepacket.com, <= a href=3D"mailto:yry@cs.yale.edu">yry@cs.yale.edu, gonzalo.camarillo@ericsson.com, zhangyunfei@chinamobile.com


A new version of I-D, draft-ietf-ppsp-problem-statement-08.txt has = been successfully submitted by Yunfei Zhang and posted to the IETF reposito= ry.

Filename: =A0 =A0 =A0 =A0draft-ietf-ppsp-problem-statement
Re= vision: =A0 =A0 =A0 =A008
Title: =A0 =A0 =A0 =A0 =A0 Problem Statement and Requirements of Peer-to-Pe= er Streaming Protocol (PPSP)
Creation date: =A0 2012-02-27
WG ID: =A0= =A0 =A0 =A0 =A0 ppsp
Number of pages: 27

Abstract:
=A0 Peer-t= o-Peer (P2P for short) streaming systems show more and more
=A0 popularity in current Internet with proprietary protocols. This
=A0 = document identifies problems of the proprietary protocols, proposes a
= =A0 Peer to Peer Streaming Protocol (PPSP) including tracker and peer
= =A0 signaling components, and discusses the scope, uses cases and
=A0 requirements of PPSP.




The IETF Secretariat
=
--20cf302d48825f2e6f04ba001c4b-- From internet-drafts@ietf.org Mon Feb 27 22:00:10 2012 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 50E4B21F846F; Mon, 27 Feb 2012 22:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 ssJxiAfAP-yq; Mon, 27 Feb 2012 21:59:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF97921F8471; Mon, 27 Feb 2012 21:59:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120228055941.19477.75542.idtracker@ietfa.amsl.com> Date: Mon, 27 Feb 2012 21:59:41 -0800 X-Mailman-Approved-At: Mon, 27 Feb 2012 22:20:47 -0800 Cc: ppsp@ietf.org Subject: [ppsp] I-D Action: draft-ietf-ppsp-problem-statement-08.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: Tue, 28 Feb 2012 06:00:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Peer to Peer Streaming Protocol Worki= ng Group of the IETF. Title : Problem Statement and Requirements of Peer-to-Peer Strea= ming Protocol (PPSP) Author(s) : Yunfei Zhang Gonzalo Camarillo Richard Yang Victor Pascual Filename : draft-ietf-ppsp-problem-statement-08.txt Pages : 27 Date : 2012-02-27 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, uses cases and requirements of PPSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ppsp-problem-statement-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ppsp-problem-statement-08.txt From Martin.Stiemerling@neclab.eu Tue Feb 28 04:33:41 2012 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 9E5E521F8633 for ; Tue, 28 Feb 2012 04:33:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 VdR97FqFmIMK for ; Tue, 28 Feb 2012 04:33:40 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5114221F8629 for ; Tue, 28 Feb 2012 04:33:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BFB46280001D1 for ; Tue, 28 Feb 2012 13:33:39 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) 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 AtBOWvEY7a5L for ; Tue, 28 Feb 2012 13:33:39 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id A4BEF280001CE for ; Tue, 28 Feb 2012 13:33:34 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 28 Feb 2012 13:33:34 +0100 From: Martin Stiemerling To: "ppsp@ietf.org" Thread-Topic: IETF#83: Agenda planning Thread-Index: Acz2FNPon8xOtnADTsaH9UXUbHc/0g== Date: Tue, 28 Feb 2012 12:33:33 +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.99.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [ppsp] IETF#83: Agenda planning 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, 28 Feb 2012 12:33:41 -0000 Dear all, It is time to plan the PPSP session agenda for the upcoming IETF#83 meeting= in Paris.=20 The peer protocol and tracker protocol will get most of time in order to mo= ve them forward. However, if you have any other draft to present, please se= nd an email with the information to Yunfei and me by March 1st.=20 The information we need: - draft name - presenters name (tentative) - requested time for the presentation.=20 We will give a priority to the WG drafts.=20 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