Subject: Re: [ppsp] ppsp charter discussion

From: Ning Zong <[email-masked]>
Date: Thu, 10 Sep 2009 17:15:16 -0300

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: Thu, 10 Sep 2009 14:55:43 -0700

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

>  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.
>
>>  ------------------------------
>>  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
>>
>>> 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.
>>>  ------------------------------
>>>
>>> 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,
>>>
>>> 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*
>>>
>>> *--------------------------------------------------------*
>>>
>>> *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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>> 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: "Woundy, Richard" <[email-masked]>
Date: Thu, 10 Sep 2009 18:17:02 -0400

>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!

That wasn’t me, that was Omer Luzzatti of RayV. See slide 8 of http://www.ietf.org/proceedings/75/slides/P2PRG-8.pdf. 

-- Rich

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ping Pan
Sent: Thursday, September 10, 2009 5:56 PM
To: Ning Zong
Cc: [email-masked]
Subject: Re: [ppsp] ppsp charter discussion

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,

BR,

Ning Zong 

________________________________

Ning,

Ping

Hi, Ping,

________________________________

Ning,

2 cents,

- Ping

Hi, Lucy

BR,

Ning Zong

________________________________

Hi YunFei and Christian,

Cheers,

Lucy

________________________________

Hi Yunfei,

Best Regards

Christian Schmidt

Old text:

New text:

Architectural survey

Usage document

 

 

________________________________

Dear all,

           BR

            Yunfei

Goals and Milestones:

Apr 2010

Jun 2010

Aug 2010

Aug 2010

Oct

2010

Oct 2010

Apr 2011

Apr

2011

Aug 2011

Aug 2011

Nov 2011

Nov 2011

Jan 2012

Jan 2012

Apr 2012

Dissolve or re-charter 

________________________________

zhangyunfei

2009-09-10

________________________________

________________________________

________________________________

---

From: Ping Pan <[email-masked]>
Date: Thu, 10 Sep 2009 15:25:34 -0700

Rich,
Thanks for the correction.

Ping Pan  (408) 655-6547

On Thu, Sep 10, 2009 at 2:55 PM, Ping Pan <[email-masked]> wrote:

>    - 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
> 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!
>    - 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
>> 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
>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> 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.

---

From: "Roni Even" <[email-masked]>
Date: Wed, 16 Sep 2009 14:04:17 +0300

Hi Ping,

Maybe you should look at the DECADE work https://www.ietf.org/mailman/listinfo/decade 

There was a BAR BOF in Stockholm discussing caching solutions for P2P applications.

The scope of PPSP is to address the protocol from peers to tracker and between peers in order to get the relevant chunks. 

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ping Pan
Sent: Friday, September 11, 2009 1:26 AM
To: Ning Zong
Cc: [email-masked]
Subject: Re: [ppsp] ppsp charter discussion

Rich,

Ping Pan  (408) 655-6547

Ning,

0.5 cents,

- Ping

Hi, Ping,

BR,

Ning Zong 

  _____  

Ning,

Ping

Hi, Ping,

  _____  

Ning,

2 cents,

- Ping

Hi, Lucy

BR,

Ning Zong

  _____  

Hi YunFei and Christian,

Cheers,

Lucy

  _____  

Hi Yunfei,

Best Regards

Christian Schmidt

Old text:

New text:

Architectural survey

Usage document

 

 

  _____  

Dear all,

           BR

            Yunfei

Goals and Milestones:

Apr 2010

Jun 2010

Aug 2010

Aug 2010

Oct

2010

Oct 2010

Apr 2011

Apr

2011

Aug 2011

Aug 2011

Nov 2011

Nov 2011

Jan 2012

Jan 2012

Apr 2012

Dissolve or re-charter 

  _____  

zhangyunfei

2009-09-10

  _____  

  _____  

  _____

---

From: Ping Pan <[email-masked]>
Date: Wed, 16 Sep 2009 08:02:04 -0700

Roni,

The DECADE BAR BOF had presented the the problem statement as:

- How are P2P contents detected and stored in in-network storage?
- How are P2P contents discovered and read from in-network storage?
- What is the protocol to communicate with in-network storage?

IMO, the work is best exemplified by the SAILOR proposal. If I am not
mistaken, DECADE is to deal with STORAGE using P2P as the underlying
transport mechanism.

It's not clear to me though if DECADE is also going to introduce a protocol
that is similar to PPSP, or are they the same? If DECADE is well defined and
focused, what are we doing in PPSP? :-)

Anyway, I am not objecting the PPSP work. Rather, if PPSP is to define the
protocol between P2P nodes and the interaction with the tracker manager
during streaming applications, and can be extended and addressed in the area
of content access control in the future, then say so and focus on it in
various drafts.

Thanks!

Ping

On Wed, Sep 16, 2009 at 4:04 AM, Roni Even <[email-masked]> wrote:

>  Hi Ping,
>
> Maybe you should look at the DECADE work
> https://www.ietf.org/mailman/listinfo/decade
>
> The scope of PPSP is to address the protocol from peers to tracker and
> between peers in order to get the relevant chunks.
>
>
>
> Roni Even
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Ping Pan
> *Sent:* Friday, September 11, 2009 1:26 AM
> *To:* Ning Zong
> *Cc:* [email-masked]
>
> 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
> [Ning Zong] If I understand your question correctly, this is related to the
> incentives of PPSP work. The clarification of incentives are further
> 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)
> For a specific channel or streaming file, a PPSP tracker maintains lists of
> particiating PPSP peers. The PPSP tracker answers queries from PPSP peers
> 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
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *ext zhangyunfei
> *   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*
>
> 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
> 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.
>
>
>

---

From: "Roni Even" <[email-masked]>
Date: Wed, 16 Sep 2009 18:30:33 +0300

Ping,

The idea is to address a topic that people feel should be addressed, in the PPSP after looking at the full architecture the feeling was that the first thing to address is the tracker and peers interoperability. The result may be a protocol or an extension to an existing protocol which at the IETF is the preference.

So in the case of PPSP the focus is on finding the information about who holds the content while I think that DECADE will address the caching topic, I think the proposal is to define a P2P application-agnostic in-network storage access protocol that will be used for caching.

For all this work once the problem statement and requirements are clear a solution is needed which like I said may leverage existing protocols if appropriate.

Roni Even

From: Ping Pan [mailto:[email-masked]] 
Sent: Wednesday, September 16, 2009 6:02 PM
To: Roni Even
Cc: Ning Zong; [email-masked]
Subject: Re: [ppsp] ppsp charter discussion

Roni,

IMO, the work is best exemplified by the SAILOR proposal. If I am not mistaken, DECADE is to deal with STORAGE using P2P as the underlying transport mechanism.

It's not clear to me though if DECADE is also going to introduce a protocol that is similar to PPSP, or are they the same? If DECADE is well defined and focused, what are we doing in PPSP? :-)

Anyway, I am not objecting the PPSP work. Rather, if PPSP is to define the protocol between P2P nodes and the interaction with the tracker manager during streaming applications, and can be extended and addressed in the area of content access control in the future, then say so and focus on it in various drafts.

Thanks!

Ping

Hi Ping,

Roni Even

Rich,

Ping Pan  (408) 655-6547

Ning,

0.5 cents,

- Ping

Hi, Ping,

BR,

Ning Zong 

  _____  

Ning,

Ping

Hi, Ping,

  _____  

Ning,

2 cents,

- Ping

Hi, Lucy

BR,

Ning Zong

  _____  

Hi YunFei and Christian,

Cheers,

Lucy

  _____  

Hi Yunfei,

Best Regards

Christian Schmidt

Old text:

New text:

Architectural survey

Usage document

 

 

  _____  

Dear all,

           BR

            Yunfei

Goals and Milestones:

Apr 2010

Jun 2010

Aug 2010

Aug 2010

Oct

2010

Oct 2010

Apr 2011

Apr

2011

Aug 2011

Aug 2011

Nov 2011

Nov 2011

Jan 2012

Jan 2012

Apr 2012

Dissolve or re-charter 

  _____  

zhangyunfei

2009-09-10

  _____  

  _____  

  _____

---

From: Ning Zong <[email-masked]>
Date: Thu, 17 Sep 2009 09:00:44 +0800

Hi, Ping,

I don't think DECADE will use P2P as the underlying transport mechanism.
(Actually could you explain more about why P2P would be regarded as
transport mechanism? Because to my knowledge, P2P itself has not been used
for transport yet. Currently, P2P is just capability or architecture for
organizing the nodes.)

Although the main motivation of DECADE is to solve some P2P problems (see
DECADE p.s.). A DECADE client will rely on a P2P or non-P2P mechanism to
locate where the data is. This step could be PPSP/Reload or whatever, which
is independent of DECADE protocols. The DECADE protocols will then be
applied between DECADE client and DECADE server (a.k.a. in-network storage)
to transfer data to the DECADE client, or control the data transfer (e.g.
auth / resource control, etc).

So the position of PPSP is more close to resource discovery, while DECADE
focuses on data transmission.

Maybe I didn't answer your questions? Comments are welcome then.

BR,

Ning Zong

  _____  

From: Ping Pan [mailto:[email-masked]] 
Sent: Wednesday, September 16, 2009 11:02 PM
To: Roni Even
Cc: Ning Zong; [email-masked]
Subject: Re: [ppsp] ppsp charter discussion

Roni,

Thanks!

Ping

Hi Ping,

There was a BAR BOF in Stockholm discussing caching solutions for P2P
applications.

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ping
Pan
Sent: Friday, September 11, 2009 1:26 AM
To: Ning Zong
Cc: [email-masked]

Rich,

Ping Pan  (408) 655-6547

Ning,

*	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).

*	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.

0.5 cents,

- Ping

Hi, Ping,

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,

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

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:

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

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

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).

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 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).

Goals and Milestones:

Apr 2010

Jun 2010

Aug 2010

Aug 2010

Oct

2010

Oct 2010

Apr 2011

Apr

2011

Aug 2011

Aug 2011

Nov 2011

Nov 2011

Jan 2012

Jan 2012

Apr 2012

Dissolve or re-charter 

  _____  

zhangyunfei

2009-09-10

  _____  

  _____  

  _____