Subject: [ppsp] ppsp revised charter proposal

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 13 Jan 2010 10:32:07 +0100

Hi,
 
in general I think, the charter is in a good shape.
Perhaps in some points clarifications are possible.
 
The following topics are excluded from this WG's scope:
1. Transport mechanisms for data transmission among PPSP peers, e.g. using TCP or UDP, unicast or multicast, etc. However the  design  of  PPSP  will  consider how it can be combined with the transport mechanisms, including NAT traversal problem. The design of PPSP will also consider the scenario of transmission of multiple streams  (layered  media).  This includes considering various media descriptions (e.g. data chunk description in peer protocol) after investigating different media coding mechanisms (e.g. SVC, MDC) to incorporate their features in the protocol.
 
This somehow mixes different issues:
- Transmission protocol selecion (not included)
- NAT traversal (included?)
- Usage of more then one stream for one channel (included?)
- Media descriptions (included?)
 
Most of the items  are not exluded from the WG´s scope and should not be mentioned under this headline.
My proposal would be:
My proposal would be:My proposal would be:My proposal would be:My proposal would be:My proposal would be:My proposal would be:
My proposal would be:To add

Media descriptions (included?)
Most- Media descriptions (included?)
- Media descriptions (included?)
- Media descriptions (included?)

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext zhangyunfei
Sent: Saturday, December 26, 2009 9:52 AM
To: [email-masked]
Subject: [ppsp] ppsp revised charter proposal

 Dear all,

   The latest version of PPSP charter is attached.Welcome to comment on this.I guess many of you guys are enjoying the Christmas holiday.Merry X'mas and happy new year!Wish to hear your valuable suggestions in the beginning of 2010.:)

   Hope PPSP can have a great development in the new year with all of your participation and contribution.

The main modifications are:

1)Para 2:

a)wish to make it better understood about what the tracker protocol and the peer protocol differ in and reply the BOF comments that the two protocols may be a single one;

b)Add the NAT issue raised in the BOF;

2)Para3:

a) Para3-bullet 4,adding the gossip communication in peer protocol as discussed in the mailing list;

b)Para3-bullet7, deleted as suggested by Lars that optional part can be detered until we think it clearer;

3)Para4, adding LEDBAT as reference raised in the BOF.

4)Para5,deleting privay raised in the BOF.

5)Para6:

a)bullet1:Adding the description of considering the NAT traversal and the multiple stream senario as discussed in the BOF and mailing list.

BR

Yunfei 

*************************************************************************

Description of PPSP Working Group:

The Peer-to-Peer (P2P) Streaming Protocol working group (PPSP WG) is chartered to develop standard signaling protocols (called PPSP protocols) for multiple types of entities (e.g. intelligent endpoints, caches, content distribution network nodes, and/or other edge devices) to participate in P2P streaming systems in both fixed and mobile Internet.

There are two kinds of components in PPSP protocols, i.e., "trackers" and "peers". PPSP protocols include the PPSP tracker protocol - a signaling protocol between "trackers" and "peers", and the PPSP peer protocol - a signaling protocol among "peers". The two protocols ensure peers to get streaming data within certain time constraints. PPSP tracker protocol deals with the initial and periodical exchanges between tracker and peers: initially the peers contact the tracker to report their static information (like IP address, NAT types and other useful things) and get a list of peers for a specific channel or streaming file from the tracker; periodically the tracker maintains lists of participating peers according to the report from the peers about their status information. PPSP peer protocol deals with the exchanges among peers. The peer exchanges its data availability and neighbor peer information with other peers. With these information, it can connect with these peers for further data downloading.  

This WG's primary tasks are to produce:
1. A "problem statement" document describing the problems, incentives, and scope of developing the PPSP protocols, as well as common terminologies and concepts.

2. A "requirements" document listing the requirements on the designed PPSP protocols (e.g., general functionality and performance requirements of PPSP protocols or basic types of information that PPSP protocols should communicate to facilitate P2P streaming).

3. An "architectural survey" document explaining the current P2P streaming architectures, in particular tracker-based P2P streaming, and key issues in best practice.

4. A proposed standard defining the PPSP peer protocol. This protocol will define how PPSP peers advertise data availability and exchange neighbor peers. The protocol will also define the requests and responses of data chunks among PPSP peers.

5. A proposed standard defining the PPSP tracker protocol. This protocol will define how PPSP peers inform and request information from PPSP trackers and how PPSP trackers reply to the requests.

6. A "usage document" explaining how the protocols defined above, along with existing IETF protocols, such as RELAOD, ALTO and RTSP, can inter-operate; and how they may be integrated together to produce complete P2P streaming systems.

The work planned for the PPSP WG is distinct from, but requires close participation with, work in other IETF WGs, particularly P2PSIP, ALTO,LEDBAT and MMUSIC. The PPSP WG assumes that it cannot modify baseline P2PSIP, ALTO, LEDBAT and MMUSIC behaviors. If PPSP determines that extensions to P2PSIP, ALTO,LEDBAT and MMUSIC are needed, PPSP will seek to define such extensions and present to the respective working groups.

The design of PPSP has to consider security issues. The protocol document will contain a complete description of the security issues that PPSP should address.

The following topics are excluded from this WG's scope:
1. Transport mechanisms for data transmission among PPSP peers, e.g. using TCP or UDP, unicast or multicast, etc. However the  design  of  PPSP  will  consider how it can be combined with the transport mechanisms, including NAT traversal problem. The design of PPSP will also consider the scenario of transmission of multiple streams  (layered  media).  This includes considering various media descriptions (e.g. data chunk description in peer protocol) after investigating different media coding mechanisms (e.g. SVC, MDC) to incorporate their features in the protocol.

2. Network coding mechanisms in P2P streaming. Network coding may be used in P2P streaming, but its support is beyond the scope of current charter.

3. Play-out mechanisms including streaming control (e.g., pause, fast-forward, and rewind).

4. Algorithms that may be different in different deployments (e.g., chunk selection, local storage strategies).

5. Research type questions related to P2P streaming. This WG will instead forward such questions to the IRTF P2PRG or other RG as appropriate. Examples include cache management.

Goals and Milestones:

Apr 2010

Working Group Last Call for problem statement

Jun 2010

Submit problem statement to IESG as Informational document

Aug 2010

Working Group Last Call for architecture survey

Aug 2010

Working Group Last Call for requirements

Oct

2010

Submit architecture survey to IESG as Informational document

Oct 2010

Submit requirements to IESG as Informational document

Apr 2011

Working Group Last Call for PPSP peer protocol

Apr

2011

Working Group Last Call for PPSP tracker protocol

Aug 2011

Submit PPSP peer protocol to IESG as Proposed Standard

Aug 2011

Submit PPSP tracker protocol to IESG as Proposed Standard

Nov 2011

Working Group Last Call of usage document

Nov 2011

Working Group Last Call of mobility BCP document

Jan 2012

Submit usage document to IESG as Informational document

Jan 2012

Submit mobility BCP document to IESG as Informational document

Apr 2012

Dissolve or re-charter 

________________________________

zhangyunfei
2009-12-26

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 13 Jan 2010 10:47:09 +0100

Hi,
 
(this time the finished mail)

 
 
Most of the items  are not exluded from the WG´s scope and should not be mentioned under this headline.
My proposal would be:
- to shorten point one of excluded topic to:
1. Transport mechanisms for data transmission among PPSP peers, e.g. using TCP or UDP, unicast or multicast, etc. 
- to add a short passage before the WGs primary tasks:
NAT traversal, the usage of multiple streams (layered media) are in scope of the WG.

What is the reason for this assumption? And how can we know before the related needed extensions are known? 
My proposal:
The work planned for the PPSP WG is distinct from, but requires close participation with, work in other IETF WGs, particularly P2PSIP, ALTO,LEDBAT and MMUSIC. If PPSP determines that extensions to P2PSIP, ALTO,LEDBAT and MMUSIC are needed, PPSP will seek to define such extensions and present to the respective working groups for evalution.
 
Best Regards
Christian Schmidt

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 13 Jan 2010 07:51:50 -0500

So looking at the change suggested below, essentially you are looking
to remove the sentence:

"The PPSP WG assumes that it cannot modify baseline P2PSIP, ALTO,
LEDBAT and MMUSIC behaviors."

Overall, this section of the charter is very much like (even borrowed
from) the P2PSIP charter, where the similar line basically says the
P2PSIP group, in itself, is not authorized to modify SIP. I think
there is a similar intended here, so I wouldn't support removing the
sentence entirely as you suggest, but I think different wording is
might be needed (i.e., using the work "assume" almost implies that the
protocols won't need to be changed, when he right wording should be
more about PPSP not being the place to modify them if they need it.

How about:

"The work planned for the PPSP WG is distinct from, but requires close
participation with, work in other IETF WGs, particularly P2PSIP,
ALTO,LEDBAT and MMUSIC. While the PPSP WG cannot modify baseline
P2PSIP, ALTO, LEDBAT or MMUSIC behaviors, if PPSP determines that
extensions or modifications are required, PPSP may seek to define such
extensions and present them to the respective working groups."

Thoughts?

David

On Wed, Jan 13, 2010 at 4:47 AM, Schmidt, Christian 1. (NSN -
DE/Munich) <[email-masked]> wrote:
> 1. Transport mechanisms for data transmission among PPSP peers, e.g. using
> TCP or UDP, unicast or multicast, etc. However the  design  of  PPSP  will
> consider how it can be combined with the transport mechanisms, including NAT
> traversal problem. The design of PPSP will also consider the scenario of
> transmission of multiple streams  (layered  media).  This includes
> considering various media descriptions (e.g. data chunk description in peer
> protocol) after investigating different media coding mechanisms (e.g. SVC,
> MDC) to incorporate their features in the protocol.
>
> The work planned for the PPSP WG is distinct from, but requires close
> participation with, work in other IETF WGs, particularly P2PSIP, ALTO,LEDBAT
> and MMUSIC. The PPSP WG assumes that it cannot modify baseline P2PSIP, ALTO,
> LEDBAT and MMUSIC behaviors. If PPSP determines that extensions to P2PSIP,
> ALTO,LEDBAT and MMUSIC are needed, PPSP will seek to define such extensions
> and present to the respective working groups.
>
> The work planned for the PPSP WG is distinct from, but requires close
> participation with, work in other IETF WGs, particularly P2PSIP, ALTO,LEDBAT
> and MMUSIC. If PPSP determines that extensions to P2PSIP, ALTO,LEDBAT and
> MMUSIC are needed, PPSP will seek to define such extensions and present to
> the respective working groups for evalution.
>
> Best Regards
> Christian Schmidt
>
>
>
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>
>

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 18 Jan 2010 15:10:17 +0100

Hi David,

Your modification looks better then the orginal text.
Question: 
Is the goal of the sentence, that e.g. requirements from PPSP should not
Be able to request changes in reload-base specification?
These requirements would have to be documented in a separate document?
Or what should this sentence avoid?

Regards
Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext David A. Bryan
Sent: Wednesday, January 13, 2010 1:52 PM
To: Schmidt, Christian 1. (NSN - DE/Munich)
Cc: ext zhangyunfei; [email-masked]
Subject: Re: [ppsp] ppsp revised charter proposal

How about:

Thoughts?

David

On Wed, Jan 13, 2010 at 4:47 AM, Schmidt, Christian 1. (NSN -
DE/Munich) <[email-masked]> wrote:
> TCP or UDP, unicast or multicast, etc.

---

From: "David A. Bryan" <[email-masked]>
Date: Mon, 18 Jan 2010 09:27:00 -0500

Hi Christian,

I don't think the goal is that PPSP should not be able to request
changes at all -- in fact, I hope some interesting uses, which could
mean changes/extensions do come out of PPSP. In the case of the P2PSIP
charter, the language was to make it clear at charter time that P2PSIP
wasn't going to be directly changing SIP itself, but would go through
other groups. In PPSP, I think it should be to make it clear that PPSP
work won't be able to directly change P2PSIP/ALTO etc. specifications,
but would push any suggested changes needed to the respective group.
Perhaps it is redundant (IETF rules tend to imply a group can't
usually modify another group's documents), but as chair, it has proved
to be very useful text from a scoping perspective in P2PSIP.

I tried to capture that in my rewrite, but if I didn't quite get it
right, we should certainly try changing the wording a bit more.

David

On Mon, Jan 18, 2010 at 9:10 AM, Schmidt, Christian 1. (NSN -

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 18 Jan 2010 15:32:58 +0100

Hi David,

Thank you for the explanation, now it is clear to me and I would vote to
Use your text proposal for the charter.

Regards
Christian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext David A. Bryan
Sent: Monday, January 18, 2010 3:27 PM
To: Schmidt, Christian 1. (NSN - DE/Munich)
Cc: ext zhangyunfei; [email-masked]
Subject: Re: [ppsp] ppsp revised charter proposal

Hi Christian,

David

---

From: Victor Pascual Avila <[email-masked]>
Date: Mon, 18 Jan 2010 16:01:46 +0100

+1

-Victor

On 1/18/10, Schmidt, Christian 1. (NSN - DE/Munich)
<[email-masked]> wrote:
>>> NAT traversal, the usage of multiple streams (layered media) are in scope
>>> of
>>> the WG.
>>>
>>> ALTO,LEDBAT
>>> ALTO,LEDBAT

-- 
Victor Pascual Ávila

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 21 Jan 2010 15:58:06 +0800

Agree!

zhangyunfei
2010-01-21

发件人： David A. Bryan
发送时间： 2010-01-18 22:38:49
收件人： Schmidt, Christian 1. (NSN - DE/Munich)
抄送： ext zhangyunfei; [email-masked]
主题： Re: [ppsp] ppsp revised charter proposal

Hi  Christian,

David

On  Mon,  Jan  18,  2010  at  9:10  AM,  Schmidt,  Christian  1.  (NSN  -
DE/Munich)   <[email-masked] >  wrote:
>  DE/Munich)   <[email-masked] >  wrote:
> >  Hi,
> >
> >  TCP  or  UDP,  unicast  or  multicast,  etc.  However  the?design?of?PPSP?will
> >  transmission爋f爉ultiple  streams?(layered?media).?This  includes
> >  Most  of  the  items?are  not  exluded  from  the  WG磗  scope  and  should  not  be
> >  mentioned  under  this  headline.
> >  My  proposal  would  be:
> >  What  is  the  reason  for  this  assumption?  And  how  can  we  know  before  the
> >  related爊eeded  extensions  are  known?
> >  My  proposal: