Subject: [ppsp] Latest updated version of PPSP charter

From: "zhangyunfei" <[email-masked]>
Date: Thu, 21 Jan 2010 11:19:45 +0800

Hi all,
  I have updated the PPSP charter according to the recent hot discussion in the mailing list.The main changes are basically based on David,Gonzalo,Christian,Victor,Alberto,Yingjie,Ning,Haibin,Bin and all others' comments.Thanks so much for all of your valuable suggestions and please have a final review of the charter.Gonzalo and I would like to submit it to Lars based on the consensus in the 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(e.g., live and VoD streaming)in both fixed and mobile Internet. 

There are two kinds of components in PPSP protocols, i.e., “trackers” and “peers”. Trackers index the dynamic peers for certain content and peers cache and share dynamic content. 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; 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 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 and peer properties 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. This document will also consider the specific usages in deploying PPSP, e.g., the usage of multiple streams or layered media and related media data chunk description in peer protocol for a more robust streaming.

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.

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. Basic 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:
Apr2010Working Group Last Call for problem statement
Jun2010Submit problem statement to IESG as Informational document
Aug2010Working Group Last Call for architecture survey
Aug2010Working Group Last Call for requirements
Oct2010Submit architecture survey to IESG as Informational document
Oct2010Submit requirements to IESG as Informational document
Apr2011Working Group Last Call for PPSP peer protocol
Apr2011Working Group Last Call for PPSP tracker protocol
Aug2011Submit PPSP peer protocol to IESG as Proposed Standard
Aug2011Submit PPSP tracker protocol to IESG as Proposed Standard
Nov2011Working Group Last Call of usage document
Nov2011Working Group Last Call of mobility BCP document
Jan2012Submit usage document to IESG as Informational document
Jan2012Submit mobility BCP document to IESG as Informational document
Apr2012Dissolve or re-charter 

zhangyunfei
2010-01-21

---

From: Lars Eggert <[email-masked]>
Date: Thu, 21 Jan 2010 13:11:47 +0200

Hi,

On 2010-1-21, at 5:19, zhangyunfei wrote:
> Gonzalo and I would like to submit it to Lars based on the consensus in the mailing list.

thanks for the charter proposal. I've taken your version and edited it a bit further. Please find my version below and let me know if you agree or disagree with what you see.

Here's what I changed:

- reworded the description of the scope a bit and removed some duplication between the introductory paragraphs and the work items

- removed some "this is out of scope" text, because it's implied (everything not listed is out of scope...)

- cut the text about security; it's clear this will be needed so we don't need it specifically on the charter

- cut mentioning the P2PRG; again, it's clear we'll work with them as/if needed

- removed the "mobility BCP document" work item, since it wasn't talked about anywhere in the charter so far?

- bumped the milestone dates a bit & just listed "submit to IESG" milestones

Lars

Peer-to-Peer Streaming Protocol (PPSP) 
--------------------------------------------------
Current Status: Proposed Working Group

Chair(s):
  TBD

Transport Area Director(s):
  Magnus Westerlund <[email-masked]>
  Lars Eggert <[email-masked]>

Transport Area Advisor:
  Lars Eggert <[email-masked]> 

Mailing Lists:
  [email-masked]

Description of Working Group:

The Peer-to-Peer Streaming Protocol (PPSP) working group develops
two signaling and control protocols for a peer-to-peer (P2P) streaming
system for transmitting live and pre-recorded media content.

Two kinds of nodes exist in the targeted P2P streaming system, i.e.,
"peers" and "trackers". Peers are nodes that are actively sending
and receiving streamed media content, and include both statically
connected hosts as well as mobile devices with connectivity and IP
addresses that change over time. The set of peers that are participating
in a streaming session will dynamically change over time. Trackers
are well-known nodes with stable connectivity that maintain meta
information about the streamed content and the dynamic peer set.

The PPSP WG designs a protocol for signaling and control between
trackers and peers (the PPSP "tracker protocol") and a signaling
and control protocol for communication among the peers (the PPSP
"peer protocol"). The two protocols enable peers to receive streaming
data within the time constraints required by specific content items.
The tracker protocol handles the initial and periodic exchange of
meta information between trackers and peers, such as peer lists and
content information. The peer protocol controls the advertising and
exchange of media data between the peers.

Existing IETF and other standards will be used for the encoding and
transmission of the media content between peers. PPSP is not chartered
to work on media transmission protocols, media encoding techniques
or other components of a P2P streaming system such as playout
scheduling and control, etc.

The work items of the PPSP WG are:

  (1) A "problem statement" document that gives an overview of the
      proposed P2P streaming system, motivates the desire for 
      standardized protocols, defines the envisioned scope of those
      standardized components and discusses common terminologies and
      concepts.

  (2) A "requirements" document that details the specific functional,
      operational and performance requirements of the two PPSP protocols.

  (3) An "architectural survey" document that summarizes current
      P2P streaming architectures, in particular tracker-based P2P
      streaming systems, and highlights best current practices.

  (4) A detailed specification of the PPSP peer protocol.

  (5) A detailed specification of the PPSP tracker protocol.

  (6) A "usage guide" that describes how the two PPSP protocols and
      existing IETF protocols, such as RELOAD, ALTO or RTSP, can be
      combined to create a deployable operational P2P streaming system.
      This document may also discuss variants of such a system that,
      for example, use layered media encoding and related media chunk
      descriptions in peer protocol for more robust streaming.

The work items of the PPSP WG interacts with the work performed in
other IETF WGs, including P2PSIP, ALTO, LEDBAT and MMUSIC. Whenever
extensions or modification to the protocols developed in other WGs
are deemed necessary, PPSP shall communicate and discuss the
requirements for such extensions with the relevant WGs. The design
of such extensions is out of scope for PPSP.

Goals and Milestones:

Dec 2010   Submit problem statement to IESG as Informational
Apr 2011   Submit architectural survey to IESG as Informational
Apr 2011   Submit requirements document to IESG as Informational
Aug 2011   Submit PPSP peer protocol to IESG as Proposed Standard 
Aug 2011   Submit PPSP tracker protocol to IESG as Proposed Standard
Dec 2011   Submit usage guide to IESG to IESG as Informational

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 22 Jan 2010 09:32:28 +0800

Hi Lars,
   Thanks so much for your review and carefully modification.The charter looks perfect and more clear.I agree with all your changes on PPSP charter.Sincerely thanks for all your help in moving forward PPSP and wish it can be appproved by IESG successfully.

Best regards,
Yunfei

zhangyunfei
2010-01-22

发件人： Lars Eggert
发送时间： 2010-01-21 19:24:30
收件人： [email-masked]
抄送： 
主题： Re: [ppsp] Latest updated version of PPSP charter

Hi,

Here's  what  I  changed:

Lars

Chair(s):
   TBD

Transport  Area  Director(s):
   Magnus  Westerlund   <[email-masked] >
   Lars  Eggert   <[email-masked] >

Transport  Area  Advisor:
   Lars  Eggert   <[email-masked] >  

Mailing  Lists:
   [email-masked]

Goals  and  Milestones:

Dec  2010      Submit  problem  statement  to  IESG  as  Informational
Apr  2011      Submit  architectural  survey  to  IESG  as  Informational
Apr  2011      Submit  requirements  document  to  IESG  as  Informational
Aug  2011      Submit  PPSP  peer  protocol  to  IESG  as  Proposed  Standard  
Aug  2011      Submit  PPSP  tracker  protocol  to  IESG  as  Proposed  Standard
Dec  2011      Submit  usage  guide  to  IESG  to  IESG  as  Informational
_______________________________________________
ppsp  mailing  list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Fri, 22 Jan 2010 17:37:57 -0500

Hi Lars,

The problem statement mentions the need to consider mobility in the
context of PPSP, e.g.:

" It is worth mentioning at this point that the development of PPSP
   should consider the requirements of mobile Internet.  For example,
   the overhead of PPSP be small in low bandwidth mobile Internet.
   Also, information exchange in PPSP should support mobility, low
   battery and heterogeneous capabilities of mobile terminals."

I would suggest leaving the "mobility BCP document" work item and adding
supporting paragraphs in the charter, similar to the ones in the PS. For
instance, the following work item description can be added:
 
...

(7) 	A "mobility BCP" document describing how to better handle PPSP
over mobile networks, for instance, taking into account considerations
such as low overhead, information exchange mobility support, low battery
consumption and heterogeneous capabilities of mobile terminals.

...

Best regards,

Juan Carlos

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Lars Eggert
> Sent: Thursday, 21 January, 2010 6:12 AM
> To: [email-masked]
> Subject: Re: [ppsp] Latest updated version of PPSP charter
> 
> Hi,
> 
> thanks for the charter proposal. I've taken your version and edited it
> a bit further. Please find my version below and let me know if you
> agree or disagree with what you see.
> 
> Here's what I changed:
> 
> - reworded the description of the scope a bit and removed some
> duplication between the introductory paragraphs and the work items
> 
> - removed some "this is out of scope" text, because it's implied
> (everything not listed is out of scope...)
> 
> - cut the text about security; it's clear this will be needed so we
> don't need it specifically on the charter
> 
> - removed the "mobility BCP document" work item, since it wasn't
talked
> about anywhere in the charter so far?
> 
> The Peer-to-Peer Streaming Protocol (PPSP) working group develops two
> signaling and control protocols for a peer-to-peer (P2P) streaming
> "peers" and "trackers". Peers are nodes that are actively sending and
> receiving streamed media content, and include both statically
connected
> hosts as well as mobile devices with connectivity and IP addresses
that
> change over time. The set of peers that are participating in a
> streaming session will dynamically change over time. Trackers are
well-
> known nodes with stable connectivity that maintain meta information
> about the streamed content and the dynamic peer set.
> 
> trackers and peers (the PPSP "tracker protocol") and a signaling and
> control protocol for communication among the peers (the PPSP "peer
> protocol"). The two protocols enable peers to receive streaming data
> within the time constraints required by specific content items.
> The tracker protocol handles the initial and periodic exchange of meta
> information between trackers and peers, such as peer lists and content
> information. The peer protocol controls the advertising and exchange
of
> media data between the peers.
> 
> to work on media transmission protocols, media encoding techniques or
> other components of a P2P streaming system such as playout scheduling
> and control, etc.
> 
> extensions or modification to the protocols developed in other WGs are
> deemed necessary, PPSP shall communicate and discuss the requirements
> for such extensions with the relevant WGs. The design of such
> extensions is out of scope for PPSP.
> 
> 
> Goals and Milestones:
>

---

From: Lars Eggert <[email-masked]>
Date: Sat, 23 Jan 2010 08:22:25 +0200

Hi,

>   battery and heterogeneous capabilities of mobile terminals."

you're quoting the previous charter text. 

> consumption and heterogeneous capabilities of mobile terminals.

I agree that mobile peers need to be supported and the new charter says so, but I believe this will need to be done as part of the protocol specifications and cannot be done as an add-on document. In other words, we've always found out that it is very difficult if not impossible to design something and then add "mobility support" to it later.

Lars

---

From: "zhangyunfei" <[email-masked]>
Date: Sat, 23 Jan 2010 17:37:21 +0800

Hi Juan Carlos,
   Some mobile support description is as follows in the new charter.Please refer to it.
*********************************************
Two kinds of nodes exist in the targeted P2P streaming system, i.e.,"peers" and "trackers". Peers are nodes that are actively sending and receiving streamed media content, and include both statically connected hosts as well as mobile devices with connectivity and IP addresses that change over time.
*********************************************
    And I think we can share the pracitce of deploying PPSP with mobile devices participation in the "usage guide" document.
    Thanks for your suggestion.

BR
Yunfei 

zhangyunfei
2010-01-23

发件人： Lars Eggert
发送时间： 2010-01-23 14:35:48
收件人： Zuniga, Juan Carlos
抄送： [email-masked]
主题： Re: [ppsp] Latest updated version of PPSP charter

Hi,

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

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Mon, 25 Jan 2010 10:44:46 -0500

Yunfei, Lars,

I agree that mobility should be taken into account from the beginning, and if you both believe that the work will fulfill the mobility requirements then I’m fine with it.

Thanks for the clarifications.

Regards,

Juan Carlos

From: [email-masked] [mailto:[email-masked]] On Behalf Of zhangyunfei
Sent: Saturday, 23 January, 2010 4:37 AM
To: Lars Eggert; Zuniga, Juan Carlos
Cc: [email-masked]
Subject: Re: [ppsp] Latest updated version of PPSP charter

Hi Juan Carlos,

BR

Yunfei 

________________________________

zhangyunfei

2010-01-23

________________________________

发件人： Lars Eggert

收件人： Zuniga, Juan Carlos

抄送： [email-masked]

Hi,

 

ppsp  mailing  list

[email-masked]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 26 Jan 2010 20:59:29 +0200

Hi,

I think this charter proposal is almost ready. Thanks everyone for your
comments! A few extra comments from my side:

The charter needs to state that the WG will take into account real-time
requirements. That is, we are not building a file sharing system but a
system that can handle real-time streams. The charter already says that
live streaming is within scope. You may or may not want to further
stress this point.

At the last BOF, there were people who were confused by the term
"signalling" protocol. They assumed that a signalling or control
protocol would not carry data... but the protocol to be used between
peers will actually transfer data chunks. We may want to clarify that is
the case.

Also at the last BOF, there was a discussion on whether or not the WG
should address privacy issues. Privacy in terms of who is participating
in the system and who is watching a given stream. Some people (e.g.,
Dave Oran) thought this still is a research issue and, thus, should be
out of scope. Other people thought the WG should try and tackle it
because it is an important property... if people cannot agree on this,
it may be worthwhile letting those who believe it is feasible to tackle
privacy issues within the WG start working on a model to provide this
type of privacy and check at some point if that model can really resolve
the privacy issues at hand.

My 2 cents...

Cheers,

Gonzalo

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 26 Jan 2010 15:15:33 -0500

Just to make sure there is no confusion, can you clarify this comment
a bit, as I'm still a bit confused!

> peers will actually transfer data chunks. We may want to clarify that is

I think what you are saying here is that you *do* think the peer
protocol (but I assume not the tracker protocol) will actually
transfer the data. Is that correct? If so, the statement in the
charter "PPSP is not chartered to work on media transmission
protocols" seems a bit contradictory. I guess maybe I am one of those
who felt that signalling meant "not carrying data".

Are you picturing that we do use the peer protocol itself to exchange
chunks in the off-line scenario, but that some existing streaming
media protocol would be used in the live streaming scenario? (or have
I just hopelessly mangled what you meant to say ;) )

If we do transfer the chunks in the peer protocol itself rather than
using some existing bulk transfer protocol (even if just the off-line
case), depending on the transport we then have the concerns
fragmentation etc., which I would assume would then be in-scope for
the peer protocol design?

Just trying to get a handle on what you are thinking here (and see if
you and Lars are on the same page...). Thanks!

David

---

From: Victor Pascual Avila <[email-masked]>
Date: Tue, 26 Jan 2010 21:24:41 +0100

Hi,

> who felt that signalling meant "not carrying data".

My understanding is that the peer protocol won't transfer any "media",
just the information required to enable and schedule this transfer. Am
I right?

Cheers,
-- 
Victor Pascual Ávila

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 26 Jan 2010 22:24:43 +0200

Hi,

the peer protocol would handle the exchange of data chunks between
peers. Whether the peer protocol will negotiate a connection that will
carry those chunks between peers, or will carry the chunks inline in its
own protocol messages was not clear at the BOF... if we already know,
the charter text could say so. If this is for further study, the charter
text could also say so...

Cheers,

Gonzalo

---

From: "David A. Bryan" <[email-masked]>
Date: Tue, 26 Jan 2010 15:36:33 -0500

Thanks, I appreciate the clarification.

I'd say that reading the current charter text proposal from Lars as it
stands now basically says you can't transfer inline (i.e., I'd
interpret "signaling and control protocol" in para 3, and "Existing
IETF and other standards will be used for the encoding and
transmission of the media content between peers." in para 4 as
implying that transport is being done with an existing protocol, not
inline).

Personally, I am fine with charter saying either "must negotiate a
connection to be transmitted using another protocol" or "we may decide
to send inline or negotiate a connection". I expect the best choice
will be to use an existing protocol for the actual transmission of the
data in both the off-line and live cases, but am ok if we still think
that is an open question -- we would however need to refine the
charter text in that case. (Interestingly, we are having a similar
discussion over on the DECADE list about bulk data transmission
protocol reuse...).

David

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 27 Jan 2010 10:37:38 +0800

Hi,
   In my understanding,the peer protocol is exchanging the information of what peers have,rather than the real data transferring.The real data transfer is probably done by exisiting IETF protocols like UDP,TCP or RTP.
   So I would propose to update the last sentence of Para 3 of latest charter as follows:
   The peer protocol controls the advertising and exchange of media data availability between the peers.The real data transfer is probably done by exisiting IETF protocols like UDP,TCP or RTP.
   Any comments?
    P.S.:Gonzalo,I agree with your suggestions on the privacy issue.I think this may be a topic we can discuss in March meeting.
           As for the real-time requirement, the current charter says: The two protocols enable peers to receive streaming
data within the time constraints required by specific content items.

BR
Yunfei

zhangyunfei
2010-01-27

发件人： Gonzalo Camarillo
发送时间： 2010-01-27 04:37:14
收件人： David A. Bryan
抄送： [email-masked]
主题： Re: [ppsp] Latest updated version of PPSP charter

Hi,

Cheers,

Gonzalo

David  A.  Bryan  wrote:
>   <[email-masked] >  wrote:
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 27 Jan 2010 08:17:44 +0200

Hi,

>    The peer protocol controls the advertising and exchange of media data
> availability between the peers.The real data transfer is probably done
> by exisiting IETF protocols like UDP,TCP or RTP.
>    Any comments?

something along those lines would work.

>     P.S.:Gonzalo,I agree with your suggestions on the privacy issue.I
> think this may be a topic we can discuss in March meeting.

Sure.

>            As for the real-time requirement, the current charter says:
> The two protocols enable peers to receive streaming

Yes... additionally, we may want to say that some of those specific
content items will have near real-time constraints. This point was
considered important by some during the BOF since they wanted to make
sure that the protocols will also be usable in near real-time
situations. I think everybody on the list assumes that is indeed the
case but having the charter say it explicitly would not hurt.

Cheers,

Gonzalo

---

From: "zhangyunfei" <[email-masked]>
Date: Wed, 27 Jan 2010 15:19:18 +0800

Hi Gonzalo,

Sure.

Any good suggestions on the expression of the charter?

BR,

Yunfei

---

From: Lars Eggert <[email-masked]>
Date: Wed, 27 Jan 2010 11:43:38 +0200

Hi,

> live streaming is within scope. You may or may not want to further

please propose text :-)

> peers will actually transfer data chunks. We may want to clarify that is

I guess I was one of those people, and the charter text I sent was written based on that assumption. If that was a misunderstanding and the peer protocol does carry media data, we can change that text. But it needs to be clear that the peer protocol is not a media streaming protocol, just a data transfer protocol. In other words, it doesn't do all that RTP does.

> the privacy issues at hand.

That seems like a reasonable approach. I'm skeptical too that all aspects of the privacy issue are solvable, but the WG can try - we just need to be clear that if that support appears like it will add too much complexity, we're dropping it.

Lars

---

From: zongning 63316 <[email-masked]>
Date: Wed, 27 Jan 2010 12:33:10 +0100

Hi,

I agree with what Yunfei has proposed, that is, "The peer protocol controls the advertising and exchane of media data availablility between peers" which means neither data chunk, nor media streaming between peers.
However, I would suggest that PPSP consider the gap between "advertising the media data availability between peers" and "real data transfer", because there should be a signalling protocol between peers to negotiate connections. I would propose that we need at least some gap analysis to see if some existing protocols (e.g. RTSP/SDP) fits the scenarios/requirements of PPSP and thus are reused as connection negotiation following PPSP peer prot
ocol, or new signalling protocol is required as part of PPSP peer protocol to do connection negotiation.

My 2 cents,

BR,
Ning Zong

----- 原邮件 -----
发件人: zhangyunfei <[email-masked]>
日期: 星期三, 一月 27日, 2010 上午3:41
主题: Re: [ppsp] Latest updated version of PPSP charter
收件人: Gonzalo Camarillo <[email-masked]>, "David A. Bryan" <[email-masked]>,Victor_Pascual_脕vila <[email-masked]>
抄送: "[email-masked]" <[email-masked]>

> Hi,
>   In my understanding,the peer protocol is exchanging the 
> information of what peers have,rather than the real data 
> transferring.The real data transfer is probably done by exisiting 
> IETF protocols like UDP,TCP or RTP.
>   The peer protocol controls the advertising and exchange of 
> media data availability between the peers.The real data transfer 
> is probably done by exisiting IETF protocols like UDP,TCP or RTP.
>   Any comments?
>    P.S.:Gonzalo,I agree with your suggestions on the privacy 
> issue.I think this may be a topic we can discuss in March meeting.
>           As for the real-time requirement, the current charter 
> says: The two protocols enable peers to receive streaming
> >  protocol  (but  I  assume  not  the  tracker  protocol)  will  
> actually>  transfer  the  data.  Is  that  correct?  If  so,  the  
> statement  in  the
> >  charter  "PPSP  is  not  chartered  to  work  on  media  
> transmission>  protocols"  seems  a  bit  contradictory.  I  guess 
> maybe  I  am  one  of  those
> >  case),  depending  on  the  transport  we  then  have  the  
> concerns>  fragmentation  etc.,  which  I  would  assume  would  
> then  be  in-scope  for

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 28 Jan 2010 09:30:12 +0800

Agree.Just like Gonzalo's proposal on privacy issues, the gap analysis may be useful if there are some written materials to the mailing list/meetings.

BR
Yunfei

zhangyunfei
2010-01-28

发件人： zongning 63316
发送时间： 2010-01-27 19:45:30
收件人： zhangyunfei
抄送： Gonzalo Camarillo; David A. Bryan; Victor_Pascual_脕vila; [email-masked]
主题： Re: Re: [ppsp] Latest updated version of PPSP charter

Hi,

My  2  cents,

BR,
Ning  Zong

-----  原邮件  -----
发件人:  zhangyunfei   <[email-masked] >
日期:  星期三,  一月  27日,  2010  上午3:41
主题:  Re:  [ppsp]  Latest  updated  version  of  PPSP  charter
收件人:  Gonzalo  Camarillo   <[email-masked] >,  "David  A.  Bryan"   <[email-masked] >,Victor_Pascual_脕vila   <[email-masked] >
抄送:  "[email-masked]"   <[email-masked] >

>  actually >    transfer    the    data.    Is    that    correct?    If    so,    the    
>  statement    in    the
>  transmission >    protocols"    seems    a    bit    contradictory.    I    guess  
>  maybe    I    am    one    of    those
>  concerns >    fragmentation    etc.,    which    I    would    assume    would    
>  then    be    in-scope    for