Subject: [decade] DECADE meeting minutes

From: Song Haibin <[email-masked]>
Date: Thu, 30 Jul 2009 16:43:30 +0200

Hi all,

Here are the meeting notes of DECADE Bar BOF.  It's a merged version from the notes taken by Roni and Linda. Please check for consistency with your own memories!

DECADE BAR BOF

There were about 50 people in the room
Yu Shun and Haibin chaired the BOF

The Chair announced the agenda and announced IETF policy.

Agenda bashing (chairs)

Eric - leave time to discuss the objectives and if this is a topic for IETF
Yu-Shun: there are no drafts yet

Goals & Next steps

Introduction:
Architecture framework - application agnostics in network caches for both p2p and client server applications.
Main components - had a simplified picture.

Qusetions: 
Should the cache be between the source and client – response: it depends on how it is deployed.
Linda: Will the cache be a published server, who owns them who provide - response: there are several options including server providers and ISPs. This is not a complete picture. 
Volker: caches exists (CDN) why not say HTTP is the protocol and we are pushing the data to them. Response: The result of the requirements may be the current CDN but there are issues. It will be discussed later. HTTP might be a possible solution.

Dave Crocker: Sounds like using standard CDN protocol and check if existing CDN is not efficient. If the existing protocols are not enough, can you list them?  Response: It will be discussed on the second presentation.

Yunfei - Will we standardize the cache to cache - Response: this is a scope question

Then Haibin presented Problem Statements:

Rich Woundy: Reduce uplink will definitely help me as an ISP. But other ISPs may not have this problem. Is it universal true that reducing uplink bandwidth is an issue? Wireless operator may have this issue. 

Kar from Vodafone agreed: it is true that uplink bandwidth is an issue. They do want to reduce uplink. But they believe that Cache will reduce the downlink as well. 

Dave Crocker: Now you are talking about link behavior. P2P is many things. If you don’t have specific application at the beginning, then this is an abstract discussion. Therefore, the debate is not very useful. 

Yu Shun - need not to concentrate on the link but application use cases.

Dave Crocker: Caching will not solve problem for IM and IM is P2P. Richard Alimi stated one example of File Sharing, which can demonstrate that the caching can reduce the link utilization. 

Lucy Yong: saving the uplink is not the main driving force. It is for saving both links. 

Rich Woundy- current caching system based on transparent passing by which they ssume that if it is p2p protocol they put cache inline of the transmission line.
Answer: you do not have to intercept traffic to cache it. It will be in the requirement.

The direction is for off path cache but the peer will be aware 

Qustion from Rich Woundy: There are a lot of cache vendors. Using DPI to re-direct the traffic. Is it the assumption for transparent caching?

Richard Alimi: It should have a requirement that caching failure should allow the P2P to resume the normal communication.

Steven Right: Do you mean multiple systems sharing the single cache? Do you need to configure how much cache should be reserved to BitTorrent?   Answer: it should depend on the configuration. 

Rich from an ISP: stating saving uplink is too broad scope, but it is not specific to P2P. 

Response: The cache solution can be used to non p2p solution. The bar BOF is about p2p

Q: When you say that P2P represent 40% traffic of internet, what other traffic are in the network. Answer: it is not the concern for this work.

ZongNing: web cache is another way of caching. Now we want to find other way to cache

Q: using the cache is not mandatory so there need to be motivation
for clients to use them. Answer: maybe better performance, so that P2P software wants to use it. 

Q: what is the difference between your protocol and RELOAD? 

    a.. Response from the chair of P2PSIP, David Bryan stated RELOAD is for resource discovery. 
Vijay: what is the role of caching in the streaming application? When the load is consistent

Q: is it desirable to make it the goal of this BoF to have certain location or structure will make this protocol practical? Chair: let’s see first if the protocol is interesting enough to get down to the topology. 

Kar: Is it specifically for P2P or others? Chair: The motivation is from P2P, but solution could be used for others. Let’s consider it for future. 

Q: who decides what to be stored in the cache? Answer: The third presentation will show a possible example of the details. 

Then Ning Zong and Richard Alimi did joint presentation on Survey slides.

Network storage system components

Web Caching: use HTTP, but not designed for P2P applications. 

Transparent P2P Cache and non-transparent P2P cache

CDN: Push the content to the edge, but not designed for P2P. Discussion about the issue of resource control requirement. Q: What do you mean by saying it doesn’t provide resource control? Answer: the push model doesn’t require the content from the content provider to know the bandwidth available for the client. 

Richard Alimi’s presentation on Amazon S3, Windows Azure, Ocean Store, iSCSI

Doesn’t provide the resource control (bandwidth and connections)

Question from Dave Crocker: what is the access control? Answer: the peer client should have control on which peer to have the content.

Dave from Verizon: what is the topology for caching? Is it for unicast or multicast?  Answer: it is not important at this point. 

Then Richard Alimi did Sailor presentation.

Possible solution to decade
Use application agnostic data lockers. Change from “client to client P2P data”, to using data locker for client to get data from Cache as if it gets the data from the other client. 

Rich Woundy - is there a relation between the chunks ids in bit torrent and the
ones in the cache - response they are not the same but mapping is required

Question - can the client control the life time of the data in the cache - for example time for file sharing compared to streaming chunks. 
Richard yes it will be considered.

Question from Rich (ISP): does Locker associate with mega data? 

Questoin from Rich (ISP): should you allocate a timer to a block of data? Answer: another way is to specify a cache policy. 

Kar (Vodafone): for optimization: maybe only store for x minutes, but not the entire length.  

Locker Access Protocol (LAP)

Question from Eric: how to revoke the access? Answer: permanent grant

Question: how to protect privacy? Like IP address. Answer: today’s DPI already expose the IP address

Branch cache - Yu-Shun
There is IPR on some of the content
The motivation was for branch offices of large corporation where the data is
usually in the main office and the cost of communication to the branch are
large.

  a.. Decouple the application protocol from cache. 
  b.. Goal: to reduce the link utilization. Local search requires authentication before searching the local content. 
  c.. Distributed Cache: 
  d.. Hosted Cache: 
  e.. Q from Lucy: will App Get have authentication? A: yes. If the authentication fails, there is no key coming back. 
  f.. Break the content to segment and blocks. Segments have ID, which is used by client to search 
  g.. All the data transfer uses HTTP 
  h.. Q: if the content has any changes, will the client get updated information? A: All content searches have to go to the center to get authentication. If there is any change to the content, the data center will inform the change status when passing down the key.
  i.. For more information: www.branchcache.com 
  j.. Q from Rich Woundy: Did you cover InterStream? which is a Multi-ISP CDN method. Multiple ISP provided contents to a common content distribution network. Another similar aspect is Remote DVR, which requires to story separate copy in multiple caches due to legal issues. Bill stated: we decide to turn the cache off due to the regulatory issue. 
  k.. Eric: will ISP be interested in providing this? 
  l.. Rich Woundy: if mega data is stored with data, ISP is liable for validate the source, otherwise the ISP can get sued
Eric Roger: if an employee has a pirated data on his/her laptop, an enterprise backing off the content can get into legal trouble.

Request - to make the presentations available

http://www.branchcache.com

Rich - did you look at interstream association http://interstream.com/ 
, another solution is remote dvr set by cablevision

     Chair: how many people think it should be worked in IETF? Majority of people raised    their hands. 

Volker: I am not fully convinced it is a problem. 

How many would like to work on this problem if it becomes a work in the IETF. 
There were about 23 hands

Thanks,

Haibin

---

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 30 Jul 2009 12:46:00 -0400

In the minutes, I think I am both "Rich Woundy" and "Rich from ISP".

> Rich Woundy- current caching system based on transparent passing by
which they ssume that if it is p2p protocol they put cache inline of the
transmission line.

They put the cache inline, or they intercept the traffic inline ala DPI.

> Rich from an ISP: stating saving uplink is too broad scope, but it is
not specific to P2P.

Actually, I think I said that "saving uplink bandwidth" is too broad of
a statement. Some ISPs benefit from reduced uplink traffic, others do
not.

>Question from Rich (ISP): does Locker associate with mega data?

My question was, does the Locker store both the content and its
associated metadata.

Here is a concrete example of what I mean by metadata: see the
BitTorrent description of 'metainfo' in
http://www.bittorrent.org/beps/bep_0003.html. Or possibly just the
'info_hash'. Essentially I mean the data that helps identify the
content.

>  j.. Q from Rich Woundy: Did you cover InterStream? which is a
Multi-ISP CDN method. Multiple ISP provided contents to a common content
distribution network. Another similar aspect is Remote DVR, which
requires to story separate copy in multiple caches due to legal issues.

With Remote DVR, video content is kept in centralized storage (by the
cable operator), with each cable subscriber getting their own allocation
of storage, and their own copies of video content. This approach was
debated for years in the US courts, and an appeal to the US supreme
court was recently rejected.

http://www.engadget.com/2006/03/27/cablevision-to-rollout-remote-storage
-dvr-service/

http://arstechnica.com/tech-policy/news/2009/06/cablevision-remote-dvr-s
tays-legal-supremes-wont-hear-case.ars

My point is that there can be legal issues associated with content
storage -- even outside the 'content piracy' domain.

>  l.. Rich Woundy: if mega data is stored with data, ISP is liable for
validate the source, otherwise the ISP can get sued

Again "mega data" should be "metadata".

Let me explain the dilemma better. Let's start with the scenario where
some subscriber has placed copyright infringing content in the "Locker",
and the offended content provider has detected this. In the US, the
content provider sends a "take down notice" to the ISP, and the ISP is
expected to remove the offending content.

If the metadata is associated with the content data in the Locker, then
the ISP can find the offending content and delete it. The Locker can
also be programmed to prevent any other data associated with the
metadata from being stored in the Locker (aka "blacklisting"). The
downside is that some customers may prefer the anonymity of content
within their own Locker, even for non-piracy-related reasons. But is
anonymity important? Maybe not for public P2P file sharing???

Now suppose that metadata is not associated with the content data in the
Locker. Then the required response by the ISP becomes much more
complicated. First possible response: the ISP might say that it cannot
determine which data in the Locker is offending content and therefore do
nothing; this response would likely prompt the content providers to
advocate for tougher anti-piracy regulations (because they would see
this as a 'piracy loophole'). Second possible response: the ISP might
choose to remove *all* the content from that subscriber's Locker; that
might satisfy the content provider, but the ISP may be deleting
non-infringing content as well as the offending content, which doesn't
seem user-friendly. Third possible response: the ISP turns off the
Locker because it seems like the "safest" approach.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Song Haibin
Sent: Thursday, July 30, 2009 10:44 AM
To: [email-masked]
Subject: [decade] DECADE meeting minutes

Hi all,

Here are the meeting notes of DECADE Bar BOF.  It's a merged version
from the notes taken by Roni and Linda. Please check for consistency
with your own memories!

DECADE BAR BOF

Agenda bashing (chairs)

Eric - leave time to discuss the objectives and if this is a topic for
IETF
Yu-Shun: there are no drafts yet

Goals & Next steps

Introduction:
Architecture framework - application agnostics in network caches for
both p2p and client server applications.
Main components - had a simplified picture.

Qusetions: 
Should the cache be between the source and client - response: it depends
on how it is deployed.
Linda: Will the cache be a published server, who owns them who provide -
response: there are several options including server providers and ISPs.
This is not a complete picture. 
Volker: caches exists (CDN) why not say HTTP is the protocol and we are
pushing the data to them. Response: The result of the requirements may
be the current CDN but there are issues. It will be discussed later.
HTTP might be a possible solution.

Dave Crocker: Sounds like using standard CDN protocol and check if
existing CDN is not efficient. If the existing protocols are not enough,
can you list them?  Response: It will be discussed on the second
presentation.

Yunfei - Will we standardize the cache to cache - Response: this is a
scope question

Rich Woundy: Reduce uplink will definitely help me as an ISP. But other
ISPs may not have this problem. Is it universal true that reducing
uplink bandwidth is an issue? Wireless operator may have this issue. 

Kar from Vodafone agreed: it is true that uplink bandwidth is an issue.
They do want to reduce uplink. But they believe that Cache will reduce
the downlink as well. 

Dave Crocker: Now you are talking about link behavior. P2P is many
things. If you don't have specific application at the beginning, then
this is an abstract discussion. Therefore, the debate is not very
useful. 

Dave Crocker: Caching will not solve problem for IM and IM is P2P.
Richard Alimi stated one example of File Sharing, which can demonstrate
that the caching can reduce the link utilization. 

Lucy Yong: saving the uplink is not the main driving force. It is for
saving both links. 

Rich Woundy- current caching system based on transparent passing by
which they ssume that if it is p2p protocol they put cache inline of the
transmission line.
Answer: you do not have to intercept traffic to cache it. It will be in
the requirement.

Qustion from Rich Woundy: There are a lot of cache vendors. Using DPI to
re-direct the traffic. Is it the assumption for transparent caching?

Richard Alimi: It should have a requirement that caching failure should
allow the P2P to resume the normal communication.

Steven Right: Do you mean multiple systems sharing the single cache? Do
you need to configure how much cache should be reserved to BitTorrent?
Answer: it should depend on the configuration. 

Rich from an ISP: stating saving uplink is too broad scope, but it is
not specific to P2P. 

Response: The cache solution can be used to non p2p solution. The bar
BOF is about p2p

Q: When you say that P2P represent 40% traffic of internet, what other
traffic are in the network. Answer: it is not the concern for this work.

ZongNing: web cache is another way of caching. Now we want to find other
way to cache

Q: using the cache is not mandatory so there need to be motivation for
clients to use them. Answer: maybe better performance, so that P2P
software wants to use it. 

    a.. Response from the chair of P2PSIP, David Bryan stated RELOAD is
for resource discovery. 
Vijay: what is the role of caching in the streaming application? When
the load is consistent

Q: is it desirable to make it the goal of this BoF to have certain
location or structure will make this protocol practical? Chair: let's
see first if the protocol is interesting enough to get down to the
topology. 

Kar: Is it specifically for P2P or others? Chair: The motivation is from
P2P, but solution could be used for others. Let's consider it for
future. 

Q: who decides what to be stored in the cache? Answer: The third
presentation will show a possible example of the details. 

Then Ning Zong and Richard Alimi did joint presentation on Survey
slides.

CDN: Push the content to the edge, but not designed for P2P. Discussion
about the issue of resource control requirement. Q: What do you mean by
saying it doesn't provide resource control? Answer: the push model
doesn't require the content from the content provider to know the
bandwidth available for the client. 

Richard Alimi's presentation on Amazon S3, Windows Azure, Ocean Store,
iSCSI

Doesn't provide the resource control (bandwidth and connections)

Question from Dave Crocker: what is the access control? Answer: the peer
client should have control on which peer to have the content.

Dave from Verizon: what is the topology for caching? Is it for unicast
or multicast?  Answer: it is not important at this point. 

Possible solution to decade
Use application agnostic data lockers. Change from "client to client P2P
data", to using data locker for client to get data from Cache as if it
gets the data from the other client. 

Rich Woundy - is there a relation between the chunks ids in bit torrent
and the ones in the cache - response they are not the same but mapping
is required

Question - can the client control the life time of the data in the cache
- for example time for file sharing compared to streaming chunks. 
Richard yes it will be considered.

Questoin from Rich (ISP): should you allocate a timer to a block of
data? Answer: another way is to specify a cache policy. 

Kar (Vodafone): for optimization: maybe only store for x minutes, but
not the entire length.  

Question: how to protect privacy? Like IP address. Answer: today's DPI
already expose the IP address

Branch cache - Yu-Shun
There is IPR on some of the content
The motivation was for branch offices of large corporation where the
data is usually in the main office and the cost of communication to the
branch are large.

  a.. Decouple the application protocol from cache. 
  b.. Goal: to reduce the link utilization. Local search requires
authentication before searching the local content. 
  c.. Distributed Cache: 
  d.. Hosted Cache: 
  e.. Q from Lucy: will App Get have authentication? A: yes. If the
authentication fails, there is no key coming back. 
  f.. Break the content to segment and blocks. Segments have ID, which
is used by client to search
  g.. All the data transfer uses HTTP
  h.. Q: if the content has any changes, will the client get updated
information? A: All content searches have to go to the center to get
authentication. If there is any change to the content, the data center
will inform the change status when passing down the key.
  i.. For more information: www.branchcache.com
  j.. Q from Rich Woundy: Did you cover InterStream? which is a
Multi-ISP CDN method. Multiple ISP provided contents to a common content
distribution network. Another similar aspect is Remote DVR, which
requires to story separate copy in multiple caches due to legal issues.
Bill stated: we decide to turn the cache off due to the regulatory
issue. 
  k.. Eric: will ISP be interested in providing this? 
  l.. Rich Woundy: if mega data is stored with data, ISP is liable for
validate the source, otherwise the ISP can get sued Eric Roger: if an
employee has a pirated data on his/her laptop, an enterprise backing off
the content can get into legal trouble.

Rich - did you look at interstream association http://interstream.com/ ,
another solution is remote dvr set by cablevision

     Chair: how many people think it should be worked in IETF? Majority
of people raised    their hands. 

How many would like to work on this problem if it becomes a work in the
IETF. 
There were about 23 hands

Thanks,

Haibin

---

From: Song Haibin <[email-masked]>
Date: Fri, 31 Jul 2009 08:52:51 +0200

Hi Rich,

Thank you for correcting and detailed explanations.

BR,
Haibin

----- Original Message ----- 
From: "Woundy, Richard" <[email-masked]>
To: "Song Haibin" <[email-masked]>; <[email-masked]>
Sent: Thursday, July 30, 2009 6:46 PM
Subject: RE: [decade] DECADE meeting minutes

not specific to P2P.

-- Rich

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

Hi all,

DECADE BAR BOF

Agenda bashing (chairs)

Goals & Next steps

Introduction:

Qusetions: 

 

Branch cache - Yu-Shun

Thanks,

Haibin

---

From: Spiros Spirou <[email-masked]>
Date: Fri, 31 Jul 2009 09:49:50 +0300

I didn't attend the BoF, so I quickly went over the minutes. (BTW, 
thanks to the note takers).

I'm surprised that the legal issues associated with the storage of 
copyright-infringing content in P2P caches were not debated further. 
I've been led to believe that P2P cache owners (e.g., ISPs) are liable 
for the content stored on their caches and this is a show-stopper for 
work on P2P caches. Opinions? What's the situation outside the US?

Thanks,

Spiros

---

From: Song Haibin <[email-masked]>
Date: Fri, 31 Jul 2009 09:09:17 +0200

Hi Spiros,

It's really a very interesting question. "Legal" means different things in different countries. I know some organizations are trying hard to protect the copyright using DRM mechanisms. We really don't want to touch the legal issues and the content itself.

Haibin

---

From: "Y.J. Gu" <[email-masked]>
Date: Fri, 31 Jul 2009 15:33:32 +0800

Hi, this is Yingjie.
Thanks to chairs and attendees.
Glad to see that many people are interested in this topic, that's a good
beginning to DECADE. 
However we still have much work to do before IETF 76, following are my
conclusion of what to do according to the meeting minutes. 
1) Motivation clarification; First, saving uplink/downlink bandwidth is a
possible motivation, although it may be not true for all ISPs, it really
helps a lot. Second, for each application it supports, the existing cache
has to understand the corresponding protocol, which makes it painful to
adapt new applications, especially in flourishing P2P.
2) Advantages over existing mechanisms; maybe not overwhelming advantage,
but it should be clarified about what DECADE can do (or do better) while the
others cannot, i.e. why we need a new one instead of reusing the existing
ones with some modification.  
3) Specific application use case; I agree with Yu Shun that we should first
list the applications that might benefits from DECADE, meanwhile specify how
and how much these apps will benefit.
4) Legal issues; Sure it is not so much important in some countries as in
others, but we should give some consideration or further explanation before
simply leaving it out of account.

Hope for more comments and proposals.

Regards
Yingjie Gu

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Woundy, Richard
发送时间: 2009年7月31日 乐乐0:46
收件人: Song Haibin; [email-masked]
主题: Re: [decade] DECADE meeting minutes

They put the cache inline, or they intercept the traffic inline ala
DPI............

---

From: Yu-Shun Wang <[email-masked]>
Date: Fri, 31 Jul 2009 16:13:45 +0000

Hi,

I've gone through the notes as well. Please
take a look, especially those who contributed
to the discussion.

I have also asked Alexey. He agrees to put the
slides up in the Wiki page.

Thanks,
Yushun & Haibin

DECADE BAR BOF

7/29/2009 WED 8PM-10PM
Room 201
Attendance: about 50
BoF Co-Chairs: Yu-Shun Wang & Haibin Son
Note Takers: Linda Dunbar & Roni Even

The Chair announced the agenda, Note Well 7 IPR policy.

Agenda bashing (chairs)

Eric Burger (EricB) - leave time to discuss the objectives and if
this is a topic for IETF
Yu-Shun: there are no drafts yet

Goals & Next steps

Introduction:

Qusetions:
Q: Should the cache be between the source and client
Answer (A): Response: it depends on how it is deployed.

Linda: Will the cache be a published server, who owns them who provide
A: There are several options including server providers and ISPs.
This is not a complete picture.

Volker: Caches exists (CDN) why not say HTTP is the protocol and
we are pushing the data to them.
A: The result of the requirements may be the current CDN but there
are issues. It will be discussed later. HTTP might be a possible
solution.

Dave Crocker (DaveC): Sounds like using standard CDN protocol and
check if existing CDN is not efficient. If the existing protocols
are not enough, can you list them?
A: It will be discussed on the second presentation.

Yunfei - Will we standardize the cache to cache
A: This is a scope question (Yushun: To further clarify, this will be
considered. The current thinking is that it can be the same protocol
as the one between client and cache.)

===============

Rich Woundy (RichW): Reduce uplink will definitely help me as an ISP.
But other ISPs may not have this problem. Is it universal true that
reducing uplink bandwidth is an issue? Wireless operator may have
this issue.

Kar from Vodafone agreed: it is true that uplink bandwidth is an
issue. They do want to reduce uplink. But they believe that
cache will reduce the downlink as well.

DaveC: Now you are talking about link behavior. P2P is many things.
If you don't have specific application at the beginning, then this
is an abstract discussion. Therefore, the debate is not very useful.

Yu Shun - So the feedback is that we should not just focus on link
aspect but also the application use cases.

DaveC: Caching will not solve problem for IM and IM is P2P.
Richard Alimi (RichardA): File Sharing is one example, which can
demonstrate that the caching can reduce the link utilization.

Lucy Yong (LucyY): Saving the uplink is not the main driving force.
It is for saving both links.

RichW - (paraphrasing based on RichW's clarification) Current
caching systems are usually deployed inline, or they can intercept
packets for DPI. They use DPI to determine if the packets are p2p
and whether to cache it or not.

A: you do not have to intercept traffic to cache it. It will be
in the requirement.
The direction is for off path cache but the peer will be aware.

RichW: There are a lot of cache vendors. Using DPI to re-direct the
traffic. Is it the assumption for transparent caching?

RichardA: It should have a requirement that caching failure should
allow the P2P to resume the normal communication.

Steven Right (StevenR): Do you mean multiple systems sharing the
single cache? Do you need to configure how much cache should be
reserved to BitTorrent?
A: It should depend on the configuration. (It should be

RichW: "Saving uplink is good for ISP" is probably too broad
a statement. Some ISPs benefit from reduced uplink traffic, but
some may not. Also it is not specific to P2P.

A: The cache solution can be used to non p2p solution. The bar BOF
is about p2p

Q: When you say that P2P represent 40% traffic of internet, what
other traffic are in the network.
A: it is not the concern for this work.

ZongNing: Web cache is another way of caching. Now we want to
find other way to cache

Q: Using the cache is not mandatory so there need to be motivation
for clients to use them. Answer: maybe better performance, so that
P2P software wants to use it.

Q: What is the difference between your protocol and RELOAD?
David Bryan (P2PSIP chair): RELOAD is for resource discovery.
Vijay: what is the role of caching in the streaming application?
When the load is consistent

Q: Is it desirable to make it the goal of this BoF to have certain
location or structure will make this protocol practical?

Chair: Let's see first if the protocol is interesting enough to
form a wg; then we can think if we want to get down to the
topology and deployment optimization.

Kar: Is it specifically for P2P or others?
Chair: The motivation is from P2P, but solution could be used
for others. Let's consider it for future.

Q: Who decides what to be stored in the cache?
Answer: The third presentation will show a possible example
of the details.

===============

Then Ning Zong and Richard Alimi did a joint presentation on
Survey slides.

CDN: Push the content to the edge, but not designed for P2P.
Discussion about the issue of resource control requirement.

Q: What do you mean by saying it doesn't provide resource control?
A: The push model doesn't require the content from the content
provider to know the bandwidth available for the client.

Richard Alimi's presentation on Amazon S3, Windows Azure, Ocean
Store, iSCSI

DaveC: What is the access control?
A: the peer client should have control on which peer can access
The content.

David McDysan from Verizon (DavidM): What is the topology for
caching? Is it for unicast or multicast?
Answer: it is not important at this point.

===============

Possible solution to decade
Use application agnostic data lockers. Change from "client to
client P2P data", to using data locker for client to get data
from Cache as if it gets the data from the other client.

RichW - Is there a relation between the chunks IDs in BitTorrent
and the ones in the cache?
A: They are not the same but mapping is required

Q: Can the client control the life time of the data in the cache
- for example time for file sharing compared to streaming chunks.
RichardA: Yes it will be considered.

RichW: Does Locker associate with meta data?
A: Currently no. But it's possible to add.

RichW: Should you allocate a timer to a block of data?
A: Another way is to specify a cache policy.

Kar (Vodafone): For optimization: maybe only store for x minutes,
but not the entire length.

EricB: How to revoke the access?
Answer: Permanent grant? (Chair: I thought RichA said there is
a valid time associated with the data?)

Q: How to protect privacy? Like IP address.
A: Today's DPI already expose the IP address

===============

Windows BranchCache Presentation - Yu-Shun Wang
There is IPR on some of the content

The motivation was for branch offices of large corporation where
the data is usually in the main office and the cost of
communication to the branch are high.

- Decouple the application protocol from cache access protocol
- Goal: To reduce the link utilization.
- Local search requires authentication with the original content
  server before a client can search for the local content.

- Distributed Cache:
- Hosted Cache:

Q from LucyY: will App Get have authentication?
A: Yes. If the authentication fails, there is no content ID coming
back.

- Break the content to segment and blocks. Segments have ID, which
  is used by client to search
- All the data transfer uses HTTP

Q: if the content has any changes, will the client get updated
information?

A: All content accesses have to go to the content servers to
get authentication. If there is any change to the content, the
data center will need to generate new content IDs (hashes) and
pass the new IDs back.

Q: Would you publish the protocol?
A: Currently, the protocol specification is available under
the consent decree regulation license (not sure the complete
or correct term here). We will need to discuss internally
to see if we will write this up as informational RFC.

- For more information: www.branchcache.com

===============

General Discussion:

RichW: Did you cover InterStream? which is a Multi-ISP CDN method.
Multiple ISP provided contents to a common content distribution
network. Another similar aspect is Remote DVR, which requires to
story separate copy in multiple caches due to legal issues.

Bill: We decide to turn the cache off due to the regulatory issue.

EricB: Will ISP be interested in providing this?

RichW: If meta data is stored with data, ISP is liable for
Validating the source, otherwise the ISP can get sued

EricB: If an employee has a pirated data on his/her laptop, an
enterprise backing up the content can get into legal trouble.

===============

BoF Summary

Chair: How many people think it should be worked in IETF?
Majority of people raised    their hands.

Chair: How many would like to work on this problem if it becomes
a working group in the IETF.
There were about 23 hands