Minutes IETF98: icnrg
||Minutes IETF98: icnrg
9:00 Meeting starts
Welcome, Agenda Bashing, Minutes taker, Bluesheets, Status - Chairs (10 min)
ICNRG interim meetings - Sunday
- Luca presented updates from cisco about CICN,
- Lixia reported on NDN community meting
- Glass-to-glass video distribution
- transport API ideas
- current status of terminology document; Progressed this week, expect update
ICN Harmonization update
Discussions this week with people from the different groups, support on all
sides to resume harmonization effort
Good time to resume harmonization effort. Kicked off last year. First task to
understand differences between 2 main designs: NDN and CCNx 1.x. Discuss
regularly, what different, why different. A little bit of a slow-down at end
of year, but will pick up again. Plan weekly call to follow up; everybody
enthusiastic to go further.
Goal - finalize differences document before IETF-99
- ICN conference in Berlin. Deadline May 1 (register), May 8 (paper). Two
tracks (short/long). + RIOT Summit adjacent to conference.
Soon: INFOCOM NOM workshop (Atlanta), ICME MuSIC workshop in July
Status of CCNx Drafts
NSF/Intel proposal call ICN WEN on ICN and IoT - Eve Schooler (20 min)
- Intel backstory: ICN for IoT // debate on how to deploy ICN on the broader
Internet. Edges side step this issue. - ICN centers not on sending
measurement, but on computer function / analytics. - Intel looking for use-case
requirement / to drive. - Some work uses CCNx (early), NDN (later work).
Proof-of-concept released by .... - NSF/Intel set aside 6.5M for 2-3 project to
award. Focus on wireless edge network, low latency apps, massive deployments.
- ICN for 5G+ - Intel interested to evaluate ICN potential for industry
solutions, 5G+, ultra-low latency and massive IoT and enabling edge/fog
Ravi; when you see ICN, do you see CCN or NDN, or others?
Eve: we are agnostic, we are not looking for any particular brand
Ravi: you said 5G+, you mean more the radio access networks? Or something else?
Ravi; any focus on specific application scenarios?
Eve; no a bit open, based on use cases
Hannu (Nokia); how do you move processing with the data?
Eve: billion of devices / dense / sensors /logical entities. As things
encounter, they may not know how to comm. they may need to download
app/executables. May be through virtualization, etc. First step: how to talk
to things you encounter. Experiment with analytics libraries that we make
available as service.
(?) Vedicker: how far is "this" is for deployment? How usable?
Eve: important for open source / publicly available of software, so
experimentation can happen now. In edge you don't need to wait for the whole
Internet. (?) Vedicker: ultra low latency // IoT at the moment has significant
latency. Eve: ramp up academic projects (?) Vedicker: virtual overlay network
for a while. we don't have a high latency iot looking for pervasive wireless
solutions. I'm grappling with 3 years... (?) Vedicker: Is organization that
owns? Eve: Partnership NSF/Intel
Brief Description of DARPA SHARE program - Dave Oran (5 mins)
- Goal: secure handhelds on assured resilient networks at the tactical Edge
- Interesting topics for ICNRG; multi-level secure group keying, differentiated
service, strong DTN properties, mobility across both mesh tactical radios and
COTS LTE-style radios
Dirk: There is also EU .. 2020. closing april 25.
ICN in the IoT on RIOT: CCNlite & Pub-Sub - Thomas C. Schmidt (15 min)
- Looking at Constrained systems, communication and naming
- Added new features to CCN-Lite and Riot, e.g. LoWPAN,
Multi-Transceiver/Multi-Stack support - How to publish data efficiently without
continued node presence and huge FIBs? New draft on pub/sub:
Jan: in EU greenICN project, published a couple of papers on publish subscibe
in ICN. E.g. COPS ??: Question about opportunities. listed 4 properties.
which most important property T: depends on perspective. Most important: don't
need end-to-end involvement to disseminate / nodes are not online / still want
access. For secure apps, secure is most important. ??: these concepts can also
be achieved by other technologies, right? Thomas: yes, but it also depends on
NDN on RIOT - Alex Afanasyev (10 min)
- One of the goals; Enable flexible experimentation with NDN IoT apps using
Dave: this is a really good situation, in the process of figuring out the pro's
and con's of different architectures it is really good to have both of these
stacks running on IoT devices.
Update on the ICN in disaster scenarios draft - Jan Seedorf (15 min)
If you have a paper describing on how ICN is beneficial in these disaster
scenarios, authors are open for contributions.
Dirk: chair-hat off. With these kind of documents we do not say ICN shines, but
state open challenges. Dirk: we need more people looking at this draft,
volunteers?. => Eve Schooler, ??, ??
New draft on “Deployment Configurations for ICN” - Akbar Rahman (15 min)
One point need extra input for RG: charter item for concrete path for
deployment of ICN. But not much progress on this topic.
In draft: guidelines for operator, for someone looking to deploy network.
identify areas that need for standardization.
Looking at what guidance for deployment / define what deployment meant. Take
ICN, integrate whole internet
- wholesale replacement (clean slate)
- ICN as an overlay (ICN over UDP, names mapped to IPv6 addresses, convergence
layer to map ICN semantics to HTTP) - ICN as an underlay (infrastructure
islands to integrate IP through Network Attachment points, NAPs; backward
compatible introduction) - ICN as a slice (using new concept of network
slicing, ICN as virtual functions of service chain)
- app & service
- content delivery
Soliciting feedback from RG on any other public ICN trials/experiments that we
can reference, especially CCN(x).
- edge network
- core network
Summary/Light survey of trials, published results. (Not focused on simulations.)
- ICN as Overlay (PURSUIT, SAIL, NDN Testbed)
- ICN as an underlay (... Copelabs CDN)
Ideas for standardization:
- what to do with REST APIs
- (4 more listed on slides)
- ICN mapping: map bw HTTP and ICN message exchanges + all parameters.
- need CCNx 1.x examples
- draft is useful, need feedback
Hannu (nokia): are you proposing // ICN work to split among 6 WG out of 6/5 WGs
are new and require BOF. Not realistic Akbar: This is one way to address
standardization. What is realistic?
Hannu(nokia): a lot of open issues. Still trying to harmonize. Now you're
proposing split even more. No way we can consolidate .. At this point of time
realistic approach to stay in a single place Akbar: If it is single place,
should be IETF. ICNRG going to do experimental draft. If influence protocol,
have to be in IETF. Single BOF, big effort, etc. Not today
Hannu (nokia) For strong industry impact, have to be IETF. From what we see,
ICN is not for prime time, not ready for WG.
Ravi: One section .. name-based routing. One section .. section for privacy
discussion. How to scale it. Akbar: Agree
Prakash (Cisco): Good document. Trying to encompass whole ICN, many areas to
cover. More context to document.. 2nd point: ICN as a slice -- iCN not
creating is slice. Slice created to support ICN. Slice capable of ICN. 3rd:
Ravi: One section should address privacy discussion, e.g. advertising name
context into the network. How do you scale this thing?
Prakash: good document. Scope of the document too broad I think.
Dave: chair hat off:
1. document doing 2 things, identifying gaps in protocols and barriers to
deployments. Second is how to structure the gaps to fill to enable deployment,
but needs new research. Maybe split the work. 2. one of the things missing, how
do you want to use ICN to deploy ICN. Now we use all these IP tools to setup
ICN networks. So should think about how to bootstrap ICN natively. 3. your HTTP
mapping point, I am co-author of published paper on that. (Ilya Moiseenko, Mark
Stapp, David Oran, “Communication Patterns for Web Interaction in Named Data
Networking,” DOI: 10.1145/2660129.2660152 Conference: ACM Conference on
Information-Centric Networking, Paris, France, 2014 )
Alex: one thing that is missing is about security. In ICN fundamental thing.
How to do that especially for these deployment, huge thing. Should be somewhere
in a document.
Requirements and Challenges for IoT over ICN - Ravi Ravindran (15 min)
- Recap of draft history
- A lot of changes in draft, highlight of changes.
- Next steps: further improve comments; hope to adopt as RG document to solicit
more comments & get help from community to improve draft
Borje: Who has read the draft (not that many). Should do it! ICN become one
of the important research topic / need to collect basic issues, capabilities of
these combinations. If people better ideas they are welcome. Really like more
comments on this draft, on mailing list to move forward. Any volunteer (Eve,
Borje: There was thing-to-thing discussion. They will write up, can be taken as
inspiration. Missing - when have large amount of data that large beyond
putting cloud. Ravi: we have challenges in section 3, partly covers this but
should add more
Contrace: Traceroute Facility for Content-Centric Network - Hitoshi Asaeda (10
Today discuss security, as last time overview was given of protocol and
architecture. - Recap of the proposed protocol; New request message, new reply
message. - Security consideration > policy based; routers can prohibit
reply. > permission: all, partial, deny > topology discovery >
characteristics of content > reply timeout > request rates > adjacency
Drafts don't define specific security mechanisms. Can be mentioned in separate
Dirk: you said really useful, software available?
Hitoshi: Yes, in near future
Alex: what is relation with Cisco work?
Hitoshi: ICNtrace is more on FIB, this works both on FIB and CS
Alex: could Dave comment on the ICN-ping draft?
Dave: We have the ICN-ping drafts, but no one to present
Spyros Mastorakis ("out of band" comment): Could IETF/IRTF provide some funding
for students that have IDs to attend the meetings? The reason that nobody is
there to present ping and traceroute is funding. A Phd student cannot afford to
pay for airfare and lodging out of his own pocket.... Alex: why needs it to be
a separate message. Why not application on each forwarder? Hitoshi: This is
specific demo, so this a specific implementation. Alex: this is part of
interest and data message, why new type? Each app new Hitoshi: special type of
message, otherwise stuff gets aggregated Alex: you now only mention the
security issues, but not address them.
huwaii??: looks more like ping or traceroute than inband telemetry.
Hitoshi: following traditional traceroute
Huawii: interested in in-band?
DaveO: chair hat off,
1. one of the reasons for separate type of packet is because of interest
aggregation. The right way to do that is separate indication in interest
message, e.g. nonce. Important to see more justification. 2. a lot of
commonality between this and icn-traceroute draft
(draft-mastorakis-icnrg-icntraceroute-01). Nice to see like an overview of the
commonalities and differences
DaveO: chair hat on; this is part of getting the management instrumentation of
ICN going. Important area, so would be good to look into the inband measurement
Challenges in Networking to Support Augmented Reality and Virtual Reality -
Cedric Westphal (15 min)
- Overview, use cases of AR/VR requirements; Network impact (bandwidth, delay
- ICN - network architecture that exposes semantics to network layer, native
mcast, content distribution, edge caching and edge functions - Overview of
Dirk: big interest. Do you want a draft on this
Cedrick: yes, porting paper into draft.
Deploying Information Centric Networking in LTE Mobile Networks - Prakash
Suthar (5 min) https://datatracker.ietf.org/doc/draft-suthar-icnrg-icn-lte-4g/
Out of time :(
During Prague meeting organizing full Sunday interim and regular meeting during
Also interim in conjunction with ACM ICM in Berlin.