Subject: Re: [P2PSIP] New draft on enhanced client operation for RELOAD

From: "Xiao, Lin (NSN - CN/Beijing)" <[email-masked]>
Date: Wed, 1 Jul 2009 17:51:27 +0800

Hi Vidya,

It is really a good start to discuss the client mobility issues in
RELOAD. Using DAP and OAP seems a good solution for clients that
attached to arbitary peers. However, does eClient really need a specific
bootstrapping different with that in RELOAD BASE? 

IMO, a client does not need to claim itselft an eClient or not when
joining in the overlay. A ordinary bootstrapping can work as if it is a
normal client. The node ID is allocated by bootstrap server. This client
can use the Node ID to set up connection with OAP and neighbours as
normal overlay nodes do. If the bootstrap server used here has the
ability to consider a little bit physical network topology, the
allocated node ID, of cause, is quite close to its OAP.  There should no
problem to set up a direct connection between the client and OAP on the
overlay at the begining. Only when the client found that it is
impossible to directly connect to its OAP (most of time, it is due to
the client moving out of the OAD's reachability), it'll select a DAP
from its neighbours. This could keep your scheme more simpler and
accordant with RELOAD BASE. Right?

Best Regards,
Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Narayanan, Vidya
Sent: Wednesday, July 01, 2009 4:51 AM
To: [email-masked]
Subject: [P2PSIP] New draft on enhanced client operation for RELOAD

Hi,
We have submitted a draft on enhanced client operation for RELOAD.  It
supports the attachment of clients to arbitrary peers without needing
application specific destination list population and it inherently
provides support for client mobility.  

The draft can be found at
http://www.ietf.org/internet-drafts/draft-vidya-p2psip-eclients-00.txt.
Comments welcome.  

Thanks,
Vidya
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 1 Jul 2009 12:13:42 -0700

Hi Lin,
Thanks for looking through the draft and sharing comments.  The motivation to attach to an arbitrary peer may not only be driven by inability to attach to the OAP due to NAT problems - a node may choose to attach to a DAP due to proximity or even to use the same DAP to attach to multiple overlays, thereby providing significant power savings to a client.  Of course, a node may choose to first attach as a regular client at the OAP and then decide to find a DAP if conditions change as well - the draft does not preclude that.  But, in order to handle appropriate state at OAP and DAP and to set up the connections, we will need support for indicating the DAP to the OAP.  

Also, we want the enrollment server to assign node ids randomly to all nodes.  A node need not have a strict rule about always participating as a client or a peer - a node may start out as a peer and then switch to a client role later (say, when its battery is low). 

At the moment, even regular client behavior is not documented in the base draft.  I had sent the authors some text a while ago for this.  I will also forward that along to the mailing list for comments.  

Thanks,
Vidya 

> From: Xiao, Lin (NSN - CN/Beijing) [mailto:[email-masked]]
> Sent: Wednesday, July 01, 2009 2:51 AM
> To: Narayanan, Vidya; [email-masked]
> Subject: RE: [P2PSIP] New draft on enhanced client operation for RELOAD
> 
> Hi Vidya,
>

---

From: lichun li <[email-masked]>
Date: Sun, 12 Jul 2009 12:00:59 +0800

Interesting. I think we may start considering using RELOAD for
applications other than P2PSIP. Some questions and comments are below.

It seems that all the contents are provided by service provider. Can
users upload and share contents?

Servers or user PCs form the the RELOAD overlay for content sharing?

I think the RELOAD overlay is more than a CDN. CDN is not responsible
for data durability but traffic localization.
DHT overlay can assure data durability, and this draft adds CDN
function to RELOAD.
Other than store files, the RELOAD overlay may store user list for
up-layer distributed tracker function.

So I think the RELOAD overlay may have three functions: CDN, file
storing and user list storing.
The RELOAD overlay may provide all three functions to some contents
(e.g. content provided by service provider)
and only part functions to other contents (e.g. contents provided by users).

On Wed, Jul 1, 2009 at 9:16 AM, <[email-masked]> wrote:
>
> Hi all,
>
> We have submitted a draft on content sharing usage for RELOAD. It provides
> the functionality of distributing and fetching shared content efficiently to
> and from a P2P overlay network, which performs as Content Delivery Network
> and is service insensitive.
>
> http://www.ietf.org/internet-drafts/draft-shen-p2psip-content-sharing-00.txt.
>  Comments are welcome.
>
>
> Thanks,
> Jiong
>
>
> --------------------------------------------------------
> 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.
>

-- 
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT

---

From: [email-masked]
Date: Mon, 13 Jul 2009 09:30:08 +0800

Hi, li
   In this draft, provider's servers are preferable to form the overlay. 
Users can put some content into this RELOAD based overlay, but before 
that, the security must be guaranteed.
   I totally agree that the RELOAD based overlay acts as not only a CDN 
but also a content storage server. As for storing the user list or user 
profiles, I think  an existing overlay could be used to do this, e.g., the 
existing p2p based subscriber database.

    Wang Jun(Russell Wang)

lichun li <[email-masked]> 
发件人:  [email-masked]
2009-07-12 12:00

收件人
[email-masked]
抄送
[email-masked]
主题
Re: [P2PSIP] New draft on content sharing usage for RELOAD

and only part functions to other contents (e.g. contents provided by 
users).

> The draft can be found at
http://www.ietf.org/internet-drafts/draft-shen-p2psip-content-sharing-00.txt
.

-- 
Sincerely yours,

Lichun Li

---

From: lichun li <[email-masked]>
Date: Mon, 13 Jul 2009 10:41:30 +0800

2009/7/13  <[email-masked]>:
> Users can put some content into this RELOAD based overlay, but before that,
> the security must be guaranteed.
>    I totally agree that the RELOAD based overlay acts as not only a CDN but
> also a content storage server. As for storing the user list or user

So there are two overlays? Are there any interactions between two overlays?

-- 
Sincerely yours,

Lichun Li

---

From: lichun li <[email-masked]>
Date: Mon, 13 Jul 2009 10:46:54 +0800

Section 9 "Overlay Optimize Example" is interesting. Can you give more
details about the multi-domain overlay architecture? For example,
which content is stored in which domain?

-- 
Sincerely yours,

Lichun Li

---

From: [email-masked]
Date: Mon, 13 Jul 2009 15:41:28 +0800

Yes, there are two overlays, users who want to access the content sharing 
service should have registered in the basic overlay firstly. 
Nodes of the content-sharing overlay can access the basic user profiles 
overlay via RELOAD protocol, and a 'overlay' parameter in the RELOAD 
forwarding head  can be used to distinguish different overlay.

2009-07-13 10:41

�ռ���
[email-masked]
����
[email-masked], [email-masked], [email-masked]
����
Re: [P2PSIP] New draft on content sharing usage for RELOAD

> Users can put some content into this RELOAD based overlay, but before 
that,
>    I totally agree that the RELOAD based overlay acts as not only a CDN 
but
> existing p2p based subscriber database.

So there are two overlays? Are there any interactions between two 
overlays?

> ������:  [email-masked]
>
> 2009-07-12 12:00
>
> �ռ���
> [email-masked]
> ����
> [email-masked]
> ����
users).
>> the functionality of distributing and fetching shared content 
efficiently
>> to
>> 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.
> 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.

-- 
Sincerely yours,

Lichun Li

�mz�ڶ+��M���͹�

---

From: [email-masked]
Date: Mon, 13 Jul 2009 17:52:56 +0800

Hi Lichun,

Section 9 "Overlay Optimize Example" is an example of optimizing data flow 
trafic if the overlay is constructed and running by carriers. As carriers 
know the the network infrastructure topology( the backbone networks 
infrastructure), they can construct the overlay by domains, and the data 
flow in one domain will not across over backbone networks, that can limit 
the data flow across over backbone networks. Normally, the domains are 
constructed by region.

For the detail usage of content storing by domain based overlay, there are 
many methods. 
For instance, the content provider can distribute the content to each 
domain of the overlay, the resource ID is generated by domain ID(Can be 
identified by carriers or May hash by domain name) plus generic ID( e.g. 
hashed by resource name). Here, the domain ID is the identity of one 
domain, and all the node IDs and resource IDs in one domain are generated 
by domain ID plus IDs constituted by the specific rule and hash algorithm 
. When one CSC(Content Sharing Client) wants to fetch resource, it 
generates the resource ID by same rule such as domain ID plus ID(e.g. 
hashed by resource name) and gets the resource from the peer in same 
domain. 

Thanks.
Jiong

2009-07-13 10:46

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

> the functionality of distributing and fetching shared content 
efficiently to

-- 
Sincerely yours,

Lichun Li