Subject: [ppsp] PPSP Re-charter discussion

From: zhangyunfei <[email-masked]>
Date: Sun, 19 Feb 2012 23:58:44 +0800

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 20110Submit problem statement to IESG as Informational 
Apr 2011 2012Submit problem statement and requirementsarchitectural survey documentto IESG as Informational 
Apr 2011 2012Submit architectural survey requirements document to IESG as Informational 
Aug Sep20121 Jan 2013Submit PPSP tracker peer protocol to IESG as Proposed Standard 
Aug Dec20121 Jan 2013Submit 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

---

From: zhangyunfei <[email-masked]>
Date: Mon, 20 Feb 2012 10:34:54 +0800

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 next IETF. 

      The purpose of this virtual interim meeting is to progress the works on the
peer and tracker protocols. 

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

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

**Please fill in your availability in the doodle poll until Feb 22. **
     Thanks.

BR
Yunfei

zhangyunfei

发件人： zhangyunfei
发送时间： 2012-02-19 23:58
收件人： ppsp
抄送： Martin Stiemerling; Wesley Eddy
主题： 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

 

zhangyunfei

---

From: Arno Bakker <[email-masked]>
Date: Mon, 20 Feb 2012 10:04:40 +0100

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?

> 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 <[email-masked]>
Date: Tue, 21 Feb 2012 08:33:57 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of zhangyunfei
Sent: Sunday, February 19, 2012 11:59 PM
To: ppsp
Subject: [ppsp] PPSP Re-charter discussion

Hi all,

BR
Yunfei

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

________________________________
zhangyunfei

---

From: Riccardo Bernardini <[email-masked]>
Date: Tue, 21 Feb 2012 10:25:50 +0100

ZongNing <[email-masked]> 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?
> 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

>    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:
>     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
>
>
>
> 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.
> protocols will be usedThe WG will work on the peer and tracker  
> protocol and . The WG will consider existing protocols and, if
> streaming systems, and highlights best current practices, as input  
> to the design of the peer and tracker protocols..
> (8) A implementation and operational experience guide document that  
> describes the performance of the proposed protocols and usable  
> systems.

-- 
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 <[email-masked]>
Date: Wed, 22 Feb 2012 11:15:28 +0800

Hi Arno,  
     Please see inline.

BR
Yunfei

zhangyunfei

From: Arno Bakker
Date: 2012-02-20 17:04
To: [email-masked]
Subject: Re: [ppsp] PPSP Re-charter discussion

Hi

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.

Typo: "that is"

Thanks for the careful review.

CU,
     Arno
_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: zhangyunfei <[email-masked]>
Date: Wed, 22 Feb 2012 11:15:28 +0800

Hi Ning,
    Please see inline.

BR
Yunfei

zhangyunfei

From: ZongNing
Date: 2012-02-21 16:33
To: zhangyunfei; ppsp
Subject: RE: [ppsp] PPSP Re-charter discussion
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).
[Yunfei] I would prefer the second option, which makes every part of PPSP protocol suite clear. But we may need some discussion in the PPSP usage document to make the signaling and media transfer most efficient in the combined usage.
 
BR,
Ning Zong
 
Hi all,
 
BR
Yunfei

 

zhangyunfei

---

From: zhangyunfei <[email-masked]>
Date: Wed, 22 Feb 2012 11:29:47 +0800

Hi Riccardo,
    Please see inline.

BR
Yunfei

zhangyunfei

From: Riccardo Bernardini
Date: 2012-02-21 17:25
To: ppsp
Subject: Re: [ppsp] PPSP Re-charter discussion

[Yunfei] Good proposal. I think this is a feasible approach to start the work.

is an "is" missing?
  [Yunfei] It should be "A peer looks for a particular media stream first in viewing the program". 

Regards,
Riccardo

---

From: Arno Bakker <[email-masked]>
Date: Wed, 22 Feb 2012 15:55:48 +0100

On 22/02/2012 04:15, zhangyunfei wrote:
> 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

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: Wesley Eddy <[email-masked]>
Date: Wed, 22 Feb 2012 10:44:50 -0500

> 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