<p dir="ltr">Marc,</p>
<p dir="ltr">There is nothing in JJ's latter proposal in ICN 2016 indicating anchors' identifiers are not anchors' names. Actually the namespaces could be the same. So name lookup can still hold.</p>
<p dir="ltr">Thanks,<br>
Sabet</p>
<div class="gmail_extra"><br><div class="gmail_quote">On 29 Sep 2016 10:11 am,  <<a href="mailto:Marc.Mosko@parc.com">Marc.Mosko@parc.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<div>In the earlier label-swapping proposals, some of which are JJ’s, it is true that the Interest is routed per-hop via the name and the labels are established only to label swap back the Data.  The state space scales in the number of flows through
 a node.</div>
<div><br>
</div>
<div>In some of the later proposals, such as the paper JJ just presented at ICN 2016, because the routing is done on anchors one no longer needs to do a lookup on names at every hop, but on anchor identifiers.  I think it also went further in that
 once a forward path label is picked for an Interest, it could be label swapped in the forward direction too (assuming an SVC was already setup for that destination).  In this respect, the switching of interests and data inside the network is no different and
 only the edge devices need to do different computations on them.</div>
<div><br>
</div>
<div>Marc</div>
<div><br>
</div>
<br>
<div>
<blockquote type="cite">
<div>On Sep 29, 2016, at 9:47 AM, Luca Muscariello <<a href="mailto:luca.muscariello@gmail.com" target="_blank">luca.muscariello@gmail.com</a>> wrote:</div>
<br>
<div>I think the PIT is not just a question of interests aggregation. It is more than that. 
<div>We need to be careful in comparing forwarding and the way routing is/can be built  on top of a given forwarding plane.</div>
<div><br>
</div>
<div>I read JJ's paper but not yet Gene's and Ravi's.</div>
<div>If Ravi's can send a preprint that would help the discussion.</div>
<div><br>
</div>
<div>Of course I would expect the authors of such papers to make the comparison we look for in the papers.</div>
<div><br>
</div>
<div>Why is the PIT more than just aggregation?</div>
<div><br>
</div>
<div>In CCN only Interests are routed. Data is in a way label switched by using local state. The name in the data is used to implement label switching and to follow the bread crumbs. But in principle you could use a token to implement data forwarding. </div>
<div>Still this token state space would scale with the interest names state space. </div>
<div><br>
</div>
<div>So the label switching proposed by JJ scales better because the system has changed state space of the labels. JJ is using an address space and not a name space. The assumption is that the address state space is way smaller. And it is true.</div>
<div><br>
</div>
So the big change in JJ design is this one and not label swapping per se.
<div><br>
</div>
<div>I read other papers proposing that like Carzaniga's work (ICN 2014) but I would like to read Gene's work and also Ravi's work to see how the solved the issue.</div>
<div><br>
</div>
<div>Now routing on locators is a whole new thread I guess. But PIT-less design that route on names is different. Again I need to check the new papers.</div>
<div><br>
</div>
<div>Luca<br>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<br>
<div><br>
</div>
<div><br>
<div><br>
On Thursday, 29 September 2016, <<a href="mailto:Marc.Mosko@parc.com" target="_blank">Marc.Mosko@parc.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">
<div>This message got a bit off topic from the OP, so I label swapped the subject ;)</div>
<div><br>
</div>
<div>I think preserving the possibility of symmetric paths is a significant feature.  It is the main property that new congestion control protocols use and I think an attribute that deserves serious thought.</div>
<div><br>
</div>
I agree with Luca that going label swapping instead of PIT trades one set of features for another set of features.  I think it would be useful to systematically list the features offered by the PIT and the features offered by label swapping.  One could then
 make a principled comparison between them.
<div><br>
</div>
<div>I believe that the main feature lost is Interest aggregation.  If one has caching, then I think this is a minor loss.  The window for Interest aggregation to work is a RTT.  The window for caching to work could be much longer.  All the memory
 one was spending on the per-packet PIT state can now be used for more caching.  It would be useful to look at flash crowd dynamics to see if even in those cases aggregation saves much compared to caching.</div>
<div><br>
</div>
<div>In the NDN architecture, one would also lose the PIT nonce state, but NFD already has a second nonce table to keep them around after a PIT entry is erased, so that could stay as it is.  It wouldn’t be exactly like now, but one could probably make
 nonces still work if one thinks keeping them is worth the memory usage.</div>
<div><br>
</div>
<div>A significant feature gained is a large reduction in memory bandwidth by not having to update a large data structure at wire speed.  As we saw today from JJ’s presentation, if one uses label swapping and routing on anchor identifiers, then one
 can make the case of running on today’s forwarding hardware at or near full speed.  Thus the time to deployment on high speed routers could really shrink down.</div>
<div><br>
</div>
<div>Anyway, I think this is worth more formal study rather than this piecewise analysis.</div>
<div><br>
</div>
<div>Marc</div>
<div><br>
</div>
<div>
<blockquote type="cite">
<div>On Sep 29, 2016, at 5:26 AM, GTS <<a>gts@ics.uci.edu</a>> wrote:</div>
<br>
<div>
<div bgcolor="#FFFFFF" text="#000000">To get back to the issue of having or not having the PIT:<br>
<br>
Recall that this thread started with discussion of massive DoS attacks on <br>
the current Internet, initiated from IoT devices. It progressed to a discussion<br>
of DoS attacks in CCN. It was then suggested that a PIT-less<br>
design might address the only glaring major type of DoS attack in CCN --<br>
interest flooding. I specifically say "address", not "solve" or "obviate". <br>
(That's because even a PIT-less design allows the producers to be interest-flooded).<br>
Now, the particular PIT-less design that Cesar mentioned is this:<br>
<br>
<a href="https://arxiv.org/abs/1512.07755" target="_blank">https://arxiv.org/abs/1512.077<wbr>55</a><br>
<br>
It is NOT motivated solely by interest flooding mitigation. It just happens<br>
to be one of its features. The authors (of whom I'm one) would love to<br>
hear some reasoned criticism of this PIT-less design. It should be based<br>
on actually reading the paper. <br>
<br>
More generally, the PIT is currently a fundamental feature of both NDN and CCNx.<br>
Should it even be questioned? To some true believers, this is clearly an anathema.<br>
IMHO, all architecture features should be up for debate and all dogmas ought to be questioned.<br>
For example, I believe that the PIT and the CACHE (for example) are not what <br>
make an architecture Content-Centric. Either or both can be removed and what <br>
remains would still be a Content-Centric Network (though perhaps not a good one).
<br>
<br>
Finally, the PIT-less design mentioned above could well be ill-advised,<br>
or even totally senseless. We simply don't know yet. <br>
Indeed, as the paper admits, it has some problems of its own.<br>
Or, it might make sense in some settings, e.g., where the <br>
network infrastructure is mobile. Or, it might be an alternative/optional implementation.<br>
(BTW, it can in fact co-exist with a PIT-ful CCN).<br>
<br>
Cheers,<br>
Gene<br>
<br>
<pre cols="72">======================
Gene Tsudik
Chancellor's Professor of Computer Science
University of California, Irvine

</pre>
<div>On 9/27/16 10:12 PM, Luca Muscariello wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">The work JJ has presented this morning is probably another interesting thread.
<div>And I agree that the signal mentioned here is not a prerogative of the PIT.</div>
<div><br>
</div>
<div>So, to stay in topic to this thread, from my point of you what JJ has proposed</div>
<div>has more compelling properties to remove the PIT than the DDoS example</div>
<div>considered here.</div>
<div><span></span>
<div><br>
</div>
<div>In JJ's proposition, you trade something for something else. It's not an equivalent</div>
<div>architecture to NDN though. So we need to be careful before laying away pieces of the architecture. There is a  price for that.</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
On Wednesday, 28 September 2016, <<a>Marc.Mosko@parc.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Removing the PIT and using, for example, a label swapping approach such as J.J. Garcia-Luna-Aceves has suggested, does not remove the “signal” you talk about.  One could keep upstream and downstream counters for each label swap identifier and see which labels
 are not getting downstream data.<br>
<br>
I do not think the strategy of purging PIT entries based on the shortness of their remaining lifetime gives you any correlation to purging attack packets.  First of all, an attacker could easily use a very large Interest Lifetime.  Well-behaved clients that
 are using RTT estimates in their Interest Lifetime would, by definition, likely have very small margins in the Interest Lifetime remaining  before the Data comes back (personally, I think it is a problem to make InterestLifetime based on RTT, but that’s a
 different thread).<br>
<br>
<br>
Marc<br>
<br>
> On Sep 28, 2016, at 10:47 AM, <a>christopherwood07@gmail.com</a> wrote:<br>
><br>
> On September 27, 2016 at 5:14:14 PM, Christos Papadopoulos<br>
> (<a>christos@colostate.edu</a>) wrote:<br>
>><br>
>><br>
>> On 09/27/2016 04:59 PM, <a>woodc1@uci.edu</a> wrote:<br>
>>> To re-iterate Cesar’s point, as of now, there is no truly effective<br>
>>> interest flooding mitigation. However, one concrete way to minimize<br>
>>> the attack surface (for routers) is to get rid of the attack's root<br>
>>> cause: the PIT. (Producers could still be hosed with bogus interests.)<br>
>>> And since the PIT enables several important functions, other<br>
>>> architecture changes will probably have to follow in its wake.<br>
>><br>
>> You start with what I believe to be the wrong premise: protecting the<br>
>> router. In NDN we care about communication, not a single router.<br>
>> Protecting a router is winning the battle but losing the war.<br>
><br>
> I respectfully disagree. If the adversary takes out the producer,<br>
> there is no communication. If the adversary takes out the routers<br>
> adjacent or otherwise on the path to the producer, there is no<br>
> communication. Protecting the router(s) is equally important,<br>
> especially since it may impact more than just a single producer.<br>
><br>
>><br>
>> I don't understand your statement that the root cause of DDoS attacks is<br>
>> the PIT. The root cause of DDoS is resource exhaustion.<br>
><br>
> In these attack scenarios, the PIT *is* the resource being exhausted.<br>
><br>
>><br>
>>><br>
>>> Personally, I don’t think we should settle with an architectural<br>
>>> element that has a known (and quite severe) weakness simply because it<br>
>>> enables some nice features in practice. The more serious design<br>
>>> problems must be dealt with first, not last.<br>
>><br>
>> You are underestimating the importance of the signal the PIT provides.<br>
>> It is an important insight into the status of communication. The PIT<br>
>> does not simply enable some "nice features". Think a bit harder about<br>
>> the things you can do with this signal.<br>
><br>
> In most attack scenarios, yes, it tells you when bogus interests are<br>
> flooding a particular prefix and otherwise when communication is<br>
> failing. But consider this scenario. Suppose you have a malicious<br>
> producer cooperating with one or more malicious consumers. The<br>
> consumers are quickly sending interests to this legitimate producer,<br>
> who responds with legitimate data. The communication is not failing.<br>
> Their goal is to do nothing other than saturate the PIT of some<br>
> intermediate router. Per Spyros’ follow-up suggestion, that router<br>
> might kick out old, legitimate interests in favor of these malicious<br>
> ones. Of course, this is fundamentally how we would expect one to deal<br>
> with and manage a limited resource. So preventing this attack seems<br>
> difficult for any approach. But the point is that this resource, the<br>
> PIT, is easily abused in CCN/NDN.<br>
><br>
> Chris<br>
><br>
> ______________________________<wbr>_________________<br>
> Ndn-interest mailing list<br>
> <a>Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">
http://www.lists.cs.ucla.edu/m<wbr>ailman/listinfo/ndn-interest</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
Ndn-interest mailing list<br>
<a>Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/m<wbr>ailman/listinfo/ndn-interest</a><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset></fieldset> <br>
<pre>______________________________<wbr>_________________
Ndn-interest mailing list
<a>Ndn-interest@lists.cs.ucla.edu</a>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" target="_blank">http://www.lists.cs.ucla.edu/m<wbr>ailman/listinfo/ndn-interest</a>
</pre>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>

<br>______________________________<wbr>_________________<br>
Ndn-interest mailing list<br>
<a href="mailto:Ndn-interest@lists.cs.ucla.edu">Ndn-interest@lists.cs.ucla.edu</a><br>
<a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/<wbr>mailman/listinfo/ndn-interest</a><br>
<br></blockquote></div></div>