Subject: Re: [ppsp] ppsp charter discussion

From: Ning Zong <[email-masked]>
Date: Fri, 11 Sep 2009 11:24:43 -0300

Hi, Ping,

Thank you for suggestions. I agree that narrow down our work is very important and will make our work more clear.
I think the scope of PPSP is based on the components of P2P streaming systems. We have narrowed the scope down to PPSP tracker and peer protocols, as pointed in charter.
But my point is that as standard tools (note that we are not building a streaming system), PPSP tracker and peer protocols can be applied to either network devices such as cache and CDN, or end users.
Regarding why the end users need to implement PPSP protocol, I think you are right that current subscribers of main P2P streaming vendors (e.g. PPlive) would not do that. But from other ISP's perspective, it maybe beneficial to run standard protocols. For instance, in China Mobile's document, it is discussed that open protocol would have benefits esp. for mobile terminals, etc. Of course, we need more ISPs and streaming vendors to contribute to our work here.
Anyway, whether the PPSP protocol applies to end users or not depend on who would use PPSP protocol. In WG level, we are just developing open protocols/tools which are missing parts towards open P2P streaming system. Another words, we can (and actually have) narrow down our scope in protocol level. But shall we need to narrow down our work regarding who will use our protocol? Maybe no.
2 cents.

BR,
Ning Zong 

Ning,

Thanks for the clarification.

Here is my main concern: currently, PPSP is positioned as yet another streaming protocol to the end users.

IMHO, the end users can care less where the traffic are streaming from so long it's convenient, safe and have reasonable QoE. Do we need another streaming protocol to do this?

One may argue the advantages in P2P. But, to many, PPSP is actually endorsing the following:
I need to install a special software from the ASP's, which may use my local CPU and storage for P2P operation, and do some other things that I don't know about. 
The software enables me to watch some movies from the peers, who may be chased by the lawyers from some media companies. 
On top of that, the service networks, especially, those who have to pay for the expensive backhaul links, may be sick of the traffic volume, and may install DPI boxes at every possible intersection to drop my video stream traffic (here goes my QoE). 
In short, I don't think it's wise to address all of the above in one WG, one architecture or one protocol. Rather, it would be nice to focus on what P2P streaming is good at, use it to solve a couple of real problems, and move on to the next.

We must not ignore the advancement of the following in P2P streaming:
Cost efficiency: I saw a presentation from last IETF's P2PRG (from Rich Woundy?), where it takes a $3,000 PC to support 5,000 concurrent streams. That's cheap! 
Simplicity: it never occurred to me that why we must have storage servers, called CDN, sitting all over the place, while some simple caching would be sufficient. In PPlive's Sigcomm paper, it mentioned of using 8/12G of Flash only, and no harddrive. (This may help answering some copyright concerns). 
Portability: people may argue uplink vs. inter-domain locality. But all service providers need to do is inserting a few P2P edge caching boxes in the network. If more locality is needed, add another one. Chunk discovery and tracker manager are perfect for this. 
This is the line of reasoning I had: why not narrow the scope of PPSP, and solve the caching problem first?

Once again, I don't think PPSP needs to deal with end users for now. In fact, by forcing an open standard, you are taking away the leverage from the existing P2P media companies, including PPlive and PPstream (as mentioned in another draft of yours :-)). Nobody wins!

0.5 cents,

- Ping

2009/9/10 Ning Zong <[email-masked]>

Hi, Ping,

End users will run PPSP. As addressed in charter, PPSP protocols could run on multiple entities such as end users, caches, CDN nodes, etc.
Here we talk about the standard protocols running on end users. What do you mean by non-technical issues? If you mean security, privacy and copyrights issues, I think not only PPSP, but some other BoF/WGs have same issues. You are perfectly right, they will be not in the working scope (but need some considerations during the WG work).

BR,
Ning Zong 

Ning,

We are in agreement here. So, you have listed three objectives for PPSP:

1. Standard interface to CDN/Cache
2. Enable media providers to stream content through standard interfaces
3. Help the service providers to manage their network/links better.

So, curious, does it require the end users to run PPSP as well? The problem statement draft (draft-zhang-ppsp-problem-statement-04.txt) seems to assume that is the case. (If I am not mistaken, all the "proprietary protocols" listed in Section 3.1 are client P2P applications). If yes, you have a wide scope of non-technical issues to deal with. If no, then you need to make it clear in the documents.

Thanks for clarification.

Ping

2009/9/10 Ning Zong <[email-masked]>

Hi, Ping,

Thank you for your comments, please see in-line.

Ning,

I'd think that it is very important to emphasis the target users of the work, which has been quoted as "intelligent endpoints, caches, content distribution network nodes, and/or other edge devices."

[Ning Zong] This is a good suggestion.

If possible, I would hope that further specification, clarification and constraints to be added in one of the documents.

The reasoning is that, if the work is to enable further proliferation of P2P clients within the networks, then the WG needs to address issues including security, privacy and copyrights extensively. This may be above and beyond technology, and is probably outside the scope of PPSP.

On the other hand, if the work is to enable more efficient streaming content distribtution within a controlled environment by leveraging mechanisms such as tracker management and chuck discovery, then the work is well understood, and can be clearly defined, specified and experimented in the near future.

[Ning Zong] If I understand your question correctly, this is related to the incentives of PPSP work. The clarification of incentives are further provided in problem statement. IMO, the second point in your comments is closer to current intention of PPSP. To be brief, the intention include (maybe not limited to): 1) enable more efficient streaming to integrate 3rd party devices, e.g. cache/CDN nodes; 2) enable streaming vendors to accomplish content distribution via some standard API, thus reduce the time-to-market and maybe cost, we hope; 3) enable ISPs to construct standard streaming platform to run content provisioning services.

2 cents,

- Ping

2009/9/10 Ning Zong <[email-masked]>

Hi, Lucy

The participating entities in the first paragraph include both peers and trackers in P2P streaming systems. In second paragraph, we discuss the roles of trackers - assuming that people know the basic meaning of peers.
Formal definitions of PPSP peers and PPSP trackers are defined in Problem Statement Draft.

BR,
Ning Zong

Hi YunFei and Christian,

One clarification: “participating entities” listed in the text are the peer in P2P streaming systems, is that right? Thus, “PPSP” trackers are another participator in the systems.  Suggest stating that clearly in the first paragraph.

Cheers,
Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Schmidt, Christian 1. (NSN - DE/Munich)
Sent: Thursday, September 10, 2009 3:03 AM
To: ext zhangyunfei; [email-masked]
Subject: Re: [ppsp] ppsp charter discussion

Hi Yunfei,
after reading your charter proposal, a text proposal and 2 questions for clarifications.

Best Regards
Christian Schmidt

Proposed new text for more transparency in main description:
Old text:
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.

PPSP protocols include the PPSP tracker protocol – a signaling protocol between “PPSP trackers” and “PPSP peers”, and the PPSP peer protocol – a signaling protocol among “PPSP peers”. A PPSP tracker maintains lists of participating PPSP peers, each for a specific channel or streaming file, and answers the queries from PPSP peers for candidate PPSP peers. PPSP peers inform their status information to PPSP trackers, exchange their chunk availability with other PPSP peers and/or PPSP trackers, and ask other PPSP peers for wanted data. 

New text:
The Peer-to-Peer (P2P) Streaming Protocol working group (PPSP WG) is chartered to develop standard signaling protocols (called PPSP protocols) for P2P streaming systems in both fixed and mobile Internet. Participating entities could be intelligent endpoints, caches, content distribution network nodes, and/or other edge devices.

For a specific channel or streaming file, a PPSP tracker maintains lists of particiating PPSP peers. The PPSP tracker answers queries from PPSP peers for candidate PPSP peers. PPSP peers provide their status information to PPSP trackers, exchange their chunk availability with other PPSP peers and/or PPSP trackers, and ask other PPSP peers for wanted data. PPSP protocols include the PPSP tracker protocol – a signaling protocol between “PPSP trackers” and “PPSP peers”, and the PPSP peer protocol – a signaling protocol among “PPSP peers”. 

Architectural survey
3. An "architectural survey" document explaining the current P2P streaming architectures, in particular tracker-based P2P streaming, and key issues in best practice.
It is good to have a description of the current P2P streaming architecture. What is missing is the relation to the PPSP work. Will it contain a proposal for the PPSP architecture?

Usage document
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.
This sounds more like a "interop document". Was this the intention?

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext zhangyunfei
Sent: Thursday, September 10, 2009 8:24 AM
To: [email-masked]
Subject: [ppsp] ppsp charter discussion

Dear all,
   The following is the modified version of PPSP charter(An early version was published in the IETF PPSP wiki page).Please review it and any comments and suggestions are highly appreciated.

           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.

PPSP protocols include the PPSP tracker protocol – a signaling protocol between “PPSP trackers” and “PPSP peers”, and the PPSP peer protocol – a signaling protocol among “PPSP peers”. A PPSP tracker maintains lists of participating PPSP peers, each for a specific channel or streaming file, and answers the queries from PPSP peers for candidate PPSP peers. PPSP peers inform their status information to PPSP trackers, exchange their chunk availability with other PPSP peers and/or PPSP trackers, and ask other PPSP peers for wanted data. 

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 chunk availability. The protocol will also define the requests and responses of 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.

7. Optionally a ”mobile usage document” (PPSP mobile BCP document) to evaluate PPSP with and without Mobile IP support when there are a lot of mobile peers in the system.

The work planned for the PPSP WG is distinct from, but requires close participation with, work in other IETF WGs, particularly P2PSIP, ALTO and MMUSIC. The PPSP WG assumes that it cannot modify baseline P2PSIP, ALTO, and MMUSIC behaviors. If PPSP determines that extensions to P2PSIP, ALTO, 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/privacy issues. The protocol document will contain a complete description of the security/privacy 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.

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 2010Working Group Last Call for problem statement
Jun 2010Submit problem statement to IESG as Informational document
Aug 2010Working Group Last Call for architecture survey
Aug 2010Working Group Last Call for requirements
Oct
2010Submit architecture survey to IESG as Informational document
Oct 2010Submit requirements to IESG as Informational document
Apr 2011Working Group Last Call for PPSP peer protocol
Apr
2011Working Group Last Call for PPSP tracker protocol
Aug 2011Submit PPSP peer protocol to IESG as Proposed Standard
Aug 2011Submit PPSP tracker protocol to IESG as Proposed Standard
Nov 2011Working Group Last Call of usage document
Nov 2011Working Group Last Call of mobility BCP document
Jan 2012Submit usage document to IESG as Informational document
Jan 2012Submit mobility BCP document to IESG as Informational document
Apr 2012Dissolve or re-charter 

zhangyunfei
2009-09-10

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

---

From: Ping Pan <[email-masked]>
Date: Fri, 11 Sep 2009 08:55:56 -0700

2009/9/11 Ning Zong <[email-masked]>
> I think the scope of PPSP is based on the components of P2P streaming systems. We have narrowed the scope down to PPSP tracker and peer protocols, as pointed in charter.

Agree. Actually, this is the part that is really interesting. You guys
have done some very impressive original work in this area. For many of
us, it's been an eye-opener. :-) Thanks!

> Regarding why the end users need to implement PPSP protocol, I think you are right that current subscribers of main P2P streaming vendors (e.g. PPlive) would not do that. But from other ISP's persp…

This is my original point. The work needs to be clarified and
validated by the potential users, in terms of what specific problems
it's solving, why they are problems, why PPSP is a preferred solution,
and how the users (ISP's, media guys and end users) may benefit from
it.

In case of mobility, I wonder if it's the access/backhaul bandwidth
that concerns the mobile providers, or the actual user applications
running on the phones that make them tick. If latter, like to know why
PPSP helps them. :-)

> Anyway, whether the PPSP protocol applies to end users or not depend on who would use PPSP protocol. In WG level, we are just developing open protocols/tools which are missing parts towards open P2…

OK. Please make sure the documents reflect this.

Many thanks!

Regards,

- Ping

> Ning Zong

Regards,

- Ping

---

From: Yong Lucy <[email-masked]>
Date: Fri, 11 Sep 2009 11:03:49 -0500

Hi Ning,

I agree your statement here. But I think the charter description is not as
clear as your statement here. The confusion is in the first paragraph. Based
on your statement, PPSP WG works on standard protocols in P2P streaming
systems. P2P streaming system has two components, peer and tracker. This
will be very clear. 

The participation entities listed in the charter is related to the
applicability of P2P streaming system, not P2P streaming system itself.
Whether P2P streaming system provider wants to deploy the system on which
device is provider business decision. Provider may or may not work out with
their users on content sharing. Thus, end-user device may or may not be a
peer in the system. This is not relevant to P2P streaming system
architecture and protocols itself.

Suggest revising the first paragraph as

The Peer-to-Peer (P2P) Streaming Protocol working group (PPSP WG) is
chartered to develop standard signaling protocols (called PPSP protocols)
for the communications among P2P system components, peers or peer trackers
via both fixed and mobile Internet.

Consider adding third paragraph to highlight the applicability.

Best Regards,

Lucy

 

  _____  

From: Ning Zong [mailto:[email-masked]] 
Sent: Friday, September 11, 2009 9:25 AM
To: Ping Pan
Cc: Yong Lucy; 'Schmidt, Christian 1. (NSN - DE; ext zhangyunfei;
[email-masked]
Subject: Re: Re: Re: Re: [ppsp] ppsp charter discussion

Hi, Ping,

Thank you for suggestions. I agree that narrow down our work is very
important and will make our work more clear.

I think the scope of PPSP is based on the components of P2P streaming
systems. We have narrowed the scope down to PPSP tracker and peer protocols,
as pointed in charter.

But my point is that as standard tools (note that we are not building a
streaming system), PPSP tracker and peer protocols can be applied to either
network devices such as cache and CDN, or end users.

Regarding why the end users need to implement PPSP protocol, I think you are
right that current subscribers of main P2P streaming vendors (e.g. PPlive)
would not do that. But from other ISP's perspective, it maybe beneficial to
run standard protocols. For instance, in China Mobile's document, it is
discussed that open protocol would have benefits esp. for mobile terminals,
etc. Of course, we need more ISPs and streaming vendors to contribute to our
work here.

Anyway, whether the PPSP protocol applies to end users or not depend on who
would use PPSP protocol. In WG level, we are just developing open
protocols/tools which are missing parts towards open P2P streaming system.
Another words, we can (and actually have) narrow down our scope in protocol
level. But shall we need to narrow down our work regarding who will use our
protocol? Maybe no.

2 cents.

BR,

Ning Zong 

  _____  

Ning,

Here is my main concern: currently, PPSP is positioned as yet another
streaming protocol to the end users.

IMHO, the end users can care less where the traffic are streaming from so
long it's convenient, safe and have reasonable QoE. Do we need another
streaming protocol to do this?

One may argue the advantages in P2P. But, to many, PPSP is actually
endorsing the following:

*	I need to install a special software from the ASP's, which may use
my local CPU and storage for P2P operation, and do some other things that I
don't know about. 
*	The software enables me to watch some movies from the peers, who may
be chased by the lawyers from some media companies.  
*	On top of that, the service networks, especially, those who have to
pay for the expensive backhaul links, may be sick of the traffic volume, and
may install DPI boxes at every possible intersection to drop my video stream
traffic (here goes my QoE). 

In short, I don't think it's wise to address all of the above in one WG, one
architecture or one protocol. Rather, it would be nice to focus on what P2P
streaming is good at, use it to solve a couple of real problems, and move on
to the next.

*	Cost efficiency: I saw a presentation from last IETF's P2PRG (from
Rich Woundy?), where it takes a $3,000 PC to support 5,000 concurrent
streams. That's cheap! 
*	Simplicity: it never occurred to me that why we must have storage
servers, called CDN, sitting all over the place, while some simple caching
would be sufficient. In PPlive's Sigcomm paper, it mentioned of using 8/12G
of Flash only, and no harddrive. (This may help answering some copyright
concerns). 
*	Portability: people may argue uplink vs. inter-domain locality. But
all service providers need to do is inserting a few P2P edge caching boxes
in the network. If more locality is needed, add another one. Chunk discovery
and tracker manager are perfect for this. 

This is the line of reasoning I had: why not narrow the scope of PPSP, and
solve the caching problem first?

Once again, I don't think PPSP needs to deal with end users for now. In
fact, by forcing an open standard, you are taking away the leverage from the
existing P2P media companies, including PPlive and PPstream (as mentioned in
another draft of yours :-)). Nobody wins!

0.5 cents,

- Ping

Hi, Ping,

End users will run PPSP. As addressed in charter, PPSP protocols could run
on multiple entities such as end users, caches, CDN nodes, etc.

Here we talk about the standard protocols running on end users. What do you
mean by non-technical issues? If you mean security, privacy and copyrights
issues, I think not only PPSP, but some other BoF/WGs have same issues. You
are perfectly right, they will be not in the working scope (but need some
considerations during the WG work).

BR,

Ning Zong 

  _____  

Ning,

So, curious, does it require the end users to run PPSP as well? The problem
statement draft (draft-zhang-ppsp-problem-statement-04.txt) seems to assume
that is the case. (If I am not mistaken, all the "proprietary protocols"
listed in Section 3.1 are client P2P applications). If yes, you have a wide
scope of non-technical issues to deal with. If no, then you need to make it
clear in the documents.

Ping

Hi, Ping,

  _____  

Ning,

I'd think that it is very important to emphasis the target users of the
work, which has been quoted as "intelligent endpoints, caches, content
distribution network nodes, and/or other edge devices."

If possible, I would hope that further specification, clarification and
constraints to be added in one of the documents.

The reasoning is that, if the work is to enable further proliferation of P2P
clients within the networks, then the WG needs to address issues including
security, privacy and copyrights extensively. This may be above and beyond
technology, and is probably outside the scope of PPSP.

On the other hand, if the work is to enable more efficient streaming content
distribtution within a controlled environment by leveraging mechanisms such
as tracker management and chuck discovery, then the work is well understood,
and can be clearly defined, specified and experimented in the near future.

[Ning Zong] If I understand your question correctly, this is related to the
incentives of PPSP work. The clarification of incentives are further
provided in problem statement. IMO, the second point in your comments is
closer to current intention of PPSP. To be brief, the intention include
(maybe not limited to): 1) enable more efficient streaming to integrate 3rd
party devices, e.g. cache/CDN nodes; 2) enable streaming vendors to
accomplish content distribution via some standard API, thus reduce the
time-to-market and maybe cost, we hope; 3) enable ISPs to construct standard
streaming platform to run content provisioning services.

2 cents,

- Ping

Hi, Lucy

The participating entities in the first paragraph include both peers and
trackers in P2P streaming systems. In second paragraph, we discuss the roles
of trackers - assuming that people know the basic meaning of peers.

Formal definitions of PPSP peers and PPSP trackers are defined in Problem
Statement Draft.

BR,

Ning Zong

  _____  

Hi YunFei and Christian,

One clarification: "participating entities" listed in the text are the peer
in P2P streaming systems, is that right? Thus, "PPSP" trackers are another
participator in the systems.  Suggest stating that clearly in the first
paragraph.

Cheers,

Lucy

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Schmidt, Christian 1. (NSN - DE/Munich)
Sent: Thursday, September 10, 2009 3:03 AM
To: ext zhangyunfei; [email-masked]
Subject: Re: [ppsp] ppsp charter discussion

Hi Yunfei,

after reading your charter proposal, a text proposal and 2 questions for
clarifications.

Best Regards

Christian Schmidt

Old text:

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.

PPSP protocols include the PPSP tracker protocol - a signaling protocol
between "PPSP trackers" and "PPSP peers", and the PPSP peer protocol - a
signaling protocol among "PPSP peers". A PPSP tracker maintains lists of
participating PPSP peers, each for a specific channel or streaming file, and
answers the queries from PPSP peers for candidate PPSP peers. PPSP peers
inform their status information to PPSP trackers, exchange their chunk
availability with other PPSP peers and/or PPSP trackers, and ask other PPSP
peers for wanted data. 

New text:

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

For a specific channel or streaming file, a PPSP tracker maintains lists of
particiating PPSP peers. The PPSP tracker answers queries from PPSP peers
for candidate PPSP peers. PPSP peers provide their status information to
PPSP trackers, exchange their chunk availability with other PPSP peers
and/or PPSP trackers, and ask other PPSP peers for wanted data. PPSP
protocols include the PPSP tracker protocol - a signaling protocol between
"PPSP trackers" and "PPSP peers", and the PPSP peer protocol - a signaling
protocol among "PPSP peers". 

Architectural survey

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

It is good to have a description of the current P2P streaming architecture.
What is missing is the relation to the PPSP work. Will it contain a proposal
for the PPSP architecture?

Usage document

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.

 

 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
zhangyunfei
Sent: Thursday, September 10, 2009 8:24 AM
To: [email-masked]
Subject: [ppsp] ppsp charter discussion

Dear all,

   The following is the modified version of PPSP charter(An early version
was published in the IETF PPSP wiki page).Please review it and any comments
and suggestions are highly appreciated.

           BR

            Yunfei

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.

PPSP protocols include the PPSP tracker protocol - a signaling protocol
between "PPSP trackers" and "PPSP peers", and the PPSP peer protocol - a
signaling protocol among "PPSP peers". A PPSP tracker maintains lists of
participating PPSP peers, each for a specific channel or streaming file, and
answers the queries from PPSP peers for candidate PPSP peers. PPSP peers
inform their status information to PPSP trackers, exchange their chunk
availability with other PPSP peers and/or PPSP trackers, and ask other PPSP
peers for wanted data. 

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 chunk availability. The protocol will also
define the requests and responses of 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.

7. Optionally a "mobile usage document" (PPSP mobile BCP document) to
evaluate PPSP with and without Mobile IP support when there are a lot of
mobile peers in the system.

The work planned for the PPSP WG is distinct from, but requires close
participation with, work in other IETF WGs, particularly P2PSIP, ALTO and
MMUSIC. The PPSP WG assumes that it cannot modify baseline P2PSIP, ALTO, and
MMUSIC behaviors. If PPSP determines that extensions to P2PSIP, ALTO, 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/privacy issues. The protocol
document will contain a complete description of the security/privacy 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.

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-09-10

  _____  

  _____  

  _____  

  _____

---

From: "Y.J. Gu" <[email-masked]>
Date: Mon, 14 Sep 2009 13:32:06 +0800

Hi Ning, 
I'm sorry I missed the discussion of this draft, I've just read it.
I'm not very clear about the following terms.
Video ID: is it a descriptive strings of the video name, or a numerable
label represents the name, or a hash of "name and related information".
Chunk ID: are the chunk ids, for a particular movie, sequent series start
from, e.g., 1? Or they are discontinuous numbers that show the offset from
the start of chunk to the start of the movie?
 
Meanwhile, I have some comments on the text.
First,  how about defining two separate data structures for
PeerRegistrationData and PeerStorageData. 
PeerRegistrationData should be much simple, which only contains the node id
of the registration peer and the chunks it has. It's only used when a peer
want to send chunk registration infor.
struct {
  Destination    destination_id;
  uint16         chunk_id_list_length;
  ChunkID        chunk_id_list[chunk_id_list_length];
  } PeerRegistrationData;
 
PeerStorageData is used when a storage peer combine and store the chunk
registration information, as well as when a peer fetch the indication of
where to download the chunk. It also can be used when a storage peer, who is
going to drop, transfer the registration information stored on it to a
successor storage peer.
    typedef opaque       ChunkID[2];
 
    struct {
      Destination    destination_id;
      uint16         chunk_id_list_length;
      ChunkID        chunk_id_list[chunk_id_list_length];
    } DestChunkData
 
    struct {
      uint16         destination_id_list_length;
      DestChunkData  destination_chunk_list[destination_id_list_length];
    } PeerStorageData;

Second,  you suggest that a peer can tell the storage peer what other chunks
it has within one registration message. For example, Peer A:
 
      Movie A:Chunk 1 -> 1234, {1, [ {1234, 2, [Chunk 1, Chunk 2]} ] }   
      Movie A:Chunk 2 -> 1234, {1, [ {1234, 2, [Chunk 1, Chunk 2]} ] }
It's a good way to accelerate the process of chunk discovery. However, if
registration peer is designed to carry these additional infor in every
registration message it sends, there might be a cumulated increase in the
chunk list, and extremely waste. It's meaningful when peer A do its first
registration on a particular storage peer, it can register all the chunks it
has by one message. 
 
Last, in section 6, you suggest that peer reports to tracker coarse
information (i.e.
      Video-ID). I think it's useful for Live streaming, where peers
watching the same chunk. However, for VoD, peers choose such different
chunks that a coarse infor may not help tracker to decide which peers might
have the chunks and should be replied to the request peer. 
 
 my two cents.

Regards

Yingjie Gu