[Ndn-interest] [icnrg] Caching Dynamic Content

Thu May 18 05:25:06 PDT 2017

On 18 May 2017, at 2:07, n.boubakr at bit.edu.cn wrote:

> Thank you for your clarification,
>
> However, this is true only if the content is static (correct me please 
> if I'm wrong). I can not see the benefits of caching in dynamic 
> content scenarios.
>
Both the error control and link-smoothing (thanks Cedric!) scenarios 
have benefit for dynamic content.

> Let’s reform my old example in another way!
> Assuming 02 consumers C1 and C2 from the same network, sending a 
> request to Facebook and Youtube.
This is the sharing scenario, which does not benefit from caching for 
the portion of the content that is not common (or generated dynamically 
for each request).

> • The  case of Facebook: both of Interest packets carry the sane 
> name  com/facebook (or something like), because of they carry the same 
> name, an Interest aggregation will be done (How can we distinguish 
> between different requests with the same name for dynamic ontent).

> Facebook  server sent the Data packet to them, how can the ICN engine 
> distinguish between consumers and which one has which Data (C1(Data) 
> is not the same as C2(Data)).
If different content is intended for different consumers, the Interest 
has to carry something in the requested name that is different. For 
Facebook, you’d need to wouldn’t just ask for /com/facebook/myfeed; 
you’d ask for /com/facebook/<me>/myfeed. If going after a profile, in 
the NDN case you’d ask for /com/facebook/donaldtrump in the Interest, 
but the dynamic data generated would be for 
/com/facebook/donaldtrump/filtered-for-<me> or 
/com/facebook/donaldtrump/filtered-for-<otherperson>.

If you were using CCN, which only does exact match; you’d directly ask 
for /com/facebook/donaldtrump/filtered-for-<me>.

> Also, we can not cache the Data, because it has a relation to a 
> specific consumer, even if we cache it and serve it to the same 
> consumer request from a different network in different Interest 
> request, it can not be true as the content by nature should be dynami.
Well, that’s an interesting application design question - who is in 
charge of deciding when dynamic content gets regenerated. One extreme is 
that the application does it on every request (e.g. for a different ad). 
The other extreme is time-series dynamic data where you regenerate on a 
time scale, which could be short (in which case temporal caching is less 
halpful), or on a longer timescale of minutes to hours where it can be 
quite useful. The often-cited example of “the New York Times home 
page. Is of the latter sort.

> • The case of Youtube: C1 and C2 send the same Interest request to 
> V1, both of them got the same video, an intermediate node cache the 
> video (if it is a shared video and can not break the copyright rule 
> – how ICN deal with copyrights).
Usually content is protected with application layer broadcast 
encryption.

> Moreover, even the video is a static content, but Youtube integrates 
> ads on it (business view), which means if we cache it, Youtube can not 
> integrate ads on it (even if we cache the video and ads, ads should be 
> dynamic from video/consumer to another), in another word, Youtube can 
> not get money using this networking paradigm.
>
The ads are likely to be separate content objects, so I don’t think 
the problem presents itself the way you are describing it.
One possible design (there are many - this is just an example). Is that 
the user’s player requests a given video and gets back a Manifest 
object which contains:
<name of selected pre-roll ad>
<name of requested video>
and possibly other stuff.

the Manifest generated dynamically is custom per-user and per request, 
so caching it is only useful for error control or link-smoothing. 
However, both <name of selected pre-roll ad> and <name of requested 
video> are fairly static and can benefit from medium to long-term 
caching, since neither the ad nor the video itself are dynamically 
generated (ignoring live content for the moment)

> I think ICN (NDN) can not be applied to real network environment, just 
> when if it can be commercialized and companies can get their benefits  
> from the offered service, especially in dynamic content networks.
>
This may be the case, but I don’t think it’s for the reasons you 
cite.

> Boubakr Nour (Ph.D Candidate)
> Beijing Institute of Technology (北京理工大学)
>
> From: David Oran
> Sent: Wednesday, May 17, 2017 7:36 PM
> To: Cedric Westphal
> Cc: n.boubakr at bit.edu.cn; ndn-interest at lists.cs.ucla.edu; 
> icnrg at irtf.org
> Subject: Re: [Ndn-interest] [icnrg] Caching Dynamic Content
>
> I stand corrected! :-)
> On 16 May 2017, at 14:45, Cedric Westphal wrote:
> Caching is a win under THREE conditions ;-)
>  
> 1. For error control
> 2. For sharing the same content among multiple consumers
> 3. To smooth out link variability over time.
>  
> For an example of c), the most extreme case is that of DTN. Assume A 
> wants to send contente to C. Node A would send a content for node B to 
> cache because the link A-B is up; the link A-B may go down, but link 
> B-C comes up, and the content can now be shared from the cache of B to 
> C. But this case covers bandwidth fluctuation due to congestion and/or 
> wireless interface fluctuations. See: F. Bronzino, D. Stojadinovic, C. 
> Westphal, D. Raychaudhuri, Exploiting Network Awareness to Enhance 
> DASH over Wireless, IEEE CCNC, January 2016 
> https://users.soe.ucsc.edu/~cedric/papers/bronzino2016exploiting.pdf
>  
> C.
>  
> From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On 
> Behalf Of David Oran
> Sent: Friday, May 12, 2017 6:51 AM
> To: n.boubakr at bit.edu.cn
> Cc: ndn-interest at lists.cs.ucla.edu; icnrg at irtf.org
> Subject: Re: [Ndn-interest] [icnrg] Caching Dynamic Content
>  
> Caching is a win under two conditions:
> a) for error control (recovering from lost Interest or data messages 
> due to congestion, mobility, or other disruptions), or re-fetch of 
> content that is unchanged
> b) for sharing the same content among multiple consumers.
> The former remains useful even if each user gets different content.
> The latter is useful only if multiple consumers are getting the same 
> identical content, and if the content is unencrypted or encrypted 
> under a shared key.
> You are right that dynamically generated content that is unique per 
> consumer will not experience any sharing gains though caching, but may 
> have value for error control or temporal sharing.
> Some privacy advocates recommend that all content be encrypted with 
> non-shared keys, in order to provide protection against correlation 
> attacks, leakage through key sharing not controlled by the consumer, 
> and perfect forward secrecy (PFS).
> So, there you have it…
> On 12 May 2017, at 0:19, n.boubakr at bit.edu.cn wrote:
> Dear all,
>  
> Talking about the in-network caching for dynamic-content on ICN, I 
> have the following miss-understanding:
> 1. Let’s take a scenario when two end-users want to access to the 
> same website (e.g. Facebook), they requested facebook.com/home, well 
> the name appears the same for both users, however, the content of each 
> request is not the same. How does ICN work with this situation, 
> because caching such content is not useful at all (even if the same 
> user requests the same content name, the content will be different)? 
> Does in-network caching have no benefits with dynamic content? Also, 
> how does the content delivery process in this situation (because 
> Interest/Data packets have not the requester name), how ICN nodes 
> distinguish between the two (N) requesters?
> 2. Another question arises, requesting a video from Youtube for 
> example (the video can be cached on any node), however, the real 
> process is that the Youtube page associated with such video has some 
> dynamic content such as Recommended Videos… Also, the video itself 
> has many ads that appear on the video and they are different from user 
> to another, and cannot be cached, and they are the main business 
> method for the company. How can ICN treat the business model for such 
> situation, as any company will not migrate to ICN if ICN can not 
> ensure a business achievement?
>  
>  
> Best regards,
>  
> Boubakr Nour (Ph.D Candidate)
> Beijing Institute of Technology (北京理工大学)
> _______________________________________________
> icnrg mailing list
> icnrg at irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg
> DaveO
>
> DaveO

> _______________________________________________
> icnrg mailing list
> icnrg at irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO