Subject: Re: [icnrg] Comments on draft-gundogan-icnrg-pub-iot-00

From: "David Oran" <[email-masked]>
Date: Sat, 01 Jul 2017 08:30:35 -0400

Thanks for the detailed responses.
On the name publication piece, it may be I misunderstood the draft - it was not at all clear to me you were talking about the protocol for propagating name advertisements from the individual IoT nodes to the content proxy rather than the general routing problem of announcing names to the network.

I suspect that the protocol will be heavily influenced by the kind of interconnection - quasi-fixed meshes are different from MANET which in turn are quite different from wireless access networks which tend to be one-hop trees.

On the issue of separate data plane, since you said the name publication was not done using the existing request-response NDN/CCNx data plane, it seemed to imply you had an entirely separate control plane that only interacted by being multiplexed with the request-response data plane over the same L2, as opposed to being part of the regular NDN/CCNx data plane, which concludes multi-hop forwarding among other things.

It probably isn’t too productive to sort this out over email - let’s take advantage of the high-bandwidth channel in Prague to talk more. For now take those comments as a suggestion that you need to explain the name publication/flooding part of the proposed design better in the draft.

Best, DaveO.

On 30 Jun 2017, at 17:43, Cenk Gündoğan wrote:

> Hello DaveO,
>
> Thank you very much for this quite detailed review. We will address your
> comments and incorporate your suggestions into the new version of this
> document.
>
> For the sake of completeness, I inlined some minor comments and
> questions below.
>
> On 17-06-30 10:05:50, David Oran wrote:
>> These are offered with <Chair Hat Off>
>>
>> Your draft is interesting and timely in that it addresses what about Pub/Sub
>> provides a good match for constrained IoT devices, and points toward ways to
>> map this well-understood abstraction onto the current ICN designs like NDN
>> and CCNx.
>>
>> The main points seem to be:
>>
>> - direct “end-to-end” Pub/Sub using request-response (e.g. Interest/Data)
>> protocols are not a good match for the characteristics of these devices
>>
>> - by decoupling the last hop to the device(s) using a “content proxy” the
>> advantages of pub/sub can be preserved
>>
>> - the content proxy represents the devices by flooding the content names in
>> a routing protocol, causing requests to come to it rather than all the way
>> to the individual devices.
>>
>> - the devices provide current data to the proxy either push or pull,
>> depending on the specific data of interest.
>>
>> This is fine in the abstract, and deserves drilling down to a lot more
>> detail in what the system model is, how the protocols work, and doing
>> evaluation as to how effectively the decoupling works, and what level of
>> robustness is gained/lost by indirecting everything through the content
>> proxy.
>>
>> The missing and problematic pieces are significant:
>>
>> - The question of PUSH versus PULL seems deep and complicated, but is marked
>> as a “TODO” in the draft
>>
>> - It really matters whether the Content proxy acts as a “repo” or a “cache”.
>> You waffle on this point.
>>
>> - The prefix advertisement scheme gets a lot of attention compared to other
>> parts, but this devolves essentially to link-state (ok, actually name-prefix
>> state) flooding, which is well understood. It has elegant characteristics
>> and scaling problems. What’s new/different here? Are you proposing a
>> protocol like NLSR? Or Chronosync? Or standard LSR to build a tree and then
>> flooding the prefixes over the tree?
>
> Actually, the proposed name-prefix flooding is rather comparable to the
> process of building a delivery tree rooted at the content proxy. AFAIK,
> (N)LSR comes with a great overhead in communicating and storing a full
> topology map. For our use case, the best path originating from a node
> towards the content proxy only is sufficient and therefore a
> distance-vector approach is preferred.
> ChronoSync also does not seem to be suitable for our use case, since a
> change in the data set is synced to every single node. In our scenario,
> replicating the NDO to nodes on a gradient towards the content proxy
> suffices.
>
>>
>> - It seems really unsatisfying to put the routing protocol in a control
>> plane that does not reside on top of the existing NDN/CCNx data plane. Even
>> with moderate amounts of traffic, you now have two very different data
>> planes operating in parallel over the same links, causing complexity in
>> routing, security, congestion control, and QoS.
>
> I have to admit, I did not quite understand parts of this comment.
> Could you elaborate on "... control plane that does not reside on top of
> the existing NDN/CCNx data plane." and "... two very different data
> planes operating in parallel ..." ?
>
> For clarity:
> The proposed idea is to split a Publish operation into two parts, where
> (i) a name of a published NDO is advertised on a hop-by-hop basis
> towards the content proxy. Due to the name based routing of NDN/CCNx,
> this "advertising" of a name appropriately fits right into the control
> plane. In the control plane, a name advertisement is pushed towards the
> parent node, but is limited to that parent node alone, i.e., such an
> advertisement does not go beyond the first hop. Iteratively, this
> advertising is repeated hop-by-hop on a gradient, until the content
> proxy is reached.
> (ii) However, the actual replication of the NDO towards the content
> proxy is performed on the data plane using the NDN or CCNx semantics,
> i.e., by using an Interest to request the NDO from the immediate "child
> node" (in the tree). The advertising (i) and replication (ii) can, to
> some extent, be performed concurrently. E.g., a received advertisement
> can be re-advertised in the upwards direction (towards content proxy),
> while the NDO is requested from the downward direction.
>
> The above description is slightly different from the approach outlined
> in the -00 version in that it focuses on a hop-by-hop content
> replication, which is especially suitable for networks with intermittent
> connectivity where parts of the DAG get partitioned. Will be adapted for
> the -01 version.
>
>>
>> - Many of the subtle issues around mapping to pub/sub, and especially either
>> emulating or eliminating PUSH, are specific to the expectations of IoT-style
>> applications. If the data production is timer-driven, this interacts
>> intimately with both the polling algorithm for PULL and the construction of
>> names that adhere to the time-series clock of the data. Conversely, if the
>> data is alert-like (e.g. alarms, thresholds, etc.) strict PULL will
>> introduce either long delays or high polling overhead (with the latter
>> blocking sleep), so one needs to either put PUSH into the data plane
>> (messing with congestion control, channel scheduling and lots of other
>> stuff) or design a “phone home” style protocol using multiple RTTs. Figuring
>> out how to design a content proxy that does all this well, and does it in an
>> *application independent* fashion seems one of the biggest challenges in
>> providing pub/sub semantics.
>>
>
> This is a very good point. Designing the content proxy is indeed a
> complex endeavour and admittedly the current -00 document version is
> rather reluctant about this topic. Future versions will improve on that.
> However, in our proposal we want to refrain from PUSH operations on the
> data plane for the same reasons you mentioned (congestion control, cache
> poisoning, etc.).
>
>> some small points:
>>
>> - please define “converge cast” and give a reference
>>
>> - beefed up reference would be really helpful here, including to some of the
>> T2TRG work which takes a different approach that would be useful for
>> comparison
>>
>>
>> DaveO
>>
>
> Cheers,
> Cenk
>
>> _______________________________________________
>> icnrg mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/icnrg
>
>
> -- 
> Cenk Gündoğan
>
> Hamburg University of Applied Sciences
> Dept. of Computer Science / Internet Technologies Group
> Berliner Tor 7, 20099 Hamburg, Germany
> Fon: +49 40 42875 - 8426
> Mail: [email-masked]
> Web: https://www.inet.haw-hamburg.de/
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

DaveO