Subject: [decade] Comment for motivations and goals of DECADE

From: "Y.J. Gu" <[email-masked]>
Date: Mon, 03 Aug 2009 15:28:22 +0800

I did not attend DECADE bar BOF, just follow the progress by analyzing
meeting minutes. So, forgive me if there might be any misunderstanding.  ^_^

I notice that both the "Problem statement" and "BranchCache presentation"
take "band-saving" as a primary motivation/incentive for DECADE.

IMHO, "band-saving" might not be a good reason to convince IETF to work on
DECADE and might put DECADE into much more debate. There are already various
caching or non-caching solutions implemented to reduce uplink/downlink
bandwidth, for both C/S and P2P applications, e.g. CDN, P2P caching and DPI.
Some others are under discussion in mailing list, such as ALTO.

I know DECADE is different, but why IETF need another "band-saving"
solution? That's a hard question. 
"saving uplink is too broad scope", as Rich said.
"saving the uplink is not the main drving force", said Lucy Yong.
I agree with them, it will make things too complicated. Look back the
meeting minutes, and you will find that 7 out of 15 questions in "Problem
statement" Q&A are about bandwidth. We do not need multi-motivations to
indicate the importance of DECADE, we just need an overwhelming one.

To decouple signaling and data transmission is the very incentive that we
need. Up to now, there is no WG in IETF ever intends to address the updating
pressure to existing caches system.  Absorbing people's attention on this
aspect might help us clarify the necessary of DECADE more convincibly.

And we can regard "band-saving" as a subordinate advantage, instead of as an
incentive.

Regards

Yingjie Gu

---

From: "Alan Arolovitch" <[email-masked]>
Date: Mon, 3 Aug 2009 11:00:22 +0300

0.02$ from P2P caching vendor perspective

I agree that bandwidth savings as a scope is too narrow and not
exclusive enough.
P2P caching systems can accommodate a variety of value propositions,
including
bandwidth savings, SLA assurance and service delivery.
Based on discussions spurred by ALTO, it seems that there's a perceived
and 
understood challenge in scaling multi-protocol support of P2P
applications
Maybe DECADE should focus on this narrow protocol problem, and not
preclude any
particular form of caching systems architectures and/or P2P applications
types.
Just as HTTP1.1 RFC 2616 doesn't spell out particular caching
architecture, but 
rather standardizes solid protocol-level caching support, that allows to
build 
transparent and non-transparent caching systems based on it.

Lastly, on the legal side, I don't think DECADE should focus exclusively
on DMCA agenda
(i.e. caching-of-potentially-copyright-infringing-content)
There is plenty of deployment scenarios that do not fall into this
bucket, even though
it would be nice if DECADE wasn't in a clear violation of the procedures
set by DMCA 
and other very similar legal acts adopted globally.

--alan 

--------------------------------------------------------------------------
This e-mail Contains PeerApp Proprietary and Confidential information.

--------------------------------------------------------------------------
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Y.J. Gu
Sent: Monday, August 03, 2009 10:28 AM
To: [email-masked]
Subject: [decade] Comment for motivations and goals of DECADE

I did not attend DECADE bar BOF, just follow the progress by analyzing
meeting minutes. So, forgive me if there might be any misunderstanding.
^_^

I notice that both the "Problem statement" and "BranchCache
presentation"
take "band-saving" as a primary motivation/incentive for DECADE.

IMHO, "band-saving" might not be a good reason to convince IETF to work
on
DECADE and might put DECADE into much more debate. There are already
various
caching or non-caching solutions implemented to reduce uplink/downlink
bandwidth, for both C/S and P2P applications, e.g. CDN, P2P caching and
DPI.
Some others are under discussion in mailing list, such as ALTO.

meeting minutes, and you will find that 7 out of 15 questions in
"Problem

To decouple signaling and data transmission is the very incentive that
we
need. Up to now, there is no WG in IETF ever intends to address the
updating
pressure to existing caches system.  Absorbing people's attention on
this
aspect might help us clarify the necessary of DECADE more convincibly.

And we can regard "band-saving" as a subordinate advantage, instead of
as an
incentive.

Regards

Yingjie Gu

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

************************************************************************
*********************

---

From: "Y.J. Gu" <[email-masked]>
Date: Mon, 03 Aug 2009 17:30:18 +0800

" Maybe DECADE should focus on this narrow protocol problem, and not
preclude any particular form of caching systems architectures and/or P2P
applications types. "

Support, a universal protocol should be the final target of DECADE.
But, IMHO, at beginning,  we should base our discussion on a particular
caching form, to avoid abstract discussion.
This caching form should be scalable, open architecture and protocol, and,
of course, P2P friendly.
This could be either an existing caching form or a new one. 

Regards

Yingjie Gu

-----Original Message-----
From: Alan Arolovitch [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 4:00 PM
To: Y.J. Gu; [email-masked]
Subject: RE: [decade] Comment for motivations and goals of DECADE

I agree that bandwidth savings as a scope is too narrow and not exclusive
enough.
P2P caching systems can accommodate a variety of value propositions,
including bandwidth savings, SLA assurance and service delivery.
Based on discussions spurred by ALTO, it seems that there's a perceived and
understood challenge in scaling multi-protocol support of P2P applications
Maybe DECADE should focus on this narrow protocol problem, and not preclude
any particular form of caching systems architectures and/or P2P applications
types.
Just as HTTP1.1 RFC 2616 doesn't spell out particular caching architecture,
but rather standardizes solid protocol-level caching support, that allows to
build transparent and non-transparent caching systems based on it.

Lastly, on the legal side, I don't think DECADE should focus exclusively on
DMCA agenda (i.e. caching-of-potentially-copyright-infringing-content)
There is plenty of deployment scenarios that do not fall into this bucket,
even though it would be nice if DECADE wasn't in a clear violation of the
procedures set by DMCA and other very similar legal acts adopted globally.

--alan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Y.J. Gu
Sent: Monday, August 03, 2009 10:28 AM
To: [email-masked]
Subject: [decade] Comment for motivations and goals of DECADE

Regards

Yingjie Gu

---

From: "zhangyunfei" <[email-masked]>
Date: Tue, 4 Aug 2009 11:56:31 +0800

Please see inline for the comments.

                     BR
                       Yunfei

 Best regards!
  Sincerely yours,
      Yunfei 
       2009-08-04
*****************************************************

Yunfei Zhang, Ph.D.

R&D, CHINA MOBILE COMMUNICATIONS CORPORATION

Tel: +86 10 158016966688 ext. 3247

Fax: +86 10 63601087

MOBILE: 1360-1032-119

*****************************************************

发件人： Y.J. Gu
发送时间： 2009-08-03 15:31:58
收件人： [email-masked]
抄送： 
主题： [decade] Comment for motivations and goals of DECADE

Many initiatives have similar incentive,e.g., PPSP decouples signaling and data transmission as well, which can also include exisiting cache system as the peers.So I think it's more convincing to focus the incentive and scope of DECADE as "saving uplink usage"and "developing signaling protocol between client and cache nodes".

Regards

Yingjie  Gu

---

From: "Y.J. Gu" <[email-masked]>
Date: Tue, 04 Aug 2009 14:30:28 +0800

Hello Yunfei, thank you for your comments.
First of all, I need to explain that when I said "decouple  signaling  and
data  transmission", I actually mean that cache will act as a content
storage without understanding various proprietary protocol.   
As much as I know, PPSP is going to establish a standard architecture and
protocol for P2P streaming. I guess what you mean by  "PPSP decouples
signaling and data transmission " is PPSP provides a universal signaling,
regardless who store the data and how it is transmitted to terminal.  That
means, in PPSP, an object who performing signalling could also be the one
who store and transmit the data.
So, I think we are talking about different issues.
Besides,  PPSP focus on streaming and DECADE has no such limitation.
PPSP is also an very interesting topic. I'm still looking forward to the
meeting minutes of PPSP.
 
Could you list other initiatives that is incentived by "decouple  signaling
and  data  transmission on cache " , so we can make a deep and wide
comparison. That will be really helpful.

Regards

Yingjie Gu

  _____  

From: zhangyunfei [mailto:[email-masked]] 
Sent: Tuesday, August 04, 2009 11:57 AM
To: Y.J. Gu; [email-masked]
Subject: Re: [decade] Comment for motivations and goals of DECADE

                     BR
                       Yunfei
 
  _____  

 Best regards!
  Sincerely yours,
      Yunfei 
       2009-08-04
 
Yunfei Zhang, Ph.D.

 
Fax: +86 10 63601087
 
MOBILE: 1360-1032-119

  _____  

发件人： Y.J. Gu
 
I  did  not  attend  DECADE  bar  BOF,  just  follow  the  progress  by
analyzing
meeting  minutes.  So,  forgive  me  if  there  might  be  any
misunderstanding.    ^_^

IMHO,  "band-saving"  might  not  be  a  good  reason  to  convince  IETF
to  work  on
DECADE  and  might  put  DECADE  into  much  more  debate.  There  are
already  various
caching  or  non-caching  solutions  implemented  to  reduce
uplink/downlink
bandwidth,  for  both  C/S  and  P2P  applications,  e.g.  CDN,  P2P
caching  and  DPI.
Some  others  are  under  discussion  in  mailing  list,  such  as  ALTO.
 
I  know  DECADE  is  different,  but  why  IETF  need  another
"band-saving"
solution?  That's  a  hard  question.  
"saving  uplink  is  too  broad  scope",  as  Rich  said.
"saving  the  uplink  is  not  the  main  drving  force",  said  Lucy  Yong.
I  agree  with  them,  it  will  make  things  too  complicated.  Look  back
the
meeting  minutes,  and  you  will  find  that  7  out  of  15  questions  in
"Problem
statement"  Q&A  are  about  bandwidth.  We  do  not  need
multi-motivations  to
indicate  the  importance  of  DECADE,  we  just  need  an  overwhelming
one.
 
To  decouple  signaling  and  data  transmission  is  the  very  incentive
that  we
need.  Up  to  now,  there  is  no  WG  in  IETF  ever  intends  to  address
the  updating
pressure  to  existing  caches  system.    Absorbing  people's  attention
on  this
aspect  might  help  us  clarify  the  necessary  of  DECADE  more
convincibly.
Many initiatives have similar incentive,e.g., PPSP decouples signaling and
data transmission as well, which can also include exisiting cache system as
the peers.So I think it's more convincing to focus the incentive and scope
of DECADE as "saving uplink usage"and "developing signaling protocol between
client and cache nodes".
 
And  we  can  regard  "band-saving"  as  a  subordinate  advantage,  instead
of  as  an
incentive.
 
Regards
 
Yingjie  Gu

---

From: Spiros Spirou <[email-masked]>
Date: Tue, 04 Aug 2009 10:08:43 +0300

Hi Yingjie,

Y.J. Gu wrote:

> First of all, I need to explain that when I said "decouple  signaling 
>  and  data  transmission", I actually mean that cache will act as a 
> content storage without understanding various proprietary protocol.   

Would you please explain this a bit further?

Thanks,

Spiros

---

From: "zhangyunfei" <[email-masked]>
Date: Tue, 4 Aug 2009 15:41:52 +0800

Hi Yingjie,
    Please see inline for the reply.Thanks!
                     BR
                      Yunfei

zhangyunfei
2009-08-04

发件人： Y.J. Gu
发送时间： 2009-08-04 15:29:45
收件人： 'zhangyunfei'; [email-masked]
抄送： 
主题： RE: [decade] Comment for motivations and goals of DECADE

Hello Yunfei, thank you for your comments.
First of all, I need to explain that when I said "decouple  signaling  and  data  transmission", I actually mean that cache will act as a content storage without understanding various proprietary protocol.   

As much as I know, PPSP is going to establish a standard architecture and protocol for P2P streaming. I guess what you mean by  "PPSP decouples signaling and data transmission " is PPSP provides a universal signaling, regardless who store the data and how it is transmitted to terminal.  That means, in PPSP, an object who performing signalling could also be the one who store and transmit the data.
So, I think we are talking about different issues.
Besides,  PPSP focus on streaming and DECADE has no such limitation.
-----Yunfei:
In the last week PPSP bar bof, acutally there are suggestions to explore more services possiblity, e.g., file sharing.So welcome to discuss the scope in PPSP mailing list.
PPSP is also an very interesting topic. I'm still looking forward to the meeting minutes of PPSP.
Yunfei---
Thanks so much for your interest in PPSP.The meeting minutes is to be published soon.Victor will post it in the mailing list.
Could you list other initiatives that is incentived by "decouple  signaling  and  data  transmission on cache " , so we can make a deep and wide comparison. That will be really helpful.
Yunfei---
Hum..I think the most attacting point is to reduce the uplink pressure.

Regards
Yingjie Gu

                     BR
                       Yunfei

 Best regards!
  Sincerely yours,
      Yunfei 
       2009-08-04

Yunfei Zhang, Ph.D.

Fax: +86 10 63601087

MOBILE: 1360-1032-119

发件人： Y.J. Gu

Regards

Yingjie  Gu

---

From: 오승훈 <[email-masked]>
Date: Tue, 4 Aug 2009 17:58:29 +0900

Hello Yingjie, 

I also have difficult to understand how "cache will act as a content
storage w/o understanding various proprietary protocol" is related with "
decouple  signaling >  and  data  transmission"

Please explain more. 

Thanks in advance, 
Seung-Hun Oh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Spiros Spirou
Sent: Tuesday, August 04, 2009 4:09 PM
To: Y.J. Gu
Cc: [email-masked]
Subject: Re: [decade] Comment for motivations and goals of DECADE

Hi Yingjie,

Thanks,

Spiros

---

From: "Y.J. Gu" <[email-masked]>
Date: Tue, 04 Aug 2009 17:02:33 +0800

Hi Spiros,
I would like to explain this issue from my perspective.

Caches are widely deployed in network and serve both C/S and P2P
applictions, especially those with large amounts of data. For each
application it supports, the existing caches have to understand the
corresponding protocol(e.g. BT, Emule) in order to perform singalling and
transmit data to the end client. So it's necessary to update caches if a new
application needs to be supported.

                +------------+
                |   caches  |
                +------------+
                 0      &      * 
               0        &        * 
             0          &          * 
     +------+    +--------+   +-------+
     |  BT  |     |Emule |    | CDN |
     | user |     | user   |    | user | 
     +------+    +---------+  +-------+
0 is BT protocol
& is Emule protocol
*  is some other protocol
                  Fig 1   existing caching system

If we perform signalling among peers or C&S, and let caches store data,
things will change. E.g peers negotiate with each other using proprietary
protocol and download data from caches using a same protocol. See in Fig2.

                +------------+
                 |  caches  |
                +------------+
                 $      $      $ 
               $        $        $ 
             $          $          $ 
     +------+     +--------+  +--------+
     |  BT  |      |Emule|    | CDN  |
     | user |      | user  |    | user  | 
    +-------+     +--------+  +--------+
         0               &             *
         0               &             *
         0               &             *
     +-----+    +-------+      +--------+
     |  BT |     |Emule|      | CDN  |
     | user|     | user  |      | server| 
    +------+    +--------+    +---------+

0 is BT protocol
& is Emule protocol
*  is some other protocol
$ is a new protocol we need to design in DECADE
                    Fig 2  decouple application and data

Does this explaination make sense to you, Spiros? 

Regards

Yingjie Gu 

-----Original Message-----
From: Spiros Spirou [mailto:[email-masked]] 
Sent: Tuesday, August 04, 2009 3:09 PM
To: Y.J. Gu
Cc: [email-masked]
Subject: Re: [decade] Comment for motivations and goals of DECADE

Hi Yingjie,

Thanks,

Spiros

---

From: "Alan Arolovitch" <[email-masked]>
Date: Tue, 4 Aug 2009 12:27:26 +0300

Yingjie,

I agree with the practical test, need to have a caching framework in
mind
to make the discussion practical
I am familiar with two main caching architectures when applied to P2P:

- in-line caching 
	cache intermediates transactions between peers, similarly to
	conventional Web caching
-"super-peer" caching 
	peer discovers cache and contacts it separately and in addition
to 
	regular peer discovery and swarming

Each form of caching has its own advantages, depending on the objectives
of
application and/or network operator.
It seems to me that it is possible to come up with a solution that would

accommodate more than one form of caching

--alan

-----Original Message-----
From: Y.J. Gu [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 12:30 PM
To: Alan Arolovitch; [email-masked]
Subject: RE: [decade] Comment for motivations and goals of DECADE

This caching form should be scalable, open architecture and protocol,
and,

Regards

Yingjie Gu

-----Original Message-----
From: Alan Arolovitch [mailto:[email-masked]] 
Sent: Monday, August 03, 2009 4:00 PM
To: Y.J. Gu; [email-masked]
Subject: RE: [decade] Comment for motivations and goals of DECADE

exclusive
preclude
any particular form of caching systems architectures and/or P2P
architecture,
but rather standardizes solid protocol-level caching support, that
allows to

Lastly, on the legal side, I don't think DECADE should focus exclusively
on
DMCA agenda (i.e. caching-of-potentially-copyright-infringing-content)
There is plenty of deployment scenarios that do not fall into this
bucket,
even though it would be nice if DECADE wasn't in a clear violation of
the
procedures set by DMCA and other very similar legal acts adopted
globally.

--alan 

------------------------------------------------------------------------
--
This e-mail Contains PeerApp Proprietary and Confidential information.

------------------------------------------------------------------------
--
-----Original Message-----
Of

Regards

Yingjie Gu

---

From: 오승훈 <[email-masked]>
Date: Tue, 4 Aug 2009 19:23:39 +0900

Hello Yingjie Gu, 

I appreciate for your in-depth explanation. 

According to your description, "SIGNALING" takes place among the peers and 
is the proprietary protocol. 
"DATA TRANSMISSION" takes place between caches and peers of different types 
and is something (protocol) that DECADE is going to make. 
In that sense, are 'signaling' and 'data transmission' decoupled?

Do I understand correctly?

Regards, 
Seung-Hun Oh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Y.J. Gu
Sent: Tuesday, August 04, 2009 6:03 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [decade] Comment for motivations and goals of DECADE

Hi Spiros,

                +------------+
                |   caches  |
                +------------+
                 0      &      * 
               0        &        * 
             0          &          * 

                +------------+
                 |  caches  |
                +------------+
                 $      $      $ 
               $        $        $ 
             $          $          $ 

0 is BT protocol
& is Emule protocol
*  is some other protocol

Regards

Yingjie Gu 

-----Original Message-----
From: Spiros Spirou [mailto:[email-masked]] 
Sent: Tuesday, August 04, 2009 3:09 PM
To: Y.J. Gu
Cc: [email-masked]
Subject: Re: [decade] Comment for motivations and goals of DECADE

Hi Yingjie,

Thanks,

Spiros

---

From: "Woundy, Richard" <[email-masked]>
Date: Tue, 4 Aug 2009 19:06:20 -0400

>I agree that bandwidth savings as a scope is too narrow and not
exclusive enough. P2P caching systems can accommodate a variety of value
propositions, including bandwidth savings, SLA assurance and service
delivery.

I agree with Alan that there are different motivations by different
members of the overall community for caching. End users may be more
interested in faster downloads, while ISPs may be more interested in
saving bandwidth.

But I had some other tradeoffs in mind when I made my original comment.
Some broadband access providers are more constrained on uplink
bandwidth, and others are more constrained on downlink bandwidth,
depending on their network topologies, eg the relative uplink/downlink
bandwidths available across the bottleneck shared links.

In addition, some ISPs are more affected (economically) by inbound
traffic on backbone interconnects than other ISPs, e.g. see the
"bandwidth cost" bullet on slide 8 of
http://www.ietf.org/proceedings/75/slides/P2PRG-8.pdf.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alan Arolovitch
Sent: Monday, August 03, 2009 4:00 AM
To: Y.J. Gu; [email-masked]
Subject: Re: [decade] Comment for motivations and goals of DECADE

--alan 

-----Original Message-----

Regards

Yingjie Gu

---

From: "Y.J. Gu" <[email-masked]>
Date: Wed, 05 Aug 2009 09:34:13 +0800

To Seung-Hun:
Yes, that's what I mean.

To Alan:
It depends on the concept of DECADE.  When the mailing list make out what
DECADE is going to do, then folks can figure out what kind of form is
acceptable to most people.

Regards

Yingjie Gu

---

From: Song Haibin <[email-masked]>
Date: Wed, 05 Aug 2009 15:36:52 +0800

Hi Alan,

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Alan Arolovitch
>Sent: Tuesday, August 04, 2009 5:27 PM
>I agree with the practical test, need to have a caching 
>framework in mind to make the discussion practical I am 
>familiar with two main caching architectures when applied to P2P:
>
>- in-line caching 
>	peer discovers cache and contacts it separately and in 
>addition to 
>Each form of caching has its own advantages, depending on the 
>objectives of application and/or network operator.
>It seems to me that it is possible to come up with a solution 
>that would accommodate more than one form of caching
>

I would like to find another term instead of "cache". Because the existing
P2P "cache" system is either transparent or non-transparent, which are all
application protocol aware. What we want to develop is an application
protocol agnostic framework, esp. the standard protocol(s) (control and data
transport) spoken between the peers and the in-network storage, in order to
minimize the complexity of supporting various and continuous changing p2p
application protocols on existing cache systems, and also save bandwidth for
ISPs. The final solution could be used by both p2p and c/s applications. The
access control and resource control on the sharing model are important.

BR,
Haibin

>" Maybe DECADE should focus on this narrow protocol problem, 
>and not preclude any particular form of caching systems 
>architectures and/or P2P applications types. "
>
>But, IMHO, at beginning,  we should base our discussion on a 
>particular caching form, to avoid abstract discussion.
>This caching form should be scalable, open architecture and 
>protocol, and, of course, P2P friendly.
>I agree that bandwidth savings as a scope is too narrow and 
>not exclusive enough.
>P2P caching systems can accommodate a variety of value 
>propositions, including bandwidth savings, SLA assurance and 
>service delivery.
>Based on discussions spurred by ALTO, it seems that there's a 
>perceived and understood challenge in scaling multi-protocol 
>support of P2P applications Maybe DECADE should focus on this 
>narrow protocol problem, and not preclude any particular form 
>of caching systems architectures and/or P2P applications types.
>architecture, but rather standardizes solid protocol-level 
>caching support, that allows to build transparent and 
>non-transparent caching systems based on it.
>
>Lastly, on the legal side, I don't think DECADE should focus 
>exclusively on DMCA agenda (i.e. 
>caching-of-potentially-copyright-infringing-content)
>There is plenty of deployment scenarios that do not fall into 
>this bucket, even though it would be nice if DECADE wasn't in 
>a clear violation of the procedures set by DMCA and other very 
>similar legal acts adopted globally.
>
>--alan 
>
>
> 
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Y.J. Gu
>analyzing meeting minutes. So, forgive me if there might be 
>any misunderstanding.
>^_^
>
>IMHO, "band-saving" might not be a good reason to convince 
>IETF to work on DECADE and might put DECADE into much more 
>debate. There are already various caching or non-caching 
>solutions implemented to reduce uplink/downlink bandwidth, for 
>both C/S and P2P applications, e.g. CDN, P2P caching and DPI.
>I agree with them, it will make things too complicated. Look 
>back the meeting minutes, and you will find that 7 out of 15 
>questions in "Problem statement" Q&A are about bandwidth. We 
>do not need multi-motivations to indicate the importance of 
>DECADE, we just need an overwhelming one.
>
>To decouple signaling and data transmission is the very 
>incentive that we need. Up to now, there is no WG in IETF ever 
>intends to address the updating pressure to existing caches 
>system.  Absorbing people's attention on this aspect might 
>help us clarify the necessary of DECADE more convincibly.
>
>And we can regard "band-saving" as a subordinate advantage, 
>instead of as an incentive.
>
>Regards
>
>Yingjie Gu
>

---

From: "Alan Arolovitch" <[email-masked]>
Date: Wed, 5 Aug 2009 11:09:37 +0300

Haibin,

I think we're in agreement on these high-level objectives
When we talk about the standardized communications between peers and 
in-network storage, it is common to think of content retrieval.
The acquisition of content by in-network storage from P2P applications 
is as important, and in fact may be more difficult to make 
application/protocol agnostic.

Also, is it the intention to use RELOAD work for in-network storage
discovery?

--alan

-----Original Message-----
From: Song Haibin [mailto:[email-masked]] 
Sent: Wednesday, August 05, 2009 10:37 AM
To: Alan Arolovitch; 'Y.J. Gu'; [email-masked]
Subject: RE: [decade] Comment for motivations and goals of DECADE

Hi Alan,

>that would accommodate more than one form of caching

I would like to find another term instead of "cache". Because the
existing
P2P "cache" system is either transparent or non-transparent, which are
all
application protocol aware. What we want to develop is an application
protocol agnostic framework, esp. the standard protocol(s) (control and
data
transport) spoken between the peers and the in-network storage, in order
to
minimize the complexity of supporting various and continuous changing
p2p
application protocols on existing cache systems, and also save bandwidth
for
ISPs. The final solution could be used by both p2p and c/s applications.
The
access control and resource control on the sharing model are important.

BR,
Haibin

---

From: Song Haibin <[email-masked]>
Date: Wed, 05 Aug 2009 16:12:22 +0800

Hi Rich,

>On Behalf Of Woundy, Richard
>Sent: Wednesday, August 05, 2009 7:06 AM
>To: Alan Arolovitch; Y.J. Gu
>Cc: [email-masked]
>exclusive enough. P2P caching systems can accommodate a 
>variety of value propositions, including bandwidth savings, 
>SLA assurance and service delivery.
>
>I agree with Alan that there are different motivations by 
>different members of the overall community for caching. End 
>users may be more interested in faster downloads, while ISPs 
>may be more interested in saving bandwidth.
>

Agree. Besides that, the cache system providers may be more interested in
their maintenance cost.

>bandwidth, and others are more constrained on downlink 
>bandwidth, depending on their network topologies, eg the 
>relative uplink/downlink bandwidths available across the 
>bottleneck shared links.
>

>In addition, some ISPs are more affected (economically) by 
>inbound traffic on backbone interconnects than other ISPs, 
>e.g. see the "bandwidth cost" bullet on slide 8 of 

Thanks. I think ISPs would like to save both uplink and downlink bandwidths
whenever possible. It will depend on the deployment to save downlink or
inbound backbone bandwidths sometimes. 

BR,
Haibin

---

From: Song Haibin <[email-masked]>
Date: Wed, 05 Aug 2009 16:34:25 +0800

Hi Alan,

>Sent: Wednesday, August 05, 2009 4:10 PM
>To: Song Haibin; Y.J. Gu; [email-masked]
>I think we're in agreement on these high-level objectives When 
>we talk about the standardized communications between peers 
>and in-network storage, it is common to think of content retrieval.
>The acquisition of content by in-network storage from P2P 
>applications is as important, and in fact may be more 
>difficult to make application/protocol agnostic.
>

It's not content retrieval. It's content store/retrieval. P2P applications
users also use the standard protocol (control/data transport) to store
content to the in-network storage and share it to other peers. It will be
application protocol agnostic.

>Also, is it the intention to use RELOAD work for in-network 
>storage discovery?
>

We need the discovery for the in-network storage entity for contents,
although we don't want to touch the content format itself. The discovery
will be based on either application protocols or some other existing
mechanisms.

BR,
Haibin

>>From: [email-masked] [mailto:[email-masked]] On 
>>Behalf Of Alan Arolovitch
>>mind to make the discussion practical I am familiar with two main 
>>caching architectures when applied to P2P:
>>
>>- in-line caching 
>>It seems to me that it is possible to come up with a solution that 
>>would accommodate more than one form of caching
>>
>
>I would like to find another term instead of "cache". Because 
>the existing P2P "cache" system is either transparent or 
>non-transparent, which are all application protocol aware. 
>What we want to develop is an application protocol agnostic 
>framework, esp. the standard protocol(s) (control and data
>transport) spoken between the peers and the in-network 
>storage, in order to minimize the complexity of supporting 
>various and continuous changing p2p application protocols on 
>existing cache systems, and also save bandwidth for ISPs. The 
>final solution could be used by both p2p and c/s applications.
>The
>>preclude any particular form of caching systems architectures and/or 
>>P2P applications types. "
>>
>particular 
>>and, of course, P2P friendly.
>perceived 
>>and understood challenge in scaling multi-protocol support of P2P 
>>applications Maybe DECADE should focus on this narrow 
>protocol problem, 
>>and not preclude any particular form of caching systems architectures 
>>and/or P2P applications types.
>>architecture, but rather standardizes solid protocol-level caching 
>>support, that allows to build transparent and non-transparent caching 
>>systems based on it.
>>
>>bucket, even though it would be nice if DECADE wasn't in a clear 
>>violation of the procedures set by DMCA and other very similar legal 
>>acts adopted globally.
>>
>>--alan
>>
>>
>> 
>>From: [email-masked] [mailto:[email-masked]] On 
>>Behalf Of Y.J. Gu
>misunderstanding.
>IETF to work 
>>on DECADE and might put DECADE into much more debate. There 
>are already 
>>various caching or non-caching solutions implemented to reduce 
>>uplink/downlink bandwidth, for both C/S and P2P applications, 
>e.g. CDN, 
>>P2P caching and DPI.
>>"Problem statement" Q&A are about bandwidth. We do not need 
>>multi-motivations to indicate the importance of DECADE, we 
>just need an 
>>overwhelming one.
>>
>incentive that 
>>we need. Up to now, there is no WG in IETF ever intends to 
>address the 
>>updating pressure to existing caches system.  Absorbing people's 
>>attention on this aspect might help us clarify the necessary 
>of DECADE 
>>more convincibly.
>>

---

From: "Y.J. Gu" <[email-masked]>
Date: Wed, 05 Aug 2009 16:40:32 +0800

"The acquisition of content by in-network storage from P2P applications is
as important, and in fact may be more difficult to make application/protocol
agnostic."

Good comment. 
Seems that DECADE wants to design a new access protocol to establish a
relationship between peer and in-network storage. Then peer   can upload
content to in-network storage by RTP, FTP, HTTP,..., the in-network storage
need not know what the application protocol is.

Regards

Yingjie Gu

-----Original Message-----
From: Alan Arolovitch [mailto:[email-masked]] 
Sent: Wednesday, August 05, 2009 4:10 PM
To: Song Haibin; Y.J. Gu; [email-masked]
Subject: RE: [decade] Comment for motivations and goals of DECADE

Haibin,

I think we're in agreement on these high-level objectives When we talk about
the standardized communications between peers and in-network storage, it is
common to think of content retrieval.
The acquisition of content by in-network storage from P2P applications is as
important, and in fact may be more difficult to make application/protocol
agnostic.

--alan

-----Original Message-----
From: Song Haibin [mailto:[email-masked]]
Sent: Wednesday, August 05, 2009 10:37 AM
To: Alan Arolovitch; 'Y.J. Gu'; [email-masked]
Subject: RE: [decade] Comment for motivations and goals of DECADE

Hi Alan,

>	peer discovers cache and contacts it separately and in addition to

BR,
Haibin

>applications Maybe DECADE should focus on this narrow protocol problem, 
>on DECADE and might put DECADE into much more debate. There are already 
>uplink/downlink bandwidth, for both C/S and P2P applications, e.g. CDN, 
>P2P caching and DPI.
>multi-motivations to indicate the importance of DECADE, we just need an 
>overwhelming one.
>
>we need. Up to now, there is no WG in IETF ever intends to address the 
>attention on this aspect might help us clarify the necessary of DECADE 
>more convincibly.
>
>as an incentive.

---

From: "Alan Arolovitch" <[email-masked]>
Date: Wed, 5 Aug 2009 12:02:19 +0300

Song, Yingjie,

If I follow you correctly, you limit the function of in-network storage 
to content origination, when all addressable content is always available

in the storage.
In this case indeed there's a simple flow of sharing content into
the storage ("upload") and retrieving it back.
You can think of this scenario as P2P-based YouTube service.

There are other feasible and interesting scenarios where the in-network
storage
acts as a cache, when only some of addressable content is available in
the storage.
It could be because the content is not locally available, to support
differentiated 
service levels or to gain some scalability benefits
In this case the in-network storage system would have to acquire content
from P2P overlay and/or other forms of networked storage, on its own.

--alan

-----Original Message-----
From: Song Haibin [mailto:[email-masked]] 
Sent: Wednesday, August 05, 2009 11:34 AM
To: Alan Arolovitch; 'Y.J. Gu'; [email-masked]
Subject: RE: [decade] Comment for motivations and goals of DECADE

Hi Alan,

>difficult to make application/protocol agnostic.

It's not content retrieval. It's content store/retrieval. P2P
applications
users also use the standard protocol (control/data transport) to store
content to the in-network storage and share it to other peers. It will
be
application protocol agnostic.

BR,
Haibin

---

From: Spiros Spirou <[email-masked]>
Date: Wed, 5 Aug 2009 12:28:39 +0300

Hi Yingjie,

Many thanks for the elaborate explanation.

It's clear that the concept of Fig. 2 provides a protocol target for  
DECADE. That's the protocol that applications (P2P or C/S) would use  
to retrieve content from caches (in-network storage).

However, I think we need to consider the effects that such a protocol  
would have on stakeholders (cache vendors, cache owners, app  
developers, app users, etc.). With the concept of Fig. 1 a cache  
vendor would have to do more work to support another app, but at the  
same time she's able to minimize the investment risk both for herself  
and the cache owner. Everything is under the control of the cache  
vendor/owner; the cache is ready to work out-of-the-box without  
dependencies to external factors (e.g., app modifications).

On the other hand, the concept of Fig. 2 simplifies the job of the  
cache vendor/owner, because no extra work is necessary to support a  
new app. However, unless app developers modify their apps and app  
users install those apps, the cache will not be effective. In fact,  
dependence on such many factors under different authorities can make  
cache success ambiguous.

I'm not saying that we should resolve the socio-economic issues of a  
common app-cache protocol here. (Besides, the existence of such a  
protocol could handle those issues naturally in the long run). I'm  
only suggesting that we should discuss the protocol's possibly adverse  
effects and emphasize stakeholder incentives to mitigate them.

Thanks,

Spiros

---

From: Song Haibin <[email-masked]>
Date: Wed, 05 Aug 2009 17:48:38 +0800

>Sent: Wednesday, August 05, 2009 5:02 PM
>If I follow you correctly, you limit the function of 
>in-network storage to content origination, when all 
>addressable content is always available
>
>in the storage.
>In this case indeed there's a simple flow of sharing content 
>into the storage ("upload") and retrieving it back.
>There are other feasible and interesting scenarios where the 
>in-network storage acts as a cache, when only some of 
>addressable content is available in the storage.
>It could be because the content is not locally available, to 
>support differentiated service levels or to gain some 
>scalability benefits In this case the in-network storage 
>system would have to acquire content from P2P overlay and/or 
>other forms of networked storage, on its own.
>

That depends on which party determines what to be stored in in-network
storage and whether the standard protocol we want to develop here is
supported among that p2p application users.

Haibin

>When we talk 
>>about the standardized communications between peers and in-network 
>>storage, it is common to think of content retrieval.
>applications users also use the standard protocol 
>(control/data transport) to store content to the in-network 
>storage and share it to other peers. It will be application 
>protocol agnostic.
>
>We need the discovery for the in-network storage entity for 
>contents, although we don't want to touch the content format 
>itself. The discovery will be based on either application 
>protocols or some other existing mechanisms.
>
>
>BR,
>Haibin
>
>
>>--alan
>>
>>
>> 
>>existing P2P "cache" system is either transparent or non-transparent, 
>>which are all application protocol aware.
>framework, 
>>esp. the standard protocol(s) (control and data
>>transport) spoken between the peers and the in-network storage, in 
>>order to minimize the complexity of supporting various and continuous 
>>changing p2p application protocols on existing cache systems, 
>and also 
>>save bandwidth for ISPs. The final solution could be used by both p2p 
>>and c/s applications.
>>The
>architectures 
>back the

---

From: Spiros Spirou <[email-masked]>
Date: Wed, 5 Aug 2009 12:53:13 +0300

Hi all,

> inbound backbone bandwidths sometimes.

I'm aware of 3 transit traffic charging models so far:

1) download only
2) abs(download - upload)
3) max{download, upload}

IMO, these have been created with download's dominance in mind. It  
seems that tier-3 ISPs are controlling upload through asymmetric  
access connections. Of course these could change with FTTH.

If anyone is aware of alt charging models/trends or the popularity of  
those above please share. Info like this can show us what requirements  
for DECADE are important.

Thanks,

Spiros

---

From: Spiros Spirou <[email-masked]>
Date: Wed, 5 Aug 2009 13:11:16 +0300

Hi all,

> from P2P overlay and/or other forms of networked storage, on its own.

I fully agree with Alan. If I understood correctly, it seems there are  
2 separate concepts here:

1) Delegation of uploading. Instead of uploading themselves, app nodes  
delegate that task to the in-network storage (cache).
2) In-network storage content provisioning. The in-network storage  
needs to know what content to store and how to get it from the app.

IMO, (2) needs a protocol between the in-network storage and the app  
resource directory (e.g. trackers in BitTorrent). The in-network  
storage would use such a protocol to query the resource directory for  
e.g. the most popular content in it's domain. However, there's no  
clear incentive for a resource directory to offer such a protocol.

Thanks,

Spiros

---

From: Richard Alimi <[email-masked]>
Date: Wed, 5 Aug 2009 09:26:24 -0400

Hi Yingjie,

On Wednesday 05 August 2009 4:40:32 am Y.J. Gu wrote:
> as important, and in fact may be more difficult to make
> application/protocol agnostic."
>
> Good comment.

In terms of populating the in-network storage, this is indeed the model we had 
in mind.  We had not originally considered the possibility of the in-network 
storage discovering content itself since, as has been pointed out, that can 
complicate matters by making in-network storage not application/protocol 
agnostic.

In the Sailor presentation, we showed a single operation called 'slr-store' 
(it was actually implemented as an HTTP PUT) that was used to put an object 
into the user's data locker.  Of course, this is just one possibility...

-- 
Richard Alimi
Department of Computer Science
Yale University

---

From: "Y. R. Yang" <[email-masked]>
Date: Wed, 05 Aug 2009 12:46:30 -0400

Hi Spiros and Alan,

Good comments. Please see below.

> 2 separate concepts here:
This classification is good.
> clear incentive for a resource directory to offer such a protocol.
Provisioning and access control are coupled.

There are two provisioning methods to get content into the storage:

P1: Application entity stores content into the storage (e.g., peer A or 
content publisher C; it may be in a format that A stores a content block 
itself, or A asks the storage to fetch a content block from a location);
P2: The storage fetches content by itself (not on behalf of any 
particular entity).

The access problem is who does gatekeeping and distributes access token 
to the content in the storage. This is related with who does the 
provisioning. (Note that this is a logical model; there are 
under-the-hood optimization to avoid duplicating upload to the storage).

In the current Sailor design, we felt that P1 is a cleaner design, and 
there is an access-control mechanism that is simple to state and allows 
easy accountability: only who puts the content in can grant access to 
that content to others (modular some storage usage policies imposed by 
an ISP storage provider such as no uploading to those outside the ISP).

To support P2, you are right that we then need a notification mechanism 
(for content provider or P2P app to notify the storage about content 
availability) and/or query mechanism (e.g., the storage queries tracker 
or a content registry, as once mentioned by Nick Weaver). There is also 
a need for solving the access control policy problem for the the content 
obtained by P2. Yet another problem is the notification/query problem of 
telling applications what content the storage has (as it maybe the case 
that no application entity knows that the storage has fetched some 
particular content).

Let me add that even if a system allows only P1, there is an alternative 
design for access: peer A puts some content into the storage; if there 
is a querying mechanism to the storage to know what is available in the 
storage, peer B, who has no connection to peer A, can query and then 
download. We considered this possibility in the P2P context but did not 
pursue due to complexity. Overall, I have no strong objection to 
allowing P2 (I feel that it may help existing P2P caches for content 
acquisition). But it appears to be a separate protocol of the main 
protocols that we will consider.

Richard

---

From: "zhangyunfei" <[email-masked]>
Date: Thu, 06 Aug 2009 02:01:28 -0000

Hi all,
   I agree with Spiros's opinion. As pointed earlier, I don't think the In-network  storage  content  provisioning protocol between the caches or between caches and apps are within the scope of DECADE.There are two options about this protocol: 1) Reuse exisiting proprietary protocols; Cache is just like a common peer when doing this;But it need regular update of the cache systems.2) There are already attempts like PPSP doing such standard protocols.
The real value of DECADE is point1,Delegation  of  uploading, from an opertor's point of view.

                               BR
                                Yunfei

zhangyunfei
2008-08-09

发件人： Spiros Spirou
发送时间： 2009-08-05 18:11:31
收件人： Alan Arolovitch
抄送： [email-masked]
主题： Re: [decade] Comment for motivations and goals of DECADE

Hi  all,

Thanks,

Spiros

---

From: Yong Lucy <[email-masked]>
Date: Tue, 11 Aug 2009 16:29:26 -0500

Hi All,

I am pleased to jump this discussion and hope not too late. It is very clear
to me the need for a standard protocol for in-network storage access.
However, it seems a necessary to revise DECADE problem statement. As I
stated in bar BOF meeting, the main driver for this work is not for saving
the uplink BW. Here are motivations I see:

1)     Support a standard in-network storage access that is application
agnostic

2)     Allow the contents at in-network storage sharing with single or
multiple users who may run different applications  

3)     Enable more advanced caching at in-network storages (no need depend
on applications)

4)     Bring network operator opportunity to offer in-network storage
service along with network service

5)     In-network storage is the trend of industry moving, a standard
protocol will help in-network storage venders as well

Cheers,

Lucy

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
zhangyunfei
Sent: Friday, August 08, 2008 9:01 PM
To: Spiros Spirou; Alan Arolovitch
Cc: [email-masked]
Subject: Re: [decade] Comment for motivations and goals of DECADE

Hi all,

   I agree with Spiros's opinion. As pointed earlier, I don't think the
In-network  storage  content  provisioning protocol between the caches or
between caches and apps are within the scope of DECADE.There are two options
about this protocol: 1) Reuse exisiting proprietary protocols; Cache is just
like a common peer when doing this;But it need regular update of the cache
systems.2) There are already attempts like PPSP doing such standard
protocols.

The real value of DECADE is point1,Delegation  of  uploading, from an
opertor's point of view.

                               BR

                                Yunfei

  _____  

zhangyunfei

2008-08-09

  _____  

发件人： Spiros Spirou

收件人： Alan Arolovitch

抄送： [email-masked]

Hi  all,

On  05  Αυγ  2009,  at  12:02  ΜΜ,  Alan  Arolovitch  wrote:

>  If  I  follow  you  correctly,  you  limit  the  function  of  in-network

>  to  content  origination,  when  all  addressable  content  is  always

>  available

>  In  this  case  indeed  there's  a  simple  flow  of  sharing  content
into

>  There  are  other  feasible  and  interesting  scenarios  where  the  in-

>  network

>  It  could  be  because  the  content  is  not  locally  available,  to
support

>  In  this  case  the  in-network  storage  system  would  have  to
acquire    

>  content

>  from  P2P  overlay  and/or  other  forms  of  networked  storage,  on
its  own.

I  fully  agree  with  Alan.  If  I  understood  correctly,  it  seems
there  are    

1)  Delegation  of  uploading.  Instead  of  uploading  themselves,  app
nodes    

needs  to  know  what  content  to  store  and  how  to  get  it  from  the
app.

IMO,  (2)  needs  a  protocol  between  the  in-network  storage  and  the
app    

storage  would  use  such  a  protocol  to  query  the  resource  directory
for    

Thanks,

Spiros

decade  mailing  list

[email-masked]

---

From: "Y.J. Gu" <[email-masked]>
Date: Mon, 24 Aug 2009 16:07:54 +0800

Maybe the subject of the mail is not very clear.
I'd like to explain it.

Applicant In-network storage, I creat the name to represent the In-network
storage who download a content for its client from another In-network
storage.
Should the Applicant In-network storage store the content it downloads, to
server the later requests for this content from other clients?

Regards

Yingjie Gu

---

From: Song Haibin <[email-masked]>
Date: Mon, 24 Aug 2009 17:12:05 +0800

Hi Yingjie,

In general, assuming that an out-of-path method has been used for protecting
the copyright issues, and the in-network storage is allocated to different
users with many individual accounts, I would say a P2P client(in-network
storage user) could decide whether to store the content for himself in its
in-network storage account, and of course it can share the content in its
in-network storage account to other peers. However, in implementation, you
may have many methods to optimize it to avoid duplication on the same server
or on the servers of an local area. 

Thanks!
Haibin

>Sent: Monday, August 24, 2009 4:08 PM
>To: [email-masked]
>Subject: [decade] Should content be repeatedly stored on 
>different In-network storage?
>
>Applicant In-network storage, I creat the name to represent 
>the In-network storage who download a content for its client 
>from another In-network storage.
>Should the Applicant In-network storage store the content it 
>downloads, to server the later requests for this content from 
>other clients?
>
>
>
>Regards
>
>Yingjie Gu
>

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 24 Aug 2009 13:40:33 +0200

What is the name standing for?

D - Distributed?
E - External?
C - Cache?
A - Application?
D - Data?
E - Experience?

Or what was the original shorting for?

Regards
Christian

---

From: "Y.J. Gu" <[email-masked]>
Date: Tue, 25 Aug 2009 08:55:27 +0800

Hi Christian

It's DECoupled Application Data Enroute.
As for the goal of DECADE, you can refer to the earlier post. 

Regards

Yingjie Gu

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Schmidt, 
> Christian 1. (NSN - DE/Munich)
> Sent: Monday, August 24, 2009 7:41 PM
> To: ext Song Haibin; [email-masked]
> Subject: [decade] DECADE
>

---

From: Song Haibin <[email-masked]>
Date: Tue, 25 Aug 2009 14:11:48 +0800

Hi Christian,

I'm sorry for the mistake. I just added the full name for DECADE to the list
welcome message :) 

Thanks!
Haibin

>Sent: Tuesday, August 25, 2009 8:55 AM
>To: 'Schmidt, Christian 1. (NSN - DE/Munich)'; 'ext Song 
>Haibin'; [email-masked]
>Subject: RE: [decade] DECADE
>
>Hi Christian
>
>> [mailto:[email-masked]] On Behalf Of Schmidt, Christian 1. 
>> (NSN - DE/Munich)

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 26 Aug 2009 15:51:16 -0400

I would agree with Song that this would likely be something that is
implementation (or deployment) dependent. Ignoring the (possibly very
salient in this context) question about copyright,I can see a couple
of ways to do this:

1) The user (and the user only) decides what goes up in their storage
area. Obviously, this has maximum control on the part of the user, and
for privacy reasons is very appealing. That said, this variety is
unlikely to lead to as much of an optimization of the network, since
users may or may not choose to cache, etc., so may not be a practical
way of approaching this.

2) A system where it is completely transparent. In other words, once
someone downloads from me, it automatically is in my network storage,
and likely the remote parties as well. It could be removed when the
store is full, the file/chunk/whatever is a certain age, in a FIFO
style. Basically, this turns into a cache. This (or 3 below) would
likely result in far better overall improvement in network performance
than 1, although I admit that is not backed up by any research or
data, just my gut feeling looking at the options.

3) Something in between. Here I would picture some space the user
could use to place content in deliberately, and some space that is
effectively used as a cache.

It is worth noting that at first glance (I have to admit I haven't
thought might about it) it appears that the underlying protocol
constructs that would be needed to do this are the same -- the
decision is just made in the "network storage server" as to if data
passing through is cached or not -- so this may be an interesting
thing to think about from a deployment, charter, and scope
perspective, but in practice, may end up having very little impact on
what a possible protocol would look like.

David

---

From: "David A. Bryan" <[email-masked]>
Date: Wed, 26 Aug 2009 17:14:14 -0400

One clarification -- while I am talking in 2 and 3 about things that
are "transparent", I mean to the user -- not at the protocol layer.
The application is still aware of the fact it is using DECADE here, so
it isn't really a cache (which of course is different from what DECADE
is trying to do), but the behavior to the user appears similar, in
that recent shared and downloaded items would appear in it.

Someone pinged me offline and asked, and I realized my email was a bit
unclear on that point...

David

---

From: Song Haibin <[email-masked]>
Date: Fri, 28 Aug 2009 16:48:00 +0800

Hi David,

I like these three ways for P2P contents in-network storage. I agree that a
standard in-network storage access protocol could be applicable to all these
three ways. Here is my understanding of them.

For (1), I think I understand how it works. That's similar to what in the
SAILOR presentation at DECADE BAR BOF. In this method, User A can read/write
from/to its in-network storage, and also A can download from peer B or peer
B's in-network storage, and decide whether to store that content in A's
in-network storage (in-path). That's to say, what contents will be stored in
A's network storage is fully under control of user A. On the other hand, A
is aware of what is in its in-network storage, and could use its in-network
storage instead of itself to send data to other peers on requests. 

For (2), the difference from (1) is that user A does not have to decide what
will be in its in-network storage. When A dowloads a content from B(assume
that B's in-network storage does not have the content), then the content
will be stored in both A and B's in-network storage automatically.   In this
way, B's in in-network storage will tell B what contents are stored there.
So that when receiving a request for the same data content from another peer
later, B can make the decision whether to download from it or its in-network
storage. A's in-network storage will also tell A what contents are stored in
the core when there is update. I'm not sure if I catch the right thing here.
 
There might be the possiblity of (3) if the two above would be
complementary.

Thanks!
Haibin

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of David A. Bryan
>Sent: Thursday, August 27, 2009 3:51 AM
>To: Song Haibin
>Cc: Y.J. Gu; [email-masked]
>Subject: Re: [decade] Should content be repeatedly stored on 
>differentIn-network storage?
>
>I would agree with Song that this would likely be something 
>that is implementation (or deployment) dependent. Ignoring the 
>(possibly very salient in this context) question about 
>copyright,I can see a couple of ways to do this:
>
>1) The user (and the user only) decides what goes up in their 
>storage area. Obviously, this has maximum control on the part 
>of the user, and for privacy reasons is very appealing. That 
>said, this variety is unlikely to lead to as much of an 
>optimization of the network, since users may or may not choose 
>to cache, etc., so may not be a practical way of approaching this.
>
>2) A system where it is completely transparent. In other 
>words, once someone downloads from me, it automatically is in 
>my network storage, and likely the remote parties as well. It 
>could be removed when the store is full, the 
>file/chunk/whatever is a certain age, in a FIFO style. 
>Basically, this turns into a cache. This (or 3 below) would 
>likely result in far better overall improvement in network 
>performance than 1, although I admit that is not backed up by 
>any research or data, just my gut feeling looking at the options.
>
>3) Something in between. Here I would picture some space the 
>user could use to place content in deliberately, and some 
>space that is effectively used as a cache.
>
>It is worth noting that at first glance (I have to admit I 
>haven't thought might about it) it appears that the underlying 
>protocol constructs that would be needed to do this are the 
>same -- the decision is just made in the "network storage 
>server" as to if data passing through is cached or not -- so 
>this may be an interesting thing to think about from a 
>deployment, charter, and scope perspective, but in practice, 
>may end up having very little impact on what a possible 
>protocol would look like.
>
>David
>
>> In general, assuming that an out-of-path method has been used for 
>> protecting the copyright issues, and the in-network storage is 
>> allocated to different users with many individual accounts, I would 
>> say a P2P client(in-network storage user) could decide whether to 
>> store the content for himself in its in-network storage account, and 
>> of course it can share the content in its in-network storage account 
>> to other peers. However, in implementation, you may have 
>many methods 
>> to optimize it to avoid duplication on the same server or on 
>the servers of an local area.
>>
>> Thanks!
>> Haibin
>>
>>
>>
>>>Subject: [decade] Should content be repeatedly stored on different 
>>>In-network storage?
>>>
>>>Applicant In-network storage, I creat the name to represent the 
>>>In-network storage who download a content for its client 
>from another 
>>>In-network storage.
>>>downloads, to server the later requests for this content from other 
>>>clients?
>>>
>>>
>>>
>>>Regards
>>>
>>>Yingjie Gu
>>>

---

From: "Y.J. Gu" <[email-masked]>
Date: Sat, 29 Aug 2009 09:55:06 +0800

Hi, Haibin and David.
See in line pls.

Regards

Yingjie Gu

> [mailto:[email-masked]] On Behalf Of Song Haibin
> Sent: Friday, August 28, 2009 4:48 PM
> To: 'David A. Bryan'
> Cc: [email-masked]
> I like these three ways for P2P contents in-network storage. 
> I agree that a standard in-network storage access protocol 
> could be applicable to all these three ways. Here is my 
> understanding of them.
> 
> For (1), I think I understand how it works. That's similar to 
> what in the SAILOR presentation at DECADE BAR BOF. In this 
> method, User A can read/write from/to its in-network storage, 
> and also A can download from peer B or peer B's in-network 
> storage, and decide whether to store that content in A's 
> in-network storage (in-path). That's to say, what contents 
> will be stored in A's network storage is fully under control 
> of user A. On the other hand, A is aware of what is in its 
> in-network storage, and could use its in-network storage 
> instead of itself to send data to other peers on requests. 
 
In this case, does A's in-network storage need to bear all that
responsibility that B's in-network storage holds for the data? 
For example, does that mean A's In-network storage have to authenticate
other peers to retrieve the data, as A might download the data from B's
In-network storage with a token? With B's token or a new token set by A to
authenticate? And some other examples like "Data updating/aging" ? 

> For (2), the difference from (1) is that user A does not have 
> to decide what will be in its in-network storage. When A 
> dowloads a content from B(assume that B's in-network storage 
> does not have the content), then the content
> So that when receiving a request for the same data content 
> from another peer later, B can make the decision whether to 
> download from it or its in-network storage. A's in-network 
> storage will also tell A what contents are stored in the core 
> when there is update. I'm not sure if I catch the right thing here.

As far as I'm concerned, I would say DECADE should not be transparent to
users. The data that is distributed might be private, and the user need to
have totally control over the data. And if it's transparent to user, we need
do much more effort on IP filter issues than it's not transparent.

> There might be the possiblity of (3) if the two above would 
> be complementary.
> 
The way between (1) and (2) might be better. AS for (1), A has too much
control over B's data, and in (2) B has too little control over its data.
There might need a negotiation between A and B (or between their in-network
storages) about whether to cache the data in a remote storage and how the
remote-cached data is managed(updating, aging, deleting). And B or B's
in-network storage has a 'map' about where its data is stored so that B can
approach them when necessary. 
> Behalf Of 
> >David A. Bryan
> >salient in this context) question about copyright,I can see 
> a couple of 
> >ways to do this:
> >
> >style.
> >Basically, this turns into a cache. This (or 3 below) would likely 
> >result in far better overall improvement in network 
> performance than 1, 
> >although I admit that is not backed up by any research or 
> data, just my 
> user could 
> >use to place content in deliberately, and some space that is 
> >constructs that would be needed to do this are the same -- 
> the decision 
> >is just made in the "network storage server" as to if data passing 
> >through is cached or not -- so this may be an interesting thing to 
> >think about from a deployment, charter, and scope 
> perspective, but in 
> >practice, may end up having very little impact on what a possible

---

From: Song Haibin <[email-masked]>
Date: Sat, 29 Aug 2009 11:46:08 +0800

Hi Yingjie,

See in line.  

>Sent: Saturday, August 29, 2009 9:55 AM
>To: 'Song Haibin'; 'David A. Bryan'
>Cc: [email-masked]
>Subject: RE: [decade] Should content be repeatedly stored on 
>> I agree that a standard in-network storage access protocol could be 
>> applicable to all these three ways. Here is my understanding of them.
>> 
>> For (1), I think I understand how it works. That's similar 
>to what in 
>> the SAILOR presentation at DECADE BAR BOF. In this method, 
>User A can 
>> read/write from/to its in-network storage, and also A can download 
>> from peer B or peer B's in-network storage, and decide whether to 
>> store that content in A's in-network storage (in-path). 
>That's to say, 
>> what contents will be stored in A's network storage is fully under 
>> control of user A. On the other hand, A is aware of what is in its 
>> in-network storage, and could use its in-network storage instead of 
>> itself to send data to other peers on requests.
> 
>In this case, does A's in-network storage need to bear all 
>that responsibility that B's in-network storage holds for the data? 
>For example, does that mean A's In-network storage have to 
>authenticate other peers to retrieve the data, as A might 
>download the data from B's In-network storage with a token? 
>With B's token or a new token set by A to authenticate? And 
>some other examples like "Data updating/aging" ? 
>

A's in-network storage will not do the authentication on behalf of B, it
only does that for A. "Updating/aging" might be done by existing mechanisms
used by P2P applications instead of DECADE. DECADE could be used for user A
to delete an expired data from its in-network storage or update a data
object with a new one. The goal of DECADE is not a full solution but a
simple protocol that can be integrated into P2P applications.

>> For (2), the difference from (1) is that user A does not have to 
>> decide what will be in its in-network storage. When A dowloads a 
>> content from B(assume that B's in-network storage does not have the 
>> content), then the content will be stored in both A and B's 
>in-network 
>> storage
>> automatically.   In this
>> So that when receiving a request for the same data content from 
>> another peer later, B can make the decision whether to download from 
>> it or its in-network storage. A's in-network storage will 
>also tell A 
>> what contents are stored in the core when there is update. I'm not 
>> sure if I catch the right thing here.
>
>As far as I'm concerned, I would say DECADE should not be 
>transparent to users. The data that is distributed might be 
>private, and the user need to have totally control over the 
>data. And if it's transparent to user, we need do much more 
>effort on IP filter issues than it's not transparent.
>
>The way between (1) and (2) might be better. AS for (1), A has 
>too much control over B's data, 

It's not totally right. A may have the right to distribute the data object
in its in-network storage to other peers, or with how many processing
resources(bw,conncetions...) the data object is shared to other peers, but
it could not modify the data object if there is protection for the data
object itself. 

and in (2) B has too little 
>control over its data.
>storages) about whether to cache the data in a remote storage 
>and how the remote-cached data is managed(updating, aging, 
>deleting). And B or B's in-network storage has a 'map' about 
>where its data is stored so that B can approach them when necessary. 
>> 
I think you mean the owner of the content could manage where the content can
be sotored and monitor it. Please leave these strategies to applications.

Haibin

>words, once