Subject: [icnrg] comments on icnrg-scenarios-01

From: Mark Stapp <[email-masked]>
Date: Mon, 27 Jan 2014 15:39:55 -0500

On the whole, this presents a useful survey of work in a number of 
areas. And considering the number of contributors (I think)
there is a very reasonable consistency of presentation - thanks to the
editor(s) for that work.

On the other hand, a number of sections contain material that seems to
be more like advocacy than analysis. I've tried to highlight some 
examples below where generalizations appear in ways that don't add much 
value (imo). It might be helpful for an editing pass to look
for "cheerleading" and evaluate whether that material is useful?

I did have a security question: there are some often-repeated claims 
about the security properties of "ICN", in a sort of general way. I'd 
have thought that would have been an interesting axis to compare the 
various approaches, but there isn't a 'security' or 'privacy' section at 
all other than the ietf boilerplate section at the end. Is that just a 
result of the way that research has happened over these last few years?

Thanks,
Mark

1.

   "this documents [sic] shows that certain baseline scenarios seem to
    emerge in which ICN architectures could showcase their superiority
    over current systems"

I don't find the "superiority" claims to be very compelling -
and there are too many of them in this document. I'd prefer it if the
overall editing was pushing back against these kinds of assertions. In
many of the instances in the document where these claims are made,
there are many assumptions: minute rtts, free mobile radio bandwidth,
the willingness of arbitrary users to transport and cache content for
one another, willingness of service providers to permit global routing
updates from hosts. In addition, many scenarios could be replicated
easily with IP/UDP. It would be more useful to highlight any new,
distinctive properties of ICN proposals.

I'd rather see some clear guidance to help sort the wheat from the
chaff. If a scenario relies on free mobile bandwidth, it should have
to say right up-front "if it costs money to have mobile data service,
then this falls apart." And if a scenario depends on the willingness
of strangers' mobiles to transport and cache photos, it should have to
say right up-front "this is entirely dependent on the willingness of
total strangers to do work for free." If a scenario depends on tcp to
do congestion-control, or on broadcast communication among all the
nodes, then it should have to say "without this specific IP network
behavior, we have no idea how to make this work."

2.

   "Content dissemination is at the heart of the ICN paradigm and,
    therefore, we would expect that they are a 'natural fit' for
    showcasing the superiority of ICN over traditional client-server
    TCP/IP-based systems."

sigh. "showcasing the superiority" in what way? In terms of richness
of services/features offered? in terms of latency or bandwidth used?
in terms of complexity of the network required to transport the
service's data? in terms of provisioning or operational complexity?
And what if ... client-server were to do some things better - would
that reduce interest in icn in some way? Can't icn be used for network
services that need servers?

The "service akin to Twitter" only works if it never has to be managed
in any way, if ISPs give away free caching (all over the world), and
if no one ever needs the services that require servers (like ... old
messages, or large ones, or transport across boundaries where p2p
can't really go, or indexing/search/analysis of large data sets of
messages.)  that may not be "superior".

hmmm:

   "with ICN there is no need for a classic client-server architecture
    (let alone a cloud-based infrastructure)"

but ... without some infra, in these examples, you don't get the same
services you get with infra. and of course there are plenty of
ip-based p2p examples. aren't there ICN proposals that have things
like name-resolution - isn't that 'infrastructure'? why is this
statement here?

3.

   "despite the extra cost of adding security support in the ICN
    approach, performance was virtually identical..."

not entirely accurate, or at least sounds spun to me. both linphone
and ccnx used srtp for media, so the audio was already 'secure'. the
ccnx implementation added some crypto to the sip signalling path used
for call setup and that was valuable, but that's just a few
messages. the only thing really "added" by ccnx was a redundant
encrypt/decrypt alongside the srtp operation. and the extra cost did
show up - the 70% interarrival mark for linphone was 20ms, for ccnx it
was 30ms.

that example basically took srtp packets - on a very constrained
network - and turned them into udp packets with ccnx stuff around
them.

some other points:
   * securing every little voice packet with asymmetric crypto may
   be expensive for small/embedded devices
   * encrypting things in a way that doesn't offer forward secrecy may
   not be brilliant anyway

5.

   "It is important to highlight that since the focus of communication
    changes, keep-alives in this scenario are simply unnecessary, as
    devices participating in the testbed network contribute resources
    in order to maintain user content consistency, not link state
    information as is the case in the host-centric paradigm.  This
    means that the notion of "infrastructure" may be completely
    different in the future."

missed that - why are keep-alives so important? and is it even true -
can you figure out which of the available links to use in a way
cheaper than the ways the ip stack uses? it's neat to have a testbed
where everyone "contributes resources" and there are no bad actors,
but the CBIS scenario has some quirks too. CBIS didn't compare similar
protocols using plain ip and ccnx-sync-over-ip. CBIS compares
completely un-cached content from ip with edge caching in ccnx, and
then compares a full-mesh 'routing' protocol, using no summarization,
with something like ccnx sync, which relies on some amount of
broadcast and aggressively summarizes content subtrees using
hashes. At least to me, that says more about what you get when you
compare apples with oranges than it does about "the notion of
infrastructure."

in this example in particular, the infrastructure was responsible for
most of the benefit, actually. without the manual provisioning of
phones to each home gateway, followed by another round of manual
pairing between different homes' gateways, there would have been no
per-home caching. isn't that exactly what 'infrastructure' is for?

6.

   "a video stream could be associated with different audio streams and
    subtitle sets, which can all be obtained from different sources."

but ... even if you wanted to do that (and could get all the bits to
arrive at the right time, and be decoded), how does that differ from
ip?  you could gather pieces from different sources using
ip... shouldn't the emphasis be on (once again) something that's
different, qualitatively different?

   "one may be interested in traffic conditions 2 km ahead while having
    no interest in similar information about the area around the path
    origin"

what's the point there? I might be interested in the traffic
conditions while sitting at home, before I ever enter the
"VANET".

8. economics

isn't a lot of the routing stuff here ... really about routing? should
there be a routing section? [should there be a forwarding section?]

9. energy

what's different for icn here: is it really true that an icn can
transfer more data per ... milliwatt - is that a criterion? the text
complains about "always-on", but how much of that is ip and how much
is driven by various links' characteristics? my mobile is happy to
manage its radio interfaces: is there really any difference in link
behavior? would routers use more energy if they had caches - or less?
would mobiles use more energy if they were "participating" in other
nodes' communication by "contributing resources"? how much of a
router's power dissipation is due to its optical ports? do optical
links really use significantly less energy if they're not carrying
"redundant traffic"?