
<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I feel things are becoming too complicated. Here’s my opinion:<div><br></div><div>The backdoor, i.e., caching unsolicited data from local apps, was a hack to make some apps work quickly. It is not the proper way to write the app nor the forwarder. Apps should take care of their own data (think e2e argument). They should work with or without local CS, or with any size of local CS. In other words, they shouldn’t rely on the backdoor.</div><div><br></div><div>The most effective way to take care of one’s data is to store and manage them in the app itself. So an in-app storage mechanism such as MemoryContentCache is the way to go. An app can also use a database, the file system, or any other way to manage its data.</div><div><br></div><div>If data duplication, one copy in app and one copy in CS, is a concern, the CS can be made not to cache data coming from local apps. Caching such data doesn’t improve user-perceived performance much anyway.</div><div><br></div><div>Solving app’s data management problem in CS will only make the forwarder unnecessarily complicated, and I don’t see any clear gain from doing that.</div><div><br></div><div>Beichuan<br><div><br></div><div><br><div><div>On Sep 9, 2014, at 9:50 PM, Junxiao Shi <<a href="mailto:shijunxiao@email.arizona.edu">shijunxiao@email.arizona.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">Dear folks</div><div class="gmail_extra"><br></div><div class="gmail_extra">Below is a summary of the problem, and a comparison of three solutions.</div><div class="gmail_extra">"In-Forwarder Storage" is my proposed solution.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Yours, Junxiao</div><div class="gmail_extra"><br></div><div class="gmail_extra"><h1 style="font-family: 'Times New Roman';">Background</h1><h2 style="font-family: 'Times New Roman';">ContentStore concept</h2><p style="font-family: 'Times New Roman'; font-size: inherit;">ContentStore is an element of NFD which serves as an <strong>opportunistic cache</strong>. Incoming Data packets have the opportunity to be admitted into the ContentStore. Data packets are not persistent in ContentStore: they can be evicted when ContentStore is full.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">Admission to the ContentStore is a two step process:</p><ol style="font-family: 'Times New Roman'; font-size: inherit;"><li>Forwarding pipelines must decide whether a Data packet <em>SHOULD</em> be admitted. A Data packet should be admitted if it's believed to be legitimate (ie. not part of an attack).</li><li>ContentStore must decide whether there is space for this Data packet.</li></ol><p style="font-family: 'Times New Roman'; font-size: inherit;">Data packets in the ContentStore can be used to satisfy incoming Interests. <br>When an incoming Interest contains <em>MustBeFresh=yes</em> selector, only <em>non-stale</em> Data packets can be returned. A Data packet is <em>stale</em> if it has been in the ContentStore for longer than<em>FreshnessPeriod</em>; note that if a Data packet is admitted while the same Data packet already exists in the ContentStore, the admission timestamp is reset, so this is equivalent to deleting the old Data packet and admitting the new one.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">Retention in the ContentStore is not guaranteed. The ContentStore is permitted to <strong>evict</strong> any Data packet at any time, regardless of its origin, staleness, admission time, etc.</p><h3 style="font-family: 'Times New Roman';">ContentStore in NFD 0.2.0</h3><p style="font-family: 'Times New Roman'; font-size: inherit;"><strong>Admission</strong>: <em>Incoming Data pipeline</em> determines whether a Data packet <em>SHOULD</em> be admitted. If a Data packet satisfies one or more PIT entries, it should be admitted; this is regardless of whether an Interest has been forwarded to the origin of this Data packet. Otherwise, the Data packet is said to be <em>unsolicited</em>, and decision is given to <em>Data unsolicited pipeline</em>.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">Generally, unsolicited Data needs to be dropped as it poses security risks to the forwarder. However, there are cases when unsolicited Data packets needs to be accepted to the ContentStore. In particular, the current implementation allows any unsolicited Data packet to be cached if this Data packet arrives from a local Face.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">Once forwarding pipelines decide a Data should be admitted, ContentStore always admits it. If the ContentStore is full and a new Data packet needs to be admitted, one old Data packet is evicted.</p><p style="font-family: 'Times New Roman'; font-size: inherit;"><strong>Eviction</strong>: The ContentStore logically maintains three FIFO queues:</p><ol style="font-family: 'Times New Roman'; font-size: inherit;"><li>unsolicited Data</li><li>stale Data</li><li>fresh Data</li></ol><p style="font-family: 'Times New Roman'; font-size: inherit;">The front Data packet in the first non-empty queue is evicted.</p><h2 style="font-family: 'Times New Roman';">Data Generation in Application</h2><h3 style="font-family: 'Times New Roman';">Data Generation Misaligned with Interest Arrival</h3><p style="font-family: 'Times New Roman'; font-size: inherit;">NDN content distribution is receiver-driven. The producer cannot push Data packets into the network; it must wait for consumer to express Interests, before responding with Data packets.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">However, <strong>Data generation can happen before Interest arrival</strong>.</p><ul style="font-family: 'Times New Roman'; font-size: inherit;"><li>a video camera captures a consequtive video stream, and generates Data packets as a frame is captured</li><li>a <a href="http://redmine.named-data.net/projects/nfd/wiki/StatusDataset">NFD StatusDataset</a> publisher generates all segments of a StatusDataset in response to a request, not one segment at a time</li><li>a <a href="https://github.com/bruinfish/ChronoChat">ChronoChat</a> client generates a Data packet when the user enters a message, before other users discover the existence of this Data packet (through synchronization) and retrieve it</li><li>a <a href="https://github.com/named-data/NLSR">NLSR</a> daemon generates a Data packet for a Link State Announcement, before other routers discover the existence of this Data packet (through synchronization) and retrieve it</li></ul><p style="font-family: 'Times New Roman'; font-size: inherit;">Producer is not allowed to send those Data packets into the network before Interest arrival. Therefore, those Data packets must be stored <em>somewhere</em>.</p><h3 style="font-family: 'Times New Roman';">Latest Version and Short Freshness Period</h3><p style="font-family: 'Times New Roman'; font-size: inherit;">The most useful Data packets are those representing the latest version of some information. The producer has the final authority: when an incoming Interest asks for the latest version, the producer would respond with the latest version.</p><p style="font-family: 'Times New Roman'; font-size: inherit;"><em>FreshnessPeriod</em> field is an indication about how long the Data packet may remain the latest version. Typically, the producer sets this field to a duration in which it believes a newer version won't be generated. However, two situations cause the producer to prefer a shorter <em>FreshnessPeriod</em>:</p><ul style="font-family: 'Times New Roman'; font-size: inherit;"><li><em>FreshnessPeriod</em> is per network node: if a Data packet is near the end of its freshness period at one node, and it's delivered to another node, the admitted Data packet on the second node would remain <em>non-stale</em> for the entire <em>FreshnessPeriod</em>. This means, if there are N hops between consumer and producer, in the worst case, the Data may appear fresh to consumer for up to N times<em>FreshnessPeriod</em>.</li><li>The producer is sometimes unable to predict how long a version can remain to be the latest version.</li></ul><h1 style="font-family: 'Times New Roman';">Problem</h1><p style="font-family: 'Times New Roman'; font-size: inherit;">The "NFD backdoor" is a <em>feature</em>: NFD allows unsolicited Data from a local face to be admitted to the ContentStore.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">This feature allows NDN applications to "pre-publish" Data packets when future Interests are anticipated. At the other end, the NDN applications themselves do not retain the Data packet.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">The drawback of this approach is: <strong>retention is not guaranteed</strong>. <br>Although pre-published Data packets are admitted to the ContentStore, they are tagged as unsolicited. Unsolicited Data packets are the first to be evicted from ContentStore when ContentStore is full. Therefore, when there are enough solicited Data packets in the ContentStore, unsolicited Data packets can hardly be retained in the ContentStore. <br>If a Data packet is evicted, the Interest would be forwarded to the application. The application either has to generate the Data again, or is unable to respond at all.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">Another problem of application not storing generated Data packets is: <strong>a Data packet may remain to be the latest version beyond FreshnessPeriod</strong>. <br>The ContentStore can only use <em>non-stale</em> Data to satisfy an Interest with <em>MustBeFresh=yes</em>. If the producer sets a short <em>FreshnessPeriod</em>, the Interest would be forwarded to the application, even if the Data packet is still the latest version. <br>The application would have to generate (and sign) the Data again.</p><h1 style="font-family: 'Times New Roman';">Necessity of Application-Controllable Data Storage</h1><p style="font-family: 'Times New Roman'; font-size: inherit;">Both problems have a common solution: a Data storage controlled by application.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">This Data storage should have the following characteristics:</p><ul style="font-family: 'Times New Roman'; font-size: inherit;"><li>Data packets <em>useful</em> to a producer application are stored. A Data packet is <em>useful</em>, if the producer application would generate the same again when an Interest asks for it.</li><li>Producer can explicitly delete Data packets that are no longer <em>useful</em>. The most common time to delete Data packets is when a new version is generated.</li><li>Producer should delete Data packets when the Data storage is close to its capacity. Such deletions can either be explicit, or be delegated to an eviction policy.</li><li>The Data storage is not a cache.</li></ul><h1 style="font-family: 'Times New Roman';">Solutions</h1><p style="font-family: 'Times New Roman'; font-size: inherit;">The application-controllable Data storage can either be placed in the application, or be placed in the forwarder.</p><h2 style="font-family: 'Times New Roman';">In-App Storage</h2><p style="font-family: 'Times New Roman'; font-size: inherit;"><a href="http://redmine.named-data.net/projects/ndn-cxx/wiki/InMemoryStorage">In-App Storage</a> provides an application-controllable Data storage within the application. The module is typically provided by the library.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">Benefits:</p><ul style="font-family: 'Times New Roman'; font-size: inherit;"><li>keep the forwarder simple</li><li>application has a chance to inspect the Data again before using it to satisfy incoming Interest</li></ul><p style="font-family: 'Times New Roman'; font-size: inherit;">Drawbacks:</p><ul style="font-family: 'Times New Roman'; font-size: inherit;"><li>duplication: when a Data packet is used to satisfy an Interest, it would have copies in both In-App Storage and ContentStore</li><li>risk of Data loss: when a Data packet is used to satisfy an Interest, if application chooses to delete the copy in In-App Storage, the Data would be lost when the copy in ContentStore is evicted</li></ul><h2 style="font-family: 'Times New Roman';">Managed ContentStore</h2><p style="font-family: 'Times New Roman'; font-size: inherit;"><a href="http://redmine.named-data.net/projects/nfd/wiki/ManagedContentStore">Managed ContentStore</a> provides an application-controllable Data storage as part of the ContentStore. A Data packet is explicitly inserted to the ContentStore, and the ContentStore guarantees to retain the Data packet until it becomes <em>stale</em> or the application requests to delete it.</p><p style="font-family: 'Times New Roman'; font-size: inherit;">Benefits:</p><ul style="font-family: 'Times New Roman'; font-size: inherit;"><li>no duplication</li></ul><p style="font-family: 'Times New Roman'; font-size: inherit;">Drawbacks:</p><ul style="font-family: 'Times New Roman'; font-size: inherit;"><li>ContentStore is no longer a cache; eviction policy becomes more complex</li><li>application must refresh the stored Data packet, if it remains the latest version beyond <em>FreshnessPeriod</em>; setting a large <em>FreshnessPeriod</em> is still infeasible because in-network caches may retain the Data packet for too long, this means refreshing would be very frequent</li><li>higher deletion cost: deletion needs a command</li><li>inability to enumerate: unlike In-App Storage, the application is unable to enumerate stored Data packets</li></ul><h2 style="font-family: 'Times New Roman';">In-Forwarder Storage</h2><p style="font-family: 'Times New Roman'; font-size: inherit;">An application-controllable Data storage can be placed in the forwarder, but out of the ContentStore.</p><ul style="font-family: 'Times New Roman'; font-size: inherit;"><li>The application sends a command to create an application-controllable Data storage in the forwarder.<ul><li>The Data storage is logically attached to the face of this application. Its capacity and replacement policy are determined when it's created. Its destroyed when face is closing.</li></ul></li><li>To insert a Data packet to the Data storage, the application must explicitly set a field in the LocalControlHeader.<ul><li>Insertion to the Data storage is independant from forwarding pipelines, but the application can elect to deliver the same Data packet into forwarding pipelines.</li><li><em>Data unsolicited pipeline</em> would not admit unsolicited Data packets to the ContentStore, except in special environments such as vehicle networks.</li></ul></li><li>The application can scheduled the deletion of a Data packet during insertion.<ul><li>The deletion timer can be set differently from <em>FreshnessPeriod</em>.</li></ul></li><li>The application can delete Data packets by sending a command.<ul><li>Command parameter is a Name prefix. All stored Data packets under this prefix are deleted.</li></ul></li><li>Stored Data packets are considered only if an Interest is to be forwarded to the application.<ul><li>When an Interest is to be forwarded to the application, the Data storage attached to the face is queried. If a matching Data packet is found, the Interest is not sent, and the Data packet is treated as if it's received from the application.</li></ul></li></ul><p style="font-family: 'Times New Roman'; font-size: inherit;">Benefits:</p><ul style="font-family: 'Times New Roman'; font-size: inherit;"><li>no duplication: if a Data packet appears in both application-controllable Data storage and the ContentStore, it has only one in-memory copy, with references from two places</li><li>less inter-process communication and encoding/decoding, when most stored Data packets are requested more than once</li><li>no risk of cache poisoning: the application-controllable Data storage is not considered until an Interest is to be forwarded to the application</li><li>no refreshing needed</li></ul><p style="font-family: 'Times New Roman'; font-size: inherit;">Drawbacks:</p><ul style="font-family: 'Times New Roman'; font-size: inherit;"><li>higher deletion cost: deletion needs a command</li><li>inability to enumerate: unlike In-App Storage, the application is unable to enumerate stored Data packets</li><li>address space consumption: stored Data packets are mapped in forwarder's address space, and address space is limited on 32-bit platforms</li></ul></div></div>

<span><contentstore-appstorage_20140909.md></span>_______________________________________________<br>Ndn-app mailing list<br><a href="mailto:Ndn-app@lists.cs.ucla.edu">Ndn-app@lists.cs.ucla.edu</a><br>http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-app<br></blockquote></div><br></div></div></body></html>