Subject: Re: [ppsp] New draft about P2P CDN

From: [email-masked]
Date: Fri, 9 Apr 2010 09:31:39 +0800

Hi, Yingjie

Thanks for your further comments.
Please see inline.

BR
Lichun Li

"Y.J. Gu" <[email-masked]> 
2010-04-08 11:17

收件人
[email-masked]
抄送
[email-masked]
主题
RE: [ppsp] New draft about P2P CDN

Hi Li,
See inline please.
 
Regards
Yingjie Gu

From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 07, 2010 2:51 PM
To: Y.J. Gu
Cc: [email-masked]
Subject: RE: [ppsp] New draft about P2P CDN

Hi, Yingjie 

Thank you for your comments. 
Please see inline. 

BR 
Lichun Li 

"Y.J. Gu" <[email-masked]> 
2010-04-06 19:14 

收件人
[email-masked] 
抄送
[email-masked] 
主题
RE: [ppsp] New draft about P2P CDN

Hi Li, 
In section 3 Architecture, why should there be an interface between cacher 
and content source? When should this interface be used? I think cacher can 
always download resource from storer. Even there is no content on storer, 
storer can download from content source and then push to cacher. 
  
[Lichun] Content source can use CDN to publish contents in three ways: 1. 
publishing content location to tracker; 2. storing content in storage 
overlay; 3. both 1 and 2. Three ways may charge different, and may be 
suitable for different scenarios. If a content source chooses way 1, the 
interface between cacher and content source is needed.  

[gyj] No offend, but I think this more likes a bunch of cachings and 
users, all act as peers, around Tracker. Both cachers and storers are 
actually non-transparent P2P caching in typical P2P applications. None of 
CDN features are left except for the naming.  No one can find the other 
without the help of Tracker. In a P2P CDN, a user can still be served 
without P2P mechanism, but herein this seems impossible.

[Lichun] If all CSCs don't report content availability or tracker doesn't 
put CSC in peer list, a user can still download content. So this system 
works without using P2P among user nodes. And according to my knowledge, 
using P2P among servers is normal in existing CDNs. Can you tell me the 
missing CDN features so that I can improve the solution?

I find that both content source and storer can publish the location of a 
content to Tracker, and storer will publish when the location of a content 
changes. Why bother content source to publish the content location, as 
storer can do it. And there will be repeated publishing when content 
source publish a content and the storer, where content source stores the 
content, will publish again. 

[Lichun] Publishing twice can increase capacity, as cacher can download 
content from both content source and storer. 
  
In 4.3, CSC downloading content, "In that case, the CSC SHALL use  RELOAD 
Fetch method to fetch the content information from the overlay." .  CSC is 
a PPSP peer, not a reload peer.  Should it be "Tracker" instead of CSC? 

[Lichun] CSC is a RELOAD client here.  
[gyj] Sorry, but in terminology, CSC is only defined as a PPSP peer.
   CSC (Content Sharing Client): The client that is running in a user
   device for downloading shared contents.  User devices includes mobile
   device, laptop, PC etc.  A CSC is a PPSP peer.
[Lichun] My mistake. CSC is a RELOAD client in this case, but is not in 
other cases. I will add some explanation in next version.
  
In general, I think the system works and each functions can be supported 
by the system. The problem is that this is a quite complicate giant, 
almost any device, any part of the system can communicate with any other 
part, and any part can report to Tracker. Could these make network 
management too complicate and difficult? 

[Lichun] I don't think network management would be a problem. And the 
system can be simplified in real deployment. We just list possible good 
ways to use the P2P CDN. Not all message flows in the draft are mandatory. 

Regards 
Yingjie Gu 

From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Tuesday, April 06, 2010 9:29 AM
To: Softgear Ko
Cc: [email-masked]
Subject: Re: [ppsp] New draft about P2P CDN

Hi, sorry for the late reply. 
When a new channel or new movie is added to the system, the new channel or 
new movie's first chunk can be pushed to cacher.
Cacher selection can be based on locality and load. 
I agree with you. I think there are two ways (the way you said and the way 
in PPSP drafts) to get subsequent chunks. Both are OK.

Lichun

"Softgear Ko" <[email-masked]> 
2010-03-22 08:33 

收件人
"'lichun li'" <[email-masked]> 
抄送
<[email-masked]>, <[email-masked]> 
主题
RE: [ppsp] New draft about P2P CDN

Hi, Lichun Li.

About pushing,
When does a tracker ask a cacher to pull the content?
If there are many cacher, which cachers does a tracker ask?
I  think, if a CSC knows the nearest cacher, the CSC can ask the cacher to
pull the content for subsequent request or other nearby CSC.

Thank you for adding our draft as a reference.

- Softgear Ko.

-----Original Message-----
From: lichun li [mailto:[email-masked]] 
Sent: Saturday, March 20, 2010 4:35 PM
To: Softgear Ko
Cc: [email-masked]; [email-masked]
Subject: Re: [ppsp] New draft about P2P CDN

Hi
I'm glad to share ideas with you and other people with common
interests. I will add your draft to references in next version.
Comments about "push", please see inline.

On Thu, Mar 18, 2010 at 2:07 PM, Softgear Ko <[email-masked]> wrote:
> Hello, Lichun Li.
>
>
>
> I think this draft shows good overview of CDN supported P2P streaming
> service. I think, basically, the idea is very similar to our draft:
>
> http://datatracker.ietf.org/doc/draft-softgear-p2psip-iptv/  which uses
> RELOAD overlay for P2P streaming.
>
> However, your draft considers "chunk" based P2P streaming while our 
draft
> considers the live streaming only. I think we can share the idea each
other.
> Could you add our draft to References in your draft?
>
> Additionally, in your draft, only tracker (tracker overlay) can do
> "pushing". Why don't add the function which CSCs or other entities
requests
> a cacher to push/pull content from others?

Well, I have considered this before. I think this function is not
necessary if CSCs ask tracker for peer list.
But if CSCs request every chunk from nearby cachers and don't ask
tracker for peer list, CSCs need this function.
What do you think?

>
>
>
> Regards,
>
> Softgear Ko
>
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, March 04, 2010 2:20 PM
> To: [email-masked]
> Subject: [ppsp] New draft about P2P CDN
>
>
>
> Dear all,
>
> We have submitted a new Internet draft entitled "A P2P CDN based Content
> Sharing System using PPSP and RELOAD".
> It can be accessed at:
> http://www.ietf.org/internet-drafts/draft-li-ppsp-p2p-cdn-00.txt
> Any comments are welcome. Thanks.
>
> Abstract:
> This document defines a P2P CDN (Content Delivery Network) based
> content sharing system using PPSP (Peer to Peer Streaming Protocol)
> and RELOAD (REsource LOcation And Discovery).  The P2P CDN provides a
> unified platform for service/content providers and content sharing
> users to share content efficiently and safely.  The shared contents
> may include streaming media, files, etc.  This content sharing system
> uses PPSP as signaling protocol for P2P content distributing, and
> uses RELOAD to improve reliability and scalability.  More
> specifically, RELOAD is used to construct P2P overlays storing of
> massive contents and locating contents reliably.
>
> Best Regards,
> Lichun Li
>
>
>
> --------------------------------------------------------
>
>
ZTE Information Security Notice: The information contained in this mail is 
s
olely property of the sender's organization. This mail communication is 
conf
idential. Recipients named above are obligated to maintain secrecy and are 
n
ot permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended 
s
olely 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 
m
essage. Any views expressed in this message are those of the individual 
send
er.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.
>
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>
>

-- 
Sincerely yours,

Lichun Li
ZTE Corporation

--------------------------------------------------------
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.
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.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "zhangyunfei" <[email-masked]>
Date: Fri, 9 Apr 2010 10:28:41 +0800

I guess herein the terminolgoy of CDN is not a conventional one,say,a centralized scheduler and a set of CDN nodes, who can not acquire contents from each other directly.
Here the P2P CDN may more likely refer to super-peers which may be deployed by operators or new CDN vendors(like CoralCDN[1])who has no exisiting CDN infrstructures and has strong incentive for cost saving by P2P).Am I right?

BR
Yunfei
[1]Experiences with CoralCDN: A Five-Year Operational View,Appeared in 7th USENIX Symposium on Network Design and Implementation (NSDI ’10),Michael J. Freedman,Princeton University.

zhangyunfei
2010-04-09

发件人： [email-masked]
发送时间： 2010-04-09 09:53:17
收件人： Y.J. Gu
抄送： [email-masked]
主题： Re: [ppsp] New draft about P2P CDN

Hi, Yingjie 

BR 
Lichun Li

"Y.J. Gu" <[email-masked]> 
2010-04-08 11:17 [email-masked] 
[email-masked] 
主题RE: [ppsp] New draft about P2P CDN

Hi Li, 
See inline please. 
  
Regards 
Yingjie Gu 

Hi, Yingjie 

BR 
Lichun Li 

"Y.J. Gu" <[email-masked]> 
2010-04-06 19:14 
[email-masked] 
[email-masked] 
主题RE: [ppsp] New draft about P2P CDN

Hi Li, 
In section 3 Architecture, why should there be an interface between cacher and content source? When should this interface be used? I think cacher can always download resource from storer. Even there is no content on storer, storer can download from content source and then push to cacher. 
 
[Lichun] Content source can use CDN to publish contents in three ways: 1. publishing content location to tracker; 2. storing content in storage overlay; 3. both 1 and 2. Three ways may charge different, and may be suitable for different scenarios. If a content source chooses way 1, the interface between cacher and content source is needed.   

[gyj] No offend, but I think this more likes a bunch of cachings and users, all act as peers, around Tracker. Both cachers and storers are actually non-transparent P2P caching in typical P2P applications. None of CDN features are left except for the naming.  No one can find the other without the help of Tracker. In a P2P CDN, a user can still be served without P2P mechanism, but herein this seems impossible.

[Lichun] If all CSCs don't report content availability or tracker doesn't put CSC in peer list, a user can still download content. So this system works without using P2P among user nodes. And according to my knowledge, using P2P among servers is normal in existing CDNs. Can you tell me the missing CDN features so that I can improve the solution? 

I find that both content source and storer can publish the location of a content to Tracker, and storer will publish when the location of a content changes. Why bother content source to publish the content location, as storer can do it. And there will be repeated publishing when content source publish a content and the storer, where content source stores the content, will publish again. 

[Lichun] Publishing twice can increase capacity, as cacher can download content from both content source and storer. 
 
In 4.3, CSC downloading content, "In that case, the CSC SHALL use  RELOAD Fetch method to fetch the content information from the overlay." .  CSC is a PPSP peer, not a reload peer.  Should it be "Tracker" instead of CSC? 

[Lichun] My mistake. CSC is a RELOAD client in this case, but is not in other cases. I will add some explanation in next version.
 
In general, I think the system works and each functions can be supported by the system. The problem is that this is a quite complicate giant, almost any device, any part of the system can communicate with any other part, and any part can report to Tracker. Could these make network management too complicate and difficult? 

[Lichun] I don't think network management would be a problem. And the system can be simplified in real deployment. We just list possible good ways to use the P2P CDN. Not all message flows in the draft are mandatory. 

Regards 
Yingjie Gu 

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 06, 2010 9:29 AM
To: Softgear Ko
Cc: [email-masked]
Subject: Re: [ppsp] New draft about P2P CDN

Hi, sorry for the late reply. 
When a new channel or new movie is added to the system, the new channel or new movie's first chunk can be pushed to cacher.
Cacher selection can be based on locality and load. 
I agree with you. I think there are two ways (the way you said and the way in PPSP drafts) to get subsequent chunks. Both are OK.

Lichun

"Softgear Ko" <[email-masked]> 
2010-03-22 08:33 
收件人"'lichun li'" <[email-masked]> 
抄送<[email-masked]>, <[email-masked]> 
主题RE: [ppsp] New draft about P2P CDN

Hi, Lichun Li.

About pushing,

- Softgear Ko.

-----Original Message-----
From: lichun li [mailto:[email-masked]] 
Sent: Saturday, March 20, 2010 4:35 PM
To: Softgear Ko
Cc: [email-masked]; [email-masked]
Subject: Re: [ppsp] New draft about P2P CDN

Hi

On Thu, Mar 18, 2010 at 2:07 PM, Softgear Ko <[email-masked]> wrote:
> However, your draft considers "chunk" based P2P streaming while our draft
other.
requests

> massive contents and locating contents reliably.
ZTE Information Security Notice: The information contained in this mail is s
olely property of the sender's organization. This mail communication is conf
idential. Recipients named above are obligated to maintain secrecy and are n
ot permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended s
olely 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 m
essage. Any views expressed in this message are those of the individual send
er.

-- 
Sincerely yours,

Lichun Li
ZTE Corporation

---

From: "Y.J. Gu" <[email-masked]>
Date: Fri, 09 Apr 2010 10:34:26 +0800

Hi Li,
In next version, you may also need to redefine the CSC as not only
downloading but also uploading, right?

[gyj] No offend, but I think this more likes a bunch of cachings and users,
all act as peers, around Tracker. Both cachers and storers are actually
non-transparent P2P caching in typical P2P applications. None of CDN
features are left except for the naming.  No one can find the other without
the help of Tracker. In a P2P CDN, a user can still be served without P2P
mechanism, but herein this seems impossible.

[Lichun] If all CSCs don't report content availability or tracker doesn't
put CSC in peer list, a user can still download content. So this system
works without using P2P among user nodes. 
 
[gyj] What if Tracker is totally disappear from the system? Neither Content
source, or storer(cacher) can publish their content on Tracker, how should
user know where to download? In existing CDN (or P2P CDN), there are many
methods to help user find a good place to download. E.g. user can get the
url or address of a content source from EPG and then be redirected to a
nearby storage node(cacher in your draft).  This part seems lost in this
draft. 
 
And according to my knowledge, using P2P among servers is normal in existing
CDNs. Can you tell me the missing CDN features so that I can improve the
solution? 
 
[gyj ]If you take Tracker away from the system and the system still works,
then I think it's CDN based. Yes, in existing P2P-CDN, P2P mechanism can be
deployed among 1) network storage nodes, 2) users, or 3) both, from academic
perspective. Implementation will be different in practice and there is no
standard yet, and we need P2P CDN implementation experience to find out
feasible architecture before we add PPSP into them. Besides I think PPSP
should be an additional part to CDN, instead of the kernel and necessary
part, however Tracker has become a kernel in this architecture. 

Regards

Yingjie Gu

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, April 09, 2010 9:32 AM
To: Y.J. Gu
Cc: [email-masked]
Subject: RE: [ppsp] New draft about P2P CDN

Hi, Yingjie 

BR 
Lichun Li

2010-04-08 11:17 

收件人
[email-masked] 

抄送
[email-masked] 

主题

Hi Li, 
See inline please. 
  
Regards 
Yingjie Gu 

  _____  

Hi, Yingjie 

BR 
Lichun Li 

Hi Li, 

[gyj] No offend, but I think this more likes a bunch of cachings and users,
all act as peers, around Tracker. Both cachers and storers are actually
non-transparent P2P caching in typical P2P applications. None of CDN
features are left except for the naming.  No one can find the other without
the help of Tracker. In a P2P CDN, a user can still be served without P2P
mechanism, but herein this seems impossible.

I find that both content source and storer can publish the location of a
content to Tracker, and storer will publish when the location of a content
changes. Why bother content source to publish the content location, as
storer can do it. And there will be repeated publishing when content source
publish a content and the storer, where content source stores the content,
will publish again. 

In 4.3, CSC downloading content, "In that case, the CSC SHALL use  RELOAD
Fetch method to fetch the content information from the overlay." .  CSC is a
PPSP peer, not a reload peer.  Should it be "Tracker" instead of CSC? 

 
In general, I think the system works and each functions can be supported by
the system. The problem is that this is a quite complicate giant, almost any
device, any part of the system can communicate with any other part, and any
part can report to Tracker. Could these make network management too
complicate and difficult? 

[Lichun] I don't think network management would be a problem. And the system
can be simplified in real deployment. We just list possible good ways to use
the P2P CDN. Not all message flows in the draft are mandatory. 

Regards 
Yingjie Gu

---

From: [email-masked]
Date: Sun, 11 Apr 2010 23:14:56 +0800

Yunfei
  You're right, CoralCDN employed Distributed Sloppy Hash Table to store 
index/meta data, we suggest a high performance DHT algorithm such as 
one-hop DHT be used to build a tracker.
    The chunk discovery  must depend on the tracker, if the application 
does not support this mechnism, a adapter module should be implemented 
inside the CDN node.

Russell wang

"zhangyunfei" <[email-masked]> 
发件人:  [email-masked]
2010-04-09 10:28

收件人
"[email-masked]" <[email-masked]>, "Y.J. Gu" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: [ppsp] New draft about P2P CDN

I guess herein the terminolgoy of CDN is not a conventional one,say,a 
centralized scheduler and a set of CDN nodes, who can not acquire contents 
from each other directly.
Here the P2P CDN may more likely refer to super-peers which may be 
deployed by operators or new CDN vendors(like CoralCDN[1])who has no 
exisiting CDN infrstructures and has strong incentive for cost saving by 
P2P).Am I right?
 
BR
Yunfei
[1]Experiences with CoralCDN: A Five-Year Operational View,Appeared in 7th 
USENIX Symposium on Network Design and Implementation (NSDI ’10),Michael 
J. Freedman,Princeton University.

zhangyunfei
2010-04-09

Hi, Yingjie 

BR 
Lichun Li

收件人
[email-masked] 
抄送
[email-masked] 
主题

Hi Li, 
See inline please. 
  
Regards 
Yingjie Gu 

Hi, Yingjie 

BR 
Lichun Li 

收件人
[email-masked] 
抄送
[email-masked] 
主题

Hi Li, 

 

 
Regards 
Yingjie Gu 

Lichun

收件人

Hi, Lichun Li.

About pushing,

- Softgear Ko.

-----Original Message-----
From: lichun li [mailto:[email-masked]] 
Sent: Saturday, March 20, 2010 4:35 PM
To: Softgear Ko
Cc: [email-masked]; [email-masked]
Subject: Re: [ppsp] New draft about P2P CDN

Hi

draft
other.
requests

-- 
Sincerely yours,

Lichun Li
ZTE Corporation

---

From: [email-masked]
Date: Mon, 12 Apr 2010 09:50:41 +0800

Hi, Yingjie

Please see inline.

BR
Lichun Li

2010-04-09 10:34

收件人
[email-masked]
抄送
[email-masked]
主题

Hi Li,

[Li] Thank you for pointing out the definition problem. I will redefine 
CSC.  

 
[gyj] What if Tracker is totally disappear from the system? Neither 
Content source, or storer(cacher) can publish their content on Tracker, 
how should user know where to download? In existing CDN (or P2P CDN), 
there are many methods to help user find a good place to download. E.g. 
user can get the url or address of a content source from EPG and then be 
redirected to a nearby storage node(cacher in your draft).  This part 
seems lost in this draft. 

And according to my knowledge, using P2P among servers is normal in 
existing CDNs. Can you tell me the missing CDN features so that I can 
improve the solution? 
 
[gyj ]If you take Tracker away from the system and the system still works, 
then I think it's CDN based. Yes, in existing P2P-CDN, P2P mechanism can 
be deployed among 1) network storage nodes, 2) users, or 3) both, from 
academic perspective. Implementation will be different in practice and 
there is no standard yet, and we need P2P CDN implementation experience to 
find out feasible architecture before we add PPSP into them. Besides I 
think PPSP should be an additional part to CDN, instead of the kernel and 
necessary part, however Tracker has become a kernel in this architecture. 

[Li] This P2P CDN has different architecture compared with traditional 
CDN, but functions like traditional CDN. It can accelerate downloading and 
supports pull/push mode to distribute content. 
    Actually, we want to use P2P streaming/file sharing technology among 
CDN servers instead of combing existing CDN system and P2P streaming 
system together. So PPSP has to be the kernel part of this P2P CDN. 
    Maybe "P2P CDN" is not a good term for this system. Maybe "P2P CDN" is 
a term more suitable for other systems. Anyway, we are not trying to 
standardize P2P CDN here. We just want to provide a possible usage of 
PPSP. Can you share your view on your P2P CDN? What's P2P CDN? What does 
it look like?

Regards
Yingjie Gu

Hi, Yingjie 

BR 
Lichun Li

收件人
[email-masked] 
抄送
[email-masked] 
主题

Hi Li, 
See inline please. 
  
Regards 
Yingjie Gu 

Hi, Yingjie 

BR 
Lichun Li 

Hi Li, 

 

 
Regards 
Yingjie Gu

---

From: "zhangyunfei" <[email-masked]>
Date: Mon, 12 Apr 2010 10:10:20 +0800

Hi Russell，
   Thanks for the suggestions on the implementation.People can have different options in how to build a tracker.However as we had discussed in last BOF, we emphasize that the tracker is a centralized  funcitonal unit which can be IMPLEMENTED by a centralized or distributed way.But this doesn't affect how the tracker protocol goes.

Yunfei

zhangyunfei
2010-04-12

发件人： [email-masked]
发送时间： 2010-04-11 23:14:41
收件人： zhangyunfei
抄送： Y.J. Gu; [email-masked]; [email-masked]; [email-masked]
主题： Re: [ppsp] New draft about P2P CDN

Yunfei 
  You're right, CoralCDN employed Distributed Sloppy Hash Table to store index/meta data, we suggest a high performance DHT algorithm such as one-hop DHT be used to build a tracker. 
    The chunk discovery  must depend on the tracker, if the application does not support this mechnism, a adapter module should be implemented inside the CDN node. 

Russell wang 

"zhangyunfei" <[email-masked]> 
发件人:  [email-masked] 
2010-04-09 10:28 收件人"[email-masked]" <[email-masked]>, "Y.J. Gu" <[email-masked]> 
抄送"[email-masked]" <[email-masked]> 
主题Re: [ppsp] New draft about P2P CDN

BR 
Yunfei 

zhangyunfei 
2010-04-09 

Hi, Yingjie 

BR 
Lichun Li

Hi Li, 
See inline please. 
 
Regards 
Yingjie Gu 

Hi, Yingjie 

BR 
Lichun Li 

Hi Li, 

Regards 
Yingjie Gu 

Lichun

Hi, Lichun Li.

About pushing,

- Softgear Ko.

-----Original Message-----
From: lichun li [mailto:[email-masked]] 
Sent: Saturday, March 20, 2010 4:35 PM
To: Softgear Ko
Cc: [email-masked]; [email-masked]
Subject: Re: [ppsp] New draft about P2P CDN

Hi

other.
requests

-- 
Sincerely yours,

Lichun Li
ZTE Corporation

---

From: [email-masked]
Date: Mon, 12 Apr 2010 10:11:08 +0800

Yes, we have the same opinion. There are a set of schedulers and a set of 
CDN nodes in the proposed P2P CDN. Schedulers (i.e. trackers) form a DHT 
overlay to increase reliability and scalability. This P2P CDN adopts new 
protocols and new architecture. Thus, I also think operators or new CDN 
vendors may have more interests on deploying it.

BR
Lichun

收件人
"[email-masked]" <[email-masked]>, "Y.J. Gu" 
<[email-masked]>
抄送
"[email-masked]" <[email-masked]>
主题
Re: Re: [ppsp] New draft about P2P CDN

BR
Yunfei

zhangyunfei
2010-04-09

Hi, Yingjie 

BR 
Lichun Li

收件人
[email-masked] 
抄送
[email-masked] 
主题

Hi Li, 
See inline please. 
  
Regards 
Yingjie Gu 

Hi, Yingjie 

BR 
Lichun Li 

收件人
[email-masked] 
抄送
[email-masked] 
主题

Hi Li, 

 

 
Regards 
Yingjie Gu 

Lichun

收件人

Hi, Lichun Li.

About pushing,

- Softgear Ko.

-----Original Message-----
From: lichun li [mailto:[email-masked]] 
Sent: Saturday, March 20, 2010 4:35 PM
To: Softgear Ko
Cc: [email-masked]; [email-masked]
Subject: Re: [ppsp] New draft about P2P CDN

Hi

draft
other.
requests

-- 
Sincerely yours,

Lichun Li
ZTE Corporation

---

From: [email-masked]
Date: Mon, 12 Apr 2010 16:47:43 +0800

Hi Yunfei

I agree. Different implementations should share the same tracker protocol.
In our draft, CSC, content source, cacher and storer all access tracker 
with tracker protocol except one exception as Yingjie pointed out. In 
section 4.3, CSC uses RELOAD to fetch content information for generating 
chunk ID if tracker also performs as portal. Herein CSC may use PPSP 
instead if PPSP tracker protocol supports fetching that information.

BR
Lichun

2010-04-12 10:10

收件人
"[email-masked]" <[email-masked]>
抄送
"Y.J. Gu" <[email-masked]>, "[email-masked]" 
<[email-masked]>, "[email-masked]" <[email-masked]>
主题
Re: Re: [ppsp] New draft about P2P CDN

Hi Russell，
   Thanks for the suggestions on the implementation.People can have 
different options in how to build a tracker.However as we had discussed in 
last BOF, we emphasize that the tracker is a centralized  funcitonal unit 
which can be IMPLEMENTED by a centralized or distributed way.But this 
doesn't affect how the tracker protocol goes.
 
Yunfei

zhangyunfei
2010-04-12

发件人： [email-masked]
发送时间： 2010-04-11 23:14:41
收件人： zhangyunfei
抄送： Y.J. Gu; [email-masked]; [email-masked]; 
[email-masked]
主题： Re: [ppsp] New draft about P2P CDN

Yunfei 

Russell wang 

收件人

BR 
Yunfei 

zhangyunfei 
2010-04-09 

Hi, Yingjie 

BR 
Lichun Li

收件人
[email-masked] 
抄送
[email-masked] 
主题

Hi Li, 
See inline please. 
 
Regards 
Yingjie Gu 

Hi, Yingjie 

BR 
Lichun Li 

收件人
[email-masked] 
抄送
[email-masked] 
主题

Hi Li, 

Regards 
Yingjie Gu 

Lichun

收件人

Hi, Lichun Li.

About pushing,

- Softgear Ko.

-----Original Message-----
From: lichun li [mailto:[email-masked]] 
Sent: Saturday, March 20, 2010 4:35 PM
To: Softgear Ko
Cc: [email-masked]; [email-masked]
Subject: Re: [ppsp] New draft about P2P CDN

Hi

draft
other.
requests

-- 
Sincerely yours,

Lichun Li
ZTE Corporation