Minutes IETF99: icnrg
minutes-99-icnrg-00

ICNRG Wednesday meeting
9:30am - 12pm
Karlin Room- Hilton - Prague.

Note taker: Cedric Westphal (Huawei)
---------------------

* Sunday Meeting Summary (Chairs)

On Sunday we had in the morning:
- readout from ICN/IoT Workshop in Stockholm
- readout from Intel-NSF Research program kickoff 6/21-22
- research talks from ICN'7 TPC members: new NSF CC* project on using NDN for
data-intensive science (Edmund Yeh); ICE-AR under the NSF/Intel-WEN program
(Lixia Zhang); ICN Network Coding (Cedric Westphal); Keyword-based mobile
application sharing (Ioannis Psaras) - Update on CICN community Open Source
work (Luca Muscariello) - Configuration/management and control of an CICN
network demo (Marcel Enguehard)

In the afternoon:
- Update on Harmonization Work (Alex)
- ICN principle discussion (DaveO/AlexA)
- Hyper-connected IoE network technology (Jungha)
Drafts:
- draft on Status update and discussion on Terminology (Bastiaan Wissingh)
- draft Enabling Network Identifier draft (Ravi Ravindran)
- Name Resolution Services (Jungha Hong)
- Introduction to the draft Consideration of the Applicaiton of Multi-Service
Tag (Duan)
--------------------

* Results of last Call on CCNx protocol documents (chairs):
- from the point of view of the chairs, positive feedback and no issue raised.
Consider the last call complete and suggest to move the documents forward. -
DaveO: Allison, these two documents are coming to you for IRSG review. Expect
by end of the week. Intended as Experimental RFCs. Reasonably high degree of
importance to this community. - DirkK: good milestone; we want to do more of
this in the future. If you have work of this nature, we are happy to help
progressing that. - BörjeO: a number of other protocols in the pipe; please
take a look at them, as they are coming up for last call pretty soon.

-------------------------------
* ICN-LTE document. Prakash Suthar (+Milan Stolic, Anil Jangam, Cisco Cystems)

Native deployment of ICN over 4G/LTE networks.
v0: March 2017, first draft; v1: May 2017, feedback from IETF-98; Version 2:
June 2017 (additional in-depth review and feedback at IETF-99)

Objectives: ICN deployment scenarios for 4G/LTE mobile networks. Because
current research/projects covers: ICN as an overlay; ICN scenarios to date are
either in fixed wireline or wifi network; ..

ICN Deployment Options in UE - Dual Stack of Native?
Involved as well in 3GPP, proposed in parallel there.

* In the UE:
Proposing to put an ICN forwarder that co-exists with IP for ICN packets (e.g.
interest packet to eNodeB or response "data packet" from eNodeB to the
application). Propose a transport selector (ICN or IP) and radio interface
(LTE,WiFi or both), preference (content location, content type, publisher,
cost, QoS) PDCP layer updated to support ICN (sequencing, drop detection,
retransmission), ROHC, ciphering/deciphering.

* In the Base Station:
handle ICN request, can send on ICN transport
handle IP as well; can handle selection of "IP or ICN"
transport: ICN, IP, dual stack ICN/IP

* ICN Deployment in the transport
Envision a dual stack scenario (IP/ICN) to remove encapsulation tunnel (GTP
tunnel for instance); Native ICN removes the need for GTPTunnel or do it only
locally. Intent to implement ICN natively from the radio all the way up to the
GWs. Northbound API to influence decisions along QoS/Cost/Etc

* ICN Security considerations
7 key security domains: 1 UE authentication/authorization;2 radio interface
security;3 DoS attacks on mobile GW, services;4 content poisoning either in
transport or servers;5 content cache pollution attacks;6 secure naming, routing
and forwarding;7 application security Call for more input in these areas. 1/2/3
addressed in existing security specs TS33.310, TS33.320; but not the others
considerations. Additional issues: DPI, Lawful Intercept (LI)


* Next steps:
working group draft?

Q/A:
Akbar: read the previous version, and it was good. One comment, on security. I
will be presenting deployment considerations next. RFC7945 (security
considerations) actually covers some of the issues. A: I went through that, but
there is more to be done. Akbar: U/E stack. Proposing a dual stack approach,
right? ICN function: when would you use that? When you have 4G deployment that
is fully upgraded to ICN? A: when IPv6 was deployed in the network, they
introduce some capability when the client attaches, it can indicate a
preference for IPv6 or v4; now is the time to do something similar to introduce
ICN. when introduce ICN function along with IP, it will help UE indicate its
choice: I want to attach as an ICN client. Akbar: so it would be UE initiated?
A: right; we went with anchorless quite a bit, but especially when the user is
attaching to the network, it has to indicate its point of attachment. It has to
indicate: "I'm an ICN client".

Dirk Trossen: I like the draft, very good to integrate into LTE. Question I
have is at the top box, you talk about existing application, and you slot the
transport. Do you believe a transport selector is the key issue? Do you believe
an HTTP-based application, merely selecting the transport would be enough? A:
Between client and GWs, the application are requesting the content; all they
need is the socket to connect to the IP layer and send it out. We're trying to
introduce an additional mechanism in addition to IP. Tomorrow you might have
some app that uses only ICN, but other can be agnostic ICN/IP based upon
network performance. DT: so you using ICN as a pure channel? A: yes

John Dowdell (Airbus Defence and Space): I work on DTN, where we have the
concept of using any transport layer and a protocol layer on top of this. We
have in between a convergence layer, to adapt the protocol with the underlying
transport. I cannot make sense of your picture in that context. Maybe you
should take a look at this work. I believe the concept of transport selector is
implicitly defined in DTN. A: more choices in transports DK: good comment,
perhaps the ICN community has a bit of DTN background and more can be learned.
There has been some work on running ICN over DTN. Steven Farrow had a draft on
this.

Chairs: quite a bit of interest in this work. Question to Prakash: do you have
work in the pipeline for a new version? Also from today's feedback? A: yes, lot
of additional input to work on, plus what DaveO send to us. If it's a working
draft, we'll have more consideration. DT/Chair: provide an updated version, and
we'll have an adoption discussion on the mailing list. BO/Chair: ask the room
and provide a round of comment, do we have volunteers? Dirk Trossen, Ravi,
Greg, Ankbar. Thanks! Also ask your colleagues on the mobile side.

-------------------------------------------------------------------------------
* Akbar Rahman (InterDigital) Deployment Considerations for ICN (+Dirk Trossen,
Dirk Kutscher, Ravi Ravindran)

2nd revision of the draft.
ICNRG charter identifies deployment guidelines as an important topic;
specifically, defining concrete migration paths for ICN deployments which avoid
forklift upgrades and define practical ICN internetworking.

Revision history: rev0 in Chicago, good feedback; rev1: addressed feedback;
rev2: addressed detailed comments from Dave Oran

Main changes: title changed from "configurations" to "considerations"; rework
definitions to refer to existing RFCs and ICN-terminology draft; added more
details on ICN-in-a-slice; all deployment trials grouped under "overlay" and
"underlay"; added ICN2020 trial summary; generalized ICN gaps to potential
protocol effort only; removed references to IETF WGs/BoFs; expanded conclusion
to cover points from all sections; added Security considerations (key
deployment related point from RFC7945) as well as new issues (end-to-end
context for security); added more references; editorial changes...

Q: Thomas Schmidt (UHamburg) What I'm missing is the activities of ICN over
wireless, and in particular over lossy low-power networks. There has been work,
we have done some, to experiment and deploy ICN on wireless and in particular
on low-power constraint nodes. Can you add something about it? A: this would
fit in Section 5, deployment trial experiences. I'll talk to you, find the
references and I'll take an action to that. Dirt Trossen (as a co-author): I
actually suggested the reference too late. But it will be significantly
expanded in v03.

Application migration: new applications enabled by ICN? CDN is a key use case
to redeploy. Good candidate for ICN deployment. What are the issues for
edge/core network deployments.

Q: Eve Schooler (Intel): I was curious, you say your trial that range from a
few to a couple hundreds nodes. Do you know of trials that have larger
deployments? A: in the corpus, we didn't see anything in the 10,000s. The
largest was in the low 1,000s. Q: ES - is that enough to understand the gaps?
More a question to the larger community. A: the problem has been looked at from
many different angles; some protocols have been tested and are RFCs.
Comment (DT): scale is obviously an issue; limiting factor in Amazon cloud is
budget but could scale to 10,000. Engineering factors. Remark on excluding
simulations, and we have one reference on socio-economic studies; this one is
looking at large-scale migration, considering a dual-stack deployment. This is
not a deployment, but a deployment-oriented study. I could not find the NDN
study on the same topic.

Lixia: our work has not so much of a transition; we believe the most advantage
of a new architecture can be explored by taking new apps that fully take
advantage of it. I'm not confident that transition architecture will deliver
most of the advantages of ICN. Lixia: regarding the previous presentation,
having transport selector on top of ICN would lead to a long discussion.

A: application is a key area to look at. If apps are ICN-enabled, it should be
considered.

Lixia: existing apps can benefit greatly from ICN; but given that they work on
top of, and are designed for point-to-point address based delivery model. My
personal view is that they would not fully benefit from ICN. DK: research
group, we should investigate more both ICN-only and transitions. Not exclusive.

BO: I'll give you a NetInf pointer regarding IoT/COAP extensions to NetInf.

Deployment configs:
1- wholesale replacement (clean slate); IP infrastructure is replaced
2- ICN-as-an-Overlay (tunneling approach): ICN-over-UDP, name mapping, etc
3- ICN-as-an-underlay. Support ICN infrastructure islands (at the edge or
core); protocol mapping at ingress/egress Network Attachment Points (NAPs);
allows backward-compatible introduction of ICN infra while reaping ICN benefits
of multicast delivery, fast indirection, etc. 4- ICN-as-a-Slice. With
introduction of 5G network slicing, deploy ICN there (Ravi suggested this)

Lixia Zhang (UCLA): the point I care most is not there: native ICN running
directly on top of wireless, with apps directly on top of ICN. ICN-WEN program,
most interesting deployment; fully utilize wireless heterogenous technology

Dirk Trossen: I respectfully disagree. Draft has ICN at the edge, it's in the
draft. Service migration is considered as well. You have to read the draft
multi-dimensionally. IoT scenario fits in migration and deployment at the edge.

Dave Oran: one of the teams working on the WEN project is explicitly looking at
running ICN over a slice in 5G. So one of the ICN-WEN is explicitly in this.
You can contribute to the draft. Ravi Ravindran (huawei): I don't think you are
missing anything. If you listened on the talk yesterday on 5G from the 3GP
folk, it's the most flexible architecture. It's an opportunity that we see to
deploy ICN.

Lixia: saying that ICN can run on wireless is not the picture. It's a new way
of trying things out; native ICN wireless. If you segment the picture (ICN on
wireless and on the other side, something else), that's a different picture. I
want to reply to Ravi: I understand 5G has its own picture. From my angle, 5G
is nothing but one of the wireless. You could use 5G/bluetooth and WiFi
simultaneously, and that's a different picture.

Next steps: potential to do another ref on this;

BO: same as previous document: continue to comment.
DO: let's get more comments, rather than issuing another version of the draft
now. BO: we agree, get more comments now, then do a new rev. DO: let's get more
comments, ball is in your court

Jan Seedorf (Stuttgart): does the research group think we should publish this?
I believe we want this, this is useful to put out. I cannot comment on the
maturity of the text. But the primary issue is: does the group want this to be
worked on. I support moving this ahead and eventually adopted it.

BO: how many people think it's valuable. [lots of hands raised...] Yes, the
group thinks it's of interest. BO: Do we have volunteers to review? Prakash
volunteer to review, Haru (?) as well.

Dave Oran - After the 2 volunteers review the current -02 revision, the authors
should update it quickly to -03.  The -03 will then go for WG adoption call on
email list.  The authors can feel free to contact the Chairs to push the
volunteer reviewers if there is too much delay.

------------------------------------------------------------------------------
Jan Seedforf (Stuttgart): Research Directions for Using ICN Disaster Scenarios.
(+ M. Arumaithurai, A. Tagami, KK Ramakrishnan, N. Blefari Melazzi)

Taking into account Akbar's comments mostly. Akbar, feel free to chime in.
First comment: change in the name to add a research perspective.

Scope of document: scenario and use cases.
History: multiple initial versions (2013-16), output of GreenICN project.
Various feedback incorporated (how ICN relates to existing DTN...); adopted as
RG item in February 2016.

Comments/diffs:
Mention existing disaster services in mobile networks; there is already some
support that has to be mentioned. Mention some services work without
authentication (say, emergency calls). List of ICN benefits is not exhaustive.
Or is it? We should not wait until we have all possible benefits to move this
document forward; list closed now.. Voice calls after disaster: how does this
fit in ICN? We think that voice calls are not possible and that messages should
be DTN/not real time/disconnected network.

Akbar: I agree with how you handled my comments
Dirk Trossen: shouldn't be one of the advantages of ICN to have the choice
between real time or non-real time? A: maybe I can add text to say this. We can
do VoICN in certain cases, but we considered the case where it's not. DT: what
matter is availability of content, so if the user is reachable, it should be a
choice.

Comment:
is there existing work for ICN data mules? mentioned some.
if further work needed? -> yes!
how does this relate to IETF standardization?

Objectives: informational RFC. Explain why ICN is a good starting point for
addressing communication challenges after a disaster; concrete example of
existing work in the ICN research community;

DK: chairs are inclined to last-call this pretty soon.
DO: we could last-call this one and include today's comment as a last-call
comment.

DK: nit comment. You use the acronym WG, it should be RG.

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

* Cenk Gundogan (HAW Hamburg) Pub/Sub deployment option for the constrained IoT
(+Thomas Schmidt, Matthias Waehlisch)

Scenario: IoT Sensor and Actuator Networks. Sensors produce data, immediate
data propagation, alert notification. Naive approach in NDN/CCN: polling; wakes
sleepy devices, superfluous traffic. Polling unfeasible in large scale
deployments.

Problem: data propagation. Push is bad. Breaks flow balance; cache poisoning,
DoS. We should preserve the NDN/CCN request/response channel.

Publish/Subscribe option: data immediately propagated towards content proxy;
data is NOT PUSHED; name advertisements on control plane; data is replicated
hop-wise on data plane.

Built/Maintain Routing topology using Prefix Advertisement Message (broadcast,
link-local scoped) and NAM (Name Advertisement Message)

DaveO: clarifying question, as maybe others didn't misunderstand as badly as I
did. In most designs, the control plane is running on top; you are running the
control plane on top of layer n-1 in parallel with the request/response
paradigm of the regular ICN data plane? Is that the correct understanding? A:
yes DaveO: then people would be confused that you call this a control plane.

Thomas: NAM is not an interest message, it's not a data message
DaveO: this is fine, but that does not make it a control plane.
Thomas: I would consider this a classic control plane.
Cenk: objective was to not overload the semantic of the interest

Ravi: one entry in the FIB prefix?
Cenk: there is a default FIB entry with the upstream router?
Ravi: you may have more entries for the different names
Thomas: you have one FIB entry per prefix; if you have different name spaces,
you have different entries in the FIB. But all name that have a common prefix
clearly aggregate to this content prefix. So per prefix, one entry in the FIB.

Publish: hop-wise propagation of data to the Content Proxy (CP)

DaveO: why did you discard the idea of interest/interest/data exchange? In
other word, the publisher sends an interest to the CP; the CP then issues an
interest to the publisher. it seems your hop-by-hop scheme reintroduces all the
push problems, but just localized at the edge. A bad sensor can flood the
network Thomas: a bad sensor can always flood the wireless on a local link.
DaveO: we already have to build some congestion control tools for interest;
with your proposal, you have to add another layer for the hop-by-hop mechanism.

Advantages:
Publisher Mobility: Publish = NAM -> interest -> data
Network partitioning.

Ravi: I thought publish was a control plane action. You are actually pushing
data? Cenk: in response of receive the signaling, we request the name.
Ravi: it's still a trigger. Thomas: it's probably easier. no new attack vector
on the network layer .

Experimentation using RIoT and CCN-lite. 300 constrained devices.

Ravi: publisher mobility depends on the CP staying the same;
Thomas: if you move the GW or the border route, you are moving the whole
network.
-----------------------------------------------

* Ravi Ravindran (Huawei) Support for Notifications in CCN

Draft history: v0 IETF95; IETF96: more discussion around flow and congestion
control; current version attempts to respond to why current Interest/Data
abstractions fail.

Motivation for PUSH in CCN: upstream heavy traffic, with inter-arrival
distributed over mins to days.

CCN Push requirements: PUSH intent support, multicast support, security,
routing and forwarding support, minimizing processing.

Four approaches in this draft: using interest/data abstraction for push.
1- Long lived interests;2 polling;3 overloading interests;4 interest trigger
Draft offers design choices for all.
+ description of all four approaches.

Thoughts? Comments?

DK: what is your plan with this draft?
A: flow balancing is not enough, you need other mechanisms for congestion
control. ChronoSync does not cover the case of mission critical. People are not
happy with having only one mechanism for all their requirements.

Thomas: I agree with most of what you say in the presentation. But it does not
fit the title of the draft. The title should be "problem statement and brief
survey" A: yes, it was proposed as an extension to the CCNx protocol, then it
took a more research direction. I can change the title to reflect the scope.
There is a significant sized community looking at this issue.

DK: most agree that asynchronous notification is an interesting topic. It would
be good to keep working on this. Keep it as a living document as more people
are working on this field. I A: sure. I haven't read Cenk's draft either, so
will include this.

-----------------------------------------------------------------------------------
* ICN based Architecture for IoT (Ravi Ravindran, Huawei)

ICN-IoT system architecture: added authentication manager, a key component for
on-boarding and validating their ES IDs at a system level.

Thomas (HAW): can you relate the entities in the draft to the 6lopan
architecture? Ravi: it's a border router.

Lixia: there was a bar BOF on Monday. Experience shows that naming is
fundamental. I don't see this discussed here. Where is your name architecture?
Ravi: we have a local ID. Lixia: I'm talking about your name space
architecture. Name space structure. Ravi: you want to give a name to a producer
Lixia: what is your name structure that ties together identity, security?
Ravi: the draft discusses this with NDN and MobilityFirst BO: what Lixia is
looking for is in the design consideration document Lixia: I'm asking about
name space structure, I don't see this in the draft. Maybe we can take this
offline. Ravi: Figure 2 is just an architecture, there is no specific names
associated with this. Lixia: if people talk about Information-Centric, it's
that we care about information instead of location. The fundamental challenge
is how you name the information. BO: Lixia, can you provide a presentation at
the next ICNRG meeting. Lixia: I owe this group of presentations. The
discussion on Pull/Push, it's an architecture decision, it's not an
application. You can list me, I'm always working for deadlines. Muhammad
Akhbar: naming ??? Ravi: when we talk about name, how you map name to location
is name resolution. Here we focus on giving name to service, content and
devices, and then you can place on any transport. DaveO (chair hat off): I
think it's 3 years too early to talk about ICN IoT architecture. We need a lot
more work on many pieces before we can do a systems architecture. It presumes
that we know a lot about how the pieces work. Lixia: I strongly second DaveO.
Build a system first. Ravi: this is very typical architecture in any IoT
system. Lixia: paper design is one thing, build a system. Ravi: come to our lab
and see the system we build DK: is it fair to say that this document does not
reflect the system that you build? Ravi: it's true that it's high level. There
are basic functions that ICN provide that are ICN functions. You have to build
basic middleware functions to make IoT system self-configurable, scale, and to
do large scale Emmanuel Bacceli (INRIA): what are the aggregators on Fig2?
Ravi: they are the unconstrained nodes to which the sensors talk to. They are
called proxy. EB: There are some function of the GW? Ravi: I separated the GW
Thomas: question, what do the arrow mean on Fig2? The aggregators are border
routers, or are they outside? Ravi: the aggregators are the roots. Thomas: if
the arrows are communication, the aggregator would talk to the others?
Ravi: Embedded Systems can talk to each other and aggregators. Aggregators can
talk to other aggregators and ES to get the data.

BO: show of hands for this? Only a few hands. We need more input.
------------------------------------------------------------
BO: show of hand on IoT Design Consideration.
BO: that's also only a few hands. We need more people to look into this.

Eve Schooler: I have volunteered last time for the comments on the draft , I
will send my comments. Eve Schooler: I think overarching IoT architecture. I
wonder if other architectures are discussed in other IRTF/IETF, there needs to
be coordination there.

DK: IoT and ICN is an important topic. If you are doing some work, please feel
free to tell people about it, just give a presentation about experiment, it
doesn't have to be a 100 pages draft. We're interested in having discussion and
learning things.

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

* Wrap-up (Chairs)

- Upcoming ICN events: ACM ICN conference, September 26-28, Berlin; RiOT event
as well; ICNRG Interim meeting, September 29th 2017, Berlin. Future ICNRG
meetings.

- We are planning on meeting in Singapore. Week-end Sunday meeting would depend
on contributions, topics of discussion

- IEEE Com Mag feature topic on ICN security. Manuscript submission deadline:
November 1, 2018.