[Ndn-interest] [icnrg] Caching Dynamic Content

David Oran daveoran at orandom.net
Wed May 17 04:36:21 PDT 2017


I stand corrected! :-)

On 16 May 2017, at 14:45, Cedric Westphal wrote:

> Caching is a win under THREE conditions ;-)
>
>
> a)      For error control
>
> b)      For sharing the same content among multiple consumers
>
> c)      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:
>
>   *   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?
>   *   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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20170517/f2c969a2/attachment.html>


More information about the Ndn-interest mailing list