Re: [ppsp] PPSP Re-charter discussion

Riccardo Bernardini <riccardo.bernardini@uniud.it> Tue, 21 February 2012 09:26 UTC

Return-Path: <riccardo.bernardini@uniud.it>
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 <ppsp@ietfa.amsl.com>; 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 <ppsp@ietfa.amsl.com>; 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 <ppsp@ietf.org>; 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 <ppsp@ietf.org>; 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 <ppsp@ietf.org>; 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 <ppsp@ietf.org>; 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 <riccardo.bernardini@uniud.it>
To: ppsp@ietf.org
References: <2012021923584463860669@chinamobile.com> <B0D29E0424F2DE47A0B36779EC66677914919F4B@szxeml504-mbs.china.huawei.com>
In-Reply-To: <B0D29E0424F2DE47A0B36779EC66677914919F4B@szxeml504-mbs.china.huawei.com>
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 <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Feb 2012 09:26:02 -0000

ZongNing <zongning@huawei.com> 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