Minutes IETF97: icnrg
minutes-97-icnrg-00

ICNRG/T2TRG Meeting, Sunday, November 13th, 2006
Seoul
===================================================
===================================================

Note takers: Ari Keränen, Dirk Kutscher, [add-your-name-here] Michael Koster

Carsten introduced joint meeting. Morning session together with
T2TRG, afternoon ICNRG only while many T2TRG folks will be going
to NMRG IoT meeting. First part 4 presentations, second part
focusing on discussions.

Carsten introduced T2TRG. Dirk introduced ICNRG.

Presentations
=============

Research and Development of the Hyper-connected IoE Network Technology - Taewan
You

Taewan presented AETHER for future IoE networking. Fog computing, ICN, and IoT.

N.N.: specifics of naming scheme?
Taewan: self-certifying IDs used. Also source address integrity procedures.

Jairo Lopez: ID-Net proposal had a generic model -- is that continuing research?
Taewan: not using new concepts here. Can send URL for more info about details.

----------------------------------------------------------------------

Device and Network naming structures and ICN for IoT applications - Lopez Jairo

Jairo presented work on naming. Names very context dependent (Barcelona city vs
Football Club; more than one of both).

Dirk: do we need addressess?
Jairo: yes, if you need to get somewhere. But you have to be careful of the
context you're talking about. Conclusion: everything is a name. Address is how
to get to a name.

Jairo presented mapping of RFC1498 concepts to ICN. No "path" in ICN.

Jörg: there are flavors of ICN that have concepts of path. Using bloom filters
for example. Jairo: Namespaces seem to be independent. Each layer only needs to
know the relevant names (e.g., network -> nodes).

Börje: differences between ICN approaches -- you seem to primarily refer to
CCN/NDN. In other approaches, you may have name resolution services that would
give you an address for a name. Jairo: afternoon discussing mobility part. Do
we need all parts in the same namespace? Could we make them independent? Will
in IoT scenarios want to know what particular node is doing.

Börje: Do you mean that names should be different from names in addresses?
Jairo: no, one namespace (e.g., service namespace), then node name would be
come address for service name -- these namespace would become independent Ravi:
have system for managing namespace. Collapsing two namespaces become
unmanageable. For mobility etc want to have separation of namespaces.

Marc: don't know what you say ICN has no node names -- everything ICN system
uses something like this for mapping interfaces to routes

Jairo: have not read completely the area. Main difference: one thing to
identify node but another if it's in namespace need management how to give
those names

Marc: It might make management easier, but not all names may be topologically
relevant. Like in IP

Lixia: NDN does router announcements for reaching data name prefixes, not node
name

Marc: does NLSR announce router names?

Lixia: yes, but only for "management". As far as routing info is concerned, we
realy announce data prefixes

Marc: not sure how you run Dijkstra without node identifiers?

Jairo: had long discussion on this at Kyoto. Complicated topic.

----------------------------------------------------------------------

A RESTful, Distributed and Enhanced ICN System for IoT " for ICNRG/T2TRG
meeting - GQ Wang

Some reseach questions looked into: should ICN use URIs or REST be extended to
different kinds of names? Can ICN be used to create distributed Resource
Directory? Can ICN reduce the amount chatter generated by IoT devices thanks to
caching in network?

the concept is discovery and routing based on semantic attributes found in
Resource Directory entries and links

application components form a mesh, not a single monolithic application

Christian Groves: about filtering at the edge, filtering data at edge was
discussed at the T2TRG meeting at Ludwigsburg.

Dirk: mentioned translating between IoT networks and Internet. What's vision,
is such translation always needed?

every namespace has its own domain

GQ: probably yes right now because every namespace has their own domain. Flat
namespace for local network. But global network needs some mechanism. In
RESTful systems we use URIs. For scalability for routing prefixes needed. For
node/application/service name; need someone to manage the names. Can one name
serve all purposes?

Lixia: yes NDN data names serve three purposes: identifying data, forwarding
interests, and security.  Findsing the best way to handle the tradeoffs among
the three is one of the basic research challenges.

GQ: need different names if want all different functionality. Need rechability
from network. But different for application.

Lixia: can reach each other without attachment in local settings; only in large
scale need attachment to scale the forwarding.

Matthias: on mapping on ICN to REST; do ICN systems come with their own
interaction model? Every system has their own methods?

Dirk: yes, different applications use different things. For example DASH-based
video using manifests. For IoT no common agreement yet; want to figure out one.

Matthias: have impression that ICN could solve lots of issues with
intermediaries. Could roughly be replaces by ICN. For naming URIs help because
just agreed scheme how they are put into string that is opaque to the (RESTful)
application itself.

GQ: Could put that fucntionality to access point

Michael: is there a URI scheme that we could use? Right now, DNS chances names
to addressed -- how about ICN?

GQ: personal view: will be up to application. If all aps use URI, simple
mapping to URIs.

Dirk: different variants of nams in ICN. Not only hierarchical names. Also
tuples (type-value), etc.

N.n:: ETSI m2m group have standardized names.

GQ: When you know URI programming, it's easy to use this in ICN

----------------------------------------------------------------------

[coffee break; back 10:50]

----------------------------------------------------------------------

I3: some thoughts towards an Industrial Information-Centric Internet of Things
- Thomas Schmidt

i3: Industrial ICN. IoT surveillance scenario. Can ICN outperform IP in such
case? Looking into routing, mobility, security, reliability, caching, deploymen
environment.

Dirk: potential for cost efficient and safety critical infra for IoT here.
Hoping to get more practical experience.

Ravi: one question is basic benefits of ICN in IIoT. Have probably done survey
on this. See ICN having upperhand compared to current IIoT stacks?

Thomas: not looking at proprietary stacks. Looking into IP world and ICN
implementations. Have industrial partner who needs to see if there's benefits.

Jörg: comment: we built this for underground mines, using DTNs. We found that
there is no spectacular routing -- you just want to collect all data (so use
epidemic spreading). Mostly message coding for robustness. Also, management
issues (updates etc.). Also had gas sensors. Most problems were not very
researchy. Mostly engineering issues.

Lixia: Mobility support -- what are the application scenarios you are having in
mind?

Thomas: scenarios are still under debate. Refinery with relatively large space
with "factory units" spread across place apart from each other. Cars and people
moving in between in field. Endpoint (istead of network) mobility. Finite field
mobility and re-attachments. Sensor devices on person and other machinery. Mesh
of sensors.

Lixia: recent DDOS attack was lauchned on IoT devices, so IoT urgently need
security.

Thomas: security is issue. Was implementation failures on IoT device level.
Different story.

Lixia: but it makes the point that IoT today is not built with security in mind

Carsrten: if it's not usable secure, it's not IoT. Call it IoC(rap), IoS or one
of those.

Dirk: mentioned publish side & pub/sub. Need to extend current ICN protocols?
Thomas: core problem is event driven reporting. Push needed. Several solutions
how to implement this. Need initiation from alerting entity -- I'm your content
and want to share content; that's publish. Putting content to interest is one
of the suggestions but reverting the paradigm and causes other issues.
Initiated data flow needs to correspond to routing to get stuff from A to B. In
CCN have routing that guides interest, but also reverse path pointers. But no
RPP without interests. Need to cope with this. Don't necessarily want to exten
protocol, but need to think what would be semantically correcly, elegant,
solution.

Alex: comment: ICN opportunities in IoT, naming is very important. Forwarding
based on interest names. For example, in some applications, geographic
coordinates could be embedded in names. "Interest can figure out itself how it
is forwarded".

Thomas: two things: need routing and forwarding to work hand in hand. Need
setting up FIBs.

Lixia: Alex's point: can do forwarding without routing protocol. Fundamental
point: be careful in using the word routing. The fundamental goals is
forwarding.  Routing is to assist forwarding when needed (for scale).

Thomas: do not believe in namespace engineering that only works for selected
applications. Naming is important, but if constraints are too specific, then
you exclude apps that cannot deal with this naming.

Alex: that's why I said it's for subset of applications.

----------------------------------------------------------------------

Dirk gave summary on ICN & IoT discussions.

Claimed benefits on access to data, security, availability, stack simplicity,
etc. But need to substantiate these claims.

Open research questions on naming, semantics, security, IP Internet interaction.

Jörg: is semantics discussion tied to network? Will deploy contained with data
and can refer to with ID. Could argue that not pushing too many bits and pieces
to the interaction of two things might be helpful. Not sure semantics part is
intertwined with data retrieval. Carstren: important with discovery Dirk: what
doing at ICN IoT is to figure out how -- you can see the whole stack in a
different way and optimize the stack. Integrate interest information to help
with forwarding. Börje: when doing computation on things need to know what to
do with data Jörg: not sure if the things are that intertwined Carsten: don't
need to change CoAP for semantic interop Dirk: do these need to be considered
together? Carsten: both groups have the problem, for ICNRG probably not yet
painpoint but for T2TRG already is

Carsten: whole term GW is loaded. Gateway used to be router in the past. Term
has changed its meaning to something that can be complicated (and allows to
make money). In e-mail, we used to have all kinds of mail gateways, and we
managed to get rid of them, because we developed a common of how e-mail should
be handled in the network. Would it be useful to think about the functions of
an ICN-IoT that works for many different applications, so that we can do
permissionless innovation (main point of the Internet). Can we come up with a
gw abstraction that is powerful enough that we don't have to come up with a gw
for every new application?

Discussion today: how we can show that ICN is better in IoT than
application/network protocol X. More interesting: Understanding the common
major issues, so that both groups can benefit from these insights.

Carsten presentation, starting with: "endpoints..." slide. In REST world
transport addresses used. But rather need something bound to identity (but
identity is overloaded term).

Börje: folks see areas of common interest and things to work together?

Thomas: Carsten's last point (Identity Confusion, APIs) is very important. To
have applications that can run in both Restful and ICN environments.

Ravi: Naming is from applicatio perspective. Want to name services. In ICN
everything does not need to be content centrinc (depening on protocol). ICN IoT
requirements draft discusses the intersection between two groups.

Michael: interesting discussion content vs naming.

Ravi: Fundamentally, can you impose one kind of naming for all applications?

Jairo: we should maybe talk about having mechanims to include the things we
want on naming; have policy in network what to use. If no mechanism to add or
remove this, not good.

GQ: @T2TRG: ICN could be a candidate technology for mapping application to
networking layer. Do you have support for multipoint communication/distribution?

Carsten: elements in architecture like proxies but should take the details
off-line

Lixia: should work together and figure out the API together. Instead of talking
should build applications. That would teach us more than discussions. It is not
that NDN enforce any specific naming structure but we learned from real
implemnetations the relations among naming, security, and forwarding. Let's put
10-20 different things together and see how they can talk.

Jörg: There is clearly potential to explore things jointly. Building apps
certainly useful. Last week, there was a fair on industrial sensors in Munich
-- lots of proprietary solutions. We have a hard time getting CoAP and ICN
deploy individually. Could be interesting to discuss how we can create
something that creates some value so that people can pick it up.

Carsten: large part matter of education . Should examine this.

Dirk: in business environments need to build stuff and demostrate key benefits.
Not just conceptual slides.

Ravi: can also learn from existing systems. Fixed, power efficient, naming is
clearly important. Börje: how to get people to care about this, what are the
real problems people have. Then can have impact. Some design guideline for IoT
and ICN in the ICNRG which T2TRG folks could give feedback on would be good.
What should be in such document. Contact Ravi.

Ravi: authors of the document come from ICN perspective. Getting IP IoT
perspective would be quite beneficial.

Carsten: not lof of T2TRG people would be interested to write doc that says
there's another architecture that's better. Rather want to take home bits that
are useful. Need to make sure it's reseach doc, not marketing doc.

Börje: need to be closing now. Sense of the room was this useful exercise?
(folks nodding)
Carsten: probably was too short

Matthias: is someone actively working on both sides? Many quesions for example
what parts can be modularized? Someone who could comment. Someone who
participates in both communities?

Börje: Thomas, Matthias, Lixia, Börje

Lixia: more than welcome to join also our sessions.

Matthias: already participating in many groups. More meetings not helping. If
can have people who participate in two and can give executive summaries between
would be good.

(joint meeting adjourned)

======================================================================

13:30-15:00 Session 3

Note taker: Dirk Kutscher

ICNRG is using this github project to share working documents for several
activities (e.g., harmonization, terminology): https://github.com/icnrg

----------------------------------------------------------------------

IPoC: IP over CCN for seamless mobility - Greg White (25 min)

Greg presenting

Ravi: what is the reason for this approach
Greg: want to use unmodified applications
Ravi: something like a proxy on the client?
Greg: more like a tunneling endpoint
Ravi: where is the protocol translation happening?
Greg: no translation
Ravi: what is tunnel stack?
Greg: TCP/IP/IPoC/CCN
Ravi: why do tunnel IP over CCN?
Greg: because unmodified applications can benefit from CCN transport

Dirk: what is the cacheable unit? IP packet?
Greg: yes, you wouldn't get application data unit caching with that
Greg: for HTTP it might be more beneficial to do "HTTP over CCN"

Dirk: with this approach, you are losing the interest/response balance property
Greg: yes

Dirk: what about the response to an Interest packet with an IP packet?
Greg: explanation on slide

Dirk: are you dropping packets?
Greg: yes, drop tail at the moment

GQ: for upstream traffic, you are sending IP packets in interests?
Greg: yes, like a tunnel

Marc: are there interactions with timing of transport protocols
Greg: should be fairly weak interaction. There could be latency peaks, when
packets queue up at gw. But not much different to normal IP router Marc: if you
were looking at TCP window size, you could maybe make a better estimation of
the number of the interests you need Greg: Can pack multiple IP packets into
one Content Object, so this gives a lot of elasticity

GQ: did you compare with Mobile IP (PMIP etc.)?
Greg: no concrete results yet, but goal is to be competitive with EPC
Greg: in terms of latency performance, with most parts it should be very
competitive with EPC, especially considering user mobility

GQ: performance comprison to native approach?
Greg: this is definitely a tunnel protocol, but 3GPP today is also using tunnels

Ravi: for consumer mobility, you are expecting the ICN layer to resend all
interests (at handover time) Greg: just the empty interest (no need to resend
IP payload), also can do soft-handover

Ravi: do you benefit from caching also?
Greg: for handover, yes, we retransmit interest packets which could pull from
cache

Ravi: there is no semantic match for re-sending Interest
Greg: no, but not sure whether there needs to be

Dirk: comparison with TCP/CCN?
Greg: this one can support all IP-based transports, also can do bi-directional
communication directly

----------------------------------------------------------------------

Seamless mobility for ICN -- Keping Yu (25 min)

Jairo Lopez presenting

Ravi: have you looked at inter-domain mobility?
Jairo: you would have to keep the topological meaning of names for the whole
network

Ravi: domain == AS -- how would you handle that?
Jairo: with globally unique ICN names, and with topologically significant
names, it would work

Lixia: what do you mean by topolgy? AS relationship is not network domain
topology Jairo: mathematical topology, not network routing topology

Lixia: remember landmark routing?
Jairo: will take a look

Lixia: producer mobility -- producer does not know latency etc. This maybe
similar to geo-hyperbolical routing Jairo: possibly

Ravi: How would you manage mobility?
Jairo: we assume reactive network -- user has to tell network that it is moving
or has moved Jairo: network can buffer for you if you told it that you move
before Jairo: when producer moves, it has to tell the consumer the new node name

Dirk: wonder whether Saltzer's RFC is a good guidance for ICN?
Jairo: objective was to enable two namespaces and keep topology namespace from
ICN namespace

Marc: maybe also look into mobility in LISP

Lixia: Saltzer is 30 years old -- may not match too well to ICN -- should not
be taken as a bible

Jairo: maybe some of these concepts have not changed (names vs. addresses)

Marc: also look at custodian ICN forwarding (Jacobson paper)

Lixia: Survey of ICN mobility paper, one category "signalling free" mobility
Ravi: but this is not seamless mobility management

Lixia: in ICN, with facebook-like publishing, you don't need to chase producers
Jairo: mobile networks rely on mobility anchor

Lixia: pre-knowledge vs. post-knowledge. With well-known rendezvous
(pre-knowledge) points, you can avoid real-time signaling

GQ: what is the different to home agent then?
Lixia: you still need to do chasing

GQ: but centralized rendezvous point would not scale
Lixia: do it distributed

Lixia: move the data, instead of chasing the producer

Ravi: how does the rendezvous point get the data from the moving producer with
"chasing"

Lixia: rendezvous can be the namespace (so distributed)

Lixia: also K.K.'s paper at ICN-2016

----------------------------------------------------------------------

NRS Requirements Update -- Jungha Hong (25 min)

----------------------------------------------------------------------

Status update on the CCN/NDN harmonization efforts - Alex/Lixia?? (30 min)

Marc explaining status and recent process

Current write-up:
https://github.com/icnrg/draft-icnrg-harmonization

----------------------------------------------------------------------

Terminology document (20 min)

Bastiaan: submitted first version before Berlin, got some comments, now
addressing them for a next revision

current question: should this be focussed on one approach or talk about ICN in
general

telcos on Thursdays, f2f meeting during this IETF week

Lixia: agree on broaad coverage, would like to focus on one thing first

----------------------------------------------------------------------

IoT document (20 min)

Ari agreed to provide some feedback on Iot requirements drafts

----------------------------------------------------------------------

RG maintenance/admin (20 min)
Planning for future Interop / Hackathon
Planning future meetings

January interim?

note: QUIC interim from Jan 24 to 26 in Tokyo (could be a conflict)