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

From: [email-masked]
Date: Tue, 6 Apr 2010 09:28:46 +0800

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.

---

From: "Y.J. Gu" <[email-masked]>
Date: Tue, 06 Apr 2010 19:14:13 +0800

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

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

Lichun

2010-03-22 08:33 

收件人

抄送

主题

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

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

---

From: [email-masked]
Date: Wed, 7 Apr 2010 14:50:34 +0800

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]
主题

Hi Li,
 
[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.

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

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

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.

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