Subject: [ppsp] ppsp revised charter proposal

From: "zhangyunfei" <[email-masked]>
Date: Sat, 26 Dec 2009 16:52:00 +0800

Dear all,
   The latest version of PPSP charter is attached.Welcome to comment on this.I guess many of you guys are enjoying the Christmas holiday.Merry X'mas and happy new year!Wish to hear your valuable suggestions in the beginning of 2010.:)
   Hope PPSP can have a great development in the new year with all of your participation and contribution.
The main modifications are:
1)Para 2:
a)wish to make it better understood about what the tracker protocol and the peer protocol differ in and reply the BOF comments that the two protocols may be a single one;
b)Add the NAT issue raised in the BOF;
2)Para3:
a) Para3-bullet 4,adding the gossip communication in peer protocol as discussed in the mailing list;
b)Para3-bullet7, deleted as suggested by Lars that optional part can be detered until we think it clearer;
3)Para4, adding LEDBAT as reference raised in the BOF.
4)Para5,deleting privay raised in the BOF.
5)Para6:
a)bullet1:Adding the description of considering the NAT traversal and the multiple stream senario as discussed in the BOF and mailing list.
BR
Yunfei 
*************************************************************************
Description of PPSP Working Group:
The Peer-to-Peer (P2P) Streaming Protocol working group (PPSP WG) is chartered to develop standard signaling protocols (called PPSP protocols) for multiple types of entities (e.g. intelligent endpoints, caches, content distribution network nodes, and/or other edge devices) to participate in P2P streaming systems in both fixed and mobile Internet.

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

This WG's primary tasks are to produce:
1. A “problem statement” document describing the problems, incentives, and scope of developing the PPSP protocols, as well as common terminologies and concepts.
 
2. A “requirements” document listing the requirements on the designed PPSP protocols (e.g., general functionality and performance requirements of PPSP protocols or basic types of information that PPSP protocols should communicate to facilitate P2P streaming).

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

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

5. A proposed standard defining the PPSP tracker protocol. This protocol will define how PPSP peers inform and request information from PPSP trackers and how PPSP trackers reply to the requests.
 
6. A “usage document” explaining how the protocols defined above, along with existing IETF protocols, such as RELAOD, ALTO and RTSP, can inter-operate; and how they may be integrated together to produce complete P2P streaming systems.

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

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

2. Network coding mechanisms in P2P streaming. Network coding may be used in P2P streaming, but its support is beyond the scope of current charter.
 
3. Play-out mechanisms including streaming control (e.g., pause, fast-forward, and rewind).
 
4. Algorithms that may be different in different deployments (e.g., chunk selection, local storage strategies).
 
5. Research type questions related to P2P streaming. This WG will instead forward such questions to the IRTF P2PRG or other RG as appropriate. Examples include cache management.
Goals and Milestones:
Apr 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-12-26

---

From: [email-masked]
Date: Mon, 28 Dec 2009 08:44:08 +0800

Hi,

Should the interface protocol between trackers be nessary and covered in 
PPSP?

To my understanding, peers and resource information can be exchanged 
through this interface so that streaming could be shared in a much wider 
extent.

B.R.

Merry Christmas!

Yu Meng

"zhangyunfei" <[email-masked]> 
发件人:  [email-masked]
2009-12-26 16:52

收件人
"[email-masked]" <[email-masked]>
抄送

主题
[ppsp] ppsp revised charter proposal

 Dear all,
   The latest version of PPSP charter is attached.Welcome to comment on 
this.I guess many of you guys are enjoying the Christmas holiday.Merry 
X'mas and happy new year!Wish to hear your valuable suggestions in the 
beginning of 2010.:)
   Hope PPSP can have a great development in the new year with all of your 
participation and contribution.
The main modifications are:
1)Para 2:
a)wish to make it better understood about what the tracker protocol and 
the peer protocol differ in and reply the BOF comments that the two 
protocols may be a single one;
b)Add the NAT issue raised in the BOF;
2)Para3:
a) Para3-bullet 4,adding the gossip communication in peer protocol as 
discussed in the mailing list;
b)Para3-bullet7, deleted as suggested by Lars that optional part can be 
detered until we think it clearer;
3)Para4, adding LEDBAT as reference raised in the BOF.
4)Para5,deleting privay raised in the BOF.
5)Para6:
a)bullet1:Adding the description of considering the NAT traversal and the 
multiple stream senario as discussed in the BOF and mailing list.
BR
Yunfei 
*************************************************************************
Description of PPSP Working Group:
The Peer-to-Peer (P2P) Streaming Protocol working group (PPSP WG) is 
chartered to develop standard signaling protocols (called PPSP protocols) 
for multiple types of entities (e.g. intelligent endpoints, caches, 
content distribution network nodes, and/or other edge devices) to 
participate in P2P streaming systems in both fixed and mobile Internet.

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

This WG's primary tasks are to produce:
1. A “problem statement” document describing the problems, incentives, 
and scope of developing the PPSP protocols, as well as common 
terminologies and concepts.
 
2. A “requirements” document listing the requirements on the designed 
PPSP protocols (e.g., general functionality and performance requirements 
of PPSP protocols or basic types of information that PPSP protocols should 
communicate to facilitate P2P streaming).

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

4. A proposed standard defining the PPSP peer protocol. This protocol will 
define how PPSP peers advertise data availability and exchange neighbor 
peers. The protocol will also define the requests and responses of data 
chunks among PPSP peers.
 
5. A proposed standard defining the PPSP tracker protocol. This protocol 
will define how PPSP peers inform and request information from PPSP 
trackers and how PPSP trackers reply to the requests.
 
6. A “usage document” explaining how the protocols defined above, along 
with existing IETF protocols, such as RELAOD, ALTO and RTSP, can 
inter-operate; and how they may be integrated together to produce complete 
P2P streaming systems.

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

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

2. Network coding mechanisms in P2P streaming. Network coding may be used 
in P2P streaming, but its support is beyond the scope of current charter.
 
3. Play-out mechanisms including streaming control (e.g., pause, 
fast-forward, and rewind).
 
4. Algorithms that may be different in different deployments (e.g., chunk 
selection, local storage strategies).
 
5. Research type questions related to P2P streaming. This WG will instead 
forward such questions to the IRTF P2PRG or other RG as appropriate. 
Examples include cache management.
Goals and Milestones:

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

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

---

From: [email-masked]
Date: Mon, 28 Dec 2009 09:26:15 +0800

Hi, yunfei.
Peers can exchange peer lists, right?

Best regards,
Lichun Li

收件人

主题

 Dear all,

 

 

 

 

Apr 2010

zhangyunfei

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 28 Dec 2009 10:11:43 +0800

Hi Yu,
   Thanks for the quick reply.I agree with you that peers and resource information exchange among trackers can broaden the audience scope.But I think this can be placed in a second priority currently.
   As mentioned in the problem statement draft, PPSP is the necessary component of a p2p streaming system, but not the whole part of a p2p streaming system.With highest priorty, PPSP need to solve the problem of defining the basic message interaction between trackers and peers, as well as among peers. Also this is a direct reaction for the suggestions in the BOF and in the mailing list to narrow down the scope.
   I think we may turn to consider the point you mentioned once we finish the basic protocol.Thanks again for the suggestion.

BR
Yunfei

zhangyunfei
2009-12-28

发件人： [email-masked]
发送时间： 2009-12-28 08:54:17
收件人： zhangyunfei
抄送： [email-masked]; [email-masked]
主题： 答复: [ppsp] ppsp revised charter proposal

Hi, 

Should the interface protocol between trackers be nessary and covered in PPSP? 

To my understanding, peers and resource information can be exchanged through this interface so that streaming could be shared in a much wider extent. 

B.R. 

Merry Christmas! 

Yu Meng 

"zhangyunfei" <[email-masked]> 
发件人:  [email-masked] 
2009-12-26 16:52 收件人"[email-masked]" <[email-masked]> 
抄送
主题[ppsp] ppsp revised charter proposal

 Dear all, 

  

  

  

  
  
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

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 28 Dec 2009 10:13:54 +0800

Yes,you are right,Lichun. 
As suggested in the BOF and mailing list,peer gossip(including exchange of peer list)can make peers know more peers and alleviate the burden of the tracker.

BR
Yunfei

zhangyunfei
2009-12-28

发件人： [email-masked]
发送时间： 2009-12-28 09:36:31
收件人： zhangyunfei
抄送： [email-masked]; [email-masked]
主题： re: [ppsp] ppsp revised charter proposal

Hi, yunfei. 

Best regards,
Lichun Li

 Dear all, 

  

  

  

  

 

zhangyunfei

---

From: Ning Zong <[email-masked]>
Date: Mon, 28 Dec 2009 10:20:54 +0800

Agree with Yunfei.

Interaction between Trackers would be optional at this stage.

BR,

Ning Zong

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
zhangyunfei
Sent: Monday, December 28, 2009 10:12 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ppsp] 答复: ppsp revised charter proposal

Hi Yu,

   Thanks for the quick reply.I agree with you that peers and resource
information exchange among trackers can broaden the audience scope.But I
think this can be placed in a second priority currently.

   As mentioned in the problem statement draft, PPSP is the necessary
component of a p2p streaming system, but not the whole part of a p2p
streaming system.With highest priorty, PPSP need to solve the problem of
defining the basic message interaction between trackers and peers, as well
as among peers. Also this is a direct reaction for the suggestions in the
BOF and in the mailing list to narrow down the scope.

   I think we may turn to consider the point you mentioned once we finish
the basic protocol.Thanks again for the suggestion.

BR

Yunfei

  _____  

zhangyunfei

2009-12-28

  _____  

发件人： [email-masked]

收件人： zhangyunfei

Hi, 

To my understanding, peers and resource information can be exchanged through
this interface so that streaming could be shared in a much wider extent. 

B.R. 

Merry Christmas! 

Yu Meng 

2009-12-26 16:52 

收件人

抄送

主题

 

 Dear all, 

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

1)Para 2: 

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

2)Para3: 

5)Para6: 

BR 

Yunfei 

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

There are two kinds of components in PPSP protocols, i.e., “trackers” and
“peers”. PPSP protocols include the PPSP tracker protocol – a signaling
protocol between “trackers” and “peers”, and the PPSP peer protocol – a
signaling protocol among “peers”. The two protocols ensure peers to get
streaming data within certain time constraints. PPSP tracker protocol deals
with the initial and periodical exchanges between tracker and peers:
initially the peers contact the tracker to report their static information
(like IP address, NAT types and other useful things) and get a list of peers
for a specific channel or streaming file from the tracker; periodically the
tracker maintains lists of participating peers according to the report from
the peers about their status information. PPSP peer protocol deals with the
exchanges among peers. The peer exchanges its data availability and neighbor
peer information with other peers. With these information, it can connect
with these peers for further data downloading.   
  
This WG's primary tasks are to produce:
1. A “problem statement” document describing the problems, incentives, and
scope of developing the PPSP protocols, as well as common terminologies and
concepts. 
  
2. A “requirements” document listing the requirements on the designed PPSP
protocols (e.g., general functionality and performance requirements of PPSP
protocols or basic types of information that PPSP protocols should
communicate to facilitate P2P streaming). 

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

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. 

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

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

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

  

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

---

From: [email-masked]
Date: Mon, 28 Dec 2009 10:25:39 +0800

Ok, got it! 

Ning Zong <[email-masked]> 
2009-12-28 10:20

收件人
'zhangyunfei' <[email-masked]>, [email-masked]
抄送
[email-masked]
主题
RE: [ppsp] 答复:  ppsp revised charter proposal

Agree with Yunfei.
 
BR,
Ning Zong

Hi Yu,
 
BR
Yunfei

zhangyunfei
2009-12-28

发件人： [email-masked]

Hi, 

B.R. 

Merry Christmas! 

Yu Meng 

收件人
 
主题

 Dear all, 

  

  

  

  

Apr 2010 

zhangyunfei

---

From: [email-masked]
Date: Mon, 28 Dec 2009 10:53:48 +0800

The charter says "exchange neighbor peers". I think the peer list may 
include peers other than neighbors. Peers can also exchange neighbors of 
neighbors and non-neighbor peers known from tracker. 

BR,
Lichun

2009-12-28 10:13

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: re: [ppsp] ppsp revised charter proposal

Yes,you are right,Lichun. 
As suggested in the BOF and mailing list,peer gossip(including exchange of 
peer list)can make peers know more peers and alleviate the burden of the 
tracker.
 
BR
Yunfei

zhangyunfei
2009-12-28

Hi, yunfei. 

Best regards,
Lichun Li

收件人

主题

 Dear all, 

  

  

  

  

Apr 2010 

zhangyunfei 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: "Y.J. Gu" <[email-masked]>
Date: Mon, 28 Dec 2009 13:52:50 +0800

Yes. And I' m afraid that 'neighbor peer' is not a suitable expression in
the system we are talking about.  'Neighbor peer' works  in Routing Table.

Regards

Yingjie Gu

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, December 28, 2009 10:54 AM
To: zhangyunfei
Cc: [email-masked]
Subject: Re: [ppsp] ppsp revised charter proposal

BR, 
Lichun

2009-12-28 10:13 

收件人

抄送

主题

BR 
Yunfei 

  _____  

zhangyunfei 
2009-12-28 

  _____  

Hi, yunfei. 

Best regards,
Lichun Li

2009-12-26 16:52 

收件人

抄送

主题

Dear all, 

1)Para 2: 

2)Para3: 

5)Para6: 

BR 

Yunfei 

 

 

 

 

Oct 

Apr 

Jan 2012 	Submit mobility BCP document to IESG as Informational
document 

  

  _____  

zhangyunfei 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual
sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to others.

This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of the
message. Any views expressed in this message are those of the individual
sender.

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 28 Dec 2009 14:23:56 +0800

Thanks Lichun.
According to my understanding,peers exchange the neigbor peers information,i.e. which peer remains connected and which pieces already have been downloaded. As for non-neigbor peers which it just receives from the tracker, I am really not sure about the effect of such exchange because such peers are un-confirmed.
Is there anybody who can tell us more about this point in practice?James?Harold?Omer?
Thanks!

BR
Yunfei

zhangyunfei
2009-12-28

发件人： [email-masked]
发送时间： 2009-12-28 11:04:21
收件人： zhangyunfei
抄送： [email-masked]
主题： Re: re: [ppsp] ppsp revised charter proposal

The charter says "exchange neighbor peers". I think the peer list may include peers other than neighbors. Peers can also exchange neighbors of neighbors and non-neighbor peers known from tracker. 

BR, 
Lichun

"zhangyunfei" <[email-masked]> 
2009-12-28 10:13 收件人"[email-masked]" <[email-masked]> 
抄送"[email-masked]" <[email-masked]> 
主题Re: re: [ppsp] ppsp revised charter proposal

BR 
Yunfei 

zhangyunfei 
2009-12-28 

Hi, yunfei. 

Best regards,
Lichun Li

"zhangyunfei" <[email-masked]> 
发件人:  [email-masked] 
2009-12-26 16:52 
收件人"[email-masked]" <[email-masked]> 
抄送
主题[ppsp] ppsp revised charter proposal

Dear all, 

 

 

 

 

  

zhangyunfei

---

From: [email-masked]
Date: Mon, 28 Dec 2009 14:49:22 +0800

Yes, it may arouse some problems. If PPSP want to do that, some lite 
security mechanism maybe needed.

Besides that, should we change "exchange neighbor peers" to "exchange peer 
lists information (owning some resource)" so as to avoid the confusion of 
'neighbor'?

2009-12-28 14:23

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, liuhy <[email-masked]>
主题
Re: [ppsp] ppsp revised charter proposal

Thanks Lichun.
According to my understanding,peers exchange the neigbor peers 
information,i.e. which peer remains connected and which pieces already 
have been downloaded. As for non-neigbor peers which it just receives from 
the tracker, I am really not sure about the effect of such exchange 
because such peers are un-confirmed.
Is there anybody who can tell us more about this point in 
practice?James?Harold?Omer?
Thanks!
 
BR
Yunfei

zhangyunfei
2009-12-28

BR, 
Lichun

收件人

BR 
Yunfei 

zhangyunfei 
2009-12-28 

Hi, yunfei. 

Best regards,
Lichun Li

收件人

主题

Dear all, 

 

 

 

 

Apr 2010 

zhangyunfei 

_______________________________________________