[Ndn-interest] Hop-by-Hop Flow Balance

[Marc.Mosko at parc.com]

> On Mar 16, 2016, at 11:02 AM, Greg White <g.white at CableLabs.com> wrote:
> 
> On 3/15/16, 3:22 PM, "Ndn-interest on behalf of Marc.Mosko at parc.com" <ndn-interest-bounces at lists.cs.ucla.edu on behalf of Marc.Mosko at parc.com> wrote:
> 
> 
>> 
>> For small-size data, such as IoT, I think it is better to put the data in the Interest and use the Data object as a ACK.
> 
> 
> And with fragmentation support, “small-size” could be large.  :)
> 
> For IoT applications, this method seems far superior to the alternative.  Minimizing the need for IoT devices to publish routable names seems like a good idea from the perspective of routing scalability.
> 
> Since the Interest can be signed by the producer (in CCN at least, I assume the same is true in NDN), it seems the only thing it lacks is the possibility for data to be cached in-network.

An Interest can be signed in both NDN and CCN, though the mechanisms differ.  NDN adopted the method from CCNx 0.x where the consumer puts data in the name and signs the name.  They also wrote a few tech reports on this quite a while ago related to controlling stage lighting and building management, if I remember correctly.

That said one still needs keys for the signature (and encryption).

The CCNx key exchange, which PARC presented at IETF last time and we’ll have an update this IETF too, is consumer driven and does not require named consumers.  So, it could be executed by an IoT device to get shared secrets with a gateway.  It allows bi-directional authentication using public key crypto, though that authentication could be extended to any of the EAP methods (like shared passwords or secrets) if that is better for IoT devices.


> 
> Furthermore, the Data object (ACK) could provide a next-name that is unique to the receiver to allow stateful communication if needed.

Yes, I did not get into details on how one could ACK, but clearly one could use any of the current technology of SACKs, cumulative ACKs, etc., and do not need to do stop-and-wait.  

Similarly to signing Interets, it would be good to have shared symmetric keys for signing (and encrypting) the ACKs.

> 
> 
> 
> 
>