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

From: "David Oran" <[email-masked]>
Date: Fri, 30 Jun 2017 10:05:50 -0400

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?

- 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.

- 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.

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

---

From: Cenk Gündoğan <[email-masked]>
Date: Fri, 30 Jun 2017 23:43:30 +0200

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:
> 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.
> 
> - 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 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.

> 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.).

> - 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/